Category Archives: UEFI Secure Boot

VMware – UEFI-Boot simulieren

Mit weiteren Verbreitung von UEFI steigt die Relevanz, in Live-Distributionen den UEFI-Bootloader zu konfigurieren und zu testen und – als Autor – mit Screenshots Artikel zum Thema garnieren zu können. Bei mir betrifft das konkret das eigene Live-System LessLinux, derzeit primär ein Notfall- und Rettungssystem und die Multiboot-Linux-CDs, die ich für Verlage wie WEKA, Data-Becker, Heise erstelle oder miterstelle. Einen Teil der notwendigen Screenshots muss ich auf echter Hardware mit einer Capture Card erstellen (BIOS, UEFI-Setup). Für viele andere taugt die virtuelle Maschine.

Als Virtualisierungssoftware setze ich beim Desktop noch auf VMware, konkret den Player. Der ist nicht mehr kostenlos, aber dank Fusion-Lizenz ist er bei mir immerhin lizenziert (Unternehmen, die bislang den kostenlos nutzbaren Player einsetzten, müssen nach meiner Lesart der Lizenz pro Standort wohl rund 80€ investieren). Dass ich mittelfristig plane, auf VirtualBox zu wechsel, ist eine andere Geschichte.

Nun habe ich mich gewundert, dass ich weder in Fusion, noch im VMware Player irgenwo ein Option finde, BIOS/MBR oder UEFI/GPT als Firmware-Modell zu wählen. Es ist ganz einfach. Die .vmx-Datei, in der die Konfiguration gespeichert ist, lässt sich als einfache Textdatei an beliebiger Stelle um die Zeile 

firmware = "efi"

ergänzen. Danach verhält sich VMware wie ein UEFI-Rechner, der vom Betrieb im CSM in den UEFI-Modus umgeschaltet wurde. Beim Neuaufsetzen virtueller Maschinen, bedeutet das, dass man zunächst zwar die Maschine konfigurieren, aber unbedingt “I will install the Operating System later” wählen sollte. Anschließend fügt man die EFI-Zeile in die VMX-Datei ein und startet dann die Installation im UEFI-Modus.

MokList gesemmelt, Boot unmöglich – MokList corruptet, boot impossible

Please scroll down for an English version!

In den letzten Monaten habe ich viele Experimente mit UEFI Secure Boot durchgeführt, mit so ziemlich allen Bootloadern und mit den gewonnenen Erfahrungen so einige Secure Boot kompatible Boot-Medien aufgebaut: Heise Desinfect, PC Magazin Superpremium 7/2013, Data Becker Linux Extra 5 und natürlich diverse LessLinux-Builds. Seit gestern ließen sich irgendwie nur originale Ubuntu- und Windows-Systeme booten, was für meine Zwecke natürlich ziemlich bescheuert ist. Der Grund: Die MokList im UEFI NVRAM, in der Shim und PreLoader.efi (respektive deren Schlüsselverwaltungstools) vom Nutzer freigegebene Schlüssel speichern, war irgendwie beschädigt oder einfach zu groß. Alle Schlüssel per UEFI Setup auf Werkseinstellungen zurückzusetzen, hatte keinen Effekt und KeyTool.efi hängte sich sofort auf. Wie weiter und die MokList löschen?

Ich habe herausgefunden, dass der einfachste Weg ist, entweder rEFInds flash drive image oder das demo image “sb-usb.img” der LinuxFoundation herunterzuladen und auf einen USB-Stick (per “dd”) zu ziehen. Damit bootet man bei deaktiviertem Secure Boot in die EFI Shell und gibt folgendes Kommando ein:

dmpstore -d MokList

Beim nächsten Start geht es mit einer leeren MokList weiter…

…and in English

The last months I did lots of experiments with UEFI secure boot and created some boot media that was secure boot compatible: Heise Desinfect, PC Magazin Superpremium 7/2013, Data Becker Linux Extra 5, various build of LessLinux with various bootloaders. Yesterday my MokList got corrupted or just too large – the MokList (or Machine Owners Key list is a database stored in the UEFI NVRAM that contains the keys and hashes that the owner of a machine added, for example when booting with Shim or PreLoader). Secure boot just worked with loaders that dit not access the MokList, which is not very useful for my purpose. Resetting all Keys via UEFI setup did not work. And KeyTool.efi just hung when editing the MokList. So how do I clear it?

I found out that the easiest way is to download either rEFInds flash drive image or the demo image “sb-usb.img” from the LinuxFoundation. Dd either of those to an USB thumb drive, disable secure boot in the UEFI setup and boot into the EFI shell. there you can simply delete the MokList with the command:

