How to Install Custom Kernel Modules on SLES 15 with Secure Boot

To load a custom kernel module on SLES 15 with Secure Boot enabled, build it for the exact kernel you will run, sign the finished .ko file with a trusted signing certificate, enroll that certificate as a Machine Owner Key (MOK), and then load the module with modprobe. A MOK is a locally controlled certificate that SUSE’s shim and Linux kernel can trust for Secure Boot module verification. Do not turn Secure Boot off to work around a rejected signature. The process below is for an administrator who controls the machine and can approve a key enrollment at reboot.

This guide follows SUSE’s SLES 15 SP7 administration documentation and SUSE’s kernel-module packaging guidance, checked October 6, 2026. Commands use acme_driver as an example module name; replace it with the actual module name without the .ko suffix where appropriate. These are command examples, not output from a tested host.

When this method is the right fit

Use this approach for a custom out-of-tree module—one supplied separately from the running kernel—when you can rebuild or obtain a build for the target SLES kernel and can enroll a certificate on the server. It applies to systems booting through the SUSE Secure Boot and shim path. If a vendor supplies an official SLES 15 driver package, use its supported installation and signing instructions first; a vendor package may handle kernel compatibility and updates better than a manual copy.

Secure Boot validates the boot chain, and the kernel also checks signatures on loadable modules under the applicable policy. A module can be signed yet still fail to load if it targets a different kernel ABI, depends on missing symbols, or is built for the wrong architecture. Conversely, matching the kernel does not make an unsigned module trusted. Signing addresses trust; it does not establish compatibility or certify that the code is safe.

Before you start

• Use an administrator account and confirm you have a maintenance window. MOK enrollment requires a reboot and an approval action in MokManager, normally through a local or remote console.
• Check the running kernel and Secure Boot state with uname -r and mokutil --sb-state. Build the module against the matching kernel development files and toolchain for that kernel flavor. The package names and required files vary by SLES service pack, kernel flavor, and build method, so verify them against the repositories enabled on the target system.
• Decideți unde va fi stocată cheia privată de semnare. Pentru o flotă de producție, utilizați serviciul de semnare controlată al organizației sau procesul aprobat de gestionare a cheilor. Pentru un laborator sau o singură gazdă controlată, o cheie generată local poate fi practică. Protejați cheia privată; serverul are nevoie de certificatul public pentru înscriere, nu de cheia privată.
• Păstrați la îndemână o cale de recuperare, sursa modulului sau pachetul furnizorului și un kernel cunoscut ca fiind funcțional. Nu încărcați un driver pe hardware-ul de producție până nu înțelegeți cerințele de dispozitiv și kernel.

1. Creați o cheie de semnare și un certificat public

Pe un sistem de semnare protejat, creați o cheie privată și un certificat X.509 codificat DER. Ghidul SUSE pentru împachetarea modulelor kernel necesită codeSigningutilizarea extinsă a cheii pe pachetele service pack SLES 15 actuale. Acest exemplu utilizează OpenSSL și un nume de certificat descriptiv:

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

Opțiunea -nodeslasă cheia privată necriptată, deci permisiunile fișierelor și controalele de stocare contează. Nu copiați acea cheie privată într-un server de uz general și nu o încorporați într-un pachet. Dacă politica organizațională necesită o cheie criptată, semnare bazată pe hardware, rotația cheilor sau un ciclu de viață diferit al certificatului, urmați politica respectivă și cerințele instrumentului de semnare. Transferați doar module-signing.dercătre sistemul care va înscrie cheia publică.

2. Construiți modulul pentru kernelul țintă și semnați-l

Construiți modulul conform versiunii exacte a kernelului afișate de uname -r. Instrucțiunile de construire ale proiectului sursă determină compilatorul, anteturile și configurația de care are nevoie; nu există o singură comandă de construire care să se potrivească fiecărui modul personalizat. Verificați rezultatele vermagiccu modinfodacă trebuie să diagnosticați o nepotrivire a kernelului.

Semnați fișierul final al modulului după compilare și orice etapă de împachetare sau eliminare a fișierelor. SUSE își documentează ajutorul de semnare la /usr/lib/rpm/pesign/kernel-sign-file; următorul exemplu folosește formatul PKCS#7 și digestul SHA-256:

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

Instrumentul auxiliar trebuie să fie disponibil din integrarea de semnare SUSE de pe sistemul dvs. Dacă lipsește, verificați documentația oficială SLES/KMP și depozitele activate pentru configurația de semnare acceptată, în loc să înlocuiți cu o comandă de semnare arbitrară. O semnătură de modul este adăugată la fișier. Nu eliminați, editați, recomprimați și nu modificați în alt mod modulul după semnare; o astfel de modificare poate invalida semnătura. Păstrați un artefact de compilare intact, astfel încât să puteți repeta pasul final de semnare.

3. Înregistrați certificatul public ca MOK

Pe serverul SLES, plasați module-signing.dercertificatul public unde root îl poate citi, apoi puneți-l în coadă pentru înscriere:

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

Documentele SUSE --root-pwca modalitate de a autoriza înscrierea în așteptare cu parola de root. Comanda de import pune certificatul în coadă; nu îl înscrie imediat. Reporniți serverul. În MokManager, alegeți Înregistrare cheie de pe disc , selectați certificatul, confirmați înscrierea și finalizați autorizarea solicitată. Formularea meniului poate varia ușor în funcție de versiunea shim/MokManager. Dacă nu puteți accesa ecranul de înscriere, verificați calea de boot și aranjați accesul la consolă; nu presupuneți că certificatul a fost înscris doar pentru că comanda de import a reușit.

După ce serverul pornește, confirmați că cheia apare în lista de înscriși:

mokutil --list-enrolled

4. Instalați, actualizați dependențele modulului și încărcați-l

Copiați fișierul semnat în directorul extra-modules pentru kernelul care rulează, actualizați harta de dependențe și solicitați modulul după nume. Înlocuiți versiunea actuală a kernelului dacă instalați pentru un kernel bootat diferit:

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

modprobeeste în general preferabil insmoddeoarece rezolvă dependențele modulelor. Testați dispozitivul sau funcționalitatea reală oferită de driver; o comandă executată cu succes nu dovedește că hardware-ul funcționează corect. Dacă modulul este destinat să se încarce la pornire, adăugați numele modulului său pe propria linie într-un fișier precum /etc/modules-load.d/acme_driver.conf. SLES utilizează mecanismul de încărcare a modulelor al systemd pentru aceste fișiere de configurare.

5. Verificați calea de încredere și depanați erorile

Verificările utile includ:

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 signerafișează metadatele semnatarului încorporate în modul. În sine, nu dovedește că certificatul este înscris sau că kernelul care rulează a acceptat semnătura. O verificare reușită modprobecu Secure Boot încă activată, urmată de o inspecție a jurnalului kernelului și o verificare funcțională a dispozitivului, este o dovadă mai utilă. Rezultatul terminalului afișat în figură este un exemplu de comenzi și un rezultat ilustrativ, nu un raport al unui test efectuat pentru acest articol.

SUSE urmărește, de asemenea, dacă un modul este acceptat, iar încărcarea unui modul neacceptat poate afecta starea de suport sau starea de contaminare a kernelului. Această politică este separată de verificarea semnăturii: modificarea unei setări pentru modulul neacceptat nu înscrie o cheie de semnare și nu va repara o semnătură respinsă. Consultați instrucțiunile de asistență SUSE înainte de a modifica politica respectivă pe un sistem de producție acceptat.

Planificați actualizările kernelului și implementările repetate

Un modul construit pentru o versiune de kernel nu este automat compatibil cu următoarea. După o actualizare a kernelului, instalați mediul de compilare corespunzător, reconstruiți modulul pentru noul ABI al kernelului, semnați fișierul final, instalați-l în arborele de module al kernelului respectiv și reîmprospătați informațiile despre dependențe. Dacă certificatul de semnare rămâne de încredere, în mod normal nu este nevoie să îl înregistrați din nou. Un certificat de înlocuire sau rotit necesită propria înscriere și aprobare. Testați noul kernel și modulul împreună înainte de a vă baza pe încărcarea nesupravegheată la pornire.

Pentru o flotă sau un driver care trebuie să reziste actualizărilor de rutină, utilizați un flux de lucru repetabil pentru împachetare, cum ar fi abordarea Kernel Module Package (KMP) de la SUSE, acolo unde se potrivește driverului și modelului dvs. de asistență. Împachetarea poate organiza construcții și pași de semnare per kernel, dar nu elimină necesitatea unei protecții corecte a cheilor, a compatibilității modulelor, a încrederii MOK și a testării actualizărilor. Consultați documentația pentru pachetul de service SLES 15 exact și ciclul de viață al kernelului acceptat de organizația dvs.

Referințe oficiale

• Ghid de administrare SUSE Linux Enterprise Server 15 SP7 — Pornire securizată și înscriere MOK, încărcarea modulelor și politica privind modulele neacceptate.
• Manualul pachetelor de module SUSE Kernel — Procesul de semnare KMP și cerințele de semnare aplicabile pentru SLES 15.
• Documentația semnării modulelor kernel Linux — comportamentul semnăturii kernel și constrângerile asupra fișierelor modulelor semnate.