Sono le traduzioni di due post che James Bottomley ha preso sul suo blog. Il primo post è stato pubblicato l'1 febbraio e si chiama "LCA2013 and Restructuring the Secure Boot"
Sono stato in silenzio per un po', quindi è ora di un aggiornamento su cosa sta succedendo con il Secure Boot Loader della Linux Foundation (soprattutto da quando è stato presentato all'LCA2013). ( Link alle slide )
Il problema principale è che GregKH (Greg Kroah-Hartman, uno sviluppatore del kernel) ha scoperto all'inizio di dicembre che il Pre-BootLoader proposto non avrebbe funzionato nella sua forma attuale con Gummiboot. Questo è stato scoraggiante perché significava che non stava realizzando la missione della Linux Foundation di abilitare tutti i bootloader. Il motivo, dopo un'indagine, si è rivelato semplice: Gummiboot è stato creato per dimostrare che era possibile realizzare un bootloader piccolo e semplice che sfruttasse tutti i servizi disponibili sulla piattaforma UEFI, invece di essere un massiccio link loader come GRUB. Sfortunatamente, questo significa che avvia i kernel utilizzando la funzione BootServices->LoadImage(), il che implica che il kernel da avviare deve superare i controlli di avvio sicuro sulla piattaforma UEFI. In origine, il Pre-BootLoader, come shim (il bootloader di Mathew Garrett), era stato scritto per utilizzare il caricamento dei link PE/Coff per aggirare i controlli di avvio sicuro. Sfortunatamente, ciò significa che qualsiasi operazione eseguita dal Pre-BootLoader deve utilizzare anche il caricamento tramite link per superare i controlli di avvio sicuro su qualsiasi elemento che intenda caricare, e pertanto Gummiboot, che non è volutamente un caricatore tramite link, non funzionerà con questo schema.
Quindi ho dovuto ristrutturare e riscrivere: il problema ora è passato da "come creare un caricatore di link firmato da Microsoft che obbedisca alle loro politiche" a "come abilitare tutti i figli del boot loader a utilizzare la funzione BootServices-> LoadImage () di modo di obbedire alle loro politiche. Fortunatamente, esiste un modo per intercettare l'infrastruttura di firma della piattaforma UEFI installando il proprio protocollo di sicurezza dell'architettura. Sfortunatamente, la specifica di inizializzazione della piattaforma non fa effettivamente parte della specifica UEFI, ma per fortuna è implementata da ogni sistema Windows 8 che puoi trovare. La nuova architettura intercetta quel protocollo e aggiunge il proprio controllo di sicurezza. Tuttavia, c'è un secondo problema: mentre siamo nel callback del protocollo di sicurezza dell'architettura, non possediamo necessariamente la schermata del sistema UEFI, rendendo completamente impossibile eseguire un test utente per autorizzare l'esecuzione del binario. Fortunatamente, esiste un modo non interattivo per eseguire questa operazione, ovvero il meccanismo SUSE Machine Owner Key (MOK). Pertanto, il Pre-BootLoader di Linux Foundation si è ora evoluto per utilizzare variabili MOK standard per memorizzare gli hash binari autorizzati.
Il risultato di tutto ciò è che ora puoi usare Pre-BootLoader con Gummiboot (proprio come è stato fatto nella demo a LCA2013). Per avviare, devi aggiungere 2 hash: uno per lo stesso Gummiboot e l'altro per il kernel che vuoi avviare, ma in realtà è una buona cosa perché ora hai un'unica politica di sicurezza che controlla l'intera sequenza di avvio. Anche lo stesso Gummiboot è stato patchato per riconoscere un bug dovuto all'avvio sicuro e visualizza un messaggio che ti dice quale hash registrare.
Farò un post a parte per spiegare come funziona la nuova architettura, ma ho pensato che sarebbe stato meglio spiegare cosa è successo il mese scorso.
E questo secondo post l'ha fatto ieri e si chiama "Launched the Linux Foundation Secure Boot System"
Come promesso, ecco il Linux Foundation Secure Boot System. In realtà ci è stato rilasciato da Microsoft il 6 febbraio, ma con i viaggi, le conferenze e le riunioni non ho avuto il tempo di convalidare tutto fino ad oggi. I file sono:
Precaricatore.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Crea anche un'immagine mini-USB avviabile; (Devi installarlo sull'USB usando dd; l'immagine ha partizioni GPT, quindi utilizza l'intero disco). Ha una shell EFI dove dovrebbe essere il kernel e usa gummiboot per caricarlo. Potete trovare qui (md5sum 7971231d133e41dd667a184c255b599f).Per utilizzare l'immagine mini-USB, è necessario inserire gli hash per loader.efi (nella cartella \ EFI \ BOOT) e shell.efi (nella cartella principale). Include anche una copia di KeyTool.efi, devi inserire l'hash per eseguire.
Cosa è successo a KeyTool.efi? Inizialmente doveva far parte del nostro kit firmato. Tuttavia, durante i test Microsoft ha scoperto che a causa di un bug in una delle piattaforme UEFI, potrebbe essere utilizzato per rimuovere la chiave della piattaforma a livello di programmazione, il che rovinerebbe il sistema di sicurezza UEFI. Fino a quando non saremo in grado di risolvere questo problema (abbiamo il venditore privato nel giro), si sono rifiutati di firmare KeyTool.efi sebbene tu possa autorizzarlo aggiungendo variabili MOK se vuoi eseguirlo.
Fammi sapere come va perché sono interessato a raccogliere feedback su cosa funziona e cosa no. In particolare, temo che l'override del protocollo di sicurezza non funzioni su alcune piattaforme, quindi desidero in particolare sapere se non funziona per loro.
Fuentes:
http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/
http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/
Decidi se è una buona o cattiva notizia.