Plan de reversión para módulos del kernel: firma, flujos de trabajo DKMS y reversión rápida

Una actualización defectuosa del kernel o un nuevo paquete de controladores puede poner un sistema en estado de emergencia en minutos. Por eso es imprescindible un Plan de rollback para módulos del kernel: combina firma (para UEFI Secure Boot), flujos de trabajo DKMS (reconstrucción automática al cambiar de kernel) y pasos de reversión rápidos y reproducibles. Esta entrada describe de forma práctica los prerrequisitos, las secuencias de comprobación, las fuentes de error típicas y Runbooks concretos para el trabajo diario.

Por qué los módulos del kernel son especialmente críticos para la reversión

Los módulos del kernel son código ampliable del kernel (controladores, sistemas de archivos, filtros de red). Se ejecutan en contexto de kernel: los errores pueden bloquear E/S, interrumpir rutas de red o impedir el arranque. Tres mecanismos complican los rollbacks: compatibilidad de Kernel‑ABI (la interfaz entre kernel y módulo), Secure Boot/Lockdown (verificación de confianza mediante firmas) y el contexto Initramfs (imagen de arranque temprana que debe cargar módulos para el dispositivo de almacenamiento raíz).

Plan de rollback para módulos del kernel: objetivo y requisitos mínimos

Un plan pragmático cumple al menos cuatro criterios:

• Determinismo: Puede especificar con precisión qué versión de kernel/módulo está activa.
• Capacidad de arranque: La recuperación funciona incluso sin red (acceso por consola/OOB).
• Compatibilidad con Secure‑Boot: Las firmas y MOK/inscripción de claves son parte del proceso.
• Verificación operativa: Secuencias de comprobación claras documentan si el sistema vuelve a estar estable.

El plan distingue los rollbacks antes del reinicio (el cambio aún no es efectivo) y después del reinicio (el sistema no arranca o falta funcionalidad). Para ambos casos, los checks automatizados y los pasos manuales de emergencia forman parte del mismo Runbook.

Preparación: inventario, dependencias de early‑boot y retención

Inventario de módulos y rutas de early‑boot

Determine qué módulos son críticos y si se necesitan antes de montar el sistema de archivos raíz. Candidatos típicos son controladores NVMe/RAID/HBA, iniciadores iSCSI, controladores dm‑crypt o controladores NIC en entornos PXE/Netboot. Cree una lista con grupos de hosts que compartan hardware y rutas de arranque similares.

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

Retención: Conserve al menos dos o tres kernels „known good“ en los hosts o en su repositorio interno. No elimine kernels antiguos de forma automática, de lo contrario faltará la opción de retroceso.

Firma, Secure Boot y MOK: lo que los operadores deben saber

UEFI Secure Boot valida las cadenas de arranque y puede impedir la carga de módulos no firmados. Kernel Lockdown (restricciones del kernel) puede imponer limitaciones adicionales. Términos clave:

• MOK (Machine Owner Key): Una clave que se inscribe localmente y con la que se autorizan módulos propios.
• Distribution‑Key: Las distribuciones firman kernel/módulos con sus propias claves; los módulos propios no siempre quedan cubiertos por ello.
• PKI propia: Firmar artefactos centralmente es más seguro, pero exige procesos y 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

Si Secure Boot está activo, una verificación de firma debe formar parte de cada cambio: ¿se carga el módulo tras la actualización y tras el rollback, o la cadena de confianza lo bloquea?

DKMS‑Workflows: Nutzen, Grenzen und sichere Pipeline

DKMS (Dynamic Kernel Module Support) recompila los módulos automáticamente cuando cambia el kernel. Pero: DKMS no garantiza que el resultado sea ejecutable. Fallos típicos son encabezados del kernel ausentes, toolchain modificada o falta de firma de los módulos compilados. Por ello debe recopilar los registros de compilación y encadenar pasos automáticos de firmado.

# 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

Praxisregel: Testen Sie DKMS‑Builds auf einer Canary‑Instanz mit denselben Headern und derselben Secure‑Boot‑Policy wie Ihre Produktionssysteme. Automatisieren Sie Signierung unmittelbar nach dem Build.

Rollback‑Strategie nach Ebenen

Trabaje con tres niveles para elegir el alcance adecuado:

• Nivel 1 – revertir módulo: Rápido, pocos efectos secundarios, funciona solo si hay compatibilidad de ABI.
• Nivel 2 – revertir kernel y módulo: Más robusto, porque restaura pares probados; requiere manejo del bootloader y de paquetes.
• Nivel 3 – revertir ruta de arranque: Restablecer la opción predeterminada del bootloader, asegurar el initramfs para el kernel objetivo; necesario en caso de errores de arranque.

Checkliste vor Änderungen (Kurz‑Runbook)

• Acceso out-of-band disponible y probado (iLO/iDRAC/IPMI/consola virtual).
• Un kernel conocido y fiable está instalado y seleccionable.
• Las compilaciones DKMS para el kernel objetivo están marcadas como exitosas o son reproducibles.
• Proceso de firma y estado MOK documentados, claves disponibles.
• Proceso de reconstrucción de initramfs conocido y probado (dracut/mkinitramfs).
• Paquetes/artefactos antiguos disponibles en el mirror interno o en caché.
• Verificación: qué comandos deciden OK vs. rollback tras el reinicio.

How‑to: Signierung und automatischer Sign‑Step nach DKMS

Son habituales dos modelos operativos: firmado en el host (rápido, clave local) o una pipeline de firma centralizada (mejor control). Lo decisivo es: el módulo compilado debe estar firmado antes de la instalación si Secure Boot está activo.

# 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

Firmar con la herramienta del kernel scripts/sign-file es un método fiable; el script forma parte del build del kernel y utiliza material de clave privada (pem) más certificado.

