El próximo 11 de septiembre expirará el certificado Microsoft de 2011 que la gran mayoría de distribuciones Linux utilizan para firmar el shim, el cargador de arranque de primera etapa que permite arrancar el kernel con Secure Boot activado. A partir de esa fecha, los medios de instalación de Linux no podrán iniciarse en sistemas con Secure Boot a menos que el firmware del equipo ya incluya la nueva clave Microsoft 2023 UEFI para terceros, disponible desde 2023 pero que muchos fabricantes aún no han desplegado en sus equipos.
El problema, planteado por Mateus Rodrigues Costa en la lista de correo de desarrollo de Fedora el pasado 8 de julio tras detectar una advertencia en una actualización acumulativa de Windows 11, es más complejo de lo que parece a simple vista. El certificado que expira en septiembre es distinto del mencionado en los avisos de Windows sobre caducidades a partir de junio de 2026, pero ambos forman parte del mismo ecosistema de confianza que sustenta Secure Boot.
Para entender la magnitud del desafío hay que distinguir tres elementos clave: la Platform Key (PK), grabada en el hardware por el fabricante; la Key Exchange Key (KEK), específica del vendor y firmada por Microsoft; y la base de datos (db) que contiene las claves de firma permitidas. El Linux Vendor Firmware Service (LVFS) y la herramienta fwupd, desarrollada por Richard Hughes, son las piezas centrales de la solución, ya que permiten a los usuarios actualizar el firmware desde Linux sin necesidad de herramientas propietarias.
Según los datos compartidos por Hughes, las actualizaciones KEK tienen una tasa de éxito aproximada del 98%, mientras que las actualizaciones de db rondan el 99%. Aunque los porcentajes parezcan alentadores, multiplicados por los millones de equipos afectados pueden traducirse en un número significativo de fallos. Un problema recurrente es la falta de espacio contiguo en efivarfs, una región del firmware UEFI donde se almacenan las variables; la solución que funciona para algunos usuarios consiste en reiniciar y restablecer la BIOS a valores de fábrica, lo que desencadena una desfragmentación del espacio disponible. Cuanto más antiguo sea el firmware, mayor será la probabilidad de encontrar este obstáculo.
Las complicaciones adicionales son varias. Por un lado, al menos un fabricante ha perdido acceso a la parte privada de su clave de plataforma, lo que obligaría a reemplazar las claves grabadas en el hardware, una situación inédita y que, en palabras de Hughes, resulta una terrible idea desde el punto de vista de la certificación de identidad. Por otro lado, como señaló Gerd Hoffman, nunca antes se había realizado una actualización KEK, por lo que existe el riesgo real de que algunos vendors hayan implementado mal el proceso y sus actualizaciones fallen silenciosamente.
Las distribuciones ya instaladas en equipos funcionales no deberían verse afectadas, ya que cuentan con cargadores de arranque firmados con sus propias claves, que mantienen la cadena de confianza incluso después del 11 de septiembre. El problema real afecta a quienes intenten instalar Linux de nuevo o a quienes necesiten actualizar el shim por motivos de seguridad, ya que Microsoft se ha negado a firmar nada con el certificado caducado. Continuar ejecutando un shim con vulnerabilidades conocidas, como señaló Hoffman, hace que mantener Secure Boot activado carezca en buena medida de sentido.
Daniel P. Berrangé, de Red Hat, reconoció que versiones antiguas de fwupd no resolvían todos los escenarios, pero que las versiones recientes han sido mejoradas para gestionar las actualizaciones que los usuarios necesitarán, lo que debería mitigar el peor de los impactos. No obstante, recomendó a los usuarios estar atentos a posibles inconvenientes y confiar en que los vendedores de sistemas operativos y mantenedores absorban la mayor parte de la complejidad técnica.
Queda una incógnita sin resolver: no está del todo claro si las implementaciones de firmware aplicarán estrictamente la fecha de expiración del certificado de 2011. Un sistema en pleno funcionamiento con una cadena de confianza basada en esa clave podría seguir operando con un shim firmado por ella incluso después de septiembre. Adam Williamson, también de Red Hat, planteó la posibilidad teórica de distribuir un shim antiguo para esos casos, aunque reconoció que la heurística necesaria para decidir cuándo instalarlo resultaría poco práctica y que lo más sensato para muchos usuarios sería desactivar Secure Boot.
En conjunto, la comunidad Linux se prepara para una transición incómoda pero gestionable. La mayoría de los equipos no quedará inutilizable, pero el proceso de instalación de nuevas distribuciones con Secure Boot activado se complicará notablemente, especialmente en hardware antiguo o de fabricantes que no proporcionen actualizaciones de firmware a través de LVFS. El desenlace dependerá en gran medida de la voluntad y la agilidad de los fabricantes, que en muchos casos priorizan el soporte de Windows sobre el ecosistema Linux.