Secure Boot: la maledizione

Secure Boot è una porcheria invereconda che dovrebbe fornire all’utente un falso senso di sicurezza, oltre a portare all’esasperazione quei pazzi che vogliono avviare un sistema operativo che non sia Windows installato dall’OEM.

La cosa che mi lascia assai sorpreso è che gli OEM, per appicicare il logo di Windows 8 sui loro pc, secondo i dettami di Microsoft, devono attivare Secure Boot di default e lasciare obbligatoriamente all’utente la possibilità di disattivarlo.

Con Windows 10 pare che invece la possibilità di disattivarlo sia diventata opzionale, quindi verrà immediatamente rimossa da tutti gli OEM in simultanea. Con Windows 11 probabilmente verranno a spararmi un colpo di fucile nella schiena se cerco di avviare Linux.

Secure Boot

Definiamolo meglio: per ragioni di presunta sicurezza, il bootloader o il kernel o qualcosa del genere del sistema operativo deve essere firmato con una chiave nota al BIOS\UEFI, così si può stare certi che verrà avviato solo il sacrosantissimo sistema operativo benedetto con l’acqua santa e che parte tra i cori angelici, e non qualche pericolosissimo malware come Linux.

Non ho capito cosa deve essere firmato perché, nel tentativo di aggirare il vincolo, sono stati orditi una valanga di sistemi in cui un bootloader ne firma un altro ma non lo firma e lo verifica e carica l’hash del kernel che non è una firma e poi il kernel e poi si mettono cose dentro e fuori da dei database e poi ci sono una serie di chiavi e chiavistelli e database di chiavi e le chiavi in realtà sono certificati e… insomma, non si capisce nulla.

Per firmare il kernel bisogna implorare Microsoft, perché essa detiene l’unica vera chiave™. Altre chiavi possono essere caricate nell’UEFI (che detto così suona malissimo, chissà dove vengono inserite…) e usate per verificare le firme, ma non lo fa nessuno. Poi si possono anche mandare le chiavi agli OEM e chiedere di inserirle nell’UEFI di tutti i loro pc. Seh, buonanotte.

Quindi, come diamine si fa con Linux? La via migliore è sicuramente disattivare Secure Boot. Su un computer l’ho fatto e tutto funziona che è una meraviglia; il pc da cui scrivo boota in “legacy mode” avendo ancora Windows 7, che è un’altra via. E poi c’è una cosa chiamata CSM e smanettando un po’ con le opzioni del BIOS relative si ottiene l’effetto di bootare in legacy mode o una via di mezzo. Non so cosa sia di preciso.

L’aggeggio

Ora, mi è capitato tra le mani un notebook con Windows 8.1 preinstallato.

Ne ho approfittato per verificare che il Task Manager di 10, che avevo lodato, è lo stesso di 8.
E per confermare che Windows 8 è un’aberrazione della natura che non merita di esistere.

Pialliamo tutto e installiamo Linux! Yaaaaay!

Arch Linux & Secure Boot

Come chiaramente spiegato nella wiki, con Arch la cosa funziona così: all’avvio UEFI urla in preda al panico che sto cercando di avviare un OS che non ha ricevuto la benedizione, poi si apre l’HashTool che credo faccia parte di PreLoader che è un software Linux ma firmato da Microsoft quindi parte senza problemi, e con quello si può aggiungere gli hash di un qualcosa di Arch a nonsocosa e poi avviare da quelli e finalmente Arch va.

Chiaro come il fango (perché non ho voglia di approfondire), ma almeno funziona.

L’unica fonte di informazioni decente su Secure Boot che trovo in tutta internet, oltre alla wiki di Arch, è il manuale di rEFInd, in cui l’autore ci fa sapere che usando PreLoader\HashTool a ogni aggiornamento del kernel bisogna aggiungere il nuovo hash e gli hash finiscono nella NVRAM.

