Ich muss mal wieder einen kleinen Rant ablassen. In einem anderen Forum wo es um Windows 11 TPM, Secure Boot und Linux ging wurden wieder so viele falsche Informationen verbreitet - und diese auch noch verteidigt - dass ich manchmal einfach nur noch den Kopf schütteln kann.
Viele von euch werden es kennen. Die paar Tipps die man jemanden mitgibt wenn er das erste mal Linux ausprobieren will. Da sagt man oft vorab geh in dein BIOS und schalte dort TPM und Secure Boot aus sonst funktioniert Linux nicht.
Ausnahmslos alles an diesem Tipp ist falsch. Erstens heisst das nicht mehr BIOS sondern UEFI, alles an Computer, dass nicht älter als 15 Jahre ist wird UEFI und kein BIOS mehr haben. Zweitens hat Linux absolut keine Probleme mit angeschaltetem Secure Boot zu booten.
Und was TPM mit dem Boot-Prozess zu tun haben soll - kann auch niemandem erklären.
Das Problem an diesen "Tipps" ist nicht nru das sie falsch sind, sondern dass massiv die Sicherheit des Computers kompromittiert wird, wenn man diesen Tipps folgt.
Um zu verstehen woher dieses Halbwissen kommt muss man erstmal verstehen was Secure Boot und TPM ist und auch die Geschichte dahinter ergründen.
Secure Boot
Secure Boot wurde mit UEFI in Version 2.3.1 ein Teil der UEFI Spezifikation. Diese Spezifikation definiert das ein Betriebsystem nur geladen werden darf wenn es mit einer Signatur signiert wird, deren Vertrauenswüridigkeit im UEFI hinterlegt ist.
Die Idee dahinter ist, RootKits (und andere Malware) zu verhindern, die sich schon vor dem Booten in das Betriebssystem einnisten können.
Es ist in erster Linie ein Sicherheitsfeature. Es gibt unter Android und iOS bereits vor der Einführung von Secure Boot ähnliche Mechanismen - die haben dann z.b. das Booten von Custom Roms verhindert.
Auf dem PC/Computer Markt wurde Secure Boot mit Windows 8 relevant. Da Microsoft allen Hardware-Herstellern die Windows 8 per Default ausliefern wollen vorgeschrieben hat, dass Secure Boot vorhanden und aktiviert sein muss.
Windows 8 kam 2012 auf den Markt, also vor rund 10 Jahren kam die breite Einführung von Secure Boot.
Was hat das mit Linux zu tun?
Das ist etwas komplizierter. Das Problem an diesem Signatur Verfahren ist, dass man eine Organisation braucht, die diese Signaturen vergibt. Die dürfen aber nich jedem gegeben werden weil sonst Schadsoftware Hersteller ebenfalls an diese Signaturen kommen.
Die grossen Hardware-Hersteller haben sich darauf geeinigt, dass sie nur Signaturen vertrauen die von Microsoft herausgegeben werden. Das macht in Ihrer Logik Sinn, da sie Ihre Computer ja eh mit Windows verkaufen und alternative Betriebssysteme bei Ihnen nicht wirklich auf dem Radar waren.
Es gab vor 10 Jahren in der OpenSource Community dann die grosse Befürchtung, dass man Linux auf seinem Rechner gar nicht mehr installieren kann, da Microsoft die Schlüssel verwaltet und die Computer mit aktiviertem Secure Boot verkauft werden.
Das ganze war aber halb so schlimm, da die UEFI Spezifikation auch die Möglichkeit vorsah, dass man Secure Boot im UEFI ausschalten kann.
Microsoft selbst, hat bereits früh zugesichert, dass alle Betriebsysteme die eine Signatur wollen die auch unkompliziert bekommen sollen - und Microsoft hat dieses Versprechen die letzten 10 Jahre ausnahmslos gehalten.
Daher alle Mainstream-Linux-Distributionen nutzen heute einen von Microsoft siginierten Bootloader um ihr System mit aktivem Secure Boot booten und installieren zu können.
Als die neue Hardware auf den Markt kam, waren aber die meisten Linux Distributionen noch nicht ready. Wir kennen ja alle das Point-Release Modell. Sprich das aktuelle verfügbare Ubuntu hatte noch kein Secure Boot Support -> erst die Version die dann ein paar Monate später erschienen ist.
Daher wurde als Lösung vorgeschlagen im UEFI Secure Boot einfach zu deaktivieren.
Dieser Tipp von damals hat sich leider bis heute gehalten. Viele deaktivieren direkt Secure Boot bevor sie Linux Installieren, statt Linux einfach mit aktiven Secure Boot zu installieren. Obwohl ALLE Main-Stream Dsitributionen (Debian, Ubuntu, Linux Mint, Fedora, openSuse, etc) längst absolut keine Probleme mit Secure Boot hat.
Warum ist das dumm?
Naja immer mehr Software und Service Anbieter verstehen (oder werden politisch dazu gedrängt es zu verstehen), dass die Sicherheit ihrer Nutzer und deren Daten wichtig ist.
Seit Jahren kommunizieren wir bei Kurznachrichten (egal welcher Messenger) mit End-2-End Verschlüsselung. Das war nicht immer so, Wer mag sich noch an die ICQ, MSN und Skype Zeiten erinnern? Das war damals alles Klartext.
Und auch WhatsApp war zu Beginn nicht E2E verschlüsselt.
End-2-End Verschlüsselt bedeutet. Das wenn ich von meinem Gerät eine Nachricht an dein Gerät schicke. Wird diese Nachricht auf meinem Gerät verschlüsselt. Und auf deinem Gerät entschlüsselt. Der Dienstanbieter hat keinen Schlüssel und kann so die Nachrichten nicht mitlesen, da sie nur auf deinem und meinem Gerät in Klartext vorliegen.
Auch Webseiten sind heute beinahe nur noch über https:// erreichbar -> auch das war früher nicht so. Damit können Anbieter von öffentlichen Wlans z.b. nicht mehr die Inhalte der Webseiten mitlesen die oder verändern die du besuchst.
Apple beginnt nun damit ihre Cloud Inhalte E2E zu verschlüsseln (vorerst nur in den USA), so das die nun ebenfalls nicht mehr von dritten gelesen werden können.
Partitionsverschlüsselung ist unter Android, iPhone- / iPad OS, Mac OS und Windows inzwischen per DEFAULT eingeschaltet und aktiv.
Wir haben in den letzten 20 Jahren extrem viel für unsere Datensicherheit erreicht. Das Problem ist, all diese Bemühungen bringen am Ende nichts, wenn unser Boot Prozess auf unserem Computer nicht abgesichert ist.
Es bringt mir nichts, wenn man Nachrichten und Dateien alle schön verschlüsselt sind, wenn eine Schadsoftware sich beim booten in das Betriebssystem einnisten und nach dem booten alle diesen Daten lesen, verarbeiten oder sogar versenden kann.
Daher eine bitte von mir an euch alle: Bitte gebt niemanden als ersten Tipp, dass er "Secure Boot" ausschalten soll. Es kann Situationen geben wo man Secure Boot ausschalten muss (z.b. wenn man Virtual Box verwendet, da das Kernel-Modul von Virtual Box nicht sginiert ist). Aber auch da könnte man vorher überlegen ob man vllt nicht besser mit KVM/QEMU arbeitet bzw. virt-manager und gnome-boxes, die dieses Problem nicht haben.