Piano di rollback per moduli del kernel: firma, workflow DKMS e revert rapido

Un aggiornamento del kernel difettoso o un nuovo pacchetto driver possono portare un sistema in stato di emergenza in pochi minuti. Perciò è indispensabile un Piano di rollback per i moduli del kernel affidabile: combina firma (per UEFI Secure Boot), workflow DKMS (ricompilazione automatica al cambio di kernel) e passaggi di revert rapidi e riproducibili. Questo articolo descrive in modo pratico prerequisiti, sequenze di verifica, cause di errore tipiche e runbook concreti per l’operatività quotidiana.

Perché i moduli del kernel sono particolarmente critici per i rollback

I moduli del kernel sono codice estendibile del kernel (driver, file system, filtri di rete). Operano nel contesto del kernel: errori possono bloccare le operazioni I/O, interrompere percorsi di rete o impedire l’avvio. Tre meccanismi rendono i rollback complessi: compatibilità dell’ABI del kernel (l’interfaccia binaria tra kernel e modulo), Secure Boot/Lockdown (verifica di fiducia tramite firme) e il contesto initramfs (immagine di avvio precoce che deve caricare i moduli per il root storage).

Piano di rollback per i moduli del kernel: obiettivo e requisiti minimi

Un piano pragmatico soddisfa almeno quattro criteri:

• Determinismo: È possibile determinare con precisione quale versione di kernel/modulo è attiva.
• Capacità di avvio: Il recovery funziona anche senza rete (accesso console/OOB).
• Compatibilità con Secure Boot: Firme e MOK/registrazione delle chiavi fanno parte del processo.
• Verifica operativa: Sequenze di controllo documentate chiaramente per stabilire se il sistema è tornato stabile.

Il piano distingue rollback prima del reboot (la modifica non è ancora attiva) e dopo il reboot (il sistema non avvia o manca una funzionalità). Per entrambi i casi, controlli automatizzati e passaggi manuali di emergenza appartengono allo stesso runbook.

Preparazione: inventario, dipendenze early‑boot e retention

Inventario dei moduli e percorsi di avvio precoce

Identificate quali moduli sono critici e se sono necessari prima del montaggio del filesystem root. Candidati tipici sono controller NVMe/RAID/HBA, initiator iSCSI, driver dm‑crypt o driver NIC per PXE/Netboot. Create una lista di gruppi host che condividono hardware e percorsi di avvio simili.

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

Retention: Conservate almeno due o tre „known good“ kernel sui host o nel vostro repository interno. Non rimuovete automaticamente kernel vecchi, altrimenti viene meno l’opzione di fallback.

Firma, Secure Boot e MOK: cosa devono sapere gli operatori

UEFI Secure Boot verifica le catene di avvio e può impedire il caricamento di moduli non firmati. Kernel Lockdown (funzionalità kernel limitate) può introdurre ulteriori restrizioni. Termini chiave importanti:

• MOK (Machine Owner Key): Una chiave da registrare localmente che autorizza i moduli proprietari.
• Distribution‑Key: Le distribuzioni firmano kernel/moduli con chiavi proprie; i moduli personalizzati non sono necessariamente coperti.
• PKI interna: Artefatti firmati centralmente sono più sicuri, ma richiedono processi e tooling.

# 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

Se Secure Boot è attivo, un controllo della firma deve far parte di ogni modifica: il modulo viene caricato dopo l’aggiornamento e dopo il rollback oppure la catena di fiducia lo blocca?

DKMS‑Workflows: Vantaggi, limiti e pipeline sicura

DKMS (Dynamic Kernel Module Support) ricompila automaticamente i moduli quando cambia il kernel. Tuttavia: DKMS non garantisce che il risultato sia eseguibile. Cause tipiche di malfunzionamento sono header del kernel mancanti, toolchain modificata o assenza della firma sui moduli compilati. Perciò dovreste raccogliere i log di build e collegare passaggi di firma automatici.

