Come installare moduli kernel personalizzati su SLES 15 con avvio protetto

Per caricare un modulo kernel personalizzato su SLES 15 con Secure Boot abilitato, compilalo per il kernel esatto che intendi eseguire, firma il .kofile finale con un certificato di firma attendibile, registra tale certificato come chiave del proprietario della macchina (MOK) e quindi carica il modulo modprobe. Una MOK è un certificato controllato localmente che lo shim di SUSE e il kernel Linux possono considerare attendibile per la verifica del modulo Secure Boot. Non disattivare Secure Boot per aggirare un rifiuto della firma. La procedura descritta di seguito è per un amministratore che controlla la macchina e può approvare la registrazione di una chiave al riavvio.

Questa guida si basa sulla documentazione di amministrazione di SUSE SLES 15 SP7 e sulle linee guida di SUSE per il packaging dei moduli del kernel, verificate il 6 ottobre 2026. I comandi utilizzano acme_driveril nome del modulo come esempio; sostituirlo con il nome effettivo del modulo senza .kosuffisso, ove necessario. Questi sono esempi di comandi, non output di un host testato.

Quando questo metodo è adatto

Utilizzate questo approccio per un modulo personalizzato esterno al kernel, ovvero fornito separatamente dal kernel in esecuzione, quando potete ricompilare o ottenere una build per il kernel SLES di destinazione e potete registrare un certificato sul server. Si applica ai sistemi che si avviano tramite SUSE Secure Boot e il percorso shim. Se un fornitore fornisce un pacchetto driver ufficiale per SLES 15, utilizzate prima le relative istruzioni di installazione e firma supportate; un pacchetto del fornitore potrebbe gestire la compatibilità e gli aggiornamenti del kernel in modo più efficace rispetto a una copia manuale.

Secure Boot convalida la catena di avvio e il kernel verifica anche le firme dei moduli caricabili in base alla policy applicabile. Un modulo può essere firmato ma non caricarsi correttamente se ha come target un'ABI del kernel diversa, dipende da simboli mancanti o è stato compilato per l'architettura sbagliata. Viceversa, la compatibilità con il kernel non rende un modulo non firmato affidabile. La firma riguarda l'affidabilità; non stabilisce la compatibilità né certifica che il codice sia sicuro.

Prima di iniziare

• Utilizzare un account amministratore e verificare di disporre di una finestra di manutenzione. La registrazione di MOK richiede un riavvio e un'azione di approvazione in MokManager, normalmente tramite una console locale o remota.
• Verifica lo stato del kernel in esecuzione e di Secure Boot con uname -re mokutil --sb-state. Compila il modulo utilizzando i file di sviluppo del kernel e la toolchain corrispondenti per quella variante di kernel. I nomi dei pacchetti e i file richiesti variano a seconda del service pack SLES, della variante di kernel e del metodo di compilazione, quindi verificali rispetto ai repository abilitati sul sistema di destinazione.
• Decidete dove verrà archiviata la chiave privata di firma. Per un parco server in produzione, utilizzate il servizio di firma controllato dell'organizzazione o il processo di gestione delle chiavi approvato. Per un laboratorio o un singolo host controllato, una chiave generata localmente può essere una soluzione pratica. Proteggete la chiave privata; il server necessita del certificato pubblico per la registrazione, non della chiave privata.
• Tenete a disposizione un percorso di ripristino, il codice sorgente o il pacchetto del fornitore del modulo e un kernel funzionante. Non caricate un driver sull'hardware di produzione finché non ne conoscete i requisiti relativi al dispositivo e al kernel.

1. Creare una chiave di firma e un certificato pubblico

Su un sistema di firma protetto, creare una chiave privata e un certificato X.509 codificato in DER. Le linee guida di SUSE per il packaging dei moduli del kernel raccomandano l' codeSigningutilizzo della chiave estesa negli attuali service pack di SLES 15. Questo esempio utilizza OpenSSL e un nome di certificato descrittivo:

openssl req -new -x509 -newkey rsa:2048 -sha256 \
  -keyout module-signing.key \
  -out module-signing.der -outform DER -nodes \
  -days 4745 -addext "extendedKeyUsage=codeSigning" \
  -subj "/CN=Custom Module Signing/"
chmod 600 module-signing.key

Questa -nodesopzione lascia la chiave privata non crittografata, quindi è importante controllare i permessi dei file e le impostazioni di archiviazione. Non copiare la chiave privata su un server generico né incorporarla in un pacchetto. Se le policy aziendali richiedono una chiave crittografata, la firma con supporto hardware, la rotazione delle chiavi o un ciclo di vita del certificato diverso, attenersi a tali policy e ai requisiti dello strumento di firma. Trasferire la chiave privata solo module-signing.deral sistema che la utilizzerà per la registrazione della chiave pubblica.

2. Compilare il modulo per il kernel di destinazione e firmarlo

Compila il modulo utilizzando la versione esatta del kernel indicata da uname -r. Le istruzioni di compilazione del progetto sorgente determinano il compilatore, gli header e la configurazione necessari; non esiste un singolo comando di compilazione adatto a tutti i moduli personalizzati. Controlla il risultato vermagiccon modinfose devi diagnosticare un'incompatibilità del kernel.

Firmare il file del modulo finale dopo la compilazione e qualsiasi fase di packaging o striping. SUSE documenta il suo strumento di firma all'indirizzo /usr/lib/rpm/pesign/kernel-sign-file; l'esempio seguente utilizza il formato PKCS#7 e l'algoritmo di digest SHA-256:

/usr/lib/rpm/pesign/kernel-sign-file -i pkcs7 sha256 \
  module-signing.key module-signing.der acme_driver.ko

Il modulo di supporto deve essere disponibile tramite l'integrazione di firma SUSE sul sistema. Se non è presente, consultare la documentazione ufficiale di SLES/KMP e i repository abilitati per verificare la configurazione di firma supportata, anziché utilizzare un comando di firma arbitrario. La firma del modulo viene aggiunta al file. Non rimuovere, modificare, ricomprimere o alterare in altro modo il modulo dopo la firma; tali modifiche possono invalidare la firma. Conservare un artefatto di compilazione intatto per poter ripetere la fase finale di firma.

3. Registrare il certificato pubblico come MOK

Sul server SLES, posizionare il module-signing.dercertificato pubblico in una posizione accessibile all'utente root, quindi metterlo in coda per la registrazione:

mokutil --root-pw --import module-signing.der
mokutil --list-new

SUSE documenta --root-pwcome autorizzare la registrazione in sospeso con la password di root. Il comando di importazione mette in coda il certificato; non lo registra immediatamente. Riavvia il server. In MokManager, seleziona "Registra chiave da disco" , seleziona il certificato, conferma la registrazione e completa l'autorizzazione richiesta. La dicitura del menu può variare leggermente a seconda della versione di shim/MokManager. Se non riesci ad accedere alla schermata di registrazione, controlla il percorso di avvio e richiedi l'accesso alla console; non dare per scontato che il certificato sia stato registrato solo perché il comando di importazione è andato a buon fine.

Dopo l'avvio del server, verificare che la chiave compaia nell'elenco degli utenti registrati:

mokutil --list-enrolled

4. Installa, aggiorna le dipendenze del modulo e caricalo

Copia il file firmato nella directory extra-modules del kernel in esecuzione, aggiorna la mappa delle dipendenze e richiedi il modulo per nome. Sostituisci la versione effettiva del kernel se stai installando per un kernel di avvio diverso:

release=$(uname -r)
install -D -m 0644 acme_driver.ko \
  "/lib/modules/$release/extra/acme_driver.ko"
depmod -a "$release"
modprobe acme_driver

modprobeè generalmente preferibile insmodperché risolve le dipendenze dei moduli. Testa il dispositivo o la funzionalità effettiva fornita dal driver; un comando eseguito correttamente da solo non dimostra che l'hardware funzioni correttamente. Se il modulo deve essere caricato all'avvio, aggiungi il suo nome su una riga separata in un file come /etc/modules-load.d/acme_driver.conf. SLES utilizza il meccanismo di caricamento dei moduli di systemd per questi file di configurazione.

5. Verificare il percorso di fiducia e risolvere i problemi.

Tra i controlli utili si possono citare:

mokutil --list-enrolled
modinfo -F signer /lib/modules/$(uname -r)/extra/acme_driver.ko
lsmod | grep acme_driver
journalctl -k -b | tail -n 80

modinfo -F signerMostra i metadati del firmatario incorporati nel modulo. Di per sé, non dimostra che il certificato sia stato registrato o che il kernel in esecuzione abbia accettato la firma. Un avvio riuscito modprobecon Secure Boot ancora abilitato, seguito dall'ispezione del log del kernel e da un controllo funzionale del dispositivo, fornisce prove più utili. L'output del terminale mostrato nella figura è un esempio dei comandi e dell'output illustrativo, non un report di un test eseguito per questo articolo.

SUSE tiene anche traccia dello stato di supporto di un modulo e il caricamento di un modulo non supportato può influire sullo stato di supporto o sullo stato di taint del kernel. Questa politica è separata dalla verifica della firma: la modifica di un'impostazione relativa ai moduli non supportati non comporta la registrazione di una chiave di firma e non corregge una firma rifiutata. Consultare le linee guida di supporto di SUSE prima di modificare tale politica su un sistema di produzione supportato.

Pianifica gli aggiornamenti del kernel e le distribuzioni ripetute.

Un modulo compilato per una determinata versione del kernel non è automaticamente compatibile con la successiva. Dopo un aggiornamento del kernel, è necessario installare l'ambiente di compilazione corrispondente, ricompilare il modulo per la nuova ABI del kernel, firmare il file finale, installarlo nella directory dei moduli del kernel e aggiornare le informazioni sulle dipendenze. Se il certificato di firma rimane attendibile, in genere non è necessario registrarlo nuovamente. Un certificato sostitutivo o ruotato richiede invece una nuova registrazione e approvazione. Prima di affidarsi al caricamento automatico all'avvio, è consigliabile testare il nuovo kernel e il modulo insieme.

Per una flotta o un driver che deve resistere agli aggiornamenti di routine, utilizzare un flusso di lavoro di packaging ripetibile come l'approccio Kernel Module Package (KMP) di SUSE, laddove sia compatibile con il driver e il modello di supporto. Il packaging può organizzare le build e le fasi di firma per singolo kernel, ma non elimina la necessità di una corretta protezione delle chiavi, compatibilità dei moduli, attendibilità MOK e test degli aggiornamenti. Consultare la documentazione per il service pack SLES 15 specifico e il ciclo di vita del kernel supportato dalla propria organizzazione.

Riferimenti ufficiali

• Guida all'amministrazione di SUSE Linux Enterprise Server 15 SP7 — Avvio protetto e registrazione MOK, caricamento dei moduli e criteri per i moduli non supportati.
• Manuale dei pacchetti dei moduli del kernel SUSE — Processo di firma KMP e requisiti di firma applicabili a SLES 15.
• Documentazione sulla firma dei moduli del kernel Linux : comportamento e vincoli della firma del kernel sui file dei moduli firmati.