Două noutăți cu privire la pre-bootloader

Sunt traducerile a două postări pe care James Bottomley le-a luat pe blogul său. Prima postare a fost făcută pe 1 februarie și se numește „LCA2013 și restructurarea bootului sigur”

Am rămas un pic liniștit, așa că este timpul să dau o actualizare cu privire la ceea ce se întâmplă cu Secure Boot Loader de la Linux Foundation (mai ales că a fost prezentat la LCA2013). (Link către diapozitive)

Esența problemei este că GregKH (dezvoltatorul de kernel Greg Kroah-Hartman) a descoperit la începutul lunii decembrie că Pre-BootLoader propus nu va funcționa în forma sa actuală cu Gummiboot. Acest lucru a fost oarecum descurajant, deoarece a însemnat că nu îndeplinea misiunea Fundației Linux de a activa toți bootloaderii. În cercetare, motivul a fost simplu: Gummiboot a fost creat pentru a demonstra că puteți face un bootloader mic și simplu care să profite de toate serviciile disponibile pe platforma UEFI în loc să fie un încărcător de legături masiv precum GRUB. Din păcate, înseamnă că porniți nucleele folosind funcția BootServices-> LoadImage (), ceea ce înseamnă că nucleul care trebuie pornit trebuie să treacă prin verificările de pornire securizate de pe platforma UEFI. Inițial Pre-BootLoader, cum ar fi shim (Bootloader-ul lui Mathew Garrett), a fost scris pentru a utiliza încărcarea legăturilor PE / Coff pentru a bate verificările de boot sigure. Din păcate, înseamnă că ceva executat de Pre-BootLoader trebuie să folosească, de asemenea, încărcarea link-urilor pentru a depăși controalele de boot sigure pentru tot ceea ce dorește să încarce și, prin urmare, Gummiboot, care nu este în mod deliberat un link loader, nu va funcționa în cadrul acestei scheme.

Așa că a trebuit să restructurez și să rescriu: problema a trecut acum de la „cum să creezi un link loader semnat de Microsoft care le respectă politicile” la „cum să permiți tuturor copiilor încărcătorului de boot să folosească funcția BootServices-> LoadImage () a mod de a le respecta politicile. Din fericire, există o modalitate de a intercepta infrastructura de semnare a platformei UEFI prin instalarea propriului protocol de securitate arhitecturală. Din păcate, specificațiile de inițializare a platformei nu fac parte din specificația UEFI, dar din fericire este implementată de fiecare sistem Windows 8 pe care îl puteți găsi. Noua arhitectură interceptează acel protocol și adaugă propria verificare de securitate. Cu toate acestea, există o a doua problemă: în timp ce ne aflăm în apelarea protocolului de securitate a arhitecturii, nu deținem neapărat ecranul sistemului UEFI, ceea ce face complet imposibilă efectuarea unui test de utilizator pentru a autoriza executarea binarului. Din fericire, există o modalitate non-interactivă de a face acest lucru și acesta este mecanismul SUSE Machine Owner Key (MOK). Prin urmare, Linux Foundation Pre-BootLoader a evoluat acum pentru a utiliza variabile MOK standard pentru a stoca hash-uri binare autorizate.

Rezultatul tuturor acestor lucruri este că acum puteți folosi Pre-BootLoader cu Gummiboot (la fel cum s-a făcut în demo la LCA2013). Pentru a porni, trebuie să adăugați 2 hash-uri: unul pentru Gummiboot în sine și celălalt pentru nucleul pe care doriți să-l porniți, dar de fapt este un lucru bun, deoarece acum aveți o singură politică de securitate care controlează întreaga secvență de pornire. Gummiboot în sine a fost, de asemenea, corectat pentru a recunoaște o eroare din cauza boot-ului sigur și afișează un mesaj care vă spune care hash să vă înscrieți.

Voi face un post separat care să explice cum funcționează noua arhitectură, dar m-am gândit că ar fi mai bine să explic ce s-a întâmplat luna trecută.

Și acest al doilea post l-a făcut ieri și se numește „A lansat Linux Foundation Secure Boot System”

După cum am promis, iată Linux Foundation Secure Boot System. De fapt, ne-a fost lansat de Microsoft pe 6 februarie, dar cu călătoriile, conferințele și întâlnirile nu am avut timp să validez totul până astăzi. Fișierele sunt:

PreLoader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
De asemenea, creați o imagine mini-USB bootabilă; (Trebuie să-l instalați pe USB folosind dd; imaginea are partiții GPT, deci folosește întregul disc). Are un shell EFI unde ar trebui să fie nucleul și folosește gummiboot pentru al încărca. O găsiți aici (md5sum 7971231d133e41dd667a184c255b599f).

Pentru a utiliza imaginea mini-USB, trebuie să introduceți hashurile pentru loader.efi (în folderul \ EFI \ BOOT) și shell.efi (în folderul rădăcină). De asemenea, include o copie a KeyTool.efi, trebuie să introduceți hashul pentru a rula.

Ce s-a întâmplat cu KeyTool.efi? Inițial urma să facă parte din trusa noastră semnată. Cu toate acestea, în timpul testării, Microsoft a descoperit că, din cauza unei erori pe una dintre platformele UEFI, ar putea fi folosită pentru a elimina programatic cheia platformei, ceea ce ar strica sistemul de securitate UEFI. Până când vom putea rezolva acest lucru (avem furnizorul privat în buclă), au refuzat să semneze KeyTool.efi, deși îl puteți autoriza adăugând variabile MOK dacă doriți să îl rulați.

Spuneți-mi cum merge acest lucru, deoarece sunt interesat să strâng feedback despre ceea ce funcționează și ce nu. În special, sunt îngrijorat de faptul că suprascrierea protocolului de securitate nu va funcționa pe unele platforme, așa că vreau în mod special să știu dacă nu funcționează pentru ele.

Fuentes:

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

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

Decideți dacă este o veste bună sau proastă.