# 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

Regola pratica: testate i build DKMS su un’istanza Canary con gli stessi header e la stessa policy di Secure Boot dei vostri sistemi di produzione. Automatizzate la firma immediatamente dopo il build.

Strategia di rollback per livelli

Lavorate su tre livelli per scegliere l’ambito corretto:

• Livello 1 – Ripristino del modulo: veloce, pochi effetti collaterali, funziona solo con compatibilità ABI.
• Livello 2 – Ripristino di kernel + modulo: più robusto, perché si ripristinano coppie testate; richiede gestione del bootloader e dei pacchetti.
• Livello 3 – Ripristino del percorso di boot: impostare il default del bootloader, assicurarsi che l’initramfs per il kernel di destinazione sia presente; necessario in caso di errori di boot.

Lista di controllo prima delle modifiche (runbook breve)

• Accesso Out-of-Band disponibile e testato (iLO/iDRAC/IPMI/console virtuale).
• Un kernel noto e valido è installato e selezionabile.
• I build DKMS per il kernel target sono riusciti o riproducibili.
• Processo di firma e stato MOK documentati, chiavi disponibili.
• Processo di ricostruzione dell’initramfs conosciuto e testato (dracut/mkinitramfs).
• Pacchetti/artefatti vecchi disponibili nel mirror interno o nella cache.
• Verifica: quali comandi decidono OK vs. rollback dopo il riavvio.

How‑to: Firma e passaggio di firma automatico dopo DKMS

Sono comuni due modelli operativi: firma basata sull’host (veloce, chiave locale) o pipeline di firma centrale (migliore controllo). Fondamentale: il modulo compilato deve essere firmato prima dell’installazione se Secure Boot è attivo.

# 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

Firmare con lo strumento del kernel scripts/sign-file è un metodo affidabile; lo script fa parte del build del kernel e usa chiave privata (pem) e certificato.

# 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

Perché questo funziona: il kernel verifica al caricamento il checksum firmato. Se non è presente un certificato valido nella firmware/MOK, il caricamento viene rifiutato. Quando fallisce: se la chiave non è mai stata registrata o il metodo di firma non è compatibile (p.es. algoritmo hash sbagliato).

Ripristino rapido — runbook per tre scenari reali

Szenario A: Host si avvia, funzionalità assente (ad es. rete o storage)

1. Restringere i sintomi (ip link, lsblk, dmesg).
2. Verificare lo stato del modulo (lsmod, modinfo).
3. Se viene caricato il modulo sbagliato: blacklist temporanea o modprobe -r e modprobe in ordine inverso.
4. Se rilevante durante l’early‑boot: ricostruire initramfs e riavviare.

# 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

Szenario B: Host resta in initramfs o root non montabile

Opzioni rapide: impostare il bootloader su un kernel più vecchio (se disponibile) o avviare una Rescue‑ISO/Rescue‑Kernel, montare la root, riparare modulo/firma/initramfs. Assicurarsi di sapere come modificare le voci di avvio Grub/EFI o impostare un’immagine di avvio temporanea.

# 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

Alternativa per test più rapidi: kexec (carica un nuovo kernel senza riavvio del firmware). Attenzione: kexec fallisce se i problemi dell’initramfs diventano evidenti solo dopo un vero riavvio.

# 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

Szenario C: Module wurden wegen Secure Boot blockiert

Se i log mostrano “Required key not available”, verificare lo stato MOK e se il modulo è firmato. La registrazione MOK è per lo più interattiva al reboot — senza console OOB difficile da eseguire. Negli ambienti headless pianificate la registrazione con procedure di console remota o provisioning centralizzato 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: verifica, ricostruzione e validazione

Molti rollback falliscono perché l’initramfs contiene il modulo sbagliato o non contiene un modulo firmato. È cruciale verificare quali moduli sono inclusi nell’initramfs prima del riavvio.

# 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)

