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

Le nouveau démarrage Linux fonctionnera bien dans le futur en mettant l'accent sur la robustesse et la simplicité.

Lennart Poetter (le créateur de Systemd) dévoilé récemment une proposition de modernisation du processus de démarrage des distributions de Linux, dans le but de résoudre les problèmes existants et simplifier l'organisation d'un démarrage entièrement vérifié, confirmant l'authenticité du noyau et de l'environnement système sous-jacent.

Changements proposés sont réduits à création d'une seule image UKI universelle (Image du noyau unifié) qui fusionne l'image du noyau Pilote Linux pour charger le noyau depuis UEFI (stub de démarrage UEFI) et l'environnement système initrd chargé en mémoire, utilisé pour l'initialisation initiale à l'étape avant le montage du FS.

Au lieu d'une image de disque virtuel initrd, l'ensemble du système peut être emballé dans l'UKI, permettant la création d'environnements système entièrement vérifiés qui sont chargés dans la RAM. L'image UKI est conditionnée sous la forme d'un fichier exécutable au format PE, qui peut non seulement être chargé avec des chargeurs de démarrage traditionnels, mais peut également être appelé directement à partir du micrologiciel UEFI.

La possibilité d'appeler depuis UEFI permet l'utilisation d'un contrôle de validité et d'intégrité de la signature numérique qui couvre non seulement le noyau, mais aussi le contenu de l'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 actualisation.

Actuellement, la plupart des distributions Linux utilisent la chaîne "micrologiciel → couche de shim Microsoft signée numériquement → chargeur de démarrage GRUB de distribution signée numériquement → noyau Linux de distribution signée numériquement → environnement initrd non signé → racine FS" dans le processus d'initialisation. Vérification initrd manquante dans les distributions traditionnelles crée des problèmes de sécurité, puisque, entre autres, cet environnement extrait des clés pour déchiffrer la racine FS.

La vérification de l'image initrd n'est pas prise en charge, car ce fichier est généré sur le système local de l'utilisateur et ne peut pas être certifié par la signature numérique de la distribution, ce qui rend très difficile l'organisation de la vérification en mode SecureBoot (pour vérifier l'initrd, l'utilisateur doit générer vos clés et les charger dans le micrologiciel UEFI).

En outre, l'organisation de démarrage existante ne permet pas l'utilisation des informations des registres PCR TPM (Platform Configuration Registry) pour contrôler l'intégrité des composants de l'espace utilisateur autres que shim, grub et noyau. Parmi les problèmes existants, la complication de la mise à jour du chargeur de démarrage et l'impossibilité de restreindre l'accès aux clés du TPM pour les anciennes versions du système d'exploitation devenues inutiles après l'installation de la mise à jour sont également mentionnées.

Les principaux objectifs de la mise en œuvre la nouvelle architecture de démarrage :

• Fournissez un processus de téléchargement entièrement vérifié, couvrant toutes les étapes, du micrologiciel à l'espace utilisateur, et confirmant la validité et l'intégrité des composants téléchargés.
• Liaison des ressources contrôlées aux registres PCR TPM avec séparation par propriétaires.
• Possibilité de précalculer les valeurs PCR en fonction du démarrage du noyau, de l'initrd, de la configuration et de l'ID du système local.
• Protection contre les attaques de restauration associées au retour à la version vulnérable précédente du système.
• Simplifiez et améliorez la fiabilité des mises à jour.
• Prise en charge des mises à niveau du système d'exploitation qui ne nécessitent pas de réappliquer ou de provisionner localement des ressources protégées par TPM.
• Préparation du système pour la certification à distance afin de confirmer l'exactitude du système d'exploitation et de la configuration de démarrage.
• La possibilité d'attacher des données sensibles à certaines étapes de démarrage, par exemple en extrayant des clés de chiffrement pour la racine FS du TPM.
• Fournissez un processus sûr, automatique et silencieux pour déverrouiller les clés pour déchiffrer un lecteur avec une partition racine.
• L'utilisation de puces prenant en charge la spécification TPM 2.0, avec la possibilité de revenir à des systèmes sans TPM.

Les changements nécessaires mettre en œuvre la nouvelle architecture sont déjà inclus dans la base de code systemd et affecter des composants tels que systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase et systemd-creds.

Enfin si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant