Installazione e firma di moduli kernel personalizzati su Secure Boot SLES 15

Su SUSE Linux Enterprise Server 15, un driver di terze parti potrebbe compilarsi correttamente ma non caricarsi, restituendo gli errori "Chiave richiesta non disponibile" o "Chiave rifiutata dal servizio". Quando UEFI Secure Boot impone la firma dei moduli, la soluzione consiste nel firmare il modulo del kernel personalizzato con un certificato attendibile, registrare tale certificato tramite la gestione della chiave proprietaria della macchina (MOK) e quindi caricare il modulo normalmente, senza disabilitare Secure Boot.

Questa procedura presuppone un sistema UEFI SLES 15 standard che utilizza SUSE shim, un kernel-defaultkernel, i diritti di amministratore e una fonte attendibile per il driver. Si concentra sui .komoduli personalizzati, non sulla firma di un kernel sostitutivo o sulla modifica delle chiavi della piattaforma firmware. Gli esempi seguono il modello di amministrazione di SLES 15 SP6/SP7; verificare le differenze di pacchetto e di kernel sul service pack installato.

1. Verifica prima Secure Boot e il kernel in esecuzione.

Accedi con i privilegi di amministratore e identifica il kernel che hai effettivamente avviato. La sola corrispondenza del nome del pacchetto non garantisce che un modulo possa essere caricato in quel kernel.

uname -r
mokutil --sb-state
ls -ld "/lib/modules/$(uname -r)/build"

Se mokutilSecure Boot è abilitato, una firma non attendibile è una probabile spiegazione per un errore di caricamento relativo alla chiave. Se è disabilitato, indaga su altre cause prima di generare le chiavi; anche l'applicazione esplicita della firma del kernel può essere rilevante. Controlla il log del kernel dopo un caricamento fallito per il messaggio di rifiuto effettivo.

sudo journalctl -k -b --no-pager | tail -n 50

Prima di installare il modulo candidato, ispezionalo. Sostituisci il nome del file di esempio con quello reale; vermagicdeve corrispondere alla versione del kernel in esecuzione e alle proprietà di compilazione compatibili.

modinfo -F name /path/to/mydriver.ko
modinfo -F vermagic /path/to/mydriver.ko

2. Utilizzare un pacchetto driver supportato o creare un modulo corrispondente

Innanzitutto, richiedete al fornitore dell'hardware o del software un pacchetto del modulo del kernel (KMP) già firmato e compatibile con SLES. Questa soluzione è preferibile all'installazione manuale di un file binario: il fornitore potrebbe infatti occuparsi della gestione degli aggiornamenti del kernel e fornire una procedura documentata per la registrazione dei certificati. La firma del fornitore non è automaticamente considerata attendibile su ogni macchina con Secure Boot.

Se è necessario compilare il driver, installare i file di sviluppo corrispondenti al kernel in esecuzione. Per quanto riguarda la kernel-defaultversione, i pacchetti SLES standard includono il pacchetto di sviluppo del kernel predefinito, i file di sviluppo del kernel e gli strumenti di compilazione. La disponibilità del repository e le versioni dipendono dalla registrazione e dai moduli SLES abilitati.

sudo zypper install gcc make openssl mokutil kernel-devel kernel-default-devel
rpm -q kernel-default-devel kernel-devel
readlink -f "/lib/modules/$(uname -r)/build"

Se la directory di compilazione non è presente o il pacchetto di sviluppo è destinato a una versione del kernel diversa, è necessario prima risolvere l'incompatibilità tra pacchetto e kernel. Un kernel appena installato potrebbe richiedere un riavvio controllato prima di poterlo utilizzare per la compilazione.

Dalla directory sorgente del driver attendibile, utilizzare le istruzioni di compilazione del fornitore. Per i moduli convenzionali basati su kbuild, il comando seguente esegue la compilazione sul kernel in esecuzione; non scarica né crea un driver autonomamente.

cd /path/to/driver-source
make -C "/lib/modules/$(uname -r)/build" M="$PWD" modules

Salta la compilazione se disponi già di una versione compatibile .koda un fornitore affidabile. Non forzare mai il caricamento di un modulo con la versione errata vermagic; una firma non può riparare un binario incompatibile.

3. Creare la chiave di firma e firmare il modulo installato

Genera una chiave RSA e un certificato X.509 dedicati in una directory accessibile solo dall'utente root. Il certificato pubblico verrà registrato; la chiave privata deve rimanere protetta perché chiunque la controlli può firmare moduli aggiuntivi di cui questa macchina potrebbe fidarsi.

sudo -i
umask 077
mkdir -p /root/module-signing
cd /root/module-signing
openssl req -new -x509 -newkey rsa:3072 -sha256 -days 3650 -nodes \
  -subj "/CN=SLES Custom Module Signing/" \
  -keyout MOK.priv -out MOK.pem
openssl x509 -in MOK.pem -outform DER -out MOK.der
chmod 600 MOK.priv

