Samsung UEFI bug: Notebook bricked from Windows

The Samsung 900X4C is among the affected devices

Linux developer Matthew Garrett, who does a lot of research into UEFI topics, writes in a blog post that by storing a large amount of data in UEFI variables, he managed to disrupt a Samsung notebook running Windows to such a degree that it subsequently refused to start. In his post, the developer also points to some sample code of the Windows program that he executed at administrator level to disable the notebook. The developer had previously speculated that some Samsung notebooks with UEFI firmware may be rendered inoperative under Windows in the same way that they were when starting Linux under certain circumstances. The experiment to confirm this was successful.

UEFI variables enable operating systems to deposit data for the firmware that will still be available after a reboot. Microsoft's Windows 8 Hardware Certification Requirements stipulate that at least 64KB of storage must be available for this purpose. When a crash occurs in certain configurations, the Linux kernel uses this storage to deposit information that allows the cause of the crash to be investigated later; Linux places about 10KB of data in a UEFI variable for such a "crash dump". According to Garrett's analysis, this is the actual reason why some Linux distributions destroy Samsung notebooks. The samsung-laptop driver that was previously considered to be the main cause of the disruptions only contributes to the problem through the way it works on UEFI systems: it causes the crash which results in a crash dump being written. How large an amount of data is required to cause firmware malfunction remains unknown; Garrett says that he generated 36 one-kilobyte variables in the tests that resulted in a notebook being disabled under Windows.

The developer concludes that the problem is caused by a firmware flaw. "Writing UEFI variables is expressly permitted by the specification, and there should never be a situation in which an OS can fill the variable store in such a way that the firmware refuses to boot the system", says Garrett. He notes that similar bugs were seen in Intel's reference code for UEFI firmware a year ago, but adds that these bugs have all been fixed. Garrett has renewed his recommendation not to use Windows in UEFI mode on the affected devices. In a subsequent tweet, the developer pointed out that not even removing the CMOS buffer battery brought the device back to life.

(fab)