Plan de retour en arrière pour les modules du noyau : signature, workflows DKMS et restauration rapide

Une mise à jour défectueuse du noyau ou un nouveau paquet de pilotes peut mettre un système en état d’urgence en quelques minutes. C’est pourquoi un plan de rollback robuste pour les modules du noyau est indispensable : il combine la signature (pour UEFI Secure Boot), les workflows DKMS (rebuild automatique lors d’un changement de noyau) et des étapes de revert rapides et reproductibles. Cet article décrit de manière pragmatique les prérequis, les séquences de vérification, les sources d’erreurs typiques et des runbooks concrets pour l’exploitation quotidienne.

Pourquoi les modules du noyau sont particulièrement critiques pour le rollback

Les modules du noyau sont du code extensible du noyau (pilotes, systèmes de fichiers, filtres réseau). Ils s’exécutent en contexte noyau : une erreur peut bloquer les I/O, interrompre des chemins réseau ou empêcher le démarrage. Trois mécanismes complexifient les rollbacks : la compatibilité Kernel‑ABI (l’interface binaire entre le noyau et le module), Secure Boot/Lockdown (vérification de confiance via signatures) et le contexte initramfs (image de démarrage précoce qui doit charger les modules pour le stockage root).

Plan de rollback pour les modules du noyau : cible et exigences minimales

Un plan pragmatique satisfait au moins quatre critères :

• Déterminisme : vous devez pouvoir indiquer précisément quelle version du noyau / du module est active.
• Capacité de démarrage : la récupération doit fonctionner sans réseau (accès console / OOB).
• Compatibilité Secure Boot : les signatures et l’inscription MOK / des clés font partie du processus.
• Vérification opérationnelle : des séquences de vérification claires documentent si le système est redevenu stable.

Le plan distingue les rollbacks avant le reboot (la modification n’est pas encore effective) et après le reboot (le système ne démarre pas ou une fonctionnalité manque). Pour les deux cas, des checks automatisés et des étapes manuelles d’urgence appartiennent au même runbook.

Préparation : inventaire, dépendances de démarrage précoce et rétention

Inventaire des modules et chemins de démarrage précoce

Déterminez quels modules sont critiques et s’ils sont nécessaires avant le montage du système de fichiers root. Les candidats typiques sont les contrôleurs NVMe/RAID/HBA, les initiateurs iSCSI, les pilotes dm‑crypt ou les pilotes NIC pour PXE/Netboot. Établissez une liste de groupes d’hôtes partageant du matériel et des chemins de démarrage similaires.

# Basis-Inventar
lsmod | sort
lspci -nnk
lsblk -f
# Kernel-Logs, relevante Hinweise
dmesg -T | egrep -i "module|taint|firmware|dkms|secure|lockdown"

Rétention : conservez au moins deux à trois noyaux « known good » sur les hôtes ou dans votre dépôt interne. Ne supprimez pas automatiquement les anciens noyaux, sinon l’option de repli disparaît.

Signature, Secure Boot et MOK : ce que les exploitants doivent savoir

UEFI Secure Boot vérifie les chaînes de démarrage et peut empêcher le chargement de modules non signés. Le Kernel Lockdown (fonctionnalités noyau restreintes) peut apporter des contraintes supplémentaires. Termes clés importants :

• MOK (Machine Owner Key) : une clé à inscrire localement permettant d’autoriser ses propres modules.
• Clé de distribution : les distributions signent les noyaux/modules avec leurs propres clés ; les modules internes ne sont donc pas nécessairement couverts.
• PKI interne : les artefacts signés de façon centralisée sont plus sûrs, mais nécessitent des processus et des outils.

# Secure Boot Status prüfen
mokutil --sb-state || true
# Enrolled Keys
mokutil --list-enrolled 2>/dev/null | head -n 50 || true
# Kernel-Log-Meldungen
dmesg -T | egrep -i "Required key not available|module verification" || true

Lorsque Secure Boot est activé, un contrôle de signature doit faire partie de chaque changement : le module est‑il chargé après la mise à jour et après le rollback, ou la chaîne de confiance bloque‑t‑elle ?

Flux de travail DKMS : utilité, limites et pipeline sécurisée

DKMS (Dynamic Kernel Module Support) reconstruit automatiquement les modules lors d’un changement de noyau. Mais : DKMS ne garantit pas que le résultat soit exécutable. Causes typiques d’échec : en‑têtes du noyau manquants, toolchain modifiée ou absence de signature des modules construits. Vous devez donc collecter les logs de build et enchaîner des étapes automatiques de signature.

# DKMS-Status kurz prüfen
command -v dkms >/dev/null && dkms status || echo "dkms nicht installiert"
# installierte Kernel
ls -1 /lib/modules
# aktueller Kernel
uname -r

Règle pratique : testez les builds DKMS sur une instance Canary avec les mêmes en‑têtes et la même politique Secure Boot que vos systèmes de production. Automatisez la signature immédiatement après le build.

Stratégie de rollback par niveaux

Travaillez avec trois niveaux pour choisir l’étendue adéquate :

• Niveau 1 – Retour du module : rapide, peu d’effets secondaires, ne fonctionne qu’en cas de compatibilité ABI.
• Niveau 2 – Retour du noyau + module : plus robuste, car restaure des paires testées ; nécessite la gestion du bootloader et des paquets.
• Niveau 3 – Retour du chemin de boot : définir le bootloader par défaut, garantir l’initramfs pour le noyau cible ; nécessaire en cas d’erreurs de démarrage.

Liste de contrôle avant modifications (runbook court)

• Accès out‑of‑band disponible et testé (iLO/iDRAC/IPMI/console virtuelle).
• Un noyau connu et fiable est installé et sélectionnable.
• Les builds DKMS pour le noyau cible sont validés (OK) ou reproductibles.
• Processus de signature et statut MOK documentés, clés disponibles.
• Processus de reconstruction d’initramfs connu et testé (dracut/mkinitramfs).
• Anciens paquets/artefacts disponibles dans le miroir interne ou le cache.
• Vérification : quelles commandes déterminent OK versus rollback après redémarrage.

Guide pratique : signature et étape de signature automatique après DKMS

Deux modèles opérationnels sont courants : signature sur l’hôte (rapide, clés locales) ou pipeline de signature centralisée (meilleur contrôle). L’essentiel : le module construit doit être signé avant l’installation si Secure Boot est activé.

# Beispiel: Modulinfo und Testload
modinfo mydriver.ko 2>/dev/null || echo "Modul prüfen"
modinfo mydriver.ko | egrep -i "filename|version|signer|sig_hash" || true
# Testladen (nur in Wartungsfenstern oder Canary)
modprobe -v mydriver || true

La signature avec l’outil du noyau scripts/sign-file est une méthode fiable ; le script fait partie du build du noyau et utilise une clé privée (pem) plus le certificat.

# Signieren eines Moduls (Host-seitig)
KERNEL_DIR=/lib/modules/$(uname -r)/build
${KERNEL_DIR}/scripts/sign-file sha256 /root/mok.priv /root/mok.pem /lib/modules/$(uname -r)/extra/mydriver.ko
# Modul prüfen
modinfo /lib/modules/$(uname -r)/extra/mydriver.ko | egrep -i "sign|sig_hash" || true
# MOK Import (queued - enrollment beim nächsten Reboot erforderlich)
mokutil --import /root/mok.der

Pourquoi cela fonctionne : le noyau vérifie au chargement le checksum signé. Si aucun certificat valable n’est présent dans le firmware/MOK, le chargement est refusé. Échecs typiques : la clé n’a jamais été enrollée ou le procédé de signature n’est pas compatible (p.ex. algorithme de hachage incorrect).

Revert rapide — runbooks pour trois scénarios réels

Scénario A : hôte démarre, fonction manquante (p. ex. réseau ou stockage)

1. Délimiter les symptômes (ip link, lsblk, dmesg).
2. Vérifier l’état du module (lsmod, modinfo).
3. Si le mauvais module est actif : blacklist temporaire ou modprobe -r et modprobe en sens inverse.
4. Si le démarrage précoce est concerné : reconstruire l’initramfs et redémarrer.

