Verriegelt, bis man den Schalter umlegt

[PG]

Wenn ein Benutzer die Kiste öffnen will, reicht entweder der Entwicklerschalter (in Hardware, Google dokumentiert, wo dieser bei den verschiedenen Geräten zu finden ist), mit dem die Signaturprüfung abgeschaltet wird. Damit kann dann auch die untere Hälfte des cChips überschrieben werden, zum Beispiel mit einem coreboot, das _eigene_ Schlüssel zur Prüfung verwendet. Das schöne an diesem Aufbau ist, dass man bei Fehlflashes durch Wechsel aus dem Entwicklermodus wieder ein bootfähiges System hat (weil die obere Hälfte des Chips noch eine funktionsfähige Version enthält). Nachteilig ist die Warnung bei jedem Boot, dass man im Entwicklermodus ist.

Oder man öffnet das Gerät und setzt einen Jumper oder dreht an einer Schraube (je nach Gerät; dokumentiert, wenn auch nicht so gut wie der Entwicklerschalter) und das gesamte Gerät ist flashbar. Und es steht ein coreboot-Port bereit, mit dem das Gerät an eigene Wünsche angepasst werden kann - allerdings mit dem Risiko, dass man sich etwas einfallen lassen muss, falls es schief geht.
Die Google-Leute sind auch recht kooperativ, wenn es Fragen zu solchen Hacks gibt, und machen da selbst mit.

Garrett ärgert sich vermutlich vor allem darüber, dass diese Mechanismen ungeeignet sind, um fertige Images zu produzieren, mit denen man abgeriegelte (ich meinte: sichere) Linuxinstallationen auf den Kisten installieren kann. Das ist nun mal das, was er bis vor kurzem bei Fedora (als Redhat-Mitarbeiter) gemacht hat.

Die Freiheit des Benutzers kann ihn jedenfalls nicht sonderlich interessieren - ein Secure Boot Linux nach Redhat-Art sperrt eine Menge Funktionen, um die Sicherheit zu gewährleisten (nur signierte Kernelmodule, kein kexec, kein iopl - was X-Server ohne Kerneltreiber unmöglich macht) und bietet auch keinen physical presence test, mit dem man diese Sperrung im Einzelfall umgehen kann.