Linux y Secure Boot. Un error que no podemos repetir

Linux y Secure Boot

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.


El contenido del artículo se adhiere a nuestros principios de ética editorial. Para notificar un error pincha aquí.

2 comentarios, deja el tuyo

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

  1.   Curefox dijo

    Exacto, nadie en el universo GNU/Linux debe seder ante Microsoft ni ninguna empresa, debemos ser la resistencia y abogar por la libertad en la computación, ya suficiente tenemos con las cárceles de los teléfonos móviles, como para que ahora nos tengamos que tragar exigencias que solo benefician a una empresa.

  2.   ja dijo

    Hasta donde yo se , nunca las decisiones de Microsoft han beneficiado ni siquiera a su propio ecosistema, solo es una cuestion de marketing en la creencia de que si no puedes ejecutar tpm 2, cambiaras de computadora solo para poder ejecutar w 11, si algo tienen grande en microsoft es el ego, el futuro es linux no windows, y para mi la decision de microsoft es lo mejor para acercar usuarios a linux