Errores de Secure Boot tras la instalación: reparar la discordancia clave/modo

El modelo mental: modos, claves y qué falla realmente

Secure Boot no es “una opción”. Es un sistema de cadena de confianza aplicado por el firmware UEFI. El firmware decide si el siguiente ejecutable tiene permiso para ejecutarse. Ese “siguiente ejecutable” suele ser shim (en muchas distribuciones Linux), que luego valida GRUB, que a su vez valida el kernel (y a veces los módulos del kernel).

Modo Usuario vs Modo Configuración: los dos estados que importan

UEFI Secure Boot tiene dos estados operativos relevantes:

• Modo Configuración: la clave de plataforma (PK) no está instalada. El firmware está efectivamente “sin propietario”. Puedes inscribir claves sin autorización porque no existe una PK que haga cumplir la propiedad. Este es el estado al que entras a menudo cuando “borra las claves de Secure Boot”.
• Modo Usuario: una PK está instalada. Las bases de datos de Secure Boot están protegidas y las actualizaciones de claves requieren autorización. Este es el estado normal y esperado para un sistema que aplica Secure Boot.

Muchas fallas “post-instalación de Secure Boot” ocurren porque la máquina está en Modo Configuración (o tiene db/dbx vacíos), mientras que el SO espera que exista la cadena de CA de terceros de Microsoft, o espera que estén tus claves personalizadas. También ocurre al revés: la máquina está en Modo Usuario con claves del proveedor, pero instalaste un kernel o cargador de arranque que no está firmado por una clave de confianza.

Las bases de datos de claves: PK, KEK, db, dbx, y por qué dbx es el portero

• PK (Platform Key): establece la propiedad de la plataforma. Si falta la PK, estás en Modo Configuración.
• KEK (Key Exchange Key): permite actualizaciones a las listas permitidas/denegadas.
• db: firmas/hashes permitidos. Si la firma de tu cargador encadena a un certificado en db, puede ejecutarse.
• dbx: firmas/hashes prohibidos (lista de revocación). Si dbx dice “no”, es no—aun si db lo permitiría.

Las distribuciones que soportan Secure Boot normalmente incluyen un shim firmado. Ese shim está firmado por una clave que encadena a una CA UEFI de terceros de Microsoft que muchos proveedores incluyen en db por defecto. Shim luego usa su certificado incrustado y/o la lista MOK (Machine Owner Key) para validar GRUB y los kernels.

¿Qué es en la práctica la “discordancia clave/modo”?

Tienes una discordancia cuando una parte asume una raíz de confianza que no es verdadera:

• El firmware está aplicando Secure Boot en Modo Usuario, pero el cargador/kernel instalado no está firmado por una cadena de confianza.
• El firmware está en Modo Configuración (PK borrada), pero tu SO espera claves del proveedor/Microsoft, así que las firmas no validan como se esperaba (o en realidad no estás haciendo cumplir nada, pero la cadena de arranque que instalaste sigue esperando un entorno particular).
• Tienes claves personalizadas pero olvidaste inscribirlas (o las inscribiste en MOK, pero necesitabas hacerlo en db; o viceversa).
• dbx se actualizó y ahora bloquea un shim/grub antiguo (errores relacionados con SBAT suelen vivir aquí).

Una frase útil cuando te tiente “simplemente deshabilitarlo”: (idea parafraseada) “La esperanza no es una estrategia.” — Gene Kranz. Secure Boot no es perfecto, pero deshabilitarlo porque es molesto es el equivalente a cortar el cinturón de seguridad porque te arruga la camisa.

Broma #1: Secure Boot es como un portero de discoteca con una libreta. Si tu nombre no está en la lista, no entras—aunque “conozcas al dueño”.

Hechos interesantes y contexto histórico (porque el lío tiene historia)

