(U)EFI-Boot

[Frank Guthausen]

Hallo.

Ich versuche mal, die Situation zu sortieren.

On Wed, Jul 13, 2016 at 07:15:52PM +0200, Wolfgang Romey (woro) wrote:
> Am Dienstag, 12. Juli 2016, 21:16:40 schrieb Marcus Moeller:
> 
> > UEFI würde ich immer nur mit Secure Boot betreiben, andernfalls ist
> > es deutlich unsicherer als klassisches BIOS. 
> 
> Das verstehe ich noch nicht. Gehört wohl zur Einarbeitung.

Das würde ich auch gerne verstehen.

> > Bei Distros wie Ubuntu openSUSE oder Fedora ist das kein Problem, da
> > die Bootloader signiert sind. Bei Archlinux muss man da selbst Hand
> > anlegen und immer wieder die neuen Kernel enrollen. Das ist zwar
> > über ein Helper Tool einfach möglich, aber dennoch etwas nervig.
> 
> Ist das auch bei Xubuntu so? Das verwenden wir ja in Mülheim. 

Bei Ubuntu müssten auch die Derivate den signierten Bootloader shim
enthalten, allerdings finde ich gerade keine explizite Bestätigung
dafür im Netz.

> > Das Hauptproblem bei UEFI ist, dass es in der Implementierung in den
> > Anfangstagen extrem viel Schluderei gab und viele Geräte um 2012 rum
> > ziemlich vermurkste Implementierungen haben. Dafür gibts dann in den
> > meisten Fällen auch kein Update vom Hersteller.
> 
> Was bedeutet das für die Installation von (X)ubuntu auf älteren
> Geräten mit UEFI?

In Einzelfällen kann es sein, dass es nicht geht. Oder das beim Betrieb
ein Sicherheitsrisiko besteht (UEFI hat einen Netzwerkstack). Aber sowas
besteht immer.

> > Ich habe schon von 3 Jahren mein erstes Gerät gekauft, dass nur noch UEFI
> > ohne Fallback hatte und das hat in der ersten Zeit auch ziemlich Theater
> > gemacht. Ein BIOS Update hat dann aber geholfen und seit dem läuft es rund.
> 
> Es scheint mir so, daß die Unterstützung für Leute, die auf GNU/Linux 
> umsteigen wollen, deutlich schwieriger wird.

Vom Hardwareangebot auf jeden Fall. Es gibt folgende Situationen (x86):
1) BIOS
2) UEFI mit Legacy Option (CSM?)
3) UEFI ohne Legacy Option
4) UEFI Secure Boot, nicht abschaltbar.

Dabei ist 1) Geschichte, 2) wird bald Geschichte sein, und 3) könnte es
in der Zukunft auch erwischen, wenn die Marktmacht von Microsoft das so
durchdrücken kann. Bei ARM Windows RT ist Secure Boot schon heute nicht
abschaltbar, aber das ist eben kein x86.

Secure Boot bootet nur Binaries, die mit asymmetrisch privatem Schlüssel
signiert sind; dabei muss der entsprechende öffentliche Schlüssel im UEFI
hinterlegt sein.

In einigen UEFIs kann man selber über die Schlüssel verfügen, dann kann
man sich notfalls selber einen signierten Bootloader bauen. Das ist aber
eher nicht sonderlich praktikabel und massentauglich, und es kann sein,
dass das nicht immer funktioniert, besonders zukünftig. Freiheit ist an
dieser Stelle besonders stark gefährdet.

Im Regelfall sind bereits Schlüssel von Microsoft im UEFI hinterlegt:
a) ein Schlüssel ist 'required' für Microsoft Windows,
b) ein Schlüssel ist 'recommended' und wird für shim benutzt.

Insbesondere benutzt Microsoft verschiedene Schlüssel zum Signieren[1].

| There is one catch here. While Microsoft does sign Linux boot loaders
| with a Microsoft key, these boot loaders are signed with a separate
| key from the one Microsoft uses to sign Windows. PC manufacturers
| arent required to include the Microsoft key for third-party UEFI
| applications as part of the Secure Boot specification, which means
| that these Linux distributions may not actually work on all Secure
| Boot PCs. But, in practice, most PC manufacturers do install this
| Microsoft key.

Mit dem privaten Teil von Schlüssel b) hat Microsoft den Bootloader shim
signiert und einigen Distributionen zur Verfügung gestellt (oder allen,
aber nicht alle nutzen ihn)[1].

| Modern versions of Ubuntu, Fedora, openSUSE, and Red Hat Enterprise
| Linux all just work without disabling or configuring Secure Boot. They
| use a small shim boot loader signed by Microsoft, which in turn
| confirms the main boot loader was signed by the Linux distribution
| before loading it. Some other smaller Linux distributions also use
| shim.

Sofern der Hersteller des Mainboards den Schlüssel b) hinterlegt hat
oder man ihn selber dort irgendwie(TM) hinterlegen kann, kann man auch
mit Secure Boot ein GNU/Linux mit shim betreiben. Xubuntu sollte das
können. Alternativ kann man Secure Boot möglicherweise abschalten.

Problematisch wird es bei Hardware, bei der man keine Schlüssel im UEFI
hinterlegen kann, der Hersteller den Schlüssel b) von Microsoft nicht im
UEFI hinterlegt hat und Secure Boot nicht abschaltbar ist. Dann hat man
ein sehr ernstes Problem. Derartige Hardware kann ich beim besten Willen
nur noch als Bevormundungsmaschinen bezeichnen. Kartellrechtlich stellt
sich die Frage, ob sowas überhaupt zulässig ist in Deutschland und/oder
der EU.


 [1] http://www.pcworld.com/article/2951559/operating-systems/how-to-install-linux-on-a-pc-with-secure-boot-enabled.html


-- 
Gruss
Frank