Regola di validazione: dopo la ricostruzione verificare nuovamente il contenuto e testare localmente durante la finestra di manutenzione prima di distribuire ad altri sistemi.

Gestione degli artefatti e strategia dei pacchetti

Conservare i moduli compilati come artefatti pacchettizzati (.deb/.rpm) nel vostro repository interno. Un pacchetto contiene versione, firma e dipendenze — facilita i revert tramite il package manager e consente audit puliti.

# 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/

Importante: Conservate le chiavi di firma in modo sicuro (HSM o Vault) e assicuratevi che i processi di sblocco in caso di emergenza siano sottoposti ad audit e riproducibili.

Particolarità del cloud: Snapshot, Rescue‑VMAttach e kernel gestiti

Negli ambienti cloud sono disponibili opzioni aggiuntive, ma bisogna anche tenere conto di limitazioni:

• I VM‑snapshot e i volume‑snapshot consentono di ripristinare rapidamente intere istanze; tuttavia gli snapshot introducono rischi di consistenza nei servizi distribuiti.
• Le rescue‑instance (console del provider) consentono di collegare il disco root e riparare offline initramfs e i moduli.
• Con kernel gestiti (kernel fornito dal provider) i moduli personalizzati spesso non sono consentiti; è necessaria una coordinazione con il provider.

# Esempio cloud: riparazione locale tramite Rescue-Instance (concettuale)
# 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 und Lessons Learned

Dopo un rollback riuscito il lavoro non è completato. Eseguite un breve postmortem di carattere tecnico con i seguenti punti: analisi delle cause, timeline, quale sequenza di verifica è stata troppo tardiva/errata, artefatti mancanti o documentazione errata di key‑enrollment. Aggiornate Runbooks, Canary‑Tests e la policy di retention degli artefatti in base alle evidenze.

Modello: runbook minimo (una pagina)

Usate un modello di runbook monopagina che possa essere seguito rapidamente in caso di emergenza:

# RUNBOOK: Riferimento rapido per rollback modulo
1) Sintomi: 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

Conclusione

Un piano di rollback pratico per i moduli kernel è più del ripristino di una versione di pacchetto: combina conoscenza di compatibilità (kernel↔modulo↔initramfs), una strategia di trust chiara (Secure Boot/MOK/firma) e runbook riproducibili per decisioni rapide. DKMS automatizza le build, ma non sostituisce la validazione delle firme e del percorso di boot. Con Canary‑Rollouts, gestione degli artefatti confezionati, percorsi out‑of‑band testati e processi MOK documentati riducete il rischio e garantite un rapido ritorno a un’operatività stabile.

Automazione, audit e gestione delle chiavi

Per ambienti scalabili il piano di rollback non è un documento ad hoc, ma parte della pipeline di build e deployment: gli artefatti dei moduli firmati vengono costruiti automaticamente, depositati in un repository interno e distribuiti verificati tramite Configuration‑Management (p. es. Ansible). Aspetti operativi importanti:

• Key‑Management: Le chiavi private di firma devono risiedere in Vault o in un HSM; l’accesso è limitato tramite regole di ruolo e Separation of Duties (SoD).
• Auditabilità: Ogni firma, MOK‑enrollment e promozione di artefatti scrive log/hash nel repository di audit.
• Monitoring: Alert automatici per „module verification failed“/“Required key not available“ (parser journalctl/dmesg).

# Beispiel: Sign-Schritt in CI (vereinfacht)
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

Rischio: compromissione delle chiavi o iscrizioni MOK incoerenti compromettono i rollback. Perciò: rotazione d’emergenza delle chiavi, procedure di enrollment documentate (scenari OOB) e canary rollout regolari come parte della governance operativa per le vostre soluzioni aziendali digitali.

Per questo tema sono importanti anche la firma dei moduli kernel e il workflow Dkms. Il contributo inquadra questi aspetti in modo chiaro e indica cosa conta nella pratica quotidiana.