NVIDIA-Treiber mit Secure Boot auf Ubuntu- und RHEL-Servern: signierte Module, DKMS, MOK

Was Secure Boot für den NVIDIA-Treiber ändert

Der NVIDIA-Treiber läuft mit aktivem Secure Boot, solange seine Kernelmodule mit einem Schlüssel signiert sind, dem der Kernel vertraut. Unter Ubuntu sind Canonicals vorkompilierte -server-Module signiert und brauchen keinen eigenen Schlüssel; unter RHEL 10 gilt das für Red Hats vorkompilierte kmod-nvidia-open-Pakete. Mit DKMS, aus NVIDIAs Repository oder unter RHEL 8 und 9, werden die Module mit einem lokalen Schlüssel signiert, den Sie einmal als Machine Owner Key registrieren.

Der NVIDIA-Treiber ist ein Kernelmodul außerhalb des Kernelbaums, getrennt vom Kernel gebaut und ausgeliefert. Unter UEFI Secure Boot prüft der Kernel die Signatur jedes Moduls. Ubuntus Server-Dokumentation „NVIDIA drivers installation“ sagt es direkt: „If your system uses Secure Boot (as most x86 modern systems do), your kernel will require the kernel modules to be signed.“ Red Hats Leitfaden zu RHEL 9 für das Signieren von Kernelmodulen zeigt die Folge in seiner Tabelle zum Laden von Modulen: Mit aktivem Secure Boot wird ein unsigniertes Modul nicht geladen, und ebenso wenig ein signiertes, dessen öffentlichem Schlüssel das System nicht vertraut.

Für die Karten der RTX PRO Blackwell kommt eine zweite Bedingung hinzu. NVIDIA schreibt, dass man auf Blackwell „must use the open-source GPU kernel modules“, und ab R615 sind die offenen Module die einzige Variante, die NVIDIAs Pakete liefern, wie unser Leitfaden zu NVIDIA-Treiberzweigen und CUDA-Versionen erklärt. Die Frage der Signatur betrifft auf allen hier besprochenen Servern also die offenen Module.

Ubuntu-Server-Dokumentation „NVIDIA drivers installation“; NVIDIA Driver Installation Guide (aktualisiert am 23. September 2026), Seiten zu Ubuntu, RHEL und FAQ; Dokumentation zu Red Hat Enterprise Linux 9 über das Signieren von Kernelmodulen für Secure Boot; gelesen am 24. Oktober 2026.

Zwei Befehle zeigen, wo ein Server steht. mokutil --sb-state gibt den Zustand von Secure Boot aus, laut Handbuchseite „Show SecureBoot State“. modinfo nvidia | grep signer zeigt, wer das installierte Modul signiert hat; mit dieser Prüfung arbeitet Red Hats Leitfaden für sein eigenes Beispielmodul.

Ubuntu: vorkompilierte Module von Canonical

Ubuntus Dokumentation beschreibt zwei Treiberfamilien. Die Enterprise Ready Drivers „are recommended on servers and for computing tasks“, und „Their packages can be recognized by the -server suffix“. Danach nennt sie zwei Wege zu den Kernelmodulen unter Secure Boot, „mutually exclusive“: die vorkompilierten NVIDIA-Module für Ihren Kernel oder Module, die Sie mit dem NVIDIA-DKMS-Paket bauen, nachdem Sie einen eigenen Schlüssel zum Signieren der Module registriert haben („enroll your own key to sign the modules“). NVIDIAs eigener Installationsleitfaden bestätigt den ersten Weg von seiner Seite: Canonical „provides signed -server packages that correspond with NVIDIA Datacenter Driver releases“. Zum zweiten Weg merkt Ubuntu an: „We don't recommend using the DKMS modules unless you are running a custom kernel for which the prebuilt drivers are not supported“, denn „the DKMS drivers are not signed with Canonical's key and thus do not support secure boot“; die eigene DKMS-Anleitung lässt Sie deshalb einen eigenen Schlüssel registrieren.

Die Seite beschreibt außerdem das Werkzeug ubuntu-drivers, das „will, by default, only install the pre-built, signed drivers which are known to work with Secure Boot“. Für Server und Rechenlasten nutzt es die Option --gpgpu: sudo ubuntu-drivers list --gpgpu listet die Servertreiber für die eingebaute Hardware, und sudo ubuntu-drivers install --gpgpu nvidia:<branch>-server installiert einen gewählten Zweig, gefolgt von sudo apt install nvidia-utils-<branch>-server für die Werkzeuge.

