Artikel-Schlagworte: „secure-boot-seuche“

2012/2013 war Secure Boot ein megaheißes Thema. So dermaßen heiß, dass ich sogar in meinem Feedreader zweistellig zählen konnte, siehe hier.

2020 ist dieses Rotzthema immer noch nicht tot.

Wie ist das möglich?

Gestern ein Update für das mitgelieferte Windows 10 auf einem Laptop gemacht, das berüchtigte Update 2004 vom Mai. Ich weiß nicht wieso, wohl aus Laune heraus oder weil ich einfach ein System wollte, wo ich nicht dauernd darauf hingewiesen werden möchte, dass es nicht 100% aktuell ist. Ich hätte es lassen sollen, denn ich verlor meinen GRUB.

Bootet anschließend Linux, bekam ich das hier heraus:

Welcome to Grub!
error: unknown filesystem.
Entering rescue mode…
grub rescue>

Jop, das war’s dann. Kein Linux will mehr booten. Und das mit ausgeschaltetem Secure Boot, ausgeschaltetem Fastboot _und_ dem manuell ausgewählten EFI-Eintrag im mitgelieferten BIOS-Interface.

Mit ls geht dann das Debugging los. Irgendwas mit (hd1,gptX) spuckt das System dann aus. Bei mir waren das 10+ Einträge. Jeden durchgehen, mit englischsprachigem Tastaturlayout, kurz vor Mitternacht, wo hängt mein verschollenes root herum?

Als es dann gefunden war, erst einmal /home gefunden, geil! Nix bootet. Glücklich war ich dann dennoch, denn irgendwie ist mein Linux ja noch da.

Da es auf einem Haussystem eigentlich nur zwei ext-Systeme geben kann wegen / und /home (oder welches Linux-Dateisystem auch immer man verwendet, z.B. reiser, etc.), hatte ich mit dem zweiten dann Glück. Mit folgenden Codezeilen brachte ich das System wieder in einen grafischen Bootzustand:

grub rescue > root=(hd1,gpt2)
grub rescue > prefix=(hd1,gpt2)/boot/grub
grub rescue > insmod normal
grub rescue > normal

Der soll dann zwar nur temporär sein, aber mir reicht das. Windows nutze ich vielleicht einmal im Schaltjahr. Dann kracht es aber richtig.

Ahhhh! Ahahahaha! Ihr Redmonder Zoophilie-Junkies mal wieder! Hatte euch schon fast komplett vergessen!

[Update I, 16.10.20]

Das mit der temporären Lösung ist einem ja irgendwann doch zu blöde, weshalb ich mir kürzlich wieder die permanente zurückerobert habe. Hier hilft es, wenn man sich zuerst mal ausgeben lässt, welche Partitionen man benutzt und wie diese heißen: lsblk -o PATH,PTTYPE,PARTTYPE,FSTYPE,PARTTYPENAME. Heutzutage wird das eher in Richtung nvmeXYZ gehen, bei älteren PCs ohne SSDs dann wahrscheinlich sda. Dann noch ein sudo update-grub, was bekannt sein sollte, sowie ein sudo grub-install /dev/sda bzw. ein sudo grub-install /dev/nvmeXYZ danach und dann „Macht’s gut, Redmond!“.

21 Nachrichten finde ich in meinem Feed-Reader seit Mitte Oktober zum Thema Secure Boot. Und das sind nur zwei Quellen. Macht im Schnitt runde vier Beiträge pro Monat. Also jede Woche mindestens ein Mal eine Meldung zu diesem Bullshit. Es reicht!

Das denkt sich endlich auch mal eine Gruppe von Leuten (8.000 insgesamt) und will dagegen etwas machen: Hispalinux hat gegen Micro$oft Klage bei der EU-Kommission eingereicht. 14 Seiten stark. Danke!

Ich nenne das Secure-Boot-Verfahren eine Seuche. Hispalinux drückt das eloquenter aus:

„Secure Boot mitsamt Microsofts Schlüssel [ist] „de facto ein technologisches Gefängnis für Computersysteme.“ Die Windows-Plattform sei damit so wenig neutral wie noch nie und verhindere fairen Wettbewerb.“

Meins ist besser. Aber so sieht es halt aus.

Dieses Verfahren, das derzeit eh nur von Windows 8 und Windows 2012 Server verwendet wird, ist nur ein weiterer Versuch der Redmond-Sklavenhalter euch eure Hardware wegzunehmen. Das Gerät wird hier nur als Teil der Software betrachtet, was ein Schlag ins Gesicht eines jeden Ingenieurs ist.

Überhaupt EFI: Selbst der Vorgänger von UEFI, entwickelt von Intel, spiegelt diese Windows-Techniken nur. Das war nie eine Weiterentwicklung des good old BIOS, sondern eine Remote-Schnittstelle für ein strauchelndes Software-Unternehmen. UEFI mit seinen elf „Partnern“, die sich „Promoter“ schimpfen: AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde Software, Intel, Lenovo, Microsoft und Phoenix Technologies. Logo.

Denkt was ihr wollt. Ich will Micro$oft tot sehen. Für immer.

Die Redmonder gelten nicht gerade als die kreativsten Köpfe im weitreichenden IT-Feld. Wenn es aber darum geht, die eigene Vormachtstellung zu behaupten, greifen sie mitunter auf abenteuerliche Methoden zurück. Eine davon ist das (ironischerweise) sogenannte Secure-Boot-System.

Zwar sind proprietäre BIOS-Systeme alles andere als neu und selbst die bringen ja gewisse Einschränkungen für den Endanwender mit. Doch zukünftig läuft das alles etwas anders, wenn man sich einen neuen PC kauft, auf dem Windows 8 vorinstalliert ist und das hilft keinem Linux-Nutzer.

Im Klartext, hier ein Kommentar von Glyn Moody, von „ComputerWorld“:

„…this „approach seems to be making it hard if not impossible to install GNU/Linux on hardware systems certified for Windows 8“.[20]

Genial, echt. Respekt, Redmond! Ihr habt euch wieder mal selbst übertroffen!

Das Geile: Diese Methode muss zwingend von M$ zertifiziert sein.

Man wird also einen Schlüssel brauchen, um auf dem PC, den man gekauft hat, ein anderes Betriebssystem zu installieren als das mitgelieferte.

All your hardware belongs to Micro$oft!1!1

Anyway.

Die Linux-Community arbeitet (oder muss ja im Endeffekt) an Workarounds. Man entwickelt quasi einen Bootloader für den Bootloader. Das klingt nicht nur komisch, das ist es auch: Der erste Bootloader braucht zwingend diese M$-Zertifizierung. Der zweite bietet dann die gewohnte Möglichkeit alternative Betriebssysteme zu installieren.

M$ will es wiederum den PC-Herstellern überlassen, Secure Boot zu deaktivieren. Wie großzügig. Bei Windows RT-Systemen, die mit der ARM-Architektur ausgestattet sind und die bei fast allen Smartphones, sowie bei Tablet-Computern zum Zug kommt, wird eine Deaktivierung von vornherein ausgeschlossen und unmöglich gemacht.

Hier zur Zusammenfassung, das Rätsel des Tages: Wie passt ein Private Key als Lizenz, signiert von einem der schäbigsten IT-Unternehmen aller Zeiten mit Open Source zusammen? Na? No. Fucking. Way.

[Update I: 26.11.12]

Leider alles keine Paranoia, sondern harte Realität:

„Man lädt aber nicht einfach sein UEFI-Binary hoch und bekommt es signiert zurück“, schreibt Bottomley. Es muss in eine Cab-Datei gepackt und zur Verifikation signiert werden. Dafür stehen freie Anwendungen bereit, für den Upload muss aber Silverlight verwendet werden, was nicht für Linux verfügbar ist.“

[via]

Jaja, die Redmonder. Insgeheim wissen sie ja schon genau, wie sie’s machen müssen…