1. UEFI Secure Boot llegó a la corriente principal con el hardware de la era Windows 8. No se inventó para fastidiar a los usuarios de Linux; fue una respuesta a bootkits y malware persistente que vivía por debajo del SO.
2. La CA UEFI de terceros de Microsoft se convirtió en el “puente” de facto para Linux. Muchos fabricantes la incluyen en db, lo que permite a las distros arrancar un shim firmado por Microsoft sin obligar a cada usuario a gestionar sus propias claves.
3. Shim existe porque los proveedores de firmware no querían incluir la clave de cada distro. Un único shim firmado más una cadena de confianza gestionada por la distro es escalable; llenar db con los certificados de todos no lo es.
4. Las actualizaciones de dbx son efectivamente “revocaciones” globales. Cuando se encuentra una vulnerabilidad en un componente de arranque ampliamente usado, dbx puede bloquearlo en sistemas—útil y brutal.
5. SBAT se introdujo para hacer la revocación más granular. En vez de revocar un certificado de firma entero (daño colateral), los metadatos SBAT pueden bloquear builds específicos vulnerables.
6. “Borrar las claves de Secure Boot” no es lo mismo que “desactivar Secure Boot”. Borrar claves suele poner en Modo Configuración y puede crear comportamientos más extraños que simplemente desactivar la aplicación.
7. MOK (Machine Owner Key) es un mecanismo a nivel de shim, no del firmware. MOK es útil para firmar kernels/módulos, pero no popula mágicamente el db del firmware.
8. Algunos proveedores vienen con Secure Boot habilitado pero permiten claves de terceros; otros no. Ese interruptor de BIOS que dice “Allow Microsoft 3rd party UEFI CA” decide si los shims comunes de Linux arrancarán.
9. La firma de módulos del kernel es adyacente pero no idéntica. Puedes arrancar con éxito y aun así ver fallos de drivers porque la aplicación de firma de módulos es distinta de la validación UEFI Secure Boot.

Guía de diagnóstico rápido (comprueba esto en orden)

Quieres señales rápido. No comiences por reinstalar nada. No comiences por deshabilitar Secure Boot. Comprueba el estado, identifica qué eslabón de la cadena falló y luego elige la corrección más pequeña.

1) Verifica el modo del firmware y el estado de Secure Boot

• ¿El sistema arrancó en modo UEFI (no legacy/CSM)?
• ¿Secure Boot está habilitado y activo?
• ¿El firmware está en Modo Configuración (PK ausente) o en Modo Usuario?

2) Identifica el componente que falla

• ¿El error viene del firmware antes de que se ejecute shim (“Security violation”, “Invalid signature”)?
• ¿Empieza shim pero rechaza GRUB/kernel (“Verification failed: (15)”, “SBAT policy violation”)?
• ¿Arranca pero luego rechaza controladores (NVIDIA, ZFS, Wi‑Fi)? Eso es firma de módulos.

3) Confirma qué claves están realmente inscritas

• Contenido de firmware db/dbx (al menos existencia/salud).
• Contenido de la lista MOK si usas shim/MOK.
• Si “Microsoft 3rd party UEFI CA” está habilitado en el firmware.

4) Decide tu modelo de confianza

• Flota corporativa: normalmente mantener claves del proveedor + Microsoft, usar shim de la distro y MOK para tu propio kernel/módulos.
• Control estricto: usar claves personalizadas (tu propio PK/KEK/db), firmar todo lo que arranque. Más trabajo. Más certeza.
• Caja de laboratorio: si no está conectada a nada sensible, desactivar Secure Boot es aceptable, pero documentarlo y deja de fingir que es “seguro”.

Firmas de fallo: lo que el error realmente significa

Firmware: “Security violation” / “Invalid signature” antes de que aparezca cualquier cargador

El firmware rechazó el binario EFI. Causas típicas:

• El cargador no está firmado por una clave en db.
• El hash/firma del cargador está en dbx (revocado).
• Instalaste GRUB directamente (sin firma) en lugar de la ruta firmada por shim, o sobrescribiste el binario firmado.
• El firmware está configurado para no permitir CAs de terceros.

Shim: “Verification failed: (15)” después de seleccionar una entrada

Shim se está ejecutando, así que el firmware aceptó shim. Ahora shim está rechazando GRUB o el kernel porque no puede validar la siguiente etapa con su certificado incrustado o la lista MOK.

SBAT policy violation

Esto suele ser la lógica de revocación haciendo su trabajo. Tu build de shim/grub es lo bastante antiguo (o marcado como vulnerable) para que el dbx/SBAT actual lo bloquee. La solución suele ser arrancar con un shim/grub más reciente, no pelear contra la lista de revocación.

El sistema arranca, pero los controladores fallan: “Required key not available”

El kernel está aplicando la firma de módulos (a menudo porque Secure Boot está habilitado y entra en efecto el lockdown del kernel). Tu módulo de terceros (NVIDIA, DKMS, ZFS, VirtualBox) no está firmado con una clave que el kernel confíe. Eso no es un problema del db UEFI; es un problema del keyring del kernel/MOK.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las comprobaciones que ejecuto en sistemas reales. Cada tarea incluye: comando, qué significa la salida y qué decisión tomas a partir de ello. Los comandos asumen un entorno Linux; si no puedes arrancar normalmente, usa un USB live en modo UEFI y chroot donde se indica.