Die vorkompilierten Module kommen als Metapaket je Treiberzweig und Kernel-Variante, in Ubuntus Schreibweise linux-modules-nvidia-${DRIVER_BRANCH}${SERVER}-${LINUX_FLAVOUR}, gefolgt vom Treiber-Metapaket nvidia-driver-${DRIVER_BRANCH}${SERVER}. Für Blackwell tragen die Namen zusätzlich -open. Canonicals Archiv auf Launchpad führte am 24. Oktober 2026 diese Pakete:

Launchpad-API, veröffentlichte Binärpakete im Hauptarchiv von Ubuntu für noble amd64, gelesen am 24. Oktober 2026. Vollständige Namen der Modulpakete: linux-modules-nvidia-595-server-open-generic und linux-modules-nvidia-580-server-open-generic; beide gibt es auch für Ubuntu 26.04 (resolute), Kernel 7.0.0-38.

Beide Treiberversionen sind die Releases, die NVIDIAs Sicherheitsbulletin vom 30. September 2026 als korrigiert nennt; Canonicals Pakete enthalten also die Sicherheitskorrektur. NVIDIAs neueste Releases enthalten sie dagegen nicht: NVIDIAs eigene Liste zeigt 595.112.07 vom 22. Oktober 2026 und 580.196.07 vom 21. Oktober 2026, die an diesem Tag nicht in Canonicals Archiv standen. Canonical veröffentlicht nach eigenem Zeitplan.

Kernel-Updates folgen aus demselben Aufbau. Die Module werden für jeden Kernel gebaut, und Ubuntus Dokumentation empfiehlt, mit apt-cache policy und $(uname -r) zu prüfen, ob das Paket für den laufenden Kernel existiert, und, wenn es fehlt, auf den neuesten Kernel zu aktualisieren oder das Paket für den laufenden Kernel zu installieren. Ubuntu weist außerdem darauf hin, dass am Ende eines Zweigs „Canonical will transition you to the next supported driver branch automatically“; wer einen Zweig festlegt, sollte das einplanen. Der Fabric Manager, nur für NVSwitch-Systeme nötig, kommt nur mit den -server-Paketen.

Wer den Weg später wechselt, entfernt zuerst den installierten Treiber. Ubuntus beschriebene Abfolge ist apt --purge remove für die Pakete des Zweigs und apt autoremove, dann die Installation der anderen Modulart.

Wir bauen KI-Server nach Auftrag und installieren auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime; nennen Sie uns Distribution, Treiberzweig und ob Secure Boot aktiv bleiben muss, und unser Team antwortet innerhalb eines Werktages.

Ubuntu mit NVIDIAs Repository: DKMS und ein MOK-Schlüssel

NVIDIAs eigenes Repository bedient Ubuntu 22.04, 24.04 und 26.04, und sein Leitfaden installiert den Treiber mit apt install nvidia-open, für einen reinen Rechenserver mit apt -V install und den Paketen libnvidia-compute und nvidia-dkms-open. Seine Pakete zur Versionssperre, etwa nvidia-driver-pinning-580, halten einen Server auf einem Zweig. Die Module baut DKMS lokal, deshalb müssen die Kernel-Header passen: apt install linux-headers-$(uname -r).

Unter Secure Boot wird ein DKMS-Build mit einem lokalen Schlüssel signiert, und diesem Schlüssel muss das System vertrauen. NVIDIAs FAQ zeigt eine DKMS-Ausgabe, in der /var/lib/dkms/mok.key als „Signing key“ erscheint und jedes Modul, nvidia.ko und die übrigen, beim Build signiert wird; das Beispiel stammt von einem Fedora-Host. Ubuntus Dokumentation schreibt, das NVIDIA-DKMS-Paket „may automatically guide you through creating and enrolling a new key for Secure Boot“. Das Registrieren ist das Verfahren des Bootloaders shim für Machine Owner Keys: mokutil --import legt für ein Zertifikat im DER-Format eine Anfrage „to shim“ an, geschützt durch ein Einmalpasswort; beim nächsten Start fragt der MOK-Manager nach diesem Passwort und schreibt den Schlüssel ein.

