El panorama del desarrollo del kernel Linux no es ni mucho menos idílico, de hecho, el título de “dictador benevolente” que muchos le ponen a Linus Torvalds no procede de la nada, sino porque su forma de gestionar termina generando muchos conflictos con otras personas, sobre todo debido a que resulta difícil introducir puntos de vista diferentes a la que tiene el “gran líder”.

Hace dos días se pudo ver en la lista de correo de Linux otro encontronazo entre Matthew Garrett, exdesarrollador de Red Hat que actualmente trabaja para Google, y Linus Torvalds. El centro de la discusión fue una serie de parches para bloquear el kernel. Aunque pueda sonar sorprendente, Torvalds no está en contra de poder bloquear el kernel, sino más bien de la postura que mantiene Garrett. Al parecer, el jefe de Linux teme que en caso de que el bloqueo sea habilitado explícitamente con Secure Boot, este luego no pueda ser desactivado fácilmente. Esto es lo que ha comentado en su respuesta en la lista de correo:

Míralo de la siguiente manera: a lo mejor el bloqueo rompe alguna aplicación porque esta aplicación hace algo extraño. Recibo un informe de que eso está sucediendo, y sucede que quien ha reportado está utilizado la misma distribución que yo, así que lo intento sobre la misma configuración del kernel y me funciona.

Es totalmente no obvio que quien ha reportado ejecuta un kernel de una distribución que tiene Secure Boot habilitado, y yo obviamente no lo tengo.

¿Ves cuál es el problema aquí? Intentar estas cosas mágicamente juntas es una mala idea.

Según se puede entender, parece que Torvalds teme que Secure Boot altere el comportamiento de ciertos componentes o ciertos procesos dentro del kernel, razón por la cual no quiere atar el bloqueo a la característica de UEFI. Por otro lado, Matthew Garrett es uno de los principales defensores de Secure Boot dentro del espectro Linux, postura que ha mantenido incluso antes de recalar en Google.

Después del encontrazo con el jefe de Linux en la lista de correo, Matthew Garrett publicó en su blog las razones de por qué defiende unir el bloqueo del kernel con Secure Boot, diciendo sobre lo primero que “si root es capaz de modificar un kernel en ejecución, las garantías se van. Como resultado, tiene sentido extender la política de seguridad desde el entorno de arranque hasta el kernel en ejecución. En realidad es solo una extensión de la configuración del kernel para requerir módulos firmados.”

Sobre el porqué quiere el bloqueo en el arranque mediante Secure Boot, argumenta lo siguiente:

Secure Boot de UEFI está diseñado para evitar el arranque de cualquier cargador cuyo propietario no esté considerado como confiable. Pero el cargador de arranque es solo software, así que lo único que distingue es, digamos, que Firefox es ese Firefox que se ejecuta en modo usuario y no tiene acceso directo al hardware. El kernel tiene acceso directo al hardware, así que no existe una distinción significativa entre lo que Grub puede hacer y lo que el kernel pude hacer. Si puede ejecutar código arbitrario en el kernel, entonces puede usar el kernel para arrancar cualquier cosa que quiera, lo que frustra el punto de UEFI Secure Boot. Las distribuciones Linux no quieren que sus kernels sean usados como parte de una cadena de ataques contra otras distribuciones o sistemas operativos, por lo que habilitan el bloqueo (o una función equivalente) para los kernels arrancados de esta manera.

Más adelante, en la misma entrada, Matthew Garrett expone lo siguiente para justificarse:

En genreal: el conjunto de parches no es controvertido, solo la forma en que se integra con UEFI Secure Boot. La razón por la que está integrado con el arranque seguro de UEFI es porque esa es la política que la mayoría de las distribuciones quieren, ya que la alternativa es habilitarla en todas partes, incluso cuando no proporciona beneficios reales, pero sí una sobrecarga de soporte adicional. Puede utilizarlo incluso si no está utilizando UEFI Secure Boot. Deberíamos de llamarlo nivel de seguridad.

Veremos en qué acaba esta discusión, pero conocido es que la relación entre Mattew Garrett y Linus Torvalds es de todo menos buena. De hecho, hace tres años el primero tomó la decisión de abandonar el desarrollo de Linux y bifurcarlo, pero parece que pocos le siguieron, así que por eso habrá retomado su contribución a la rama oficial.