# 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

Por qué funciona: el kernel verifica al cargar la suma firmada. Si no hay un certificado válido en la firmware/MOK, la carga se deniega. Cuando falla: si la clave nunca se inscribió o el procedimiento de firma no es compatible (p. ej. algoritmo de hash incorrecto).

Schnelles Revert — Runbooks für drei reale Szenarien

Escenario A: El host arranca, falta una función (p. ej. red o almacenamiento)

1. Acotar los síntomas (ip link, lsblk, dmesg).
2. Comprobar el estado del módulo (lsmod, modinfo).
3. Si se carga el módulo incorrecto: lista negra temporal o modprobe -r y modprobe en orden inverso.
4. Si el early‑boot es relevante: reconstruir el initramfs y reiniciar.

# 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

Escenario B: El host queda en initramfs o la raíz no es montable

Opciones rápidas: cambiar el cargador de arranque a un kernel anterior (si existe) o arrancar desde una ISO de rescate / un kernel de rescate, montar la raíz, reparar módulo / firma / initramfs. Asegúrese de saber cómo modificar las entradas de arranque de Grub / EFI o establecer una imagen de arranque temporal.

# 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 para pruebas más rápidas: kexec (carga un kernel nuevo sin reinicio de firmware). Precaución: kexec fallará si los problemas del initramfs sólo se manifiestan tras un reinicio real.

# 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

Escenario C: Los módulos fueron bloqueados por Secure Boot

Si los registros muestran „Required key not available“, compruebe el estado de MOK y si el módulo está firmado. El enrolamiento MOK suele ser interactivo durante el reinicio — sin consola OOB resulta difícil. En entornos headless planifique el enrolamiento mediante procedimientos de consola remota o aprovisionamiento centralizado de 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: Comprobar, reconstruir y validar

Muchas reversiones fallan porque el initramfs contiene el módulo equivocado o un módulo no firmado. Es crucial comprobar, antes del reinicio, qué módulos están incorporados en el 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)

Regla de validación: tras reconstruir, vuelva a comprobar el contenido y pruebe localmente durante la ventana de mantenimiento antes de desplegar en otros sistemas.

Gestión de artefactos y estrategia de paquetes

Almacene los módulos compilados como artefactos empaquetados (.deb/.rpm) en su repositorio interno. Un paquete incluye versión, firma y dependencias — eso facilita las reversiones mediante el gestor de paquetes y permite auditorías limpias.

# 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: Guarde las claves de firma de forma segura (HSM o Vault) y asegúrese de que los procesos de desbloqueo en emergencias estén auditados y sean reproducibles.

Particularidades cloud: Snapshots, Rescue‑VMAttach y kernels gestionados

En entornos cloud hay opciones adicionales disponibles, pero también hay RESTricciones a tener en cuenta:

• Los snapshots de VM y los snapshots de volúmenes permiten RESTablecer rápidamente instancias completas; sin embargo, los snapshots introducen riesgos de consistencia en servicios distribuidos.
• Las instancias de rescate (consola del proveedor) permiten adjuntar el disco root y reparar initramfs y módulos fuera de línea.
• Con kernels gestionados (kernel proporcionado por el proveedor), a menudo no se permiten módulos propios; es necesario coordinarse con el proveedor.

# 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: monitorización, postmortem y lecciones aprendidas

Tras un rollback exitoso, el trabajo no ha terminado. Realice un postmortem técnico breve que incluya los siguientes puntos: análisis de causas, cronología, qué secuencia de comprobaciones fue demasiado tardía o fallida, artefactos faltantes o documentación defectuosa de enrolamiento de claves. Actualice los Runbooks, las pruebas canary y la política de retención de artefactos en función de las conclusiones.

Plantilla: Runbook mínimo (una página)

Utilice una plantilla de Runbook de una página que pueda seguirse rápidamente en emergencias:

# 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

Conclusión

Un plan de rollback práctico para módulos de kernel es más que volver a instalar una versión de paquete: combina conocimiento de compatibilidad (Kernel↔Módulo↔initramfs), una estrategia de confianza clara (Secure Boot/MOK/Firma) y Runbooks reproducibles para decisiones rápidas. DKMS automatiza las compilaciones, pero no sustituye la validación de firmas ni la validación de la ruta de arranque. Con despliegues canary, gestión empaquetada de artefactos, rutas fuera de banda probadas y procesos MOK documentados, reduce el riesgo y asegura un retorno rápido al funcionamiento estable.

Automatización, auditoría y gestión de claves

Para entornos escalables, el plan de rollback no es un documento ad hoc, sino parte de la pipeline de build y deployment: los artefactos de módulos firmados se construyen automáticamente, se colocan en un repositorio interno y se despliegan verificados mediante Configuration‑Management (p. ej. Ansible). Aspectos operativos importantes:

• Gestión de claves: Las claves privadas de firma deben guardarse en Vault o en un HSM; el acceso debe limitarse mediante reglas de roles y separación de funciones (SoD).
• Auditabilidad: Cada firma, enrolamiento MOK y promoción de artefactos registra logs y hashes en el repositorio de auditoría.
• Monitorización: Alertas automáticas ante „module verification failed“/“Required key not available“ (parsers de 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

Riesgo: la compromisión de claves o inscripciones MOK inconsistentes pueden romper los rollbacks. Por ello: rotación de claves de emergencia, enrollment‑fixtures documentadas (escenarios OOB) y despliegues Canary periódicos como parte de la gobernanza operativa de sus soluciones digitales empresariales.

Para este tema también son importantes la firma de módulos del kernel y el flujo de trabajo Dkms. El artículo contextualiza estos aspectos de forma clara y muestra en qué debe fijarse en el día a día.