Linux: Booting Via UEFI Can Brick Samsung Notebooks 232
wehe writes "Heise News reports today some Samsung notebooks can be turned into a brick if booted just one time via UEFI into Linux. Even the firmware does not boot anymore. Some reports in the Ubuntu bug tracker system report that such notebooks can not be recovered without replacing the main board. Other Linux distributions may be affected as well. Kernel developers are discussing a change in the Samsung-laptop driver."
It appears even Samsung is having trouble tracking down the problem (from the article): "According to Canonical's Steve Langasek, Samsung developers have been attempting to develop a firmware update to prevent the problem for several weeks. Langasek is advising users to start Ubuntu installation on Samsung notebooks from an up-to-date daily image, in which the Ubuntu development team has taken precautions to prevent the problem from arising. It is, however, not completely clear that these measures are sufficient."
A little bias in the article (Score:5, Informative)
Ah, brings back memories. (Score:5, Informative)
The previous guy commenting about "sabotaging free software" got marked as a troll... But this is pretty similar to a major eMMC firmware bug present in many of Samsung's phones manufactured in 2011.
The eMMC flash chip is NOT JEDEC compliant, and the wear leveller can go out into la-la-land if you issue a secure erase command to the chip.
Starting with ICS, Google started performing eMMC erase when wiping data in recovery for privacy reasons. This would kill Samsung flash chips.
In the Galaxy Nexus, Google forced Samsung to fix the damn chip with an internal firmware update.
However, in other devices, Samsung worked around it in two ways:
1) Disabling MMC_CAP_ERASE in I9100 kernels for a while
2) Replacing secure erase with nonsecure erase and not documenting this anywhere
Without the assistance of an engineer from Google (whom Samsung later tried to silence as far as I can tell) providing critical information, the opensource community would have been fucked.
Eventually, Samsung claimed they were "working hard" on the issue in early June 2012 - http://www.xda-developers.com/android/samsung-diligently-working-towards-hardbrick-fix/ [xda-developers.com]
A month later, in early July, they added MMC_CAP_ERASE to I9100 kernels without providing even the slightest warning - Within a day, a pile of bricks showed up:
http://forum.xda-developers.com/showthread.php?t=1756242 [xda-developers.com]
In late August/early September, they submitted a patch to the Linux kernel to work around the issue at a kernel level - It was merged to mainline on September 4.
In early October, they released an update for Sprint devices WITHOUT THE FIX. "testing takes time" is an invalid excuse, as the build date for Sprint FI27 was September 27, 2011 - Almost a MONTH after the patch had been mainlined. The patch is very easy to backport to their I9100 kernel source baseline, so there is no excuse for this.
As a result, I still get PMs on XDA once or twice a week due to people accidentally digging up userspace binaries that perform secure erase. This shouldn't be an issue, as it is the kernel's responsibility to protect hardware from getting damaged by userspace. Samsung's position was that it was an "open source problem" and hence refused to fix it in the end.
Now that the exynos-abuse vulnerability is known and an exploit has been published, it's not an open source problem any more - Anyone who has not yet received an update to patch the exynos-abuse hole is dependent on this planet, out of 7 billion people, not having a SINGLE asshat who decides they want to permanently destroy a few Samsung devices. Even if exynos-abuse is patched, as long as the kernel still allows secure erase commands through, any other privilege escalation exploits will endanger devices again. Despite this, Samsung released an update for Sprint devices (FL24) at the end of December 2012 that *did not contain any protection against this issue in the kernel*
So yeah, Samsung wishes free software would go away - they claim otherwise, and make promises that they care and are trying to fix things, but they never deliver on such promises. Actions speak louder than words, and Samsung's actions send a pretty clear message to open source software - "fuck off and die".
(I won't even go into Samsung's constant and incessant GPL violations here... But it's incredibly rare for any Samsung source drop to correspond to any existing firmware release for a given device. When asked about this inconsistency, Samsung will claim that the firmware that came preinstalled on the device you purchased on launch day at Best Buy is a "leak" and thus they do not need to provide source that matches it.)
Re:Fucking UEFI (Score:2, Informative)
I'd call that "fried" (Score:5, Informative)
Bricks can be fixed with JTAG; if you have to outright replace the hardware, that's fried, toasted, nuked. (How the HELL does software do something THAT bad, anyway? Even flashing a ROM for an entirely incorrect model on a smartphone is still technically reparable..)
Re:Typical Samsung... (Score:4, Informative)
yeah, to the tune of 500k a year to the linux foundation alone.
Experienced First Hand on a Samsung Laptop (Score:5, Informative)
Re:MS says: (Score:4, Informative)
Samsung is one of the best companies out there for quality and support. They made a mistake and are working to fix it. Hopefully they will learn from this lesson and put in some proper Linux tests before shipping.
People make mistakes, but only the truly good learn from those mistakes.
Re:I'd call that "fried" (Score:4, Informative)
Apparently, you CAN recover if your device is bricked by this issue: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557/comments/23 [launchpad.net]
Re:Fucking UEFI (Score:4, Informative)
Which begs the question
No it doesn't.
how does Apple boot Windows 8?
The computers are Macintoshes. Apple is the company.
Their UEFI doesn't support secure boot as OS X doesn't support it...
Windows 8 doesn't require UEFI Secure Boot. It couldn't, since one of Microsoft's requirements is that users be able to disable Secure Boot. Having UEFI Secure Boot is a requirement places on the OEMs that ship computers with Windows 8, and Apple doesn't ship Macs preinstalled with Windows.
Re:MS says: (Score:4, Informative)
True. Unfortunately, UEFI was a step in the wrong direction. Yeah, the classic BIOS was older than dirt, limited, and saddled with a variety of quirks, oddities, and cruft from its years of genetic drift and backward compatibility.
However, because it sucked, there was a strong incentive not to try anything stupid with it, and to just boot the OS and GTFO. Instead of just cleaning up and rationalizing this basic firmware function, UEFI goes wildly in the opposite direction, to the point where the firmware is tantamount to a second OS; but still with all the fucked up weirdness that we know and love from BIOS features like ACPI...
To clarify, you mean Microsoft's screwed up version of UEFI. On Mac, we've been using EFI without issue. No OS limitations, no blocking of anything. BIOS and others like Open Firmware always were their own mini OSs, heck, Open Firmware had it's own command line. Don't confuse the technology (EFI) with bastardized implementations (Samsung's EFI, Microsoft's requirements.) The same sorts of things could have been done with BIOS anyway,