En el artículo anterior recordaba un antecedente de la exigencia de Microsoft de exigir el módulo TPM versión 2 para poder utilizar Windows 11. Me estoy refiriendo a la exigencia de que los equipos que trajeran Windows 8 preinstalado utilizaran UEFI en lugar de BIOS para el gestor de arranque y que el módulo Secure Boot estuviera preinstalado.  Ahora voy a hablar de la, a mi criterio, forma errónea en la que Linux afrontó el problema.

Linux y Secure Boot

Secure Boot exige que cada programa que se inicia tenga una firma que garantice su autenticidad almacenada en la base de datos de la memoria no volátil de la placa base. Para figurar en esa base de datos hay dos caminos. Que la incluya el fabricante o que la incluya Microsoft.

La solución al que llegaron algunas distribuciones Linux con Microsoft fue que esta empresa aceptara la firma de un binario que sería el encargado de lanzar el gestor  de arranque de cada distribución. Estos binarios se pusieron a disposición de la comunidad.

Posteriormente, la Fundación Linux lanzaría una solución genérica que puede ser adoptada por todas las dsitribuciones.

Buscando una solución mejor, un desarrollador de Red Hat le propuso a Linus Torvalds lo siguiente:

Hola Linus,

¿Puedes incluir este conjunto de parches, por favor?

Proporciona una función mediante la cual las claves se pueden agregar dinámicamente a un kernel que se ejecuta en modo de arranque seguro. Para permitir que se cargue una clave bajo tal condición, requerimos que la nueva clave esté firmada por una clave que ya tenemos (y en la que confiamos), donde las claves que «ya tenemos» podrían incluir aquellas incrustadas en el kernel, aquellas en la base de datos UEFI y las del hardware criptográfico.

Ahora, «keyctl add» ya manejará los certificados X.509 que están así firmados, pero el servicio de firma de Microsoft solo firmará binarios de EFI PE ejecutables.

Podríamos requerir que el usuario reinicie en el BIOS, agregue la clave y luego vuelva a cambiar, pero en algunas circunstancias queremos poder hacer esto mientras el kernel se está ejecutando.

La forma que se nos ha ocurrido para solucionar esto es incrustar un certificado X.509 que contiene la clave en una sección llamada «.keylist» en un binario de EFI PE y luego obtener el binario firmado por Microsoft

Palabra de Linus

La respuesta de Linus (Recordemos que fue antes de su retiro espiritual para reconsiderar su actitud en las relaciones a otras personas), fue la siguiente:

AVISO: el siguiente texto incluye groserías

Chicos, esto no es un concurso de chupar pollas.

Si desean utilizar los binarios de PE, continúen. Si Red Hat quiere profundizar sus relaciones con Microsoft, ese es * su * problema. Eso no tiene nada que ver con el kernel que mantengo. Es fácil para ustedes tener un motor de firma que analice el binario PE, verifique las firmas y firme las claves resultantes con su propia clave.  El código, por el amor de Dios ya está escrito., está en esa maldita solicitud de inclusión.

¿Por qué debería importarme? ¿Por qué debería importarle al núcleo alguna estupidez idiota de «solo firmamos binarios PE»? Admitimos X.509, que es el estándar para firmar.

Esto se puede hacer a nivel usuario. No hay excusa para hacerlo en el kernel.

Linus

Mi opinión es que Linus, por una vez estaba en lo correcto. De hecho ni la Fundación Linux ni las distribuciones debieron someterse al chantaje de Microsoft.  Es cierto que se podrían haber perdido usuarios. Pero, como se demostró más tarde, Windows 8 fue un fracaso y XP siguió reinando durante mucho tiempo más.

La realidad es que cuando se le presenta batalla a Microsoft, se la obliga a respetar los estándares. Pasó cuando fracasó con SIlverlight y se vio obligada  a adoptar el estándar web HTML 5. Sucedió cuando tuvo que abandonar el desarrollo de motor de renderizado web y basar Edge en Chromium.

Tampoco hay que olvidar que para atraer programadores tuvo que incluir nada menos que la posibilidad de ejecutar Linux en Windows.

Las distribuciones Linux están  en mejor posición que nunca de ofrecer a los usuarios una alternativa para seguir utilizando un hardware perfectamente funcional.