Dos noticias con respecto al pre-bootloader

Son las traducciones de dos posts que ha sacado James Bottomley en su blog. El primer post lo hizo el 1° de febrero y se llama “LCA2013 y Reestructurando el Secure Boot”

Estuve silencioso por un rato, así que es hora de dar una actualización sobre qué es lo que pasa con el Secure Boot Loader de la Linux Foundation (Especialmente con que fue presentado en la LCA2013). (Link a las diapositivas)

La escencia del problema es que GregKH (Greg Kroah-Hartman, desarrollador del kernel) descubrió a principios de diciembre que el Pre-BootLoader propuesto no funcionaría en su forma actual con Gummiboot. Eso fue algo desalentador porque significaba que no cumplía la misión de la Linux Foundation de activar todos los bootloaders. En la investigación, la razón era simple: Gummiboot fue creado para demostrar que podías hacer un bootloader simple y pequeño que aprovechara todos los servicios disponibles en la plataforma UEFI en vez de ser un cargador de enlaces masivo como lo es GRUB. Desafortunadamente significa que bootea kernels usando la función BootServices->LoadImage(), la cual significa que el kernel a ser booteado tiene que pasar a través de los chequeos de secure boot en la plataforma UEFI. Originalmente el Pre-BootLoader, como shim (el bootloader de Mathew Garrett), fue escrito para usar la carga de enlaces PE/Coff para vencer los chequeos de secure boot. Desafortunadamente, significa que algo ejecutado por el Pre-BootLoader debe usar también la carga de enlaces para vencer los chequeos de secure boot en cualquier cosa que quiera cargar y por lo tanto Gummiboot, que deliberadamente no es un cargador de enlaces, no funcionará bajo este esquema.

Así que tuve que reestructurar y reescribir: El problema ahora pasó de ser “como crear un cargador de enlaces firmado por Microsoft que obedezca sus políticas” a “como activar todos los hijos del boot loader para usar la función BootServices->LoadImage() de forma que obedezca sus políticas”. Afortunadamente, hay una forma de interceptar la infraestructura de firmado de la plataforma UEFI instalando tu propio protocolo de seguridad de arquitectura. Desafortunadamente, la especificación de la inicialización de la plataforma no es en verdad parte de la especificación de UEFI, pero afortunadamente es implementada por todos los sistemas de Windows 8 que pueda encontrar. La nueva arquitectura intercepta ese protocolo y añade su propio chequeo de seguridad. Sin embargo, hay un segundo problema: Mientras estamos en el callback del protocolo de seguridad de arquitectura, no necesariamente poseemos la pantalla del sistema UEFI, haciendo que sea completamente imposible hacer una prueba de usuarios para autorizar la ejecución del binario. Afortunadamente, existe una manera no interactiva de hacerlo y es el mecanismo Machine Owner Key (MOK) de SUSE. Por lo tanto, El Pre-BootLoader de la Linux Foundation ahora evolucionó para usar las variables MOK estandar para guardar hashes de binarios autorizados.

El resultado de todo esto es que se puede ahora usar el Pre-BootLoader con Gummiboot (tal como se hizo en la demo en la LCA2013). Para bootear, hay que añadir 2 hashes: uno para el Gummiboot en sí y el otro para el kernel que se quiere bootear, pero de hecho es algo bueno porque ahora se tiene una sóla política de seguridad controlando toda la secuencia de arranque. El Gummiboot en sí también fue parcheado para reconocer un fallo debido al secure boot y muestra un mensaje diciendote cual hash hay que inscribir.

Haré un post separado explicando como funciona la nueva arquitectura, pero pensé que sería mejor explicar lo que pasó el último mes.

Y este segundo post lo hizo ayer y se llama “Lanzado el Sistema de Secure Boot de la Linux Foundation”

Tal como fue prometido, aquí está el Sistema de Secure Boot de la Linux Foundation. En verdad fue lanzado a nosotros por Microsoft el 6 de febrero, pero con los viajes, conferencias y reuniones no tuve tiempo para validarlo todo hasta hoy. Los archivos son:

PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
También cree una imagen mini-USB bootable; (hay que instalarlo en el USB usando dd; la imágen tiene particiones GPT, así que usa todo el disco). Tiene un shell EFI donde debe estar el kernel y usa gummiboot para cargarlo. Pueden encontrarlo aquí (md5sum 7971231d133e41dd667a184c255b599f).

Para usar la imagen mini-USB, hay que inscribir los hashes para el loader.efi (en la carpeta \EFI\BOOT) y el shell.efi (en la carpeta raiz). Tambien incluye una copia de KeyTool.efi hay que inscribir el hash para que corra.

Que pasó con el KeyTool.efi? Originalmente iba a ser parte de nuestro kit firmado. Sin embargo, durante las pruebas Microsoft descubrió que debido a un bug en una de las plataformas UEFI, podía ser usado para eliminar la clave de la plataforma programáticamente, lo cual arruinaría el sistema de seguridad de UEFI. Hasta que podamos resolver esto (tenemos al vendedor particular en el loop), rechazaron firmar el KeyTool.efi aunque se puede autorizarlo añadiendolas variables MOK si quieren correrlo.

Dejenme saber como sigue esto porque estoy interesado en reunir feedback sobre que funciona y que no. En particular, me preocupa que el override del protocolo de seguridad no funcione en algunas plataformas, así que quiero saber particularmente si no les funciona.

Fuentes:

http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/

http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/

Decidan ustedes si son buenas o malas noticias.