# Prüfbeispiele
ip link show || true
lsmod | egrep "mydriver|alternativedriver" || true
journalctl -k -b --no-pager | tail -n 200
# Temporäre Blacklist (erzwungenes Entfernen)
echo "blacklist newdriver" > /etc/modprobe.d/99-blacklist-newdriver.conf
# Modul entfernen und altes laden
modprobe -r newdriver || true
modprobe -v mydriver || true

Scénario B : l’hôte reste dans l’initramfs ou le root n’est pas montable

Options rapides : basculer le chargeur de démarrage sur un noyau plus ancien (si disponible) ou booter sur une ISO/Kernel de rescue, monter le root, réparer le module/signature/initramfs. Assurez-vous de savoir comment modifier les entrées de boot Grub/EFI ou définir une image de démarrage temporaire.

# Grub: Default setzen und Update
grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 5.15.0-46-generic"
update-grub
# EFI: Bootreihenfolge prüfen und setzen
efibootmgr -v
# Beispiel: Bootnummer 0002 an erste Stelle
efibootmgr -o 0002,0000,0001

Alternative pour des tests plus rapides : kexec (charge un nouveau noyau sans redémarrage firmware). Attention : kexec échoue si les problèmes d’initramfs ne se manifestent qu’après un redémarrage complet.

# kexec schneller Test (nur in Testumgebungen)
kernel=/boot/vmlinuz-5.15.0-46-generic
initrd=/boot/initrd.img-5.15.0-46-generic
kexec -l $kernel --initrd=$initrd --command-line="$(cat /proc/cmdline)"
kexec -e

Scénario C : les modules ont été bloqués à cause de Secure Boot

Si les logs indiquent « Required key not available », vérifiez l’état MOK et si le module est signé. L’enrôlement MOK est généralement interactif au reboot — difficile à effectuer sans console OOB. Dans des environnements headless, prévoyez l’enrôlement via une console distante ou un provisionnement centralisé des MOK.

# Logs und MOK-Status
journalctl -k -b --no-pager | egrep -i "Required key not available|verification failed|Lockdown" || true
mokutil --sb-state || true

Initramfs : vérifier, reconstruire et valider

Beaucoup de rollbacks échouent parce que l’initramfs contient le mauvais module ou pas de module signé. Il est essentiel, avant le reboot, de vérifier quels modules sont inclus dans l’initramfs.

# Debian/Ubuntu: Inhalt prüfen
lsinitramfs /boot/initrd.img-$(uname -r) | egrep "mydriver|module" || true
# dracut (RHEL/Fedora): prüfen
lsinitrd /boot/initramfs-$(uname -r).img | egrep "mydriver|module" || true
# Rebuild (Debian/Ubuntu)
update-initramfs -u -k $(uname -r)
# Rebuild (RHEL/Fedora)
dracut --force /boot/initramfs-$(uname -r).img $(uname -r)

Règle de validation : après la reconstruction, vérifier à nouveau le contenu et tester localement pendant la fenêtre de maintenance avant de déployer sur d’autres systèmes.

Gestion des artefacts et stratégie de paquets

Conservez les modules compilés comme artefacts packagés (.deb/.rpm) dans votre dépôt interne. Un paquet contient la version, la signature et les dépendances — cela facilite les retours en arrière via le gestionnaire de paquets et permet des audits propres.

# DKMS Build + Paket (vereinfachtes Beispiel)
dkms build -m mydriver -v 1.2 -k 5.15.0-46-generic
dkms install -m mydriver -v 1.2 -k 5.15.0-46-generic
# Paketieren (Debian): debhelper/PKGBUILD/Spec nutzen - hier nur Platzhalter
# dpkg-deb --build mydriver-1.2/

Important : stockez les clés de signature en lieu sûr (HSM ou Vault) et assurez-vous que les processus de déverrouillage en cas d’urgence sont audités et reproductibles.

Particularités Cloud : Snapshots, Rescue‑VMAttach et kernels gérés

Dans les environnements cloud, des options supplémentaires sont disponibles, mais des contraintes doivent aussi être prises en compte :