Dieser Bildschirm erscheint, bevor das Betriebssystem startet, auf einem Rack-Server also nur über die Fernkonsole des BMC. mokutil --list-new zeigt die offene Anfrage, mokutil --list-enrolled die bereits gespeicherten Schlüssel und mokutil --test-key, ob ein bestimmtes Zertifikat registriert ist.

DKMS hat einen zweiten Punkt für den Betrieb. NVIDIAs FAQ warnt, dass bei Kernel-Updates ohne Neustart „the DKMS framework will sometimes fail to correctly rebuild the NVIDIA kernel module packages“, und nennt die Reparatur: dkms status, dann Build und Installation für Treiberversion und Kernel. Spielen Sie Kernel und Header im selben Update ein und prüfen Sie nvidia-smi nach jedem Kernel-Update.

Der Grund für diesen Weg ist die Kontrolle über die Treiberversion: Sie installieren NVIDIAs eigene Pakete für das Release Ihrer Wahl, unabhängig davon, wann Canonical es neu baut. Der Preis ist die Schlüsselverwaltung auf jedem Server, vor der Canonicals Hinweis warnt.

RHEL: von Red Hat signierte Module unter RHEL 10, DKMS unter 8 und 9

NVIDIAs Installationsleitfaden, aktualisiert am 23. September 2026, beschreibt vorkompilierte Kernelmodule für Red Hat Enterprise Linux 10. Seine Liste der Vorteile beginnt mit „UEFI Secure Boot works out of the box via trusted keys already installed in the kernel keyring by Red Hat“, gefolgt von „Simpler dependencies: removes kernel-devel, kernel-headers, DKMS and GCC compiler requirements“ und dem Wegfall von EPEL. Der Leitfaden nennt die Module „Red Hat signed“ und „provided by Red Hat“; im Beispiel kommt das Paket kmod-nvidia-open aus dem Repository rhel-10-for-x86_64-extensions-rpms, freigeschaltet mit subscription-manager, und die Benutzerebene des Treibers aus NVIDIAs Repository cuda-rhel10. Der Installationsbefehl lautet dnf install kmod-nvidia-open nvidia-driver nvidia-driver-cuda.

Der vorkompilierte Weg bringt eine Sicherung mit. Ein DNF-Plugin „prevents upgrades to a kernel for which no precompiled driver yet exists“ und meldet „NVIDIA driver: some kernel packages have been filtered due to missing precompiled modules“; dnf nvidia-plugin zeigt, was es zurückgehalten hat. Ein Server bleibt also auf seinem aktuellen Kernel, bis vorkompilierte Module für den neuen existieren.

Unter RHEL 8 und 9 nutzt der Leitfaden DKMS-Modul-Streams wie nvidia-driver:open-dkms oder 580-open, mit kernel-devel und kernel-headers für den laufenden Kernel und EPEL für DKMS. Im Februar 2025 kündigte NVIDIA von Red Hat signierte offene Module für RHEL 9 als technische Vorschau ab RHEL 9.5 an, die „can now be installed and used without any extra key enrollment configuration“; der aktuelle Leitfaden beschränkt seinen Abschnitt zu vorkompilierten Modulen auf RHEL 10. Für Server mit RHEL 8 und 9 unter Secure Boot planen Sie einen MOK-Schlüssel ein.

Red Hats Dokumentation für diesen Schlüssel ist ausführlich: ein X.509-Paar mit efikeygen erzeugen, das Zertifikat exportieren, mit mokutil --import anmelden, neu starten und im MOK-Manager „Enroll MOK“ wählen, dann mit keyctl list %:.platform prüfen, dass der Schlüssel im Platform-Keyring liegt. Module werden mit dem Skript sign-file des Kernels und SHA-256 signiert. Rocky Linux und AlmaLinux haben in NVIDIAs Leitfaden eigene Seiten.

Den Signaturschlüssel schützen