Tarea 1: Confirmar que el sistema arrancó en modo UEFI

cr0x@server:~$ test -d /sys/firmware/efi && echo "UEFI boot" || echo "Legacy boot"
UEFI boot

Significado: Si obtienes “Legacy boot”, el estado de Secure Boot es irrelevante porque no estás en arranque UEFI.

Decisión: Si es legacy, arregla primero el modo de arranque del firmware (desactiva CSM/Legacy). No toques las claves aún.

Tarea 2: Comprobar si Secure Boot está habilitado (vista en tiempo de ejecución)

cr0x@server:~$ mokutil --sb-state
SecureBoot enabled

Significado: “enabled” significa que el kernel cree que Secure Boot está activo. “disabled” puede significar que está apagado en el firmware o que arrancaste por una ruta que lo evita.

Decisión: Si está deshabilitado pero esperabas que estuviera activo, busca cambios en el firmware o arranque legacy.

Tarea 3: Comprobar si el firmware está en Modo Configuración (PK ausente)

cr0x@server:~$ mokutil --pk
PK is not enrolled

Significado: No tener PK normalmente significa Modo Configuración.

Decisión: Si la PK no está inscrita y quieres aplicación, debes restaurar/inscribir las claves (por defecto del proveedor o PK/KEK/db personalizados).

Tarea 4: Comprobar si las claves de Microsoft y del proveedor están presentes (verificación rápida)

cr0x@server:~$ sudo efi-readvar -v db | head
Variable db, length 2346
PKCS7 signature:
Signer: Microsoft Corporation UEFI CA 2011

Significado: Ver firmantes de Microsoft UEFI CA sugiere que el ancla de confianza común está presente en db.

Decisión: Si db está vacío o ilegible, restaura las claves por defecto (si tu política lo permite) o inscribe las tuyas.

Tarea 5: Inspeccionar dbx por revocaciones obvias que causen tu fallo

cr0x@server:~$ sudo efi-readvar -v dbx | head
Variable dbx, length 17892
Signature list 1
Signature type: X509

Significado: dbx está poblado. Eso es normal. Una combinación de “dbx demasiado nuevo + shim demasiado antiguo” puede romper arranques tras actualizaciones.

Decisión: Si el error es relacionado con SBAT, prioriza actualizar shim/grub en lugar de intentar revertir dbx.

Tarea 6: Ver qué binarios EFI existen y cuál estás arrancando

cr0x@server:~$ sudo ls -R /boot/efi/EFI | sed -n '1,80p'
/boot/efi/EFI:
Boot  ubuntu

/boot/efi/EFI/Boot:
BOOTX64.EFI

/boot/efi/EFI/ubuntu:
grubx64.efi  mmx64.efi  shimx64.efi

Significado: La presencia de shimx64.efi indica una ruta compatible con Secure Boot. Si solo tienes grubx64.efi y está sin firmar, el firmware puede rechazarlo.

Decisión: Si falta shim, reinstala el paquete shim-signed de la distro y registra la entrada de arranque.

Tarea 7: Comprobar las entradas de arranque UEFI y a qué archivo apuntan

cr0x@server:~$ sudo efibootmgr -v
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0001,0002
Boot0003* ubuntu	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
Boot0001* UEFI OS	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\Boot\BOOTX64.EFI)

Significado: Si tu entrada apunta directamente a grubx64.efi, y Secure Boot está activado, estás apostando a que ese binario será aceptado.

Decisión: Apunta la entrada a shim cuando corresponda, o arregla la firma/cadena de confianza de GRUB.

Tarea 8: Confirmar que shim/grub están realmente firmados (verificación a nivel de archivo)

cr0x@server:~$ sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
signature 1
image signature issuers:
 - /CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - /CN=Canonical Ltd. Secure Boot Signing

Significado: Si sbverify puede listar firmas y estas encadenan a algo plausible, el binario no está obviamente sin firmar.

Decisión: Si está sin firmar, reinstala desde paquetes de confianza. No copies binarios EFI de fuentes aleatorias.

Tarea 9: Comprobar el estado de inscripción MOK (común tras instalar módulos DKMS)

cr0x@server:~$ mokutil --list-enrolled | head
[key 1]
SHA1 Fingerprint: 9a:7c:...
Subject: CN=Local DKMS Signing

Significado: Existe una clave inscrita localmente. Útil si necesitas cargar módulos DKMS firmados.

Decisión: Si tus kernels/módulos fallan con “Required key not available”, probablemente necesites inscribir una clave (o firmar módulos con la existente).

Tarea 10: Ver lockdown del kernel y efectos de Secure Boot

