Dues notícies pel que fa a el pre-bootloader

Són les traduccions de dos posts que ha tret James Bottomley al seu bloc. El primer post el va fer l'1 de febrer i es diu «LCA2013 i Reestructurant el Secure Boot»

Vaig estar silenciós per una estona, així que és hora de donar una actualització sobre què és el que passa amb el Secure Boot Loader de la Linux Foundation (Especialment amb què va ser presentat a la LCA2013). (Link a les diapositives)

L'escència del problema és que GregKH (Greg Kroah-Hartman, desenvolupador del nucli) va descobrir a principis de desembre que el Pre-BootLoader proposat no funcionaria en la seva forma actual amb Gummiboot. Això va ser una mica descoratjador perquè significava que no complia la missió de la Linux Foundation d'activar tots els bootloaders. A la investigació, la raó era simple: Gummiboot va ser creat per demostrar que podies fer un bootloader simple i petit que aprofités tots els serveis disponibles a la plataforma UEFI en comptes de ser un carregador d'enllaços massiu com ho és GRUB. Malauradament significa que booteja kernels usant la funció BootServices->LoadImage(), la qual vol dir que el kernel a ser bootejat ha de passar a través de les revisions de secure boot a la plataforma UEFI. Originalment el Pre-BootLoader, com fustes (el bootloader de Mathew Garrett), va ser escrit per utilitzar la càrrega d'enllaços PE/Coff per vèncer les revisions de secure boot. Malauradament, vol dir que alguna cosa executada pel Pre-BootLoader ha d'usar també la càrrega d'enllaços per vèncer les revisions de secure boot en qualsevol cosa que vulgui carregar i per tant Gummiboot, que deliberadament no és un carregador d'enllaços, no funcionarà sota aquest esquema.

Així que vaig haver de reestructurar i reescriure: El problema ara va passar de ser «com crear un carregador d'enllaços signat per Microsoft que obeeixi les seves polítiques» a «com activar tots els fills del boot loader per utilitzar la funció BootServices->LoadImage() de manera que obeeixi les seves polítiques». Afortunadament, hi ha una manera d'interceptar la infraestructura de signatura de la plataforma UEFI instal·lant el vostre propi protocol de seguretat d'arquitectura. Malauradament, l'especificació de la inicialització de la plataforma no és realment part de l'especificació de UEFI, però afortunadament és implementada per tots els sistemes de Windows 8 que pugui trobar. La nova arquitectura intercepta aquest protocol i afegeix la seva pròpia revisió de seguretat. Tot i això, hi ha un segon problema: Mentre estem al callback del protocol de seguretat d'arquitectura, no necessàriament posseïm la pantalla del sistema UEFI, fent que sigui completament impossible fer una prova d'usuaris per autoritzar l'execució del binari. Afortunadament, hi ha una manera no interactiva de fer-ho i és el mecanisme Machine Owner Key (MOK) de SUSE. Per tant, El Pre-BootLoader de la Linux Foundation ara va evolucionar per utilitzar les variables MOK estàndard per guardar hashes de binaris autoritzats.

El resultat de tot això és que ara es pot utilitzar el Pre-BootLoader amb Gummiboot (tal com es va fer a la demo a la LCA2013). Per bootejar, cal afegir 2 hashes: un per al Gummiboot en si i l'altre per al nucli que es vol bootejar, però de fet és bo perquè ara es té una sola política de seguretat controlant tota la seqüència d'arrencada. El Gummiboot en si també va ser pegat per reconèixer una fallada a causa del secure boot i mostra un missatge dient-te quin hash cal inscriure.

Faré un post separat explicant com funciona la nova arquitectura, però vaig pensar que seria millor explicar què va passar el darrer mes.

I aquest segon post ho va fer ahir i es diu «Llançat el Sistema de Secure Boot de la Linux Foundation»

Tal com va ser promès, aquí hi ha el Sistema d'Secure Boot de la Linux Foundation. En veritat va ser llançat a nosaltres per Microsoft el 6 de febrer, però amb els viatges, conferències i reunions no vaig tenir temps per validar tot fins avui. Els arxius són:

PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
També creeu una imatge mini-USB bootable; (cal instal·lar-lo a l'USB usant dd; la imatge té particions GPT, així que utilitza tot el disc). Té un shell EFI on ha d'estar el kernel i utilitza gummiboot per carregar-lo. Podeu trobar-lo aquí (md5sum 7971231d133e41dd667a184c255b599f).

Per utilitzar la imatge mini-USB, cal inscriure els hashes per al loader.efi (a la carpeta \EFI\BOOT) i el shell.efi (a la carpeta arrel). També inclou una còpia de KeyTool.efi cal inscriure el hash perquè corri.

Que va passar amb el KeyTool.efi? Originalment anava a ser part del nostre kit signat. No obstant això, durant les proves Microsoft va descobrir que a causa d'un error en una de les plataformes UEFI, podia ser usat per eliminar la clau de la plataforma programàticament, la qual cosa arruïnaria el sistema de seguretat de UEFI. Fins que puguem resoldre això (tenim a el venedor particular en el loop), van rebutjar signar el KeyTool.efi encara que es pot autoritzar afegint variables MOK si volen córrer.

Deixeu-me saber com segueix això perquè estic interessat a reunir feedback sobre què funciona i que no. En particular, em preocupa que el override del protocol de seguretat no funcioni en algunes plataformes, així que vull saber particularment si no els funciona.

Fonts:

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

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

Decidiu vostès si són bones o males notícies.