Installation und Signierung benutzerdefinierter Kernelmodule unter SLES 15 Secure Boot

Ein Drittanbietertreiber auf SUSE Linux Enterprise Server 15 lässt sich möglicherweise korrekt kompilieren, kann aber mit der Fehlermeldung „Erforderlicher Schlüssel nicht verfügbar“ oder „Schlüssel wurde vom Dienst abgelehnt“ nicht geladen werden. Wenn UEFI Secure Boot Modulsignaturen erzwingt, besteht die Lösung darin, das benutzerdefinierte Kernelmodul mit einem vertrauenswürdigen Zertifikat zu signieren, dieses Zertifikat über die Verwaltung des Maschinenbesitzerschlüssels (MOK) zu registrieren und das Modul anschließend normal zu laden – ohne Secure Boot zu deaktivieren.

Dieses Verfahren setzt ein Standard-SLES-15-UEFI-System mit SUSE-Shim, einem kernel-defaultKernel, Administratorrechten und einer vertrauenswürdigen Treiberquelle voraus. Es behandelt benutzerdefinierte .koModule, jedoch nicht das Signieren eines Ersatzkernels oder das Ändern von Firmware-Plattformschlüsseln. Die Beispiele orientieren sich am Administrationsmodell von SLES 15 SP6/SP7; prüfen Sie die Unterschiede zwischen den Paketen und Kernelvarianten Ihres installierten Service Packs.

1. Überprüfen Sie zuerst Secure Boot und den laufenden Kernel.

Melden Sie sich mit Administratorrechten an und ermitteln Sie den tatsächlich gestarteten Kernel. Ein übereinstimmender Paketname allein beweist nicht, dass ein Modul in diesen Kernel geladen werden kann.

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

Wenn mokutilSecure Boot aktiviert ist, deutet eine nicht vertrauenswürdige Signatur wahrscheinlich auf einen schlüsselbezogenen Ladefehler hin. Ist Secure Boot deaktiviert, sollten Sie andere Ursachen untersuchen, bevor Sie Schlüssel generieren; auch die explizite Durchsetzung der Kernelsignatur kann relevant sein. Überprüfen Sie nach einem fehlgeschlagenen Ladevorgang das Kernelprotokoll auf die genaue Fehlermeldung.

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

Prüfen Sie das Kandidatenmodul vor der Installation. Ersetzen Sie den Beispiel-Dateinamen durch den tatsächlichen Dateinamen; dieser vermagicmuss mit der aktuellen Kernel-Version und den kompatiblen Build-Eigenschaften übereinstimmen.

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

2. Verwenden Sie ein unterstütztes Treiberpaket oder erstellen Sie ein passendes Modul.

Fragen Sie zunächst beim Hardware- oder Softwarehersteller nach einem SLES-kompatiblen, bereits signierten Kernelmodulpaket (KMP). Dies ist der manuellen Installation einer Binärdatei vorzuziehen: Der Hersteller bietet möglicherweise Unterstützung bei Kernel-Updates und einen dokumentierten Prozess zur Zertifikatsregistrierung. Eine Herstellersignatur wird nicht automatisch auf jedem Secure-Boot-System als vertrauenswürdig eingestuft.

Falls Sie den Treiber selbst kompilieren müssen, installieren Sie die Entwicklungsdateien, die zu Ihrem verwendeten Kernel passen. kernel-defaultDie üblichen SLES-Pakete enthalten das Standard-Kernel-Entwicklungspaket, die Kernel-Entwicklungsdateien und die Build-Tools. Verfügbarkeit und Versionen der Repositories hängen von der Registrierung und den aktivierten SLES-Modulen ab.

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"

Falls das Build-Verzeichnis fehlt oder das Entwicklungspaket auf eine andere Kernel-Version abzielt, beheben Sie zunächst die Paket-/Kernel-Inkompatibilität. Bei einem neu installierten Kernel ist möglicherweise ein kontrollierter Neustart erforderlich, bevor damit kompiliert werden kann.

Verwenden Sie für die Treiber aus dem vertrauenswürdigen Quellverzeichnis die Anweisungen des Herstellers zum Kompilieren. Bei herkömmlichen, auf kbuild basierenden Modulen kompiliert der unten stehende Befehl gegen den laufenden Kernel; er lädt keinen Treiber herunter und erstellt ihn auch nicht selbst.

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

Überspringen Sie die Kompilierung, wenn Sie bereits eine kompatible Datei .kovon einem vertrauenswürdigen Anbieter besitzen. Laden Sie niemals ein Modul mit der falschen Signatur vermagic; eine Signatur kann eine inkompatible Binärdatei nicht reparieren.

3. Erstellen Sie den Signaturschlüssel und signieren Sie das installierte Modul.

Generieren Sie einen dedizierten RSA-Schlüssel und ein X.509-Zertifikat in einem Verzeichnis, auf das nur das Stammverzeichnis Zugriff hat. Das öffentliche Zertifikat wird registriert; der private Schlüssel muss geschützt bleiben, da derjenige, der ihn kontrolliert, zusätzliche Module signieren kann, denen dieser Rechner möglicherweise vertraut.

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

