Linus Torvalds non vuole integrare all'interno kernel Linux le chiavi necessarie alle varie distribuzioni per non avere problemi in fase di avvio con il Secure Boot presente sui nuovi PC Windows 8 con UEFI. Il carismatico guru del mondo open non ha usato mezzo termini per rendere noto il suo disappunto verso tale soluzione, come spiegato su Arstechnica, e ha dato vita a un acceso scontro.
Esistono diverse soluzioni (qui un esempio) per far funzionare le distribuzioni Linux con i PC dotati di Secure Boot, ma è chiaro che integrare le chiavi nel kernel, firmate da Microsoft, spazzerebbe via il problema in un sol colpo. È proprio a questo che sta lavorando David Howells, sviluppatore di Red Hat, il quale ha sollecitato Torvalds a prendere visione di un insieme di modifiche.
"Il patchset fornisce una funzione attraverso le quali le chiavi possono essere aggiunte dinamicamente a un kernel che opera in modalità secure boot. Per permettere a una chiave di essere caricata in tale condizione, richiediamo che una nuova chiave sia firmata attraverso una chiave che abbiamo già (e verificato) - dove le chiavi che 'abbiamo già' potrebbero includere quelle integrate nel kernel, quelle nel database UEFI e quelle nell'hardware crittografico", ha scritto Howells.
"Ora 'keyctl add' gestisce certificati X.509 che sono perciò firmati, ma il servizio di Microsoft firmerà solo binari EFI PE (Extensible Firmware Interface Portable Executable) eseguibili. Si potrebbe richiedere all'utente il riavvio all'interno del BIOS, l'aggiunta della chiave e poi tornare indietro, ma in alcune circostanze vogliamo essere in grado di fare tutto questo con il kernel in funzione. La soluzione che abbiamo messo a punto per aggirare il problema prevede l'integrazione di un certificato X.509 contenente la chiave in una sezione chiamata '. keylist' in un binario EFI PE e quindi ottenere il binario firmato da Microsoft".
Tecnicismi e valore della proposta a parte, Torvalds non ci ha messo molto per definire tale soluzione "incredibilmente stupida" (fucking moronic). Matthew Garrett, sviluppatore di Red Hat che da tempo sta lavorando sul Secure Boot e noto per aver scoperto i problemi tra Linux, UEFI e PC di Samsung e non solo, è intervenuto facendo notare che "c'è solo un'autorità per la firma, e firmano solo i binari", facendo riferimento a Microsoft.
A sua volta Torvalds ha replicato con un linguaggio scurrile, da censura, ma che vi riportiamo "papale papale" non avendo altra scelta. "Ragazzi, questa non è una gara di pompini. Se volete analizzare i binari PE, andate avanti. Se Red Hat vuole fare un pompino a Microsoft, questo è un vostro problema. Questo non ha nulla a che fare con il kernel che curo. È banale per voi ragazzi avere sistema di firma che analizza il binario PE, verifica le firme, e firma le chiavi risultanti con la vostra chiave. Hai già scritto il codice, per l'amor di Dio, è una richiesta stupida".
"Perché dovrei occuparmene? […] Supportiamo X.509, che è lo standard per le firme. […] Non ci sono scuse per farlo nel kernel", ha concluso Torvalds, ricordando come si possa fare a livello "user" (utente). La discussione è chiaramente proseguita, con Howells che ha espresso dubbi sull'idea di Linus e Garrett che ha ribadito come modificare il kernel sia la cosa più pratica. È intervenuto anche Greg Kroah-Hartman, mainteiner del branch stabile del kernel Linux, facendo notare che diverse distribuzioni permettono già scenari di dual-boot Linux/Windows 'per via dell'UEFI bootloader/shim che Microsoft ha già firmato'".
Chiaramente il botta e risposta è destinato ad andare avanti e il tema è importante, perché il tema del Secure Boot si trascina ormai da mesi, prima tra allarmismi di ogni tipo - giustificati da un'iniziale mancanza di chiarezza - e ora tra diverse soluzioni più o meno valide e questa richiesta di risolvere il problema alla radice modificando il kernel. C'è da scontrarsi però con Torvalds, la sua autorità e intransigenza verso alcune scelte che per altri potrebbero essere la soluzione migliore. Torvalds rimane l'autorità ultima sul codice che deve essere integrato all'interno del kernel Linux standard e questo è certamente un bene, ma a volte anche un male. Riuscirà la comunità a trovare una soluzione condivisa? Un dubbio amletico che ci tormenterà nelle prossime nottate.