• Les VM‑Snapshots et les Volume‑Snapshots permettent de remettre rapidement des instances complètes ; toutefois, les snapshots introduisent des risques de cohérence pour les services distribués.
• Les instances de rescue (console du provider) permettent d’attacher le disque root et de réparer hors ligne l’initramfs et les modules.
• Avec des Managed‑Kernels (le provider fournit le kernel), les modules personnalisés sont souvent interdits ; une coordination avec le fournisseur est nécessaire.

# Cloud-Beispiel: lokale Reparatur mittels Rescue-Instance (Konzeptionell)
# 1. Stop VM, detach volume
# 2. Attach to Rescue-VM
# 3. Chroot /mnt/volume, rebuild initramfs, sign modules
# 4. Detach, attach back, boot

Post‑rollback : monitoring, postmortem et retours d’expérience

Après un rollback réussi, le travail n’est pas terminé. Réalisez un court postmortem orienté technique couvrant les points suivants : analyse des causes, timeline, quelle séquence de vérification a été trop tardive/défaillante, artefacts manquants ou documentation d’enrôlement des clés incorrecte. Mettez à jour les runbooks, les tests canary et la politique de rétention des artefacts en fonction des enseignements tirés.

Modèle : runbook minimal (une page)

Utilisez un modèle de runbook d’une page qui peut être suivi rapidement en cas d’urgence :

# RUNBOOK: Modul-Rollback Schnellreferenz
1) Symptoms: network/storage missing? -> ip/lsblk/dmesg
2) If host up: check lsmod, modinfo
3) Try: modprobe -r newdriver; modprobe mydriver
4) If early-boot: rebuild initramfs + set grub default to known-good -> reboot
5) If SecureBoot errors: mokutil --sb-state; ensure MOK queued; plan OOB enrollment
6) Verify: uname -r; modinfo mydriver; journalctl -k -b | egrep -i "error|verification"
7) If failed: attach to rescue, repair initramfs, RESTore package from repo

Conclusion

Un plan de rollback pour les modules du noyau opérationnel est plus que la réinstallation d’une version de paquet : il combine la connaissance de compatibilité (Kernel↔Module↔initramfs), une stratégie de confiance claire (Secure Boot/MOK/signature) et des runbooks reproductibles pour des décisions rapides. DKMS automatise les builds, mais ne remplace pas la validation des signatures et du chemin de démarrage. Avec des Canary‑rollouts, une gestion empaquetée des artefacts, des chemins Out‑of‑Band testés et des processus MOK documentés, vous réduisez le risque et assurez un retour rapide en production stable.

Automatisation, audit et gestion des clés

Pour des environnements à l’échelle, le plan de rollback n’est pas un document ad hoc, mais fait partie de la pipeline de build et de déploiement : des artefacts de modules signés sont construits automatiquement, déposés dans un repo interne et déployés de manière vérifiée via le configuration management (p. ex. Ansible). Aspects opérationnels importants :

• Gestion des clés : les clés privées de signature doivent être stockées dans Vault ou un HSM ; l’accès est limité par des règles de rôle et de séparation des fonctions (SoD).
• Auditabilité : chaque signature, enregistrement MOK et promotion d’artefact écrit des logs/hashes dans le repo d’audit.
• Monitoring : alertes automatiques sur „module verification failed“/“Required key not available“ (parseur journalctl/dmesg).

# Exemple : étape de signature dans le CI (simplifié)
vault kv get -field=privkey secret/sign/mok | base64 -d >/tmp/mok.priv
/scripts/sign-file sha256 /tmp/mok.priv /tmp/mok.pem mydriver.ko

Risque : compromission de clé ou enregistrements MOK incohérents pouvant casser les rollbacks. Par conséquent : rotation d’urgence des clés, fixtures d’enrôlement documentés (scénarios OOB) et déploiements canary réguliers dans le cadre de la gouvernance opérationnelle de vos solutions numériques d’entreprise.

Pour ce thème, la signature des modules du noyau et le workflow DKMS sont également importants. L’article met ces aspects en contexte de manière compréhensible et montre ce qui importe au quotidien.