Non è una buona idea, ma proprio per nulla, con Arch: passi aggiungere gli hash, ma vanno nella NVRAM? Dove il BIOS getta la sua spazzatura… ehm… impostazioni e roba varia? E se si riempie che succede?

I BIOS dignitosi hanno delle opzioni per eliminare tutte le chiavi non di default, che non so se eliminino anche gli hash, ma questo non ha nulla di tutto ciò. Ma ci tornerò dopo.

Kubuntu & Secure Boot

I *buntu vari non usano Preloader ma shim, o forse hanno il kernel firmato da Microsoft, non ho ben capito e non ho capito se stanno riempiendo la NVRAM di chiavi di nascosto o hanno trovato un’altra soluzione al problema, ma si avviano senza fare storie, come se non ci fosse Secure Boot.

Beh, Kubuntu parte. Il touchpad è buggato, ma smanettando con i driver o Xorg o entrambi probabilmente si può far funzionare, non ho ancora approfondito.

Comunque KDE non mi piace. Volevo dargli una seconda possibilità ma è inutile e non ho minimamente voglia di perdere tempo con le impostazioni, sapendo che tutti i *buntu sono fatti talmente male che appena si devia dai default va tutto in frantumi… ehm… volevo dire, che sono io che non so configurarli perché sono un idiota.

E per favore, Unity no. Se tutto manca ricorro a Xubuntu, ma insomma, preferirei un’altra distro, ad esempio Arch perché funziona o Debian perché non devo installare aggiornamenti ogni due minuti.

Kali Linux & Secure Boot

Volevo solo avviare la live, non installarla.

Non sono né un pentester né un bimbominkia dodicenne che si crede un grande hacker, ma avendo già la chiavetta USB pronta è il modo più facile di vedere se la scheda wifi riesce ad andare in monitor mode.

Avvio e ovviamente non parte perché non supporta il boot EFI.

Scopro che da Kali 2.0 in poi o giù di lì il boot con Secure Boot è supportato senza alcuna complicazione o manovra da parte dell’utente e io ho una versione precedente: scarico la nuova, la sbatto sulla chiavetta e avvio.

Solito errore di kernel non firmato: Image failed to verify with *ACCESS DENIED*. Ok, adesso mi aprirà l’HashTool, no?

No, parte Windows.

Le ricerche su Google sono infruttuose: c’è un lunghissimo thread pieno di informazioni dichiarate obsolete su come tirare fuori il bootloader da Fedora e buttarlo sull’USB di Kali e configurare GRUB e tutto magicamente dovrebbe funzionare, ma non ho neanche voglia di provarci perché sono informazioni dichiaratamente obsolete.

Mi ricordo che sulla USB di Arch c’era anche una UEFI Shell, vediamo di improvvisare qualcosa con quella.

Nella prossima puntata.

Annunci

4 pensieri su “Secure Boot: la maledizione

  1. Pingback: Secure Boot: non disattivabile | while(false) do {/*nothing*/};

  2. fausto

    Un bagno di sangue, par di capire. Il mio HP compaq di sei anni fa comincia a perdere colpi e vorrei una macchina nuova; ma se con la roba di oggi l’installazione del pinguino è un simile calvario allora lascio perdere e vado a cercare un rottame in discarica.

    Rispondi
    1. M. Numerio Autore articolo

      Mah, guarda, Ubuntu e affini in qualche modo si avviano senza fare una piega anche con secure boot, probabilmente fanno uso della magia oscura. Io l’ho fatta tanto lunga perché volevo installare Arch e soprattutto aggirare quell’infernale trabiccolo invece di piegarmi al suo volere e aggiungere chiavi e hash di qua e di là. Peccato che il metodo di aggiramento non funzioni più.

      Tanto alla fine si farà come si è sempre fatto: si cercano i pareri dei malcapitati che hanno già tentato di installare Linux su quello specifico modello di computer prima di acquistare qualsiasi cosa. E se tutto manca, c’è sempre la discarica…

      Rispondi

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione /  Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione /  Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione /  Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione /  Modifica )

Connessione a %s...