cr0x@server:~$ dmesg | grep -i -E 'secureboot|lockdown' | head -n 20
[    0.000000] Secure boot enabled
[    0.532101] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7

Significado: El lockdown del kernel está activo; ciertas operaciones (como acceso bruto a MSR, kexec en algunos modos) pueden estar restringidas.

Decisión: Si una herramienta falla tras habilitar Secure Boot, confirma que es consecuencia del lockdown y no una “regresión aleatoria”.

Tarea 11: Diagnosticar fallos de firma de módulos (síntomas NVIDIA/DKMS)

cr0x@server:~$ sudo journalctl -k -b | grep -i -E 'module verification|Required key not available' | head
kernel: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7
kernel: nvidia: module verification failed: signature and/or required key missing

Significado: El sistema arrancó bien; ahora el kernel rechaza un módulo.

Decisión: Firma el módulo con una clave que el kernel confíe (a menudo via MOK), o usa módulos firmados por la distro cuando sea posible.

Tarea 12: Comprobar versiones instaladas de shim/grub (¿estás usando componentes de arranque antiguos?)

cr0x@server:~$ dpkg -l | egrep 'shim-signed|grub-efi-amd64-signed' || true
ii  grub-efi-amd64-signed  1.187.3+2.12-1ubuntu7  amd64  GRUB EFI signed kernel loader
ii  shim-signed            1.58+15.7-0ubuntu1     amd64  Secure Boot chain-loading bootloader (Microsoft-signed)

Significado: Puedes correlacionar estas versiones con si el sistema es probablemente compatible con SBAT y parchado.

Decisión: Si estás atrasado y ves fallos de política SBAT, actualiza estos paquetes desde tu repositorio normal.

Tarea 13: Validar la firma de la imagen del kernel (cuando tu distro firma kernels)

cr0x@server:~$ sbverify --list /boot/vmlinuz-$(uname -r) | head
signature 1
image signature issuers:
 - /CN=Canonical Ltd. Secure Boot Signing

Significado: Si el kernel está firmado y shim espera kernels firmados, esto debería parecer correcto.

Decisión: Si está sin firmar, probablemente estés ejecutando un kernel personalizado que necesita firma e inscripción MOK, o instalaste un kernel fuera del conjunto firmado de la distro.

Tarea 14: Reparar la entrada EFI para que apunte a shim (solución simple común)

cr0x@server:~$ sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "ubuntu-shim" -l '\EFI\ubuntu\shimx64.efi'
BootCurrent: 0003
BootOrder: 0007,0003,0001,0002
Boot0007* ubuntu-shim	HD(1,GPT,4d7b...,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)

Significado: Creaste una nueva entrada que arranca shim directamente.

Decisión: Si Secure Boot funciona después de esto, la entrada anterior apuntaba al binario incorrecto.

Tarea 15: Identificar si estás en una configuración “el firmware no permite terceros”

cr0x@server:~$ sudo efi-readvar -v db | grep -i -E 'Microsoft Corporation UEFI CA 2011|Windows UEFI' | head
Signer: Microsoft Windows UEFI Driver Publisher
Signer: Microsoft Corporation UEFI CA 2011

Significado: La presencia sugiere que db del firmware incluye claves de Microsoft. Aun así, algún firmware tiene un interruptor separado que desactiva el uso de CAs de terceros.

Decisión: Si db contiene la CA pero shim sigue sin arrancar, inspecciona la interfaz del firmware por la opción “third-party” o el modo “Standard/Custom” del proveedor.

Tarea 16 (live USB + chroot): Reinstalar componentes de arranque firmados limpiamente

cr0x@server:~$ sudo mount /dev/nvme0n1p2 /mnt
cr0x@server:~$ sudo mount /dev/nvme0n1p1 /mnt/boot/efi
cr0x@server:~$ for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind $i /mnt$i; done
cr0x@server:~$ sudo chroot /mnt bash -lc 'apt-get update && apt-get install --reinstall shim-signed grub-efi-amd64-signed && update-grub'
Reading package lists... Done
Setting up shim-signed ...
Setting up grub-efi-amd64-signed ...
Generating grub configuration file ...

Significado: Forzas una redeploy limpia de binarios EFI firmados y reconstruyes la configuración de GRUB.

Decisión: Si el sistema antes arrancaba con GRUB sin firmar o con un shim obsoleto, esto normalmente lo arregla—asumiendo que claves/modos están correctos.

Corregir la discordancia clave/modo: caminos prácticos

Hay tres estrategias sensatas. Elige una. Mezclarlas es como acabar en el purgatorio de “funciona hasta la próxima actualización”.

