systemd 252 arrive avec le support UKI, des améliorations et plus encore

systemd est un ensemble de démons, de bibliothèques et d'outils d'administration système conçus comme une plate-forme centrale de configuration et d'administration pour l'interface avec le noyau du système. 

Après cinq mois de développement la sortie de la nouvelle version de systemd 252 a été annoncée, version dans laquelle le changement clé dans la nouvelle version a été l'intégration de soutien un processus de démarrage modernisé, qui permet de vérifier non seulement le noyau et le chargeur de démarrage, mais également les composants de l'environnement système sous-jacent à l'aide de signatures numériques.

La méthode proposée implique l'utilisation d'une image de noyau unifiée UKI (Image du noyau unifiée) au chargement, qui combine un pilote pour charger le noyau à partir de l'UEFI (stub de démarrage UEFI), une image du noyau Linux et l'environnement système initrd chargé en mémoire, utilisé pour l'initialisation initiale à l'étape précédente du montage racine FS .

Article connexe:

Ils proposent de moderniser le processus de démarrage de Linux

En particulier, les avantages systemd-cryptsetup, systemd-cryptenroll et systemd-creds ont été adaptés d'utiliser ces informations, afin que vous puissiez vous assurer que les partitions de disque chiffrées sont liées à un noyau signé numériquement (dans ce cas, l'accès à la partition chiffrée n'est fourni que si l'image UKI a réussi la vérification basée sur la signature numérique). dans le TPM).

De plus, l'utilitaire systemd-pcrphase est inclus, ce qui vous permet de contrôler la liaison des différentes étapes de démarrage aux paramètres placés en mémoire par les cryptoprocesseurs prenant en charge la spécification TPM 2.0 (par exemple, vous pouvez rendre la clé de déchiffrement de partition LUKS2 disponible uniquement dans l'image initrd et en bloquer l'accès lors des téléchargements suivants).

Principales nouveautés de systemd 252

D'autres changements qui se démarquent dans systemd 252, c'est que sNous nous sommes assurés que la locale par défaut est C.UTF-8 si aucune autre locale n'est spécifiée dans la configuration.

En plus de cela dans systemd 252 également implémenté la possibilité d'effectuer une opération prédéfinie de service complet ("systemctl preset") lors du premier démarrage. L'activation des préréglages au démarrage nécessite une construction avec l'option "-Dfirst-boot-full-preset", mais il est prévu de l'activer par défaut dans les futures versions.

Dans les unités de gestion des utilisateurs, utilisez le contrôleur de ressources CPU, ce qui a permis de garantir que le paramètre CPUWeight est appliqué à toutes les unités de tranche utilisées pour partitionner le système en tranches (app.slice, background.slice, session.slice) pour isoler les ressources entre différents services utilisateur, en concurrence pour les ressources CPU. CPUWeight prend également en charge une valeur "idle" pour déclencher le mode de location approprié.

D'autre part, dans le processus d'initialisation (PID 1), ajout de la possibilité d'importer des informations d'identification à partir des champs SMBIOS (Type 11, "chaînes de fournisseurs OEM") ainsi que de les définir via qemu_fwcfg, ce qui simplifie l'approvisionnement des informations d'identification des machines virtuelles et élimine le besoin d'outils tiers tels que cloud -init et allumage.

Lors de l'arrêt, la logique de démontage des systèmes de fichiers virtuels (proc, sys) a été modifiée et les informations sur les processus bloquant le démontage du système de fichiers sont enregistrées dans le journal.

Le chargeur de démarrage sd a ajouté la possibilité de démarrer en mode mixte, exécutant un noyau Linux 64 bits à partir d'un micrologiciel UEFI 32 bits. Ajout de la capacité expérimentale d'appliquer automatiquement les clés SecureBoot à partir de fichiers situés sur ESP (partition système EFI).

Ajout de nouvelles options à l'utilitaire bootctl "-all-architectures" pour installer des binaires pour toutes les architectures EFI prises en charge, «–root=" et "–image=» pour travailler avec un répertoire ou une image disque, «--install-source=» pour définir la police à installer, «--efi-boot-option-description=» pour contrôler les noms des entrées de démarrage.

Des autres changements qui se démarquent du systemd 252 :

• systemd-nspawn permet l'utilisation de chemins de fichiers relatifs dans les options « –bind= » et « –overlay= ». Ajout de la prise en charge de l'option 'rootidmap' à l'option "–bind=" pour lier l'ID utilisateur racine sur le conteneur au propriétaire du répertoire monté côté hôte.
• systemd-resolved utilise le package OpenSSL comme backend de chiffrement par défaut (la prise en charge de gnutls est conservée en option). Les algorithmes DNSSEC non pris en charge sont désormais traités comme non sécurisés au lieu de renvoyer une erreur (SERVFAIL).
• systemd-sysusers, systemd-tmpfiles et systemd-sysctl implémentent la possibilité de transmettre la configuration via le mécanisme de stockage des informations d'identification.
• Ajout de la commande 'compare versions' à systemd-analyze pour comparer les chaînes avec les numéros de version (similaire à 'rpmdev-vercmp' et 'dpkg –compare-versions').
• Ajout de la possibilité de filtrer les lecteurs par masque à la commande 'systemd-analyze dump'.
• Lors du choix d'un mode de veille en plusieurs étapes (veille puis hibernation, hibernation après hibernation), le temps passé en mode veille est désormais sélectionné en fonction de la durée de vie restante prévue de la batterie.
• Une transition instantanée vers le mode veille est effectuée lorsqu'il y a moins de 5 % de charge de la batterie.

Il convient également de mentionner que en 2024, systemd prévoit de ne plus prendre en charge le mécanisme de plafonnement des ressources cgroup v1, obsolète dans la version 248 de systemd. Il est conseillé aux administrateurs de prendre soin de déplacer les services liés au cgroup v1 vers le cgroup v2 à l'avance.

La principale différence entre cgroups v2 et v1 est l'utilisation d'une hiérarchie commune de cgroups pour tous les types de ressources, plutôt que des hiérarchies distinctes pour l'allocation des ressources CPU, la gestion de la mémoire et les E/S. Des hiérarchies séparées entraînent des difficultés à organiser l'interaction entre les pilotes et des coûts de ressources de noyau supplémentaires lors de l'application de règles pour un processus nommé dans différentes hiérarchies.

Dans la seconde moitié de 2023, il est prévu de cesser de prendre en charge les hiérarchies de répertoires fractionnés, lorsque /usr est monté séparément de la racine, ou que les répertoires /bin et /usr/bin, /lib et /usr/lib sont séparés.