Samsung-UEFI-Bug: Notebook via Windows geschrottet
Der Linux-Entwickler Matthew Garrett konnte ein Samsung-Notebook schrotten, indem er mit Windows eine größeren Menge von Daten in UEFI-Variablen abgelegt hat.
Durch Ablegen einer größeren Menge von Daten in UEFI-Variablen konnte Matthew Garrett ein Samsung-Notebook unter Windows so stören, dass es nicht mehr startet. Das schreibt der Linux-Entwickler, der sich viel mit UEFI-Themen beschäftigt, in einem Blog-Eintrag. Dort verweist er auch auf den Quellcode des als Administrator ausgeführten Windows-Programms, mit dem er ein Samsung-Notebook kaputt gemacht hat. Bereits kurz zuvor hatte der Entwickler spekuliert, dass sich einige Samsung-Notebooks mit UEFI-Firmware auch unter Windows funktionsuntüchtig machen lassen, wie es durch den Start von Linux passieren kann.
In UEFI-Variablen können Betriebssysteme Daten bei der Firmware hinterlegen, die auch nach dem Neustart noch verfügbar sind. Laut Microsofts "Windows 8 Hardware Certification Requirements" muss dieser Speicher mindestens 64 KByte groß sein. In bestimmten Konfigurationen hinterlegt der Linux-Kernel dort während eines Absturzes Informationen, über die sich die Absturzursache später untersuchen lässt; für solch einen "Crash Dump" legt Linux ungefähr 10 KByte Daten in einer UEFI-Variable ab. Und genau das ist laut Analyse von Garrett der eigentliche Grund, warum manche Linux-Distributionen Samsung-Notebooks schrotten. Der Treiber "samung-laptop", der als ein Hauptverursacher der Störungen galt, ist nur insofern beteiligt, dass er durch seine Arbeitsweise auf UEFI-Systemen den Absturz auslöst, der zum Schreiben des Crash Dump führt. Wie groß die Datenmenge sein muss, damit Firmware-Störungen entstehen, ist nicht bekannt; bei seinen Versuchen mit Windows, bei denen Garrett ein Notebook zerstörte, hat er 36 jeweils ein Kilobyte große Variablen angelegt.
Das Problem sei ganz offensichtlich ein Fehler in der Firmware, wie Garrett erläutert. Das Beschreiben von UEFI-Variablen durch das Betriebssystem sei explizit durch die Spezifikation erlaubt und es dürfte nie zu einer Situation führen, bei der Betriebssysteme den Speicherplatz so füllen, dass die Firmware das Gerät danach nicht mehr starten kann. Ähnliche Fehler habe er schon vor einem Jahr in Intels Referenz-Code für UEFI-Firmware gesehen; sie wurden allerdings alle behoben. Garrett rät abermals dazu, auch Windows auf den betroffenen Geräten nicht im UEFI-Modus zu betreiben. In einem Tweet stellte Garrett später noch klar, ein Entfernen der CMOS-Pufferbatterie habe das Gerät nicht wiederbeleben können. (thl)