Camino A: Valores por defecto del proveedor + shim de la distro (recomendado para la mayoría)

Cuándo elegir: portátiles, servidores con distros mainstream, endpoints corporativos, cualquier cosa donde quieras una postura estándar y soportable.

Objetivo: El firmware permanece en Modo Usuario con claves del proveedor/Microsoft. Arrancas mediante el shim provisto por la distro y kernels/GRUB firmados. Si necesitas módulos DKMS, los firmas e inscribes una MOK.

Qué haces:

• En firmware: carga las claves por defecto (a menudo llamado “Install factory default keys” o “Restore factory keys”).
• Asegura que “Microsoft 3rd party UEFI CA” esté habilitado si tu distro la usa.
• En el SO: reinstala shim-signed y grub-efi-*-signed, asegúrate de que la entrada de arranque apunte a shim.
• Si tienes módulos sin firmar: genera una clave local de firma, inscríbela vía MOK manager y firma los módulos.

Camino B: Claves totalmente personalizadas (PK/KEK/db) para entornos de control alto

Cuándo elegir: sistemas regulados, appliances, entornos donde no quieras claves de Microsoft en tu almacén de confianza, o si distribuyes un producto y quieres un arranque determinista.

Objetivo: Controlas PK/KEK/db. Tomas la decisión de firmar shim/grub/kernel tú mismo (o usar un shim firmado por tus claves e inscribirlas). Mantienes tu propia lógica de revocación.

Verdad dura: esto implica trabajo operacional. Rotación de claves, procedimientos de recuperación, rarezas de UI de firmware y evitar bricks son ahora tu problema. Si no puedes comprometerte, elige el Camino A.

Camino C: Desactivar Secure Boot (solo cuando lo decidas)

Cuándo elegir: emergencia a corto plazo para restaurar servicio, sistemas de laboratorio, o como decisión política explícita con controles compensatorios.

Objetivo: Arrancar con fiabilidad ahora, y luego volver e implementar A o B correctamente.

Broma #2: Desactivar Secure Boot para arreglar Secure Boot es como arreglar una alarma de humo quitando la batería. El ruido para; el fuego no tiene por qué importarle.

Situaciones comunes de “discordancia de modo” y la solución limpia

Situación: PK borrada (Modo Configuración), Secure Boot “habilitado” y nada arranca consistentemente

Por qué ocurre: alguien borró las claves para “resetear todo” y dejó Secure Boot activado. Ahora estás en un estado que varía según el firmware del proveedor y a menudo rompe las cadenas esperadas.

Solución: restaura las claves por defecto de fábrica (Camino A) o inscríbete PK/KEK/db personalizados (Camino B). No lo dejes medio configurado.

Situación: El firmware no permite CA de terceros

Por qué ocurre: algunos sistemas tienen una opción que solo confía en claves de producción de Windows por defecto. Tu shim de Linux depende de la CA UEFI de terceros de Microsoft.

Solución: habilita la CA de terceros en el firmware, o inscribe el certificado del shim de tu distro en db (menos común, más tedioso), o adopta claves personalizadas completas.

Situación: Instalaste un kernel personalizado o un GRUB compilado por ti

Por qué ocurre: reemplazaste componentes firmados con versiones sin firmar y Secure Boot cumplió su función.

Solución: firma los binarios e inscribe la confianza adecuadamente. O revierte a paquetes firmados por la distro.

Situación: SBAT policy violation tras actualizaciones

Por qué ocurre: dbx/SBAT revocó builds antiguos vulnerables de shim/grub. Ahora tus binarios EFI instalados están bloqueados.

Solución: actualiza shim/grub a una versión no revocada usando un entorno de rescate, luego arranca normalmente. Evita revertir dbx salvo que aceptes deliberadamente el riesgo conocido.

Tres microhistorias corporativas del mundo de “funcionaba en mi portátil”

Incidente #1: la caída causada por una suposición equivocada

La empresa desplegaba una nueva imagen Linux para estaciones de trabajo de desarrolladores. El equipo de imagen la probó en tres modelos de portátiles y la dio por buena. El lunes, la cola de helpdesk se convirtió en un ataque de denegación de servicio—con recibos. La mitad de la flota arrancó con un error de firmware sobre firmas inválidas.

La suposición equivocada fue sutil: “Todos los proveedores incluyen la CA UEFI de terceros de Microsoft en db.” Muchos sí. Algunos no. Y algunos la incluyen pero la esconden detrás de un interruptor de BIOS que por defecto está “apagado” en ciertas regiones o perfiles de seguridad.

