Kernel-Log: Noch mehr UEFI-Probleme
Einige mit Windows ausgelieferte UEFI-Systeme nutzen eine als Fallback gedachte Zweitinstallation des Bootloaders, wodurch ein korrekt installiertes UEFI-Linux nicht startet. Außerdem: Google hat seine BadRAM-Patches nun doch veröffentlicht, bei Google+ ist ein Linus Torvalds aufgetaucht und Lennart Poettering hat weitere Blog-Einträge zu Systemd verfasst.
- Thorsten Leemhuis
Matthew Garrett wühlt sich weiter durch das Dickicht um das (U)EFI/(Unified) Extensible Firmware Interface, das Funktionen des BIOS ersetzt und in den vergangenen Wochen schon mehrfach Thema im Kernel-Log war (u. a. 1, 2). So hat er Patches ausgearbeitet, welche die x86- und IA64-EFI-Implementationen des Kernels zusammenlegen, um Code-Dopplungen zu beseitigen und eine Architektur-unabhängige Lösung zu schaffen, die auch für ARM- und MIPS-Plattformen geeignet ist.
In seinem Blog beschreibt er ein weiteres großes Probleme mit (U)EFI. Dort lobt er, dass EFI Mechanismen vorsieht, damit sich der Start-Code unterschiedlicher Betriebssysteme nicht ins Gehege kommt: Jeder Betriebssystemhersteller muss seinen Bootloader in einem eigenen, den Hersteller zugeordneten Bereich der EFI-Systempartition ablegen (beispielsweise unter EFI/microsoft) und ihn anschließend in den "EFI Boot Variables" im NVRAM registrieren. Der UEFI-Bootcode der Hardware kann dem Anwender so ein Menü zeigen, wo er zwischen den installierten Systemen wählen kann.
Die UEFI-Spezifikation erlaubt ab Version 2.3 allerdings, dass der UEFI-Bootcode wie bei Wechseldatenträger an einer bestimmten Stelle der EFI-Systempartition (etwa EFI/boot/bootx64.efi bei x86-64-Systemen) nach einem Boot-Loader sehen darf, wenn im NVRAM keine Systeme spezifiziert sind. Aktuelle Windows-Version installieren ihren Boot-Loader als Fallback dorthin, sofern dort noch kein Boot-Loader liegt. Dadurch sollte Windows auch noch starten, wenn die EFI-Boot-Einträge im NVRAM verloren gegangen sind.
Nun testen Hardware-Hersteller aber häufig nur mit Windows, wie Garrett schon in diversen Blog-Einträgen zu anderen Problemen angemerkt hat. Es sei daher nicht überraschend, dass einige Systeme die Einträge in den EFI-Boot-Variablen ignorieren und das Betriebssystem immer über den Fallback-Bootloader aufrufen. Bei mit Windows ausgelieferten Systemen dürfte das dessen Boot-Loader sein; ein korrekt installiertes Linux ist daher über die in UEFI vorgesehenen Mechanismen schlicht nicht startbar.
Als Lösung ist Garrett bislang nur ein bei der Linux-Installation eingerichteter "stub bootloader" eingefallen, der die Hersteller-spezifischen Verzeichnisse auf der EFI-Systempartition nach deren Bootloadern absucht und diese beim Start zur Auswahl anbietet.
Kernel-Versionsstatus
Bereits vor einer Woche hat Greg Kroah-Hartman die Longterm-Kernel 2.6.32.43 und 2.6.33.16 sowie die Stable-Kernel 2.6.39.3 veröffentlicht. Bei zwei davon findet sich der üblichen Text "All users of the [...] kernel series must upgrade", der zum Wechsel auf die neue Version rät, ohne klarzustellen, ob die neuen Versionen Sicherheitslücken beseitigt.
