1) Was ist was?
EFI soll mal der Ersatz für das gute alte BIOS werden. Somit ist EFI eigentlich kein BIOS, sondern dessen Nachfolger, trotzdem rede ich mitunter gerne und technisch falsch vom "EFI-BIOS".
Eigentlich müsste sich damit gar nicht soviel ändern, denn EFI stellt lediglich mehr Flexibilität zur Verfügung. Dass es trotzdem soviele Probleme damit gibt, liegt häufig an den grottenschlechten und fehlerhaften Implementierungen der Hersteller und an der Ahnungslosigkeit der Anwender. BIOS-Bugs haben mich unter Linux schon oft geärgert, und es sieht nicht so aus, als würde das durch EFI besser werden. Der beste Punkt zum Ansetzen ist somit die Ahnungsloigkeit ... darum existiert dieser Text.
Die Fehler in EFIs sind trotzdem nicht zu unterschätzen ... Samsung hat gerade ein Glanzstück der Unfähigkeit vollbracht und massenweise Notebooks rausgebracht, die sich von einer simplen Linux-Installation völlig außer Gefecht setzen lassen. Was dann erst wirklich bösartige Software auszurichten vermag, werden wir bestimmt in den nächsten Monaten in der Presse lesen.
Die GPT (oder länger "GUID-PT" oder noch länger "Globally Unique Identifier Partition Table") hat eigentlich gar nichts mit EFI zu tun, außer dass EFI sie verstehen können muss. Beides wird aber gerne in einem Atemzug genannt. Die GTP enthält eine Liste der Partitionen auf der Festplatte und erfüllt damit genau denselben Zweck wie der gute alte MBR. Allerdings erlaubt die GPT bis zu 128 Partitionen und Partitionsgrößen über 2TB, im Gegensatz zu den 4 Partitionen (mit Tricks 8 ) des MBR. Also ist auch das eigentlich eine gute Sache.
EFI (das Extensible Firmware Interface) ist, wie der Name schon sagt, durch Module erweiterbar. Eins dieser Module ist Secure Boot. Secure Boot ermöglicht es, eine digitale Signatur des Bootloaders im BIOS abzulegen und schreibt vor (das ist der wichtige Teil!) dass diese Signatur sich nach dem Anstoßen des Bootvorgangs nicht mehr ändern lässt. Ist Secure Boot eingeschaltet, prüft es den Bootloader anhand der Signatur auf Veränderungen und warnt, wenn der Bootloader kompromitiert worden ist. Auch das ist eine gute Sache ... mit einigen Folgesignaturen lässt sich die Integrität des Systems vom Bootloader über den Kernel, die Treiber bis zu wichtigen Systemprogrammen sicherstellen. Per Spezifikation ist Secure Boot denkbar harmlos ... es muss sich ausschalten lassen und über die EFI-Shell müssen sich auch die Signaturen eigener Bootloader hinterlegen lassen. Edit: Da der Debian-Installer von Wheezy zumindest in der aktuellen Version 7.1 bisher nicht mit Secure Boot umgehen kann, muss man es für eine erfolgreiche Installation ausschalten /Edit
Ein weiteres Modul von EFI ist das BIOS-Kompatibilitätsmodul. Ein reines EFI kann per Spezifikation nur mit GPT-Partitionen umgehen und startet einen Bootloader, der in einer FAT-Partition als Datei hinterlegt ist. Um auch von MBR-Partitionen booten zu können, wird das BIOS-Kompatibilitätsmodul gestartet und erledigt das, was man von einem BIOS ja eigentlich erwartet ... booten.
Bis jetzt wird jedes Desktop-Mainboard mit EFI mit so einem BIOS-Kompatibilitätsmodul ausgeliefert, sie funktionieren auch immer, aber ob es ein- oder ausgeschaltet ist und wie es bezeichnet wird, unterscheidet sich von Hersteller zu Hersteller. Auch bei den meisten Notebooks ist es vorhanden, es gibt allerdings Gerüchte über die ersten Win8-Notebooks ohne BIOS-Kompatibilität ... logisch, das spart den Herstellern Arbeit.
Das Video-Modul:
Es zwingt die Hersteller zwar niemand, ein bestimmtes Design einzuhalten, trotzdem sahen sich bisherige BIOSe allesamt recht ähnlich. Damit ist seit EFI Schluss. EFI bringt ein Video-Modul mit, welches höhere Auflösungen und anspruchsvollere grafische Oberflächen erlaubt (gerüchteweise sogar 3D-Unterstützung). Somit liegt das Aussehen und die Bedienbarkeit eines EFI jetzt in den Händen von Technikern, die noch nie im Leben eine grafische Benutzeroberfläche konstruiert haben ... und genau so sehen sie auch aus. Ein wenig Entdeckergeist und Experimentierfreude ist angesagt, und mit etwas Glück ähnelt die im Handbuch beschriebene EFI-Version sogar noch der auf dem Board.
2) Der Bootprozess
Ein EFI-Mainboard kann ja, wie gerade erklärt, entweder im EFI-Modus oder im BIOS-Modus booten. Somit macht es Sinn, trotz EFI-Board zwischen BIOS-Boot und EFI-Boot zu unterscheiden. Der EFI-Boot bietet einige Vorteile - er geht schneller und der EFI-Bootloader lässt sich mit einem sprechenden Namen in die EFI-Firmware eintragen. So kann man dann "Debian" booten statt von "SATA 1". EFI hat somit die Möglichkeit, in einer Multiboot-Installation das Auswahlmenü von Grub zu ersetzen. Wenn mehrere EFI-Bootloader in die Firmware eingetragen sind, könnte eine nette Liste mit "Debian", "Debian Testing" und "Ubuntu" auftauchen. Die Betonung liegt auf "könnte" ... nicht jeder Hersteller kriegt sowas hin oder denkt überhaupt daran.
a) EFI-Boot
Hierfür ist eine GPT-Partitionierung zwingende Voraussetzung. Das EFI sucht in der GPT eine FAT-Partition (ja, das gute alte Microssoft FAT) und in dieser FAT-Partition das Verzeichnis "EFI/boot" und in diesem Verzeichnis die Datei "bootx64.efi". Ja, das ist alles ... eine FAT Partition mit dem Bootloader unter "/EFI/boot/bootx64.efi" und die Kiste bootet. Klingt doch schön einfach, oder?
Das EFI dafür eine eigene Partition verschwendet, ist auch nicht tragisch ... wir haben ja noch 127 in Reserve.
Falls das EFI eine EFI-Shell anbietet (mein Mainboard tut das nicht), kann man mit kryptischen Tastaturbefehlen auch andere Dateien aus dem EFI-Verzeichnis in die Firmware als Bootloader eintragen.
b) BIOS-Boot von GPT
Die GPT enthält als ersten Sektor noch immer einen MBR. Im MBR steht ein winziger Bootloader und die Partitionstabelle ... eh ... nein ... die Partitionstabelle steht jetzt ja am Anfang der GPT. Der MBR der GTP enthält trotzdem noch eine Partitionstabelle ... diese enthält genau eine einzige Partition, die den gesamten Rest aller GPT-Partitionen einschließt. Das dient zum Schutz der GTP, dementsprechend heißt dieser MBR in der GPT auch "protective MBR". Aber egal ... was uns ja interessiert ist das Booten ... und das geht wie bisher auch ... der MBR wird gelesen, der Bootloader ausgeführt und lädt im Fall von Grub hoffentlich die Stage 2 und alles läuft wie gewohnt weiter.
c) BIOS-Boot vom MBR
Auch das ist mit EFI im BIOS-Kompatibilitätsmodus problemlos möglich. Ob MBR oder GTP, das hat ja nicht das EFI zu entscheiden, sondern euer Partitionierungsprogramm. Und das geht wie gewohnt ... der MBR wird gestartet, denn Grub ... alles beim Alten.
Was mache ich da eigentlich?
--------------------------------------------
Tja, das klingt zwar alles sehr einfach, aber das EFI macht es einem mitunter nicht leicht. Meins versucht zum Beispiel unheimlich schlau zu sein und zeigt mir die Festplatten allesamt mit Hersteller und Produktbezeichnung an. Nicht sehr hilfreich, wenn man vier mal die gleiche Platte im System hat. Wenigstens schreibt es ein "P0", "P1" u.s.w. davor, damit man sie auseinanderhalten kann. Was das "P" bei einem "S"ATA-Anschluss soll, weiß ich nicht. Das macht es übrigens nur, wenn es keinen EFI-Bootloader auf einer GPT-Platte findet. Damit will es mir also sagen, dass es einen BIOS-Boot durchführt. Findet es auf der Platte noch einen EFI-Bootloader, so habe ich die Platte zwei mal in der Liste ... einmal mit einem "P" davor und einmal mit einem "UEFI" davor ... ich kann sie also wahlweise im BIOS- oder im UEFI-Modus booten. Das ist praktisch zum Ausprobieren. Aber freut euch nicht zu früh ... das kann bei eurem EFI ganz anders aussehen.
Seltsamer Weise geht das bei mir nur, wenn die Platte (oder das DVD-Laufwerk) an einem der vier Intel-SATA-Anschlüsse hängt. Hängt sie am zusätzlichen Onboard-Controller, so kriegt das Mainboard keinen UEFI-Boot hin. Ihr seht also ... der Teufel steckt im Detail ... beziehungsweise in der Unfähigkeit der Mainboardhersteller.
Zwischen einem BIOS-Boot per MBR oder per GPT unterscheidet das EFI nicht ... warum sollte es auch.
3) Debian
Eins vorweg ... ich möchte es nicht beschwören, aber ich vermute, keine 32-Bit-Version macht ein EFI-Boot. Mit 32 Bit bleibt euch also nur der BIOS-Boot.
a) Squeeze
Squeeze hat noch nie von EFI gehört und wird es auch nie tun. Es kann allerdings mit einer GTP umgehen. Somit wird ein Squeeze-Upgrade auch nie ein EFI-Boot machen. Eigentlich kann einem das ja egal sein, wenn Squeeze eh schon auf der Kiste läuft, dann läuft es ja, und auch ein Upgrade auf Wheezy wird laufen, das benutzt ja einfach den alten Bootprozess weiter.
Es gibt allerdings eine Besonderheit für diejenigen, die auf einer GPT installiert haben. Grub wird aktualisiert und bringt eine Neuerung mit: Da eine GPT einem reichlich Partitionen ermöglicht, möchte Grub gerne eine für seine Stage 2 verschwenden. Diese Partition sollte 1024 KB groß sein (also winzig) und trägt die Partitionskennung "EF02". gdisk nennt sowas "Bios Boot-Partition", gparted nennt es "bios_grub". Diese Partition wird allerdings nicht automatisch angelegt, grub meckert beim Update nur, dass sie fehlt. Solang man keinen guten Grund hat, sollte man aber einfach alles so lassen, wie es ist. Debian bootet auch ohne diese Partition und das Gemecker von grub muss man halt ignorieren. Wer an den Partitionen rumschraubt riskiert, dass das System nachher nicht mehr bootbar ist, weil der MBR-Loader die Stage 2 nicht mehr findet. Dagegen hilft natürlich ein update-grub ... je nach eurem Geschick eventuell von einer Live-DVD per chroot.
b) Wheezy
Ich muss gestehen, ich habe keine Ahnung, in welchem Zustand der Installer von Wheezy gerade ist. Bei meinem Versuch habe ich es zumindest nicht hinbekommen, den Beta4-Installer im EFI-Modus zu booten, was wohl die Voraussetzung für eine Installation mit EFI-Boot ist. Das mag an meinem Mainboard gelegen haben ... Bugs kann man ja nie so ganz ausschließen *hüstel*. Die Windows 8 DVD ließ sich zumindest im EFI-Modus booten.
Erklärtes Ziel von Wheezy ist es zumindest, eine Installations-DVD mit EFI-Unterstützung herauszubringen. Diese sollte sich dann auch per EFI-Boot (bei mir steht dann "UEFI" vor dem DVD-Laufwerksseintrag im Bootmenü) starten lassen. Ich kann nur jedem, der eine Neuinstallation machen möchte raten, sich das aktuelle Daily Build zu ziehen und es damit zu versuchen.
Das bedeutet nicht, dass ich Wheezy nicht installieren konnte. Nein, das ging prima. Der Installer hat halt nur im BIOS-Modus gebootet.
Das wäre auch nicht weiter tragisch gewesen, wenn ich mir nachher etwas hätte aussuchen können ... konnte ich aber nicht. Vielleicht lag es an meiner Blödheit, vielleicht am unfertigen Installer, aber mir war weder klar, ob er jetzt GPT- oder MBR-Partitionen anlegt und ob er jetzt ein EFI- oder ein BIOS-Boot installiert. Letztendlich hat er MBR-Partitionen angelegt und nachher im BIOS-Modus gebootet.
Fakt ist - es ging! Ich habe nichts zu meckern, die Installation lief glatt durch, keine Probleme, und das Booten lief auch einwandfrei.
Ich wollte nur gerne GPT und EFI-Boot haben.
Somit hab ich die Parted-Magic-CD gezückt und mir erst mal selber eine GPT-Partitionierung auf die Platte geschrieben. Danach hab ich mich an diese Anleitung gehalten:
http://forums.debian.net/viewtopic.php?f=16&t=81120
Und das hat auch funktioniert.
Da steht übrigens, dass der aktuelle Wheezy-Installer auf einer leeren Platte zu einer GPT neigt. Nun war meine Platte nicht leer, sondern mit Zufallszahlen vollgeschrieben ... vielleicht war sie dem Installer nicht leer genug und er hat deswegen MBR gewählt. Das zeigt schon das Problem ... der Installer versucht zu erraten, was der Benutzer möchte ... eine GPT oder MBR, EFI oder BIOS. Startet man die Installer-DVD im BIOS-Modus, so geht er sinnvoller Weise von einem BIOS-System aus und installiert einen BIOS-Boot. Startet man per EFI-Boot, so installiert er auch EFI-Boot. Eigentlich ganz einfach ... wenn es nicht manchmal schon Schwierigkeiten machen würde zu erkennen, in welchem Modus man gerade bootet. Wer sicher gehen will, sorgt vorher mit gparted für die richtige Partitionstabelle und beschäftigt sich mit seinem EFI, wem es egal ist, der kriegt trotzdem ein bootbares System.
Langer Rede kurzer Sinn: ja, man kann Wheezy auf EFI installieren. Bei der großen Mehrheit der Systeme mit BIOS-Kompatibilitätsmodus geht es problemlos, und bei den wenigen reinen EFI-Systemen wird es auch gehen, spätestens wenn Wheezy fertig ist. Falls nicht, habt ihr einen handfesten Bug gefunden.
Ich mag keinen Rat geben, ob man nun auf EFI-Boot, GPT mit BIOS-Boot oder den guten alten MBR setzt, zu unterschiedlich sind die Anwendungsfälle. Wer auf EFI setzt, der hat keine Möglichkeit, diese Platte mal auf einem alten BIOS-Rechner zu starten, und wer MBR wählt, der verschenkt vielleicht tolle komfortable Möglichkeiten seines Mainboards ... falls die denn funktionieren. Letztendlich ist es egal ... Hauptsache, die Kiste bootet, und das tut sie so gut wie immer.
Ich rate jedoch, wenn man sich für GPT entscheidet, am Anfang der Festplatte zuerst eine FAT-Partition mit 250 MB Größe für den EFI-Bootloader unterzubringen (mit gdisk muss die den Partitionstyp "EF00" oder "EFI System" tragen, bei gparted wird schlicht das "boot"-Flag gesetzt). Und dahinter eine 1024 KB Partition für Grub, wie unter "Squeeze" beschrieben. Wenn ihr beide habt, könnt ihr später ohne viel Ärger zwischen EFI-Boot und BIOS-Boot hin- und herspringen. Aber um mich noch mal zu wiederholen: nötig ist das nicht - der Debian-Installer wird euch schon ein bootbares System auf den Rechner zaubern, aber da man mitunter nicht erkennen kann, ob man ein BIOS- oder ein EFI-System installiert, kann man wenigstens nachträglich noch wechseln, wenn beide Partitionen vorhanden sind.
Edit: Auch wenn die Reihenfolge der Partitionen eigentlich egal sein sollte, und das EFI die "EFI System"-Partition überall auf der Festplatte erkennen können sollte, so gibt es doch auch hier leider fehlerhafte Implementierungen, und es ist sicherer, die FAT-Partition als erste und an erster Stelle auf der Festplatte zu erzeugen. /Edit
Tipp: MBR zeichnet sich dadurch aus, das sich nicht mehr als 4 primäre Partitionen anlegen lassen. Wer im Installer testen will, ob er gerade mit MBR oder GTP partitioniert, der kann einfach mal testweise ne 5te primäre Partition anzulegen versuchen. Man kann sie ja gleich wieder löschen.
4) Tools
a) Partitionierung
Das gute alte fdisk kann nicht mit GPT umgehen - es zeigt nur die große Protected MBR Partition an. Immerhin könnt ihr so auch nichts kaputt machen, aber es hilft euch auch nicht weiter. Es gibt wohl etliche Partitionierungs-Programme, die mit einer GPT umgehen können ... hier seien nur "gparted" (mit GUI) und gdisk (Kommandozeile) genannt.
b) grub
Ihr hasst grub? Dann freut euch ... es gibt jetzt sogar zwei davon! "grub-pc" und "grub-efi".
Beide schließen einander aus.
Die "pc"-Version installiert einen gewöhnlichen Boot über den MBR.
Die "efi"-Version installiert einen EFI-Bootloader in der FAT-Partition. Hierbei wird die FAT-Partition unter /boot/efi gemounted, so dass der EFI-Bootloader von Debian aus gesehen im Verzeichnis /boot/efi/EFI/boot/ zu liegen kommt. Debian bewahrt seine eigenen Bootloader im Verzeichnis /boot/efi/EFI/debian auf, so dass man sie auch direkt von da in die Firmware eintragen könnte ... wenn man denn kann.
Theoretisch sollte man, solange die beiden oben erwähnten Partitionen angelegt sind, leicht zwischen den beiden Versionen wecheln können, schlicht durch Installation der anderen Version. Ob das geht, habe ich nicht ausprobiert, aber es könnte etwas Handarbeit nötig sein. Zumindest die Existenz der oben erwähnten Verzeichnisse sollte man überprüfen, eventuell muss man sich auch per Hand ums Mounten kümmern.
Nach dem Wechsel von grub-pc zu grub-efi konnte ich im EFI-Modus booten, jedoch nicht mehr im BIOS-Modus. Ein "Hybridsystem" scheint also nicht möglich. Zumindest nicht ohne Handarbeit.
grub-efi unterstützt übrigens kein Chainloading von MBR-Partitionen oder MBR-Bootblöcken. Dazu ist ein BIOS notwendig, und wenn man UEFI-Boot macht, existiert das BIOS während des Bootprozesses schlicht nicht mehr. Das macht Probleme in Multiboot-Umgebungen, diese sollten also vorher geplant werden.
Mitunter sieht man das Grub-Auswahlmenü beim EFI-Boot nicht. Das liegt daran, dass EFI die oben erwähnten Video-Module hat, und davon gibt es mindestens zwei verschiedene. Booten geht trotzdem, und wenn ihr betroffen seid, fehlt euch das zweite Modul. Das lässt sich leicht beheben, indem ihr in die Datei /etc/default/grub folgende Zeile eintragt:
Code: Alles auswählen
GRUB_PRELOAD_MODULES="efi_gop"* efibootmgr lässt einen von Linux aus das EFI konfigurieren, insbesondere kann man eigene Booteinträge
ins NVRAM des Mainboards schreiben. Die Ubuntu-Anleitung ist da sehr aufschlussreich:
http://wiki.ubuntuusers.de/efibootmgr
* Super Grub2 Disk - EFI x86_64 standalone version
http://www.supergrubdisk.org/category/d ... sk-stable/
Dies ist ein EFI-Binary, lässt sich also vom Mainboard direkt ausführen, wenn man es entweder als EFI-Loader auf der Festpatte oder dem USB-Stick hinterlegt, oder es per EFI-Shell direkt ausführt. Damit lassen sich zickige EFI-Systeme starten, auch wenn der eigene Bootloader mal streikt.
* Oben erwähnte EFI-Shells gibt es auch als EFI-Binary zum Selberbooten (nicht getestet):
https://wiki.archlinux.org/index.php/UEFI#UEFI_Shell
* Da der eigentliche EFI-Bootprozess herrlich einfach ist und nur ein EFI-Binary auf der FAT-Partition voraussetzt, gibt es auch zahlreiche andere EFI-Bootloader für Linux, z.B. rEFInd, bis hin zu Plänen, den gesamten Linux-Kernel als EFI-Binary zu gestalten.
5) Secure Boot unter Debian
In einem korrekten EFI-BIOS sollte sich Secure Boot ausschalten lassen, es macht also absolut keine Probleme bei der Installation.
Mit eingeschaltetem Secure Boot hat man allerdings große Probleme, es wird von Debian noch nicht unterstützt. Die Arbeit daran läuft zwar auf Hochtouren, aber da Secute Boot erst Ende 2012 auf Druck von Microsoft in den Markt geschoben wurde, wird das noch einige Zeit dauern.
Schlimm ist das nicht ... die Entwicklung von Secure-Boot-Unterstützung für Linux steckt noch in den Kinderschuhen und bietet somit auch keinen großen Schutz. Außerdem ist eh davon auszugehen, dass die aktuellen EFI-Implementierungen fehlerhaft sind und sich irgendwie aushebeln lassen.
Edit: Bitte das Posting von Mecki unten beachten, der erklärt, wie man Debian auch mit Secure Boot zum Laufen kriegt, indem man sich mit dem Ubuntu-Bootloader behilft. /Edit
Es gibt Gerüchte, dass es Laptops mit vorinstalliertem Windows 8 geben soll, auf denen sich Secure Boot nicht ausschalten lässt. Also unbedingt vorher schlau machen! Windows 8 läuft auch ohne Secure Boot, es gibt also keinen Gund, diese Option nicht-ausschaltbar einzubauen, außer der Geldgier der Hersteller. Erstens spart man so Geld an den Entwicklungskosten, und zweitens am Support, denn je weniger der Kunde am Gerät rumspielen kann, desto weniger kann er kaputt machen.
6) Windows 8
Tja ... hier fangen die Probleme an ...
Schon ein vorinstalliertes Windows 8 kann Probleme machen, denn mit aktiviertem Fast Boot geht der Bootvorgang so schnell, dass man nicht mal mehr ins EFI kommt, um Secure Boot auszuschalten. Also muss man erst mal Fast Boot ausschalten, dann kommt man auch ins EFI.
Danach sollte man sich überlegen, ob man die GPT auf der Festplatte lassen will, oder doch lieber MBR haben will, und das gegebenenfalls mit einem Partitionseditor ändern. Danach gibt es keine weiteren Probleme mehr ... einfach Debian drauf wie oben beschrieben und fertig.
7) Dualboot mit Windows 8
Das ist auch nicht so schwer. Der Königsweg ist nach wie vor, sich erst eine Partitionierung zu überlegen, dann Windows 8 zu installieren, und danach Debian. Das geht auch locker und flockig von der Hand, Grub erkennt Win8 und es erscheint im Grub-Menü.
Probleme kriegt man, wenn man einen Rechner mit billigem OEM-Win8 erworben hat ... Microsoft verkauft das nicht ohne Grund so billig. Es liegt kein Installationsmedium bei, das könnt ihr euch erst mal selber machen, es gibt auch keinen Aufkleber mit dem Product-Key mehr, der steckt jetzt im BIOS, und wenn man sich das Leben richtig schwer machen will, dann verzichtet man auf die Neuinstallation und versucht mit irgendwelchen Tools, die Windows-Partition zusammenzuschieben. Dabei sollte man Fast Boot unbedingt ausschalten, ebenso wenn man von Linux aus auf die Windows-Partition zugreifen will.
Aufgrund dieser Probleme sollte man den Verkäufer fragen, ob man nicht gegen Aufpreis die normale Version von Windows 8 (ohne OEM) bekommen kann ... die hat nämlich wenigstens einen Product Key und lässt sich somit auch auf VirtualBox oder einem anderen Rechner installieren oder gar verkaufen. Und es liegt ne DVD bei ... das ist auch immer praktisch, schon um Windows mal zu retten, Fast Boot sorgt nämlich auch dafür, dass man nicht mehr ins Windows-Bootmenü kommt, um den Abgesicherten Modus zu starten, den man mitunter braucht, um Fast Boot zu deaktivieren.
8 ) Gerüchte über Secure Boot und Microsoft
Secure Boot ist, wie oben beschrieben, eine gute Sache ... wenn man es braucht. Installiert man öfter neue Systeme und ist generell eher der "Bastler" so kommt es einem schnell in die Quere. Macht aber nix ... es lässt sich ja ausschalten.
Erfunden hat es Intel, und Microsoft hatte großes Interesse ... kann ich verstehen, deren Betriebssystem ist ja das Angriffsziel Nummer eins. Und Microsoft hat beschlossen, es zügig in den Markt zu drücken ... kann ich auch verstehen. Nun ist es bei der Zertifizierung der digitalen Signaturen so, dass irgendjemand sie zertifizieren muss ... da hat sich natürlich gleich Microsoft angeboten. Somit tragen jetzt alle Secure-Boot-Module ein Stammzertifikat von Microsoft in sich ... was sollten die Mainboard-Hersteller auch machen, ein anderes haben sie ja nicht bekommen.
Somit kann Microsoft jetzt angefangen vom Bootloader bis hin zum letzten Treiber alles als unbedenklich absegnen, was unter Windows 8 läuft, und Secure Boot prüft das. Ob das nun Sinn macht, sei mal dahingestellt ... Microsoft bastelt ja selber genug Sicherheitslücken in sein System, und die werden nicht sicherer, wenn Microsoft sie absegnet. Aber der Ansatz ist trotzdem nicht verkehrt - Secure Boot soll ja die Unkompromitiertheit des eigenen Systems sicherstellen ... inklusive aller Sicherheitslücken.
Die Linux-Szene hat das komplett überrollt ... Secure Boot ist inzwischen fertig und wird massenweise ausgeliefert und die Linux-Loader dafür stecken noch in den Kinderschuhen. Zusätzlich gab es natürlich reichlich misstrausche Kritik an der Microsoft-Signatur. Allerdings ist Microsoft da durchaus kooperativ und hat sich bereit erklärt, auch fremde Bootloader zu signieren. Das ist fein, so muss man nicht jeden Mainboardhersteller dazu bringen, auch noch andere Signaturen einzubauen. Das ist also alles gar nicht so dramatisch.
Kritik gibt es allerdings daran, dass ein Secure-Boot-Linux noch nicht fertig ist, und der Windows-Benutzer vorläufig dazu gezwungen ist, ein Sicherheitsfeature auszuschalten, damit er Linux installieren kann. Gut, das sehe ich ein ... aber ich weiß nicht recht, wieso man da die Schuld bei Microsoft sucht.
Tatsache ist - Microsoft fordert, dass es bei vorinstalliertem Windows 8 eingeschaltet ist (verstehe ich auch) und es lässt sich in einem korrekten EFI ausschalten. Microsoft fordert keineswegs, dass es nicht ausgeschaltet werden kann oder darf. Es wird also niemand von Linux abgehalten.
Völlig anders sieht die Sache bei Windows on ARM aus - auch als Windows RT bekannt. Hier fordert Microsoft in der Tat, dass Secure Boot bei vorinstalliertem Windows eingeschaltet ist und sich entgegen der Spezifikation nicht ausschalten lässt. Das finde ich durchaus bedenklich, ebenso wie die vernagelten Iphones, und Samung macht es einem auch nicht leicht, das Linux auf deren Produkten auszutauschen. Angesichts der Tatsache, dass Microsoft bei der Bootloader-Signierung kooperativ ist, könnten Microsoft-Geräte zukünftig zu den wenigen ARM-Geräten gehören, die ein freiwählbares Linux on ARM problemlos unterstützen ... das ist denkwürdig.
Edit: Ein Problem habe ich euch in diesem Text komplett verschwiegen: Die 32- und 64-Bit Problematik. Früher dachte ich, EFI sei eine reine 64-Bit-Geschichte. Seit ein paar Monaten tauchen aber zunehmend Intel-Tabletts und billig-Notebooks mit einem 32-Bit-UEFI auf, die durchaus 64-Bit-fähige Hardware enthalten. Der Sinn und Zweck dieser Entwicklung bleibt mir verborgen - vermutlich geht es darum, eine bestimmte Windows-Version auf diesen Geräten zu erzwingen. Damit gibt es zwei große Probleme unter Linux:
1) Die bisherigen Linux-Bootloader sind nur auf 64-Bit-EFIs ausgerichtet.
2) Der damit startbare 64-Bit-Kernel läuft nicht auf einem 32-Bit-EFI.
An beidem wird gearbeitet, seit Kernel 3.15 läuft ein 64-Bit-Linux auch auf einem 32-Bit-EFI, für Wheezy kommt das natürlich viel zu spät, selbst für Jessie könnte eine vollständige Unterstützung eng werden, aber Ubuntu scheint gut davor zu sein. Da ich entsprechende Hardware nicht besitze und der gesamte Bereich im Moment eine große Baustelle ist, möchte ich es bei diesem Hinweis belassen. /Edit
und noch dazu in einer Sprach die ich auch lesen kann. 
vor der Installaation von Wheezy.
