Due novità riguardanti il ​​pre-bootloader

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 aggiornare su cosa sta succedendo con il Secure Boot Loader di Linux Foundation (soprattutto che è stato presentato a LCA2013). (Link alle diapositive)

L'essenza del problema è che GregKH (sviluppatore del kernel Greg Kroah-Hartman) ha scoperto all'inizio di dicembre che il Pre-BootLoader proposto non avrebbe funzionato nella sua forma attuale con Gummiboot. Era un po 'scoraggiante perché significava che non stava adempiendo alla missione della Linux Foundation di attivare tutti i bootloader. Nella ricerca, il motivo era semplice: Gummiboot è stato creato per dimostrare che è possibile creare un bootloader piccolo e semplice che sfrutti tutti i servizi disponibili sulla piattaforma UEFI invece di essere un enorme link loader come GRUB. Sfortunatamente significa che avvii i kernel usando la funzione BootServices-> LoadImage (), il che significa che il kernel da avviare deve passare attraverso i controlli di avvio sicuro sulla piattaforma UEFI. Originariamente il Pre-BootLoader, come shim (Bootloader di Mathew Garrett), è stato scritto per utilizzare il caricamento del collegamento PE / Coff per sconfiggere i controlli di avvio sicuro. Sfortunatamente, significa che qualcosa eseguito dal Pre-BootLoader deve anche utilizzare il caricamento del collegamento per battere i controlli di avvio sicuro su tutto ciò che vuole caricare e quindi Gummiboot, che non è deliberatamente un caricatore di 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.