Secure Boot: Torvalds will keinen Support für Microsoft-Zertifikate im Linux-Kernel

Mit unverblümten Worten hat Linus Torvalds Red Hat kritisiert, nachdem ein Entwickler des Distributors die Secure-Boot-Unterstützung ausbauen wollte. Daraus entwickelte sich eine allgemeine Diskussion zur Linux-Unterstützung von Secure Boot.

In Pocket speichern vorlesen Druckansicht 13 Kommentare lesen
Lesezeit: 4 Min.
Von
  • Thorsten Leemhuis

Bei der Secure-Boot-Unterstützung betreibe Red Hat "deepthroating" von Microsoft – mit diesen, wieder mal unverblümten und direkten Worten hat Linus Torvalds den Linux-Distributor auf der Mailingliste der Linux-Kernel-Entwickler kritisiert, nachdem ein Red-Hat-Entwickler die Secure-Boot-Unterstützung von Linux ausbauen wollte. Daraus entstand eine noch andauernde Diskussion, in der sich zahlreiche wichtige Kernel-Entwickler zur Secure-Boot-Unterstützung von Linux äußern.

Red-Hat-Entwickler David Howells hatte die Diskussion auf der LKML ausgelöst, als er eine Sammlung von Änderungen zur Integration in Linux 3.9 eingereicht hat. Damit könnte ein Linux-Kernel Binaries verifizieren, die Microsofts signiert hat. DerFedora-18-Kernel beispielsweise, der bei aktivem Secure Boot nur Kernel-Module lädt, die das Fedora-Projekt signiert hat, könnte dann auch Module mit Microsoft-Signatur laden. Der Linux-Kernel unterstützt derzeit Zertifikate nach dem Standard X.509, während Microsoft mit Authenticode eine eigene Technik zum Signieren von Code erfunden hat.

Mit den Erweiterungen könnten beispielsweise AMD und Nvidia die Kernel-Module ihrer Grafiktreiber von Microsoft signieren lassen, damit Distributionen wie Fedora die AMD- und Nvidia-Module auch bei aktivem Secure Boot laden. Auch für Systemtap-Module soll eine solche Möglichkeit interessant sein. Red Hat bietet selbst keinen Signatur-Service an; ein Entwickler stellte zudem klar, dass Red Hat keine von externen Stellen herangetragenen Module signieren werde. Bei der Diskussion über die vorgeschlagenen Änderungen von Howells erklärte Torvalds, der Kernel unterstütze mit X.509 bereits eine Technik zum Verifizieren von Signaturen – nur halt nicht die Technik, die Microsoft zum Signieren nutzt.

Mittlerweile ist die Diskussion eher zu einer allgemeinen Debatte um die Implikationen von Secure Boot und dessen Unterstützung durch den Linux-Kernel und Linux-Distributionen geworden. Einer der heiß diskutierten Punkte ist die Frage, ob der Linux-Kernel zur Unterstützung von Secure Boot selbst signiert sein muss und nur signierte Module laden darf, wie es Fedora 18 macht. Die Secure-Boot-Spezifikation schreibt nichts dergleichen vor.

Laut dem Kernel-Entwickler Matthew Garrett, der den von Microsoft signierten Secure-Bootloader Shim programmiert hat, sei es aber eine Anforderung des Vertrags, um eine Secure-Boot-Signatur von Microsoft zu erhalten. Zudem behalte sich Microsoft den Widerruf von Zertifikaten vor, wenn damit signierter Code die Sicherheit von UEFI gefährdet, was durch ein unsigniertes Kernelmodul theoretisch geschehen könnte.

Es ist schon länger umstritten, ob für Microsoft-konforme Secure-Boot-Untersützung Restriktionen nötig sind, wie sie Fedora 18 eingeführt hat. Bei Ubuntu 12.04.2 und 12.10 prüft die von Microsoft signierte Version des Bootloaders Shim nur die Signatur von Grub 2; dieser startet aber auch unsignierte Kernel, die wiederum unsignierte Kernel-Module laden. Die Secure-Boot-Unterstützung in Ubuntu schränkt so den Anwender beispielsweise bei proprietären Treibern wie denen von AMD und Nvidia nicht ein, wie es Fedora tut, um die "chain of trust" aufrecht zu erhalten. Änderungen, wie von Howells vorgeschlagen, sind daher dort nicht nötig.

Diese Problematik ist nur einer Aspekt der vielschichtigen und noch laufenden Diskussion. So kam auch wieder zur Sprache, warum die Linux-Welt nicht selbst eine Infrastruktur zum Signieren von (Linux-) Betriebssystemen einzurichten. Das ist allerdings auch eine Kostenfrage: Laut Greg Kroah-Hartman erfordere es mit ziemlicher Sicherheit mehr Geld als das derzeitige Jahresbudget der Linux Foundation, eine solche Infrastruktur einzurichten und zu betreiben. (thl)