Ist ein MOK-Schlüssel registriert, vertrauen Bootkette und Kernel jedem Modul, das er signiert, nicht nur dem NVIDIA-Treiber. Red Hats Leitfaden verlangt „Apply strong security measures and access policies to guard the contents of your private key“, und wer den unverschlüsselten privaten Schlüssel besitzt, kann Module signieren, die Ihre Server laden. Ein DKMS-Schlüssel, der auf jedem Server erzeugt wird, bleibt auf diesem Server; ein Firmenschlüssel für die ganze Flotte lässt sich leichter prüfen und ist für einen Angreifer wertvoller, er gehört daher in denselben geschützten Speicher wie Ihre übrigen Code-Signing-Schlüssel. Unser Leitfaden zur Absicherung eines GPU-Servers behandelt die Schichten unter dem Betriebssystem, BMC und Firmware, auf die sich Secure Boot selbst stützt.

Kubernetes, Confidential Computing und andere Fälle

Unter Kubernetes baut der GPU Operator den Treiber normalerweise in einem Container auf jedem Knoten. NVIDIAs Seite zu vorkompilierten Treiber-Containern, aktualisiert am 14. Oktober 2026, sagt, sie „do not require internet access to download Linux kernel“-Header und sparen den Compile-Schritt; die Images gibt es für eine Reihe von Kernel-Varianten, darunter generic, nvidia und oracle, und sie „do not support NVIDIA vGPU or GPUDirect Storage (GDS)“. Wie ihre Module signiert sind, sagt die Seite nicht; testen Sie deshalb einen Knoten mit aktivem Secure Boot, bevor Sie die Einstellung ausrollen. Unser Leitfaden zum Air-Gapped-LLM-Server behandelt die Registry, die die Container brauchen.

Für Confidential Computing gilt eine eigene Regel. NVIDIAs Deployment Guide hält fest: „Setting the CC modes for the GPUs is not possible if the host is configured in Secure Boot mode“; Secure Boot ist also aus, während der Modus bei der Inbetriebnahme umgeschaltet wird, wie unser Leitfaden zu Confidential Computing auf H200 NVL und RTX PRO 6000 beschreibt. Auch Firmware-Updates, die das BIOS betreffen, können Einstellungen zu Secure Boot ändern; unser Leitfaden zu Firmware-Updates am GPU-Server enthält die Prüfung nach jedem Update.

Einen Weg für die Flotte wählen

Unsere Zusammenfassung der oben zitierten Dokumente, Stand 24. Oktober 2026.

Für die meisten Ubuntu-GPU-Server im Produktivbetrieb sind Canonicals signierte -server-open-Pakete der kürzeste Weg, Secure Boot aktiv zu lassen: kein Schlüssel zu verwalten, und die Zweige R580 und R595 mit NVIDIAs Sicherheitskorrekturen vom September. Teams, die NVIDIAs neuestes Point-Release brauchen oder mit NVIDIAs Paketen zur Versionssperre arbeiten, nehmen den DKMS-Weg, den Canonical nur für eigene Kernel empfiehlt, und planen das Registrieren des Schlüssels auf jedem Server ein. Unter RHEL 10 sind die vorkompilierten Pakete die dokumentierte Wahl. Unser Vergleich Linux für GPU-Server wägt die Distributionen selbst ab.

Prüfungen nach jedem Kernel- oder Treiber-Update

1. mokutil --sb-state meldet weiterhin aktives Secure Boot.
2. modinfo nvidia | grep signer nennt den erwarteten Signierer.
3. nvidia-smi listet jede GPU; ein „Driver/library version mismatch“ nach einem Treiber-Update heißt, dass der Server noch nicht neu gestartet wurde.
4. Auf DKMS-Servern zeigt dkms status das Modul für den laufenden Kernel.
5. Unter RHEL 10 zeigt dnf nvidia-plugin keinen ohne Grund zurückgehaltenen Kernel.
6. DCGM und das Kernel-Log zeigen in den ersten Tagen keine neuen XID-Meldungen, wie unsere Referenz der XID-Fehlercodes beschreibt.

Was wir liefern

Sie können GPU-Server bei uns kaufen: Unser Team legt die Konfiguration nach Ihrer Last und Ihrem Budget aus und antwortet innerhalb eines Werktages. Wir bauen KI-Server nach Auftrag mit zwei bis acht GPUs, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer Rechnung und Herstellergarantie auf jede Komponente, und installieren auf Wunsch Betriebssystem, Treiber, CUDA und eine Container-Runtime. Senden Sie uns Distribution, Kernel-Richtlinie und Treiberzweig, und wir antworten mit einer passenden Konfiguration.

FAQ