Lo que empeoró la situación: la imagen se había construido esperando que shim fuera aceptado, pero la entrada de arranque apuntaba directamente a grubx64.efi en un subconjunto de máquinas debido a una rareza del empaquetado durante el imaging. En máquinas con db permisivo funcionó; en firmware más estricto, no arrancó.

La solución no fue heroica. Estandarizaron configuraciones de firmware vía su herramienta de gestión, habilitaron explícitamente la CA de terceros donde se permitía, y actualizaron el proceso de imaging para registrar siempre la entrada de arranque hacia shim. La verdadera victoria fue el postmortem: añadieron una verificación previa en staging que validaba Secure Boot en cada SKU de hardware, no solo “lo que estaba cerca del banco de pruebas”.

Incidente #2: la optimización que salió mal

Un equipo de plataforma quería iteración rápida del kernel para un servicio sensible a latencia. Alguien propuso compilar un kernel personalizado con un conjunto pequeño de parches y desplegarlo en una flota de servidores de borde. También querían mantener Secure Boot habilitado—buena intención.

La “optimización” fue saltarse la canalización de firma. La teoría: “Ya estamos en el centro de datos; la seguridad física es fuerte; firmaremos después.” Empujaron el kernel por automatización, reiniciaron un canario y vieron que fallaba al arrancar por errores de firma. Eso se esperaba. Lo inesperado fue lo siguiente: su automatización interpretó la falla del canario como “el nodo está enfermo, reinícialo otra vez”, y creó una pequeña tormenta de reinicios en un subconjunto de máquinas antes de que alguien detuviera el trabajo.

Se recuperaron arrancando el kernel firmado anterior mediante la entrada de fallback del cargador—en las máquinas donde GRUB aún lo ofrecía. En las máquinas donde la configuración de arranque había sido “simplificada” a una sola entrada (para ahorrar un segundo de arranque), no hubo fallback. Esas requirieron rescate manual.

Lección: Secure Boot no rompe tu despliegue. Tu despliegue rompe tu despliegue. Si vas a distribuir kernels personalizados, la firma no puede ser algo de último momento. Es el artefacto de release.

Incidente #3: la práctica aburrida pero correcta que salvó el día

Un equipo de almacenamiento mantenía un clúster pequeño pero crítico que manejaba backups y archivos de largo plazo. Los servidores no eran glamorosos, que es precisamente por qué eran valiosos: cambiaban raramente y funcionaban siempre.

Tenían una política: cada vez que aplicaban actualizaciones de firmware registraban el estado de Secure Boot (habilitado/deshabilitado), el estado de inscripción de PK y las rutas actuales de las entradas EFI. El registro vivía en su ticket de cambio. Era aburrido, repetitivo y nadie fue promocionado por ello.

Un trimestre, una actualización de firmware reseteó silenciosamente las claves de Secure Boot en dos nodos. Los nodos siguieron arrancando, pero después un módulo del kernel usado para monitorizar HBA dejó de cargarse con “Required key not available.” El ingeniero on‑call no entró en pánico. Comparó el registro de cambios, vio que la inscripción MOK se había borrado, reinscribió la clave durante la ventana de mantenimiento y volvió a firmar los módulos. Sin pérdida de datos, sin caída prolongada, sin drama.

Lo mejor: el equipo no “lo arregló” desactivando Secure Boot. Arreglaron la discordancia y siguieron adelante. La fiabilidad es mayormente repetición poco sexy, más buenas notas.

Errores comunes: síntoma → causa raíz → solución

1) “Verification failed: (15)” tras la instalación

• Síntoma: shim se ejecuta, pero al seleccionar la entrada Linux falla.
• Causa raíz: GRUB o el kernel no están firmados por una clave que shim confíe; MOK no inscrito; o reemplazaste GRUB firmado por uno sin firmar.
• Solución: reinstala el paquete grub firmado; asegúrate de que la entrada apunte a shim; inscribe MOK y firma el kernel si usas builds personalizados.

2) Firmware “Invalid signature” antes de que aparezca cualquier menú

• Síntoma: rechazo inmediato al cargar binario EFI.
• Causa raíz: db del firmware no confía en el firmante del binario, o CA de terceros deshabilitada, o binario revocado por dbx.
• Solución: restaura claves por defecto y habilita CA de terceros; o inscribe tus propias claves y firma el binario EFI; o actualiza shim/grub si está revocado.

3) SBAT policy violation tras una actualización “normal”

