We posted last week about a severe bug plaguing select Samsung notebooks where simply installing Linux could result in a non-functional machine, and since then, kernel developers rolled-out an update that helped side-step the issue. While things seemed fine and good since then, it turns out that the situation is even worse than originally believed.
As 3vi1 pointed out in the previous post, all that it takes to brick these affected Samsung notebooks is having the proper code to do so. For the sake of logging, some UEFI implementations can offer some free space that can be written to in the event of a crash. The issue here stems from the fact that when too many characters are written, the EFI ROM becomes flooded, and is unable to recover after a reboot.
To help prove the fact, developer Matthew Garrett published the code he used to brick his own Samsung notebook from within Windows. When executed as the administrator, it writes random data to the UEFI. It's not until you actually reboot the machine that you realize the damage it's done, as it's simply unable to recover.
At this point, it does seem likely that Samsung could issue a firmware update that remedies the issue, but I do wonder if that would at the same time remove the ability to write a log to the EFI - something that's not exactly ideal. It's certainly better than a bricked machine, however.
This is a design failure in UEFI, at the bottom of it all. If logs are required (and clearly, they are useful in the event of a crash), the address space of the writable CMOS RAM *must* be totally separate from the boot code; only a PHB would insist on making them sufficiently close together to permit overwriting the boot code.
Totally agreed. Dumb, really dumb move.
But it's basic business policy to blame a mistake with the hardware on what you're trying to install on it.