Und noch mal UEFI Secure Boot

Kein Kommentar Autor: Thomas (td)

Fedora Linux LogoAuf dem Fedora-Meeting (FESCo) am vergangenen Montag hat das „Fedora_Engineering_Steering_Committee“ eine ganze Reihe in den letzten Wochen vorgeschlagener und diskutierter Funktionen für Fedora 18 abgesegnet. Damit ist auch Matthew Garretts umstrittenen Herangehensweise an die UEFI Secure Boot-Problematik für Fedora 18 beschlossene Sache.

Das Meeting vom 23. Juli hatte neben UEFI Secure Boot auch eine Reihe anderer für Fedora 18 geplante Funktionen auf der Agenda, allerdings möchte ich in diesem Beitrag noch einmal ausschließlich UEFI Secure Boot aufgreifen. Einen Test von Fedora 18 schiebe ich nach, sobald es sich lohnt.

Sichere Boot-Chain

Das neben Matthew Garrett aus acht weiteren Personen bestehende technische Leitungsgremium von Fedora  hat also Garrets  Entwurf zur UEFI-Secure-Boot-Unterstützung für Fedora 18 zugestimmt. Was bedeutet dass konkret für Fedora 18, das im November erscheinen soll?

Windows 8 UEFI Secure Boot kein Linux 150x150Der von  Garret entwickelte Mini-Boot-Loader Shim wird demnach mit dem bei Microsoft betriebenen „Signing Service“ signiert. Da die meisten in Zukunft ausgelieferten UEFI-Mainboards den zum Booten von Windows 8 via Secure Boot erforderlichen Public Key mitbringen sollten, wird sich damit auch Fedora auf solchen Systemen booten lassen, ohne dass Du Secure Boot deaktivieren muss. Du kannst aber wahlweise auch Shim mit einem eigenen Schlüssel signieren und den Public Key in Deiner UEFI-Firmware als “vertrauenswürdig” eintragen, sodass die dem auf diese Weise signierten Boot-Loader vertraut. Damit sieht die „sichere Boot-Kette“ bei Fedora wie folgt aus:

Bootet Dein PC via Shim mit aktivem Secure Boot, prüft Shim mit einem Fedora-eigenen Schlüssel vor dem Ausführen des Boot-Loaders Grub2, ob der unversehrt und korrekt signiert ist. Grub prüft dann seinerseits die Signatur des Linux-Kernels und der wiederum die Signaturen sämtlicher zu ladenden Kernel-Module. Per Default verwendet Fedora 18  zum Signieren und Prüfen der Signatur ein eigenes Schlüsselpaar. Trägst Du dagegen einen eigenen Schlüssel in Deiner UEFI-Firmware ein, solltest Du zum Validieren von Grub, Linux-Kernel und den Kernel-Modulen auch ein eigenes Schlüsselpaar verwenden können. Soweit die Theorie. Testen kann ich das frühestens Anfang Januar mit der geplanten Neuanschaffung eines schnöden Desktop-PCs.

Nebenwirkungen

Mit Fedoras Workaround sind einige Unanehmlichkeiten verbunden: Wie in Laufe der zurückliegenden Diskussion deutlich wurde, sieht Garrets Vorschlag einen „eingeschränkt arbeitenden“ Grub 2 vor, der zum Beispiel einige beim Booten übergebenen Parameter nicht weiterreicht und zudem keine DMA-Zugriffe durch Userland-Programme erlauben. Das hat weitreichende Konsequenzen. So kann etwa der Grafiktreiber für den X-Server nur Hardware-Beschleunigung nutzen, wenn dieser Kernel-Treiber mit KMS (Kernelbased Mode-Setting) verwendet. KMS wird ja in den meisten Fällen vom Linux-Kernel selbst aktiviert, allerdings muss Xorg angewiesen werden, einen Treiber zu verwenden, der auch KMS unterstützt, was eigentlich derzeit nur für Intel-Treiber gilt. Bei Nvidia müsstet Du den Noveau-Treiber benutzen. Die proprietären Treiber von AMD/ATI und Nvidia funktionieren also mit aktiviertem Secure Boot nicht. Für eine Standard-Installation von Fedora ist das zwar nicht tragisch, weil Fedora als hundert Prozent quelloffenes System die  proprietären AMD- und Nvidia-Treiber gar nicht mitliefert, aber eine Lösung für den produktiven Alltagsbetrieb ist das ja nicht. Also doch Secure Boot abschalten? Wie auch immer. Das Problem mit UEFI Secure Boot liegt ja ohnehin ganz woanders, Stichwort ARM, aber das hatten wir ja  schon.




 Alle Kommentare als Feed abonnieren

Kommentare sind geschlossen.