Windows 8 bringt unter anderem die neue Funktion Secure Boot, die auf PC-Mainboards und Notebooks mit den jüngsten UEFI-Versionen ab 2.3.1 den Start unsignierter Bootloader blockiert. Ist Secure Boot aktiv, lässt sich also auch kein Linux starten, sofern es nicht die nötigen Signaturen mitbringt und vom Besitzer oder Administrator des jeweiligen Computers explizit für das Gerät erlaubt wurde.

Das ist gerade die Intention von Secure Boot: Das System soll vor Zugriffen mit anderen Betriebssystemen geschützt werden, damit also nicht etwa ein Dieb Daten ausspäht, indem er einen gestohlenen PC beispielsweise von einem USB-Stick bootet. Zudem soll Secure Boot auch Manipulationen am Code des Betriebssystems erkennen, um Infektion mit Schadsoftware zu enttarnen. Secure Boot verlangt, dass sämtliche Firmware und Software, die für den Boot-Prozess nötig ist – also außer Bootloadern etwa auch UEFI-Treiber für Onboard-Komponenten und Erweiterungskarten – Signaturen vertrauenswürdiger Certificate Auhthorities (Trusted CAs) trägt.

Der Linux-Entwickler Matthew Garrett befürchtet jedoch, dass UEFI Secure Boot auch die Installation von Linux auf damit geschützten Systemen verhindert. Er sieht einerseits Schwierigkeiten darin, dass möglicherweise nicht alle PC-Hersteller überhaupt bereit sind, Schlüssel für signierte Linux-Software in der UEFI-Firmware ihrer jeweiligen Produkte zu hinterlegen. Andererseits erwartet er Probleme schon beim Bootloader Grub 2: Dieser steht unter der Lizenz GPLv3, die ausdrücklich verlange, dass solche Schlüssel veröffentlicht werden. Vermutlich müsste aber auch der Linux-Kernel signiert werden, was für individuell kompilierte Kernel großen Zusatzaufwand erfordere.

[Update:] Microsoft hat mittlerweile klargestellt, dass sich grundsätzlich auch auf Secure-Boot-tauglichen Rechnern andere Betriebssysteme starten lassen und dem Nutzer beziehungsweise Administrator die Entscheidung überlassen bleibt. Der auf der Build verteilte Tablet habe im Firmware-Setup beispielsweise eine Option, um Secure Boot abzuschalten. Es sei allerdings Sache der PC- beziehungsweise Mainboard-Hersteller, diese Option auch einzubauen. [/Update]

Unter Verweis auf eine Präsentation (PowerPoint-pptx-Datei), die auf der Windows-Entwicklerkonferenz Build gezeigt wurde, geht Garrett davon aus, dass alle Client-Systeme – Desktop-PCs, Notebooks, Tablets – mit Windows-8-Logo UEFI Secure Boot unterstützen müssen und diese Funktion auch aktiviert sein muss. Zumindest die zweite Vorgabe ergibt sich aus dieser Präsentation aber nicht zwingend: Es könnte ja auch vorgesehen sein, dass die Funktion ausdrücklich vom Besitzer oder Administrator des Rechners aktiviert werden muss. Außerdem dürften die meisten UEFI-tauglichen Systeme wie bisher zumindest optional ein Compatibility Support Module (CSM) laden können, das den Start von Betriebssystemen im BIOS-Modus ermöglicht, schon weil das eine zwingende Voraussetzung für die Installation von 32-Bit-Windows ist: Im UEFI-Modus lassen sich nur die x64-Versionen von Windows seit Vista installieren. Microsoft nennt Systeme, die alternativ im UEFI- oder BIOS-Modus starten können, Klasse-2-(Class-2-)Systeme; solche ohne CSM gehören zur Klasse 3.

Allerdings ist nicht klar, unter welchen Bedingungen sich mehrere Betriebssysteme, von denen manche im UEFI- und andere im BIOS-Modus starten, auf dieselbe Festplatte installieren lassen – das dürfte die Parallelinstallation bei Notebooks, Tablets und anderen Geräten mit nur einem Massenspeicher erschweren. Zumindest die angekündigten Windows-8-Mobilcomputer mit ARM-SoCs wird es überhaupt nur in Klasse-3-Versionen geben. Bei diesen Geräten will Microsoft die Sicherheit der Plattform auch dadurch steigern, dass unter der Metro-Oberfläche ausschließlich die Installation geprüfter und signierter Apps aus dem App Store vorgesehen ist.

Eine weitere Schwierigkeit für den Start alternativer Betriebssysteme könnte sich aus der Vollverschlüsselung von Festplatten per TCG Opal oder BitLocker ergeben, sofern der Bootloader Funktionen mitbringen muss, um selbstverschlüsselnden Laufwerken (Self-Encrypting Drives/SEDs) einen Schlüssel zu übergeben. (ciw)