El nuevo arranque Linux funcionará en el futuro con un enfoque en la robustez y la simplicidad.

Lennart Poettering (el creador de Systemd) dio a conocer hace poco una propuesta para modernizar el proceso de arranque de las distribuciones de Linux, con el objetivo de resolver los problemas existentes y simplificar la organización de un arranque verificado completo, confirmando la autenticidad del kernel y el entorno del sistema subyacente.

Los cambios propuestos se reducen a la creación de una única imagen universal UKI (Unified Kernel Image) que combina la imagen del kernel de Linux, el controlador para cargar el kernel desde UEFI (UEFI boot stub) y el entorno del sistema initrd cargado en memoria, utilizado para inicialización inicial en la etapa antes de montar el FS.

En lugar de una imagen de disco RAM initrd, todo el sistema se puede empaquetar en el UKI, lo que permite la creación de entornos de sistema totalmente verificados que se cargan en la RAM. La imagen UKI se empaqueta como un archivo ejecutable en formato PE, que no solo se puede cargar con los cargadores de arranque tradicionales, sino que también se puede llamar directamente desde el firmware UEFI.

La capacidad de llamar desde UEFI permite usar una verificación de validez e integridad de firma digital que cubre no solo el kernel, sino también el contenido del initrd. Al mismo tiempo, la compatibilidad con las llamadas desde los cargadores de arranque tradicionales permite guardar funciones como la entrega de varias versiones del kernel y la reversión automática a un kernel en funcionamiento en caso de que se detecten problemas con el nuevo kernel después de instalar la actualización.

Actualmente, la mayoría de las distribuciones de Linux utilizan la cadena «firmware → capa shim de Microsoft firmada digitalmente → cargador de arranque GRUB de distribución firmado digitalmente → kernel de Linux de distribución firmado digitalmente → entorno initrd sin firmar → FS root» en el proceso de inicialización. La falta de verificación initrd en las distribuciones tradicionales crea problemas de seguridad, ya que, entre otras cosas, este entorno extrae claves para descifrar el FS root.

No se admite la verificación de la imagen initrd, ya que este archivo se genera en el sistema local del usuario y no puede ser certificado por la firma digital de la distribución, lo que complica mucho la organización de la verificación cuando se utiliza el modo SecureBoot (para verificar el initrd, el usuario necesita para generar sus claves y cargarlas en el firmware UEFI).

Además, la organización de arranque existente no permite usar información de los registros TPM PCR (Registro de configuración de plataforma) para controlar la integridad de los componentes del espacio de usuario que no sean shim, grub y kernel. Entre los problemas existentes, también se menciona la complicación de actualizar el gestor de arranque y la imposibilidad de restringir el acceso a claves en TPM para versiones anteriores del sistema operativo que se han vuelto irrelevantes después de instalar la actualización.

Los principales objetivos de implementar la nueva arquitectura de arranque:

• Proporcionar un proceso de descarga completamente verificado, que cubra todas las etapas, desde el firmware hasta el espacio del usuario, y que confirme la validez e integridad de los componentes descargados.
• Vinculación de recursos controlados a registros TPM PCR con separación por propietarios.
• Capacidad para precalcular los valores de PCR en función del arranque del kernel, initrd, configuración e ID del sistema local.
• Protección contra ataques de reversión asociados con la reversión a la versión vulnerable anterior del sistema.
• Simplifique y mejore la confiabilidad de las actualizaciones.
• Compatibilidad con actualizaciones del sistema operativo que no requieren volver a aplicar o aprovisionar recursos protegidos por TPM localmente.
• Preparación del sistema para la certificación remota para confirmar la corrección del sistema operativo y la configuración de arranque.
• La capacidad de adjuntar datos confidenciales a ciertas etapas de arranque, por ejemplo, extrayendo claves de cifrado para el FS root del TPM.
• Proporcione un proceso seguro, automático y silencioso para desbloquear claves para descifrar una unidad con una partición root.
• El uso de chips que admiten la especificación TPM 2.0, con la capacidad de recurrir a sistemas sin TPM.

Los cambios necesarios para implementar la nueva arquitectura ya están incluidos en el código base de systemd y afectan a componentes como systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase y systemd-creds.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.