Windows 8 im Test: Alle Neuerungen im Überblick
5/26
Neues Bootmenü
Bevor bei einem Kaltstart der eigentliche Windows-Startvorgang erfolgt, ist bekanntlich zunächst das BIOS (Basic Input/Output System) mit der sogenannten Selbsttestphase (Power-On Self Test, kurz POST) an der Reihe. Allmählich wird das klassische BIOS mit seiner angestaubten Menü-Oberfläche, die vor fast 30 Jahren stehen geblieben zu sein scheint, vom Unified Extensible Firmware Interface (UEFI) abgelöst, das in nahezu allen neuen PCs Verwendung findet. Zwar unterstützt Windows 8 nach wie vor auch Mainboards mit klassischem BIOS, allerdings bietet die Kombination mit UEFI eine Reihe neuer Möglichkeiten, die sich nicht nur in Form einer moderneren Oberfläche sondern auch einem beschleunigten Systemstart äußern.
Zunächst ermöglicht UEFI deutlich umfangreichere grafische Möglichkeiten als sein Vorgänger, sodass zum Beispiel mittels des GOP-Treibers (Graphic Output Protocol) höhere Auflösungen dargestellt und somit einheitlichere Oberflächen beim Übergang vom UEFI-Menü zum Betriebssystem realisiert werden können. Via UEFI will Microsoft für eine einheitliche Darstellung beim gesamten Startvorgang (von POST bis zur Windows-Anmeldung) sorgen, die sich zudem komfortabel mit Touchscreens, aber auch klassisch mit Tastatur und Maus bedienen lässt. Der gesamte Startvorgang soll entsprechend „nahtlos“ vonstattengehen.
Der im vorherigen Artikelabschnitt beschriebene beschleunigte Startvorgang von Windows 8 kann gerade beim Einsatz auf UEFI-Systemen in Kombination mit einer SSD allerdings auch einen Nachteil mit sich bringen. Bei solchen Konfigurationen fällt der Zeitraum, in welchem der Bootvorgang durch den Nutzer über einen Tastendruck – beispielsweise für das Erreichen des UEFI-Menüs (BIOS-Setup) – unterbrochen werden kann, deutlich geringer als bisher aus. Zum Beispiel liege das Zeitfenster zum Drücken von „F8“ bei manchen Systemen bei nun weniger als 200 Millisekunden, was es fast unmöglich macht, dieses zu treffen.
Aus diesem Grund wurde ein neues Bootmenü geschaffen, das die sonst nur über bestimmte Funktionstasten nach dem POST erreichbaren Menüs vereint und bereits vor dem Herunterfahren über die „PC-Einstellungen“ aufrufbar ist. Wird dort der „Erweiterte Start“ ausgeführt, erscheint eine an das Windows-8-Setup angelehnte Oberfläche, über welche unter anderem das UEFI-Menü, alternative Bootquellen, Reparaturoptionen, die Kommandozeile sowie das Menü zur Auswahl der Windows-Startoptionen (z.B. Abgesicherter Modus) zur Verfügung stehen. Sofern Windows 8 wiederholt nicht korrekt gestartet werden konnte, wird dieses Auswahlmenü ebenfalls angezeigt. Zudem sei Windows 8 auch in der Lage Probleme in gewissem Maße zu identifizieren und öffnet gegebenenfalls gleich ein passendes Untermenü.
Das Bootmenü wird im Windows Recovery Environment (WinRE) ausgeführt und ist entsprechend vom Betriebssystem abgeschottet. Darüber hinaus stehen mehrere Möglichkeiten zur Verfügung es aufzurufen: Einmal über den oben beschriebenen „Erweiterten Start“, zum anderen über „Neustart“ bei gedrückter Shift-Taste im „Herunterfahren“-Menü oder aber über den Befehl „Shutdown.exe /r /o“ in der Kommandozeile.
Ältere PCs, die kein UEFI besitzen, müssen weiterhin auf Befehle wie „F8“ zurückgreifen, wobei dies bei diesen Systemen relativ problemlos möglich sein soll, da sie ohnehin nicht für den schnellen Bootvorgang von Windows 8 geeignet sind.
Secure Boot
Windows 8 soll in Verbindung mit UEFI nicht nur schneller starten und ein grafisches Bootmenü erhalten, sondern auch in Sachen Sicherheit der sogenannten Vor-Betriebssystemumgebung zulegen. Hier kommt das mit der UEFI-Spezifikation 2.2 erstmals eingeführte Protokoll Secure Boot zum Einsatz. Dieses soll dafür sorgen, dass beim Bootvorgang keine nicht-signierten beziehungsweise authentifizierten Startladeprogramme (Bootloader) geladen werden können, um beispielsweise Malware-Exploits und dem Ausführen von schädlichem Code im Startpfad des Systems einen Riegel vorzuschieben.
Bei diesem „sicheren Start“, der laut Microsoft eine Plattformfirmware, die mindestens der UEFI-Version 2.3.1 entspricht, erfordert, findet eine Firmwareüberprüfung anhand von Sicherheitszertifikaten vor dem Laden des Betriebssystems statt. Bootloader, die nicht über einen entsprechenden Schlüssel verfügen, werden als nicht vertrauenswürdig betrachtet und die Ausführung des Codes wird entsprechend unterbunden. Dies soll somit einen zusätzlichen Schutz vor Boot- oder Rootkits bieten, kann allerdings auch mancher eigentlich vertrauenswürdiger, aber eben nicht entsprechend verifizierten Software einen Riegel vorschieben, weshalb die Funktion gerade in Open-Source-Entwicklerkreisen kritisiert wird.
Laut Microsofts Voraussetzungen zur Zertifizierung von Hardware für Windows 8, müssen sämtliche (Client)Systeme Secure Boot unterstützen und standardmäßig aktiviert haben. Die Richtlinie ist bei Serversystemen weniger streng, hier werden auch Systeme ohne Secure-Boot-Support oder Deaktivierung der Funktion erlaubt. Damit auch nicht zertifizierte aber vertrauenswürdige Software im Bedarfsfall ausgeführt werden kann, um beispielsweise ein alternatives (Open-Source-)Betriebssystem auf einem Windows-8-Rechner zu installieren, muss eine Option zur Deaktivierung von Secure Boot bereitgestellt werden. Dies gilt für alle Versionen von Windows 8 bis auf die ARM-Variante (Windows RT). Hier schreibt Microsoft (auf Seite 122 der aktuellen Zertifizierungsrichtlinien im PDF-Format) eindeutig vor, dass „das Deaktivieren von Secure Boot auf ARM-Systemen nicht möglich sein darf“.
„Disabling Secure Boot must not be possible on ARM Systems.“
Microsoft
Käufer eines mit Windows RT ausgelieferten Geräts, die darauf ein alternatives Betriebssystem einsetzen wollen, sind folglich auf eine entsprechende Zertifizierung der Software angewiesen. Neben eigenen Bemühungen einiger Linux-Distributionen, für entsprechende Zertifizierungen der Bootloader zu sorgen, hat die Linux Foundation im Oktober „einen Plan“ angekündigt, der das Ausführen von Linux sowie allen Open-Source-basierten Distributionen auf Systemen mit Secure Boot ermöglichen soll. Dabei will man versuchen, für den Pre-Bootloader „Loader.c“, dessen Quellcode man bereits veröffentlicht hat, einen entsprechenden Microsoft-Schlüssel zu erlangen.
