Windows-Update blockiert den Start von vielen Linuxen
Hi, folgender Artikel in der aktuellen Ausgabe der Zeitschrift C't ließ mich aufhorchen: https://www.heise.de/hintergrund/Bootloader-Signaturen-per-Update-zurueckgez... (nur mit ABO komplett lesbar) Im Kern geht es darum, daß mit einem der letzten Windows-Updates eine Art Blacklist im UEFI-Bios des Mainboards eingespielt wurde, welche den Start von vielen Linuxen verhindert. Begründet wird das Seitens Microschrott mit Sicherheitsbedenken in den Bootloadern. Das Kernproblem ist aber dabei daß MS faktisch ein Monopol auf das Signieren der Bootloader hat und die Mainboardhersteller keine Alternativen mehr anbieten (zB Secure Boot abstellen). Meine Fragen dazu: - bei mir sind die Rechner alle MS-frei, besteht trotzdem irgendwie die Gefahr, daß da irgendwas ins BIOS geladen wird (zB bei Intel-Boards per Management Engine)? - könnte das auch mein Problem auf einer früheren Anfrage "Re: Leap 15.4 läßt sich nicht installieren, Hänger" begründen - gibt es eine Art "Aktionsbündnis" oder Petitionsaufruf (Webseite), damit die Politik aktiv wird und gegen diese MS-Monopolstellung gesetzlich aktiv wird (so wie am Ende des C't Beitrages angedacht). Momentan mache ich mir schon ein bißchen Sorgen, ob ich zukünftig problemlos PCs mit Linux betreiben kann... Jürgen
Jürgen Hochwald schrieb:
folgender Artikel in der aktuellen Ausgabe der Zeitschrift C't ließ mich aufhorchen:
https://www.heise.de/hintergrund/Bootloader-Signaturen-per-Update-zurueckgez...
(nur mit ABO komplett lesbar)
Im Kern geht es darum, daß mit einem der letzten Windows-Updates eine Art Blacklist im UEFI-Bios des Mainboards eingespielt wurde, welche den Start von vielen Linuxen verhindert. Begründet wird das Seitens Microschrott mit Sicherheitsbedenken in den Bootloadern. Das Kernproblem ist aber dabei daß MS faktisch ein Monopol auf das Signieren der Bootloader hat und die Mainboardhersteller keine Alternativen mehr anbieten (zB Secure Boot abstellen).
Meine Fragen dazu: - bei mir sind die Rechner alle MS-frei, besteht trotzdem irgendwie die Gefahr, daß da irgendwas ins BIOS geladen wird (zB bei Intel-Boards per Management Engine)? - könnte das auch mein Problem auf einer früheren Anfrage "Re: Leap 15.4 läßt sich nicht installieren, Hänger" begründen - gibt es eine Art "Aktionsbündnis" oder Petitionsaufruf (Webseite), damit die Politik aktiv wird und gegen diese MS-Monopolstellung gesetzlich aktiv wird (so wie am Ende des C't Beitrages angedacht).
Momentan mache ich mir schon ein bißchen Sorgen, ob ich zukünftig problemlos PCs mit Linux betreiben kann...
Microsoft hat mit dem August-Update einige Zertifikate für alte Versionen von "shim" für viele Linux-Distributionen revoked und zwar (nach meiner Kenntnis) nicht aus Willkür, sondern weil da ein Bug drin war. Das betrifft NICHT die aktuelle Version von shim (15.4, hat aber nichts mit der OpenSuse-Version zu tun). Alle Distributionen verwenden nach meiner Kenntnis in aktuellen Versionen diese Version von shim und dann gibt es keine Probleme. Im Übrigen lässt sich Linux auch ohne Secure Boot betreiben und ist auch im "BIOS"-Menü des UEFI abschaltbar. Ein Microsoft-freies System hat somit ohnehin kein Problem. Nach meiner Kenntnis lässt sich sogar Windows 11 ohne Secure Boot betreiben, wenn es einmal installiert ist. Es lässt sich sogar mit zusätzlichen Schritten ohne Secure Boot installieren. Und wenn man Windows in einer VM betreibt und eben nicht per Dual Boot hat man sowieso auch keine Probleme. Im Übrigen ist Secure Boot - abgesehen vom "Lizenzmonopol" von Microsoft - eigentlich ein gutes Konzept, was auch unter Linux funktioniert und den Schutz gegen Malware verbessert, die sich wenigstens nicht mehr so einfach ins System einnisten kann. Und unter Linux kann man auch seine eigenen Zertifikate in die MOK-Database laden und TROTZ aktiviertem Secure Boot selbst geschriebene Kernel-Module laden. Einfach ein Schlüsselpaar mit openssl erzeugen und per mokutil --import in die MOK-Datenbank laden, dann booten und den Import vor (!) dem Start des Betriebssystems bestätigen. Die eigenen Kernel-Module signiert man mittels "sbsign" und dem vorher erzeugten Schlüsselpaar. Habe ich schon gemacht, funktioniert perfekt. Ist nur leider mal wieder eher schlecht dokumentiert. Also, ich weiß nicht, was die bei Heise im Kaffee hatten... -- Manfred Härtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel
participants (3)
-
Jürgen Hochwald
-
Manfred Haertel, DB3HM
-
Ulf Volmer