El próximo 11 de septiembre expirará el certificado de Microsoft de 2011 utilizado para firmar el bootloader de primera etapa conocido como "shim", un componente esencial que permite a las distribuciones Linux arrancar en sistemas con Secure Boot habilitado. A partir de esa fecha, los medios de instalación de Linux que dependan de ese certificado ya no podrán arrancar con Secure Boot activo, a menos que el firmware del equipo haya sido actualizado para incluir la nueva clave de Microsoft de 2023, disponible desde hace dos años pero presente en una cantidad aún indeterminada de dispositivos.
El problema fue planteado por Mateus Rodrigues Costa en la lista de correo de desarrollo de Fedora el 8 de julio, tras detectar una advertencia incluida en una actualización acumulativa de Windows 11 que mencionaba la expiración de otros certificados de Secure Boot a partir de junio de 2026. Aunque esos certificados son distintos al que afecta a Linux, el caso puso sobre la mesa una cuestión más amplia que la comunidad del software libre deberá resolver en los próximos meses.
El mecanismo es complejo: Secure Boot requiere que el bootloader de primera etapa esté firmado con una clave reconocida en la base de datos del firmware UEFI. Desde hace más de una década, las distribuciones Linux han utilizado un shim firmado por Microsoft con una clave de 2011. Una vez que el shim valida la cadena de confianza mediante claves específicas de cada distribución, se puede cargar GRUB y, posteriormente, el kernel. Las instalaciones ya existentes que cuenten con un shim firmado por su propia distribución deberían seguir funcionando sin cambios, ya que la cadena de confianza interna no depende de la clave de Microsoft.
El verdadero problema afecta a quienes intenten instalar Linux desde cero en equipos con Secure Boot habilitado. Para esos casos existen tres escenarios posibles: sistemas con la clave antigua únicamente (dejarán de poder instalar Linux con Secure Boot tras septiembre), sistemas con ambas claves (podrán hacerlo), y sistemas con solo la clave nueva (es probable que ya no puedan hacerlo). Los fabricantes pueden distribuir actualizaciones de firmware que añadan la nueva clave, y para facilitar ese proceso existen el Linux Vendor Firmware Service (LVFS) y la herramienta fwupd, que permiten instalar actualizaciones de firmware desde Linux.
Daniel P. Berrangé, de Red Hat, señaló que las versiones recientes de fwupd ya están preparadas para gestionar estas actualizaciones, aunque advirtió que los usuarios deben estar atentos a posibles problemas. Richard Hughes, desarrollador principal de fwupd, confirmó que las actualizaciones de KEK (Key Exchange Key) tienen una tasa de éxito cercana al 98%, y las actualizaciones de la base de datos (db) alrededor del 99%, pero recordó que incluso un pequeño porcentaje de fallos multiplicado por millones de equipos supone un número considerable de dispositivos afectados. Además, existe un problema conocido de espacio en las variables EFI que puede impedir la instalación de la actualización y que en algunos casos solo se resuelve restaurando la BIOS a sus valores de fábrica.
Como señaló Gerd Hoffman, el proceso de actualización de KEK nunca se había llevado a cabo antes a esta escala, lo que aumenta el riesgo de errores por parte de los fabricantes de BIOS. Hughes también reveló que al menos un fabricante ha perdido la parte privada de su clave de plataforma (PK), lo que obligaría a sustituir las claves grabadas en el hardware, una situación sin precedentes y calificada como "una idea terrible desde el punto de vista de la atestación".
Para los usuarios cuyos fabricantes no ofrezcan actualizaciones, la única alternativa viable será desactivar Secure Boot. Adam Williamson, de Red Hat, apuntó además que una posible solución temporal sería distribuir shims antiguos para sistemas con firmware desactualizado, aunque el propio Williamson reconoció que esta estrategia puede no ser práctica, y Hoffman advirtió de que mantener un shim con vulnerabilidades conocidas anula en gran medida el propósito de tener Secure Boot activado.
En conjunto, la comunidad Linux enfrenta un nuevo episodio de dependencia respecto a hardware controlado por fabricantes que priorizan Windows. Aunque se espera que la mayoría de los sistemas no queden inutilizables, el proceso requerirá un esfuerzo coordinado entre distribuidores, fabricantes y usuarios en un plazo muy corto.