dmpstore -d MokList

Next time you boot, the MokList is empty/noexistent…

Bootfähigen USB-Stick für UEFI Secure Boot erstellen – 1. PreLoader der Linux-Foundation plus Gummiboot

Disclaimer: Dieses kleine Tutorial richtet sich an all jene, die entweder einen Admin-Stick mit verschiedenen Installern und Notfallsystemen erstellen wollen oder einfach eine Fingerübung suchen, um den Bootvorgang von UEFI Secure Boot besser nachvollziehen zu können. Die anfängliche Installation von LessLinux Search and Rescue kann nach und nach um weitere Linuxe erweitert werden. Als Bootloader verwende ich zunächst den unkomplizierten PreLoader.efi der Linux-Foundation in Kombination mit Gummiboot, möglicherweise folgt demnächst eine auf Shim (mit MOK) angepasste Anleitung. Auf den EFI-Boot von 32-Bit-Systemen möchte ich nicht eingehen, weil praktisch nur ältere Apple iBooks und MacMinis (CoreDuo, nicht Core2Duo) mit einem 32-Bit-EFI ausgeliefert wurden. Die paar Netbooks von Asus, die ebenfalls 32-Bit-EFI an Bord haben, sind in der Regel auf das CSM eingestellt (Compatibility Support Module = BIOS-Emulation zum Boot von MBR-Medien).

Hinweis: Auf dieses Tutorial folgt ein weiteres, das die hier gezeigte Konfiguration um GRUB erweitert (um 32-Bit-Systeme booten zu können) und eines, das erklärt, wie schließlich ein hybrider Stick entsteht, der auf MBR- und UEFI-Systemen startet. Wer aus dem dritten Tutorial das Optimum herausholen möchte, sollte eine dritte, 100 bis 200MB große, leere FAT32-Partition einplanen.

Wie bootet UEFI sicher vom Stick?

Der Vorgang von USB ist etwas einfacher als von Festplatte, zumindest wenn es sich um einen GPT partitionierten Stick mit einer einzigen FAT32-Partition handelt. In diesem Fall genügt es, eine Ordnerstruktur “BOOT/EFI” anzulegen, die den Bootloader “BOOTX64.EFI” enthält. Hintergrund dieser Vereinfachung ist wohl, dass es ermöglicht werden soll, alleine durch das Entpacken eines Zips mit den Bootdateien einen Stick bootfähig zu machen – aber das ist Spekulation, weder habe ich nachgeprüft welche UEFI-Implementierungen den einfachen Start unterstützen, noch habe ich getestet, ob in nennenswerten Stückzahlen USB-Sticks am Markt sind, die sowohl GPT als auch BIOS-MBR aufweisen. Continue reading →

Das Gespenst UEFI Secure Boot

In den letzten Tagen hatte ich etwas Gelegenheit, mich mit UEFI Secure Boot näher zu beschäftigen: Ich erstelle bekanntlich die Notfall-CDs für einige Computerzeitschriften oder arbeite intensiv daran mit (von Computer Bild bis desinfec’t gibt es einige). Ziel war, alle aktuellen, von Microsoft signierten EFI-Loader unter die Lupe zu nehmen und auf ihre Praktikabilität abzuklopfen. Die gute Nachricht vorweg: Wer Ubuntu oder Fedora verwendet und keine Kernel selbst kompiliert, muss sich nicht mit dem Schlüsselmanagement herumärgern. Beide Distributionen verwenden einen von Microsoft signierten Loader (auf Basis von Shim), der wenigstens sicherstellt, dass GRUB2 und der anschließend geladene Kernel “vertrauenswürdig” ist. Zu Funktionsweise, Unterschieden und Restriktionen der verwendeten gepatchten GRUB2-Varianten hat sich Thorsten Leemhuis in der c’t 5/2013 zur Genüge ausgelassen. Wirklich spannend ist die Thematik aber für den Start selbst kompilierter Kernel, für kleine Distributionen, die verteilt und schnell entwickelt werden und für Administratoren, die Linux basierte Deployment- und Notfall-Systeme per Netz oder vom Wechseldatenträger starten wollen.

In diesem Beitrag möchte ich die eher theoretischen Hintergründe erläutern und Entscheidungshilfen geben, demnächst folgen dann Beiträge zur praktischen Umsetzung von Secure Boot eigener Kernel auf USB-Sticks, optischen Datenträgern und via Netzwerk. Continue reading →