-nodesQuesto esempio semplice crea una chiave privata non crittografata; per una pipeline di firma in ambiente di produzione, utilizzare una chiave crittografata adeguatamente protetta o un servizio di firma esterno in conformità con le proprie policy di sicurezza. La validità di dieci anni qui indicata è puramente illustrativa e non rappresenta una raccomandazione aziendale per la durata a vita del certificato.

Copia il modulo completato nella directory dei moduli del kernel in esecuzione. Firma il file installato esattamente come lo hai creato, dopo qualsiasi operazione di packaging, rimozione di codice o altre modifiche al file. Sostituisci mydriveril percorso con il nome base e la posizione effettivi del modulo.

install -D -m 0644 /path/to/mydriver.ko \
  "/lib/modules/$(uname -r)/extra/mydriver.ko"
SIGN_FILE="$(readlink -f /lib/modules/$(uname -r)/build)/scripts/sign-file"
test -x "$SIGN_FILE" || echo "Locate the sign-file binary for this kernel"
"$SIGN_FILE" sha256 /root/module-signing/MOK.priv \
  /root/module-signing/MOK.der \
  "/lib/modules/$(uname -r)/extra/mydriver.ko"
modinfo -F signer "/lib/modules/$(uname -r)/extra/mydriver.ko"

Se sign-filenon è presente in quel percorso, individua lo strumento fornito con i file di compilazione del kernel corrispondenti anziché copiare una versione non correlata. La visualizzazione di un firmatario significa che il file contiene metadati di firma; ciò non dimostra che il firmatario sia stato registrato. Non rimuovere o modificare mai il modulo dopo la firma.

4. Registra il certificato pubblico utilizzando MOK

Importa il certificato pubblico in formato DER e MOK.privimposta la password di registrazione monouso richiesta mokutil. Configura l'accesso alla console prima del riavvio; l'autorizzazione avviene nell'interfaccia MokManager all'avvio, non in una shell SSH.

mokutil --import /root/module-signing/MOK.der
mokutil --list-new
reboot

Al successivo avvio, selezionare "Registra MOK" , seguire le istruzioni di conferma, inserire la password monouso e continuare l'avvio. L'aspetto del menu dipende dalla versione del firmware e dello shim. Tornare a Linux senza confermare la registrazione rende il nuovo certificato non attendibile.

Dopo l'avvio, verificare che il certificato specifico sia stato registrato:

sudo mokutil --test-key /root/module-signing/MOK.der
sudo mokutil --list-enrolled

5. Caricare il modulo firmato e isolare gli errori rimanenti

Aggiorna i metadati delle dipendenze del modulo e carica il modulo tramite il suo nome, non tramite il percorso completo del file. modprobeRisolve le dipendenze e rispetta la configurazione standard del modulo.

sudo depmod -a
sudo modprobe mydriver
lsmod | grep -w mydriver
modinfo -F signer mydriver

Se il caricamento continua a non riuscire, scegli l'azione correttiva più appropriata in base alle evidenze:

• Chiave rifiutata o chiave richiesta non disponibile: riavviare mokutil --test-key; verificare che il file installato sia quello firmato e controllare se un aggiornamento del driver lo ha sostituito.
• Formato del modulo non valido: confronta modinfo -F vermagiccon uname -r, ricompila per il kernel attivo e controlla l'architettura della CPU.
• Simbolo sconosciuto o dipendenza mancante: ispeziona journalctl -k -bi moduli richiesti dal fornitore e l'ABI del kernel; un'altra firma non risolverà il problema dei simboli mancanti.

Per i driver di archiviazione o di rete critici per l'avvio, testarli prima su un sistema non di produzione e assicurarsi che sia disponibile una console di ripristino. Configurare il caricamento automatico solo dopo che il driver funziona in modo affidabile; consultare la documentazione SUSE /etc/modules-load.d/per i moduli che altrimenti non si caricano al rilevamento del dispositivo.

Verificare il risultato dopo il riavvio.

Se il caricamento persistente è un problema, riavvia il sistema durante la finestra di manutenzione. Verifica che Secure Boot rimanga abilitato, che la chiave pubblica sia registrata, che il modulo sia presente e che il kernel non segnali nuovi errori di verifica o compatibilità. Ricompila o reinstalla e firma i driver aggiornati .kodopo gli aggiornamenti del kernel o dei driver del fornitore.

mokutil --sb-state
sudo mokutil --test-key /root/module-signing/MOK.der
modinfo -F signer mydriver
lsmod | grep -w mydriver
sudo journalctl -k -b --no-pager | tail -n 30

Documentazione principale: SUSE SLES 15 SP6: Chiavi UEFI e del proprietario della macchina ; SUSE: Gestione dei moduli del kernel ; Kernel Linux: Strumento di firma dei moduli ; Kernel Linux: Compilazione di moduli esterni . La Guida di amministrazione di SLES 15 SP6 è stata aggiornata il 17 settembre 2026; il comportamento dei comandi per i programmi di installazione di driver di terze parti e le varianti del kernel non predefinite deve essere confermato con i rispettivi manutentori.