systemd 252 llega con el soporte de UKI, mejoras y mas

systemd es un conjunto de demonios o daemons de administración de sistema, bibliotecas y herramientas diseñados como una plataforma de administración y configuración central para interactuar con el núcleo del sistema 

Después de cinco meses de desarrollo se dio a conocer el lanzamiento de la nueva versión de systemd 252, versión en la cual el cambio clave en la nueva versión fue la integración de soporte para un proceso de arranque modernizado, que permite verificar no solo el kernel y el gestor de arranque, sino también los componentes del entorno del sistema subyacente mediante firmas digitales.

El método propuesto implica el uso de una imagen de kernel unificada UKI (Imagen de kernel unificada) al cargar, que combina un controlador para cargar el kernel desde UEFI (stub de arranque UEFI), una imagen de kernel de Linux y el entorno del sistema initrd cargado en memoria, utilizado para la inicialización inicial en la etapa anterior al montaje del FS root.

Artículo relacionado:

Proponen modernizar el proceso de arranque de Linux

En particular, las utilidades systemd-cryptsetup, systemd-cryptenroll y systemd-creds se han adaptado para usar esta información, con lo que puede asegurarse de que las particiones de disco encriptadas estén vinculadas a un kernel firmado digitalmente (en este caso, el acceso a la partición encriptada se proporciona solo si la imagen UKI ha pasado la verificación por firma digital basada en los parámetros colocados en el TPM).

Además, se incluye la utilidad systemd-pcrphase, que le permite controlar el enlace de varias etapas de arranque a los parámetros colocados en la memoria de los criptoprocesadores que admiten la especificación TPM 2.0 (por ejemplo, puede hacer que la clave de descifrado de partición LUKS2 esté disponible solo en la imagen initrd y bloquear el acceso a ella en descargas posteriores).

Principales novedades de systemd 252

Otros de los cambios que se destacan en systemd 252, es que se aseguró de que la configuración regional predeterminada sea C.UTF-8 si no se especifica otra configuración regional en la configuración.

Ademas de ello en systemd 252 tambien se implementó la capacidad de realizar una operación de preajuste de servicio completo («systemctl preset») durante el primer arranque. El habilitar ajustes preestablecidos en el momento del arranque requiere una compilación con la opción «-Dfirst-boot-full-preset», pero está previsto que se habilite de forma predeterminada en versiones futuras.

En las unidades de administración de usuarios usan el controlador de recursos de la CPU, lo que hizo posible garantizar que la configuración de CPUWeight se aplique a todas las unidades de segmento utilizadas para particionar el sistema en partes (app.slice, background.slice, session.slice) para aislar recursos entre diferentes servicios de usuario, compitiendo por los recursos de la CPU. CPUWeight también admite un valor «inactivo» para activar el modo de concesión adecuado.

Por otra parte, en el proceso de inicialización (PID 1), se agregó la capacidad de importar credenciales desde campos SMBIOS (Tipo 11, «cadenas de proveedores OEM») además de definirlas a través de qemu_fwcfg, lo que simplifica la provisión de credenciales a máquinas virtuales y elimina la necesidad de herramientas de terceros como cloud -init e ignición.

Durante el apagado, la lógica para desmontar los sistemas de archivos virtuales (proc, sys) se cambió y la información sobre los procesos que bloquean el desmontaje de los sistemas de archivos se guarda en el registro.

El cargador de arranque sd ha agregado la capacidad de arrancar en modo mixto, en el que se ejecuta un kernel de Linux de 64 bits desde un firmware UEFI de 32 bits. Se agregó la capacidad experimental para aplicar automáticamente las claves SecureBoot de los archivos que se encuentran en ESP (partición del sistema EFI).

Se agregaron nuevas opciones a la utilidad bootctl «–all-architectures» para instalar binarios para todas las arquitecturas EFI admitidas, «–root=» y «–image=» para trabajar con un directorio o imagen de disco, «–install- source =» para definir la fuente a instalar, «–efi-boot-option-description=» para controlar los nombres de las entradas de arranque.

De los demás cambios que se destacan de systemd 252:

• systemd-nspawn permite el uso de rutas de archivo relativas en las opciones «–bind=» y «–overlay=». Se agregó soporte para la opción ‘rootidmap’ a la opción «–bind=» para vincular la ID de usuario raíz en el contenedor al propietario del directorio montado en el lado del host.
• systemd-resolved usa el paquete OpenSSL como el backend de cifrado de forma predeterminada (la compatibilidad con gnutls se conserva como opción). Los algoritmos DNSSEC no admitidos ahora se tratan como inseguros en lugar de devolver un error (SERVFAIL).
• systemd-sysusers, systemd-tmpfiles y systemd-sysctl implementan la capacidad de pasar la configuración a través del mecanismo de almacenamiento de credenciales.
• Se agregó el comando ‘comparar versiones’ a systemd-analyze para comparar cadenas con números de versión (similar a ‘rpmdev-vercmp’ y ‘dpkg –compare-versions’).
• Se agregó la capacidad de filtrar unidades por máscara al comando ‘systemd-analyze dump’.
• Al elegir un modo de suspensión de varias etapas (suspender y luego hibernar, hibernación tras hibernación), el tiempo que pasa en el modo de espera ahora se selecciona según el pronóstico de la vida útil restante de la batería.
• Se realiza una transición instantánea al modo de suspensión cuando hay menos del 5% de la carga de la batería.

Tambien vale la pena mencionar que en 2024, systemd planea dejar de admitir el mecanismo de limitación de recursos de cgroup v1, obsoleto en la versión 248 de systemd. Se recomienda a los administradores que se encarguen de mover los servicios vinculados a cgroup v1 a cgroup v2 con anticipación.

La diferencia clave entre cgroups v2 y v1 es el uso de una jerarquía de cgroups común para todos los tipos de recursos, en lugar de jerarquías separadas para la asignación de recursos de CPU, administración de memoria y E/S. Las jerarquías separadas generan dificultades en la organización de la interacción entre los controladores y costos adicionales de los recursos del kernel al aplicar reglas para un proceso mencionado en diferentes jerarquías.

En la segunda mitad de 2023, está previsto dejar de admitir jerarquías de directorios divididos, cuando /usr se monte por separado de la raíz, o los directorios /bin y /usr/bin, /lib y /usr/lib estén separados.