Linux-Distribution: openSUSE Tumbleweed mit Problemen nach Kernel-Locking
Die Linux-Distribution openSUSE Tumbleweed akzeptiert bei aktiviertem SecureBoot nur noch signierte Treiber. Das hat derzeit recht drastische Folgen.
(Bild: heise online)
Als Rolling-Release-Distribution erhält openSUSE Tumbleweed kontinuierlich aktualisierte Software. Vor ein paar Tagen flutschte dabei auch der Linux-Kernel 6.2.1 auf die Systeme der Anwender. Ihn hat das openSUSE-Team allerdings so präpariert, dass er bei aktiviertem SecureBoot ausschließlich signierte Treiber lädt. Dieser weitgehend kommentarlos eingeführte Lockdown führte umgehend zu gleich mehreren Problemen.
Tumbleweed: Kernel-Locking mit Nebeneffekten
So blieb auf vielen Systemen mit proprietärem Nvidia-Grafikkartentreiber der Bildschirm schwarz, auch die Kernel-Module der Virtualisierungslösung VMware Workstation verweigern ihren Dienst. Neben solchen proprietären Treibern sind zudem alle selbst geschriebenen Kernel-Module betroffen. Überdies funktioniert der Ruhezustand (Hibernation) nicht mehr und das Schreiben in Model Specific Register (MSR) ist untersagt. Letztere nutzen etwa Tools zum Undervolting von Prozessoren.
Den Lockdown wieder zurücknehmen ist jedoch aus Sicherheitsgründen keine gute Option: SecureBoot soll garantieren, dass beim Bootvorgang kein Schadcode und insbesondere kein manipulierter Betriebssystemkern startet. Würde openSUSE Tumbleweed weiterhin unsignierte Treiber gestatten, könnten Angreifer darüber eigenen Code einschleusen und so wiederum SecureBoot aushebeln. Viele andere große Distributionen haben daher bereits seit längerem das Locking aktiviert. Das gilt übrigens auch für die Schwesterdistribution openSUSE Leap, weshalb die derzeitigen Probleme bei Tumbleweed überraschen.
Für selbst entwickelte und proprietäre Treiber gab es zunächst einen vielversprechenden und auf anderen Distributionen erprobten Lösungsvorschlag: Nach der Übersetzung der Treiber erstellt man manuell ein eigenes Zertifikat, das man dann im BIOS als vertrauenswürdig hinterlegt. Wer den proprietären Nvidia-Treiber aus dem entsprechenden Community-Repository "nVidia Graphics Drivers" installiert, kann sich diesbezüglich sogar etwas zurücklehnen.
Die dortigen Pakete haben die Entwickler vor wenigen Tagen so angepasst, dass sie bei ihrer Installation automatisch ein Zertifikat erzeugen. Man muss es lediglich nach einem Rechnerneustart einmalig als gültig bestätigen. Mit diesem immer noch etwas umständlichen Verfahren könnte man leben – wenn es denn unter openSUSE Tumbleweed funktionieren würde. Dessen Kernel 6.2.1 lädt derzeit unbeirrbar nur direkt von openSUSE signierte Treiber.
Temporäre Gegenmaßnahmen
Als Workaround bleibt daher nur, SecureBoot im BIOS komplett zu deaktivieren oder über den Befehl "mokutil --disable-validation" die Überprüfung der Kernel-Module abzuschalten. In beiden Fällen knipst man jedoch eine Sicherheitsfunktion des Systems aus. Bei einem Dual-Boot-System mit Windows 11 verweigert jenes zudem nach dem Deaktivieren von SecureBoot zurecht den Start. Wer nur seine Nvidia-Grafikkarte wieder zum Leben erwecken möchte, kann in der Datei /usr/lib/modprobe.d/nvidia-default.conf eine Raute vor die darin befindliche Zeile setzen. Dies reaktiviert den freien Treiber Nouveau, dem aber noch viele Funktionen des proprietären Treibers fehlen.
Die Probleme rund um das aktivierte Locking diskutieren die Entwickler derzeit auf der openSUSE Factory Mailingliste.
Version von Windows ergänzt, die SecureBoot als Hardware-Voraussetzung hat.
(dmk)