-nodesFür ein einfaches Beispiel wird ein unverschlüsselter privater Schlüssel erstellt. Verwenden Sie für eine produktive Signaturpipeline einen entsprechend geschützten verschlüsselten Schlüssel oder einen externen Signaturdienst gemäß Ihrer Sicherheitsrichtlinie. Die hier angegebene zehnjährige Gültigkeitsdauer dient lediglich der Veranschaulichung und stellt keine Empfehlung für die Lebensdauer von Organisationszertifikaten dar.

Kopieren Sie das fertige Modul in das Modulverzeichnis des laufenden Kernels. Signieren Sie die exakt installierte Datei nach jeglichen Änderungen wie Packen, Entfernen von Dateien oder anderen Modifikationen. Ersetzen Sie `<Modulname>` mydriverund `<Pfad>` durch den tatsächlichen Basisnamen und Speicherort des Moduls.

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"

Falls sign-filedas Tool unter diesem Pfad nicht vorhanden ist, verwenden Sie das Tool, das mit Ihren Kernel-Build-Dateien ausgeliefert wurde, anstatt eine nicht zugehörige Version zu kopieren. Ein angezeigter Signierer bedeutet, dass die Datei Signaturmetadaten enthält; er beweist nicht, dass der Signierer registriert ist. Entfernen oder verändern Sie das Modul nach der Signierung niemals.

4. Registrieren Sie das öffentliche Zertifikat mit MOK.

Importieren Sie das öffentliche Zertifikat im DER-Format – nicht MOK.privdas Standardzertifikat – und legen Sie das von MokManager angeforderte Einmalpasswort fest mokutil. Stellen Sie vor dem Neustart den Konsolenzugriff sicher; die Autorisierung erfolgt über die MokManager-Oberfläche beim Systemstart, nicht über eine SSH-Shell.

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

Wählen Sie beim nächsten Systemstart „MOK registrieren“ , folgen Sie den Bestätigungsanweisungen, geben Sie das Einmalpasswort ein und fahren Sie mit dem Startvorgang fort. Die Menüdarstellung hängt von der Firmware- und Shim-Version ab. Wenn Sie zu Linux zurückkehren, ohne die Registrierung zu bestätigen, wird das neue Zertifikat als nicht vertrauenswürdig eingestuft.

Überprüfen Sie nach dem Hochfahren, ob das entsprechende Zertifikat registriert ist:

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

5. Laden Sie das signierte Modul und isolieren Sie die verbleibenden Fehler.

Die Metadaten der Modulabhängigkeiten werden aktualisiert und das Modul wird über seinen Namen und nicht über den vollständigen Dateipfad geladen. modprobeDadurch werden Abhängigkeiten aufgelöst und die Standardmodulkonfiguration berücksichtigt.

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

Falls das Laden weiterhin fehlschlägt, wählen Sie die Korrekturmaßnahme, die den vorliegenden Erkenntnissen entspricht:

• Schlüssel abgelehnt oder erforderlicher Schlüssel nicht verfügbar: erneut ausführen mokutil --test-key; überprüfen Sie, ob die installierte Datei signiert ist und ob sie durch ein Treiberupdate ersetzt wurde.
• Ungültiges Modulformat: Vergleichen Sie modinfo -F vermagicmit uname -r, kompilieren Sie für den aktiven Kernel neu und überprüfen Sie die CPU-Architektur.
• Unbekanntes Symbol oder fehlende Abhängigkeit: Überprüfen Sie journalctl -k -bdie erforderlichen Module des Anbieters und die Kernel-ABI; eine andere Signatur behebt fehlende Symbole nicht.

Bei Treibern für bootkritische Speicher- oder Netzwerkgeräte sollten Sie diese zunächst auf einem Testsystem prüfen und sicherstellen, dass eine Wiederherstellungskonsole verfügbar ist. Konfigurieren Sie das automatische Laden erst, nachdem der Treiber zuverlässig funktioniert; SUSE-Dokumente /etc/modules-load.d/beschreiben Module, die bei der Geräteerkennung nicht automatisch geladen werden.

Überprüfen Sie das Ergebnis nach einem Neustart.

Starten Sie das System im Wartungsfenster erneut, falls das dauerhafte Laden wichtig ist. Stellen Sie sicher, dass Secure Boot aktiviert bleibt, der öffentliche Schlüssel registriert ist, das Modul vorhanden ist und der Kernel keine neuen Verifizierungs- oder Kompatibilitätsfehler meldet. Erstellen oder installieren Sie das aktualisierte System .konach Kernel- oder Treiberaktualisierungen neu und signieren Sie es.

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

Primäre Dokumentation: SUSE SLES 15 SP6: UEFI und Maschinenbesitzerschlüssel ; SUSE: Kernelmodule verwalten ; Linux-Kernel: Modulsignatur ; Linux-Kernel: Externe Module erstellen . Das SLES 15 SP6-Administrationshandbuch wurde am 17. September 2026 aktualisiert. Das Befehlsverhalten für Treiberinstallationsprogramme von Drittanbietern und nicht standardmäßige Kernelvarianten muss mit deren Entwicklern abgeklärt werden.