Archivi tag: Secure Boot

Secure Boot: troppo facile da aggirare

Edit: prontamente, subito prima di pubblicare questo articolo, ho fatto un upgrade totale con pacman -Syu come avevo fatto più volte con vari aggiornamenti del kernel nel mezzo e questi aggiornamenti non sovrascrivono il bootloader o PreLoader o cose del genere.
Prontamente, “Boot failed: Access denied”, con una grafica diversa da quella del BIOS buggato che lo dice a prescindere anche se poi lascia avviare. E dopo un laggone bestiale in cui sembra che tutto si sia piantato, si apre l’HashTool da solo. Deduco che a generare l’errore adesso è PreLoader, che non ho aggiornato perché dovrei copiare a mano i file in /boot per aggiornarlo, quindi non so che diamine stia succedendo.

Alla fine, differentemente da tutte le altre volte, è stato necessario aggiungere l’hash di /boot/vmlinuz-linux alle MOK, cosa che non avevo mai fatto, ricordo benissimo.
O mi sta andando in pappa il cervello e ricordo male, o il metodo non funziona più. Nel dubbio lo pubblico comunque.

Inoltre, qualcuno ha descritto la procedura anche sulla wiki ufficiale di Arch, con annesso workaround per BIOS ancora più buggati dove il menu di avvio nella NVRAM è puramente decorativo perché avviano solo il bootloader di Windows riconoscendolo dal nome del file.
Ormai l’articolo l’ho scritto quindi, reitero, lo pubblico comunque.


Nell’ultima puntata: il dannato notebook può avviare solo con UEFI, solo con Secure Boot e solo con la chiave Microsoft.

Forse si può sostituire la PK usando il KeyTool ma non sono interamente sicuro che sia possibile o ragionevole da fare, visto che non c’è verso di attivare la Setup Mode e non ho voglia di rovistare ancora tra le frammentarie informazioni presenti su internet per capire se basta firmare il kernel con la PK o se bisogna per forza passare dalle altre chiavi, cioè dalla chiave Microsoft.

Se è obbligatorio usare quest’ultima, cosa succede se la chiave privata Microsoft cade in mano a dei malintenzionati: si può revocare? E se sì, io poi cosa avvio? O continuo a usare software firmato con una chiave non sicura, vanificando completamente l’aspetto Secure che compone metà del nome Secure Boot, o non avvio più nulla perché non posso caricare altre chiavi. Vanificando l’aspetto Boot, che è pure peggio.

Ma insomma, abbiamo già perso troppo tempo, vediamo come aggirare Secure Boot per avviare Linux senza neanche firmare i kernel o aggiungerne l’hash alle MOK.

Continua a leggere

Secure Boot: gestire le chiavi con KeyTool

Avevo detto “adesso installo Linux” e continuo a parlare d’altro, ma questo argomento è di notevole importanza.

Stando a quanto ho trovato su internet, tutti i BIOS UEFI semidecenti dovrebbero avere delle opzioni per attivare la Setup Mode e gestire le chiavi\database di chiavi (PK, KEK, DB, DBX, anche se alcuni sono certificati e altri hash e altri database di chiavi\certificati\hash, ma chiamiamole comunque chiavi perché tutti le chiamano chiavi).

Da ciò posso concludere che tutti i 3 BIOS UEFI che ho visto finora sono indecenti perché non hanno nessuna di quelle opzioni.

Fortunatamente, esiste un aggeggio chiamato KeyTool che fa parte di PreLoader, o almeno su Arch sta nel pacchetto di PreLoader.
L’obiettivo è avviare KeyTool.efi.

Continua a leggere

Secure Boot: non disattivabile

Nell’ultima puntata: l’HashTool non è una via percorribile, i *buntu vanno e Kali Linux non supporta Secure Boot nonostante venga dichiarato il contrario, cioè, ehm, sono io che sono stupido e non so farlo funzionare, sì sì, proprio così.

Arch è la mia salvezza, perché funziona sempre. Al primo colpo. O al massimo al secondo. Anche se aggiungere l’hash del kernel alle MOK con l’HashTool (sì, è questo che si fa) non è una via per me ottimale, è partito subito. Senza neanche dover cercare cosa dovevo fare. Poi l’ho cercato comunque per sincerarmi di non star piallando la chiave Microsoft o qualcosa del genere.

Comunque, Arch include questa UEFI Shell: vediamo di che si tratta.

Continua a leggere

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.

Continua a leggere