• Síntoma: el sistema arrancó ayer; hoy shim lo rechaza con mensaje SBAT.
• Causa raíz: tu shim/grub es más antiguo que la política de revocación ahora aplicada vía dbx/SBAT.
• Solución: arranca con un medio de rescate, chroot, actualiza/reinstala shim/grub y verifica que la entrada EFI apunte al shim actualizado.

4) Arranca bien, pero NVIDIA/ZFS/VirtualBox falla: “Required key not available”

• Síntoma: controlador ausente, compilación DKMS exitosa pero el módulo no carga.
• Causa raíz: módulo no firmado con una clave en los keyrings de confianza del kernel; MOK no inscrito o borrado.
• Solución: inscribe una MOK y firma los módulos; re-dispara la firma DKMS; verifica mokutil --list-enrolled.

5) Alguien “borró las claves” para depurar y ahora todo está extraño

• Síntoma: Modo Configuración, comportamiento inconsistente entre reinicios, toggles de Secure Boot que no actúan como se espera.
• Causa raíz: PK eliminada; plataforma no está en un estado estable de Modo Usuario.
• Solución: restaura claves por defecto (Camino A) o implementa un conjunto de claves personalizadas completo (Camino B). Deja de borrar claves como paso de depuración.

6) Dual-boot roto tras reinstalar Windows o Linux

• Síntoma: un SO arranca; el otro falla con errores de firma o entradas faltantes.
• Causa raíz: entradas de arranque sobrescritas; binarios EFI reemplazados; claves del proveedor sin cambios pero la ruta ahora apunta a GRUB sin firmar.
• Solución: reconstruye entradas con efibootmgr; reinstala shim/grub para Linux; confirma que cada SO apunta a su cargador firmado correcto.

7) “SecureBoot disabled” en el SO pero el firmware dice que está habilitado

• Síntoma: discrepancia entre la UI del firmware y mokutil --sb-state.
• Causa raíz: arranque en modo legacy, o por una ruta que no aplica Secure Boot, o rarezas de implementación del firmware.
• Solución: verifica arranque UEFI vía /sys/firmware/efi; comprueba entradas de arranque; desactiva CSM.

Listas de verificación / plan paso a paso

Checklist 1: Comprobaciones mínimas antes de tocar ajustes del firmware

1. Confirma arranque UEFI: test -d /sys/firmware/efi.
2. Comprueba el estado de Secure Boot en tiempo de ejecución: mokutil --sb-state.
3. Verifica inscripción de PK: mokutil --pk.
4. Inspecciona entradas de arranque: efibootmgr -v.
5. Lista binarios EFI: ls -R /boot/efi/EFI.

Si no puedes arrancar: haz esto desde un USB live arrancado en modo UEFI, después de montar la partición del sistema EFI.

Checklist 2: Camino de reparación para “entrada de arranque incorrecta” (victoria rápida)

1. Monta ESP y confirma que existe shim: /boot/efi/EFI/<distro>/shimx64.efi.
2. Crea una nueva entrada UEFI apuntando a shim usando efibootmgr -c ... -l '\EFI\...\shimx64.efi'.
3. Pónla al principio de BootOrder (o configúrala explícitamente).
4. Reinicia y confirma que pasas la validación del firmware.

Checklist 3: Camino de reparación para “shim/grub antiguo revocado” (mismatch SBAT/dbx)

1. Arranca un entorno de rescate/live actualizado en modo UEFI.
2. Monta el filesystem raíz y la ESP; bind-monta /dev, /proc, /sys, /run.
3. Chroot e reinstala paquetes firmados de shim/grub.
4. Ejecuta update-grub (o equivalente de la distro).
5. Verifica que la entrada de arranque apunte al shim actualizado.

Checklist 4: Camino de reparación para “firma de módulos requerida” (arranca pero drivers fallan)

1. Confirma fallo de módulos en logs: journalctl -k -b.
2. Comprueba la lista MOK: mokutil --list-enrolled.
3. Si no existe una clave adecuada: crea una (con herramientas de la distro), inscribe y reinicia vía MOK manager.
4. Firma módulos (o reconstruye DKMS para que firme automáticamente).
5. Confirma que el módulo carga: modprobe <module> y revisa logs.

Checklist 5: Política segura para flotas (qué estandarizar)

1. Documenta si confías en la CA UEFI de terceros de Microsoft o en claves personalizadas.
2. Estandariza toggles de firmware (Secure Boot habilitado, CA de terceros permitida si hace falta, CSM deshabilitado).
3. Pincha o estratifica actualizaciones de shim/grub; evita que binarios EFI antiguos permanezcan.
4. Tener un flujo de rescate que pueda actualizar shim/grub desde medios offline.
5. Registra procedimientos de inscripción MOK para sistemas con mucho DKMS.

Preguntas frecuentes

1) ¿Por qué falló Secure Boot justo después de instalar? Si no cambié nada.

Porque el instalador sí lo hizo. Puede haber creado una entrada de arranque apuntando al binario EFI equivocado, instalado un GRUB sin firmar, o asumido claves del firmware que tu sistema no tiene (o tiene deshabilitadas).

2) ¿Cuál es la diferencia entre borrar claves y desactivar Secure Boot?

Desactivar Secure Boot apaga la aplicación. Borrar claves elimina el estado PK/KEK/db y a menudo te pone en Modo Configuración. Borrar claves puede crear un estado a medias roto; desactivar es al menos determinista.

3) Si shim está firmado por Microsoft, ¿significa que Microsoft controla mi arranque de Linux?

No. La firma de Microsoft permite que el firmware ejecute shim. Después de eso, shim aplica las siguientes verificaciones usando certificados de la distro y/o MOK. Tu modelo de confianza depende de qué claves aceptes en db del firmware y qué confía shim.

4) Veo “Secure boot enabled” y “Kernel is locked down.” ¿Es eso malo?

Es un trade‑off. Lockdown reduce la superficie de ataque (bueno) y bloquea algunas herramientas a bajo nivel (a veces molesto). Si tu flujo de trabajo necesita esas herramientas, decide deliberadamente si quieres Secure Boot y lockdown en esa máquina.

5) ¿Puedo simplemente firmar GRUB yo mismo y dejar todo lo demás igual?

Sí, pero debes asegurarte de que el firmante sea de confianza para el componente que lo valida. El firmware valida la primera etapa que ejecuta; shim valida la siguiente etapa basándose en certificados incrustados y MOK. Firmar sin inscribir la confianza es solo producir bits caros.

6) ¿Por qué falla un driver aunque el sistema arranca?

Porque la validación de Secure Boot en el arranque y la aplicación de firma de módulos en tiempo de ejecución son capas separadas. Tu kernel puede estar firmado y aceptado, pero un módulo compilado por DKMS puede seguir sin firmar y ser rechazado.

7) ¿Qué es SBAT y por qué me arruina el día de repente?

SBAT es un mecanismo para revocar componentes de arranque vulnerables con mayor precisión. Si tu shim/grub es demasiado antiguo, la política SBAT puede bloquearlo. La solución suele ser actualizar shim/grub, no pelear contra la lista de revocación.

8) Hago dual‑boot. ¿Debería usar claves personalizadas?

Normalmente no, salvo que disfrutes manteniendo un programa de gestión de claves en tu tiempo libre. Valores por defecto del proveedor + shim de la distro es el enfoque más soportable para sistemas de arranque dual.

9) ¿Qué hago si no puedo arrancar en absoluto y necesito la máquina ya?

Arranca un USB live en modo UEFI, monta el sistema y reinstala shim/grub firmados como se muestra arriba. Si la política lo permite, desactiva temporalmente Secure Boot para recuperar acceso, luego corrige las claves y vuelve a activar.

10) ¿Cómo sé si el problema es db/dbx o MOK?

Si el firmware rechaza antes de shim, es db/dbx/confianza a nivel de firmware. Si shim se ejecuta pero rechaza GRUB/kernel, es confianza de shim/MOK/certificados de la distro. Si el SO arranca pero los módulos fallan, es keyrings del kernel/firma de módulos MOK.

Siguientes pasos que deberías hacer

Los fallos de Secure Boot tras la instalación rara vez son “aleatorios”. Normalmente son una expectativa rota: el firmware aplica un modelo de confianza, tu cadena de arranque instalada fue construida para otro, y claves/modos no coinciden.

1. Ejecuta las comprobaciones de diagnóstico rápido: arranque UEFI, estado de Secure Boot, presencia de PK, objetivo de la entrada de arranque.
2. Elige una estrategia: valores por defecto del proveedor + shim de la distro (la mayoría de los casos) o claves personalizadas completas (solo si puedes operarlo).
3. Repara la cadena de arranque con el cambio más pequeño: apunta entradas a shim, reinstala shim/grub firmados, actualiza si SBAT/dbx bloquea builds antiguos.
4. Si necesitas módulos DKMS, trata la inscripción MOK y la firma de módulos como parte de la canalización de build, no como un ritual nocturno.
5. Escribe lo que cambiaste en el firmware. El tú del futuro es otra persona, y no merece sorpresas.

Si haces esto bien, Secure Boot deja de ser una ruleta. Se convierte en lo que debería haber sido: una puerta predecible que solo se abre al software en el que explícitamente confías.