Slashdot Mirror
Linux: Booting Via UEFI Can Brick Samsung Notebooks
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."
Trying their best to sabotage free software.
UEFI is working as intended.
Be seeing you...
Kernel developers are discussing a change in the samsung-laptop driver.
To be fair, they didn't realize anybody would actually implement the HCF instruction.
How can I believe you when you tell me what I don't want to hear?
Who said "Man, I long for the old days when installing Linux wasn't as easy as today and all Linux guys were knowledgeable enough" ??
Step to the front now and apologize to all Samsung users.
And the worst thing about the response is that it isn't "Oh shit, looks like locking down your computer to prevent piracy doesn't work, we'll get rid of UEFI and find a less intrusive solution", but it's "UEFI has bricked your computer, deal with it. We'll figure something out eventually."
First you can't unlock your phone, soon you won't be able to use whichever operating system you want, some games are unplayable because of DRM that detects hardware changes, some are unplayable because of always-online DRM, some DVDs don't work on older DVD players. We're "buying" something then being told when and how to use it.
If I own something I will use it any way I damn well please (as long as its not to hurt anyone or steal something, etc).
Now THAT ladies and gentlemen, is a true brick. Not these smartphone soft-bricks that can be solved by a quick flash. you don't go home happy after a brick. Do not pass go. Do not collect $200.
My paranoid self says that we haven't eliminated the possibility that the right hand doesn't know what the left one is doing.
People in those projects know their section only. People have snuck in nefarious code before. Maybe it's exactly as the project leader wants it. It's not a good possibility, but it hasn't been eliminated yet either.
No. Just no.
The article spends four and a half paragraphs shouting how Linux has trashed the laptop and even states that "It does, however, only occur when Linux is booted using UEFI." But then right at the end it closes with "In addition to the samsung-laptop driver bug, there may be, it appears, other ways of messing up the hardware and firmware on some Samsung laptops to the extent that they will no longer boot." So, is it really the evil Linux that is fouling up Samsung's laptops, or is the the incompetent Samsung that allows the firmware on the motherboard to be fouled up so badly that it cannot be reflashed? (With regard to the replaced motherboard... I wonder if that is simply the easiest way to handle the warranty. Swap the motherboard, send it back to the customer, repair the "broken" motherboard later.)
Samsung notebooks can be turned into a brick if booted just one time
Why do people say "one time" when there's been a shorter word for it for hundreds of years? Damn Fugees...
systemd is Roko's Basilisk.
How will i know in the future, that when buying a new laptop my favorite Linux flavor will work on it?
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/
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
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.)
retrorocket.o not found, launch anyway?
This sounds like a design issue on Samsung's part. The firmware should not have been allowed to be altered to a state that the machines can no longer boot. Anyone remembers the notorious CIH virus back in the days? Now all you need is just a Ubuntu memory stick and you can render all those Samsung laptops inoperable...
"Even Samsung"? They're useless - months along and they're no closer to even acknowledging that there's cut and paste issue (hanging apps, randomly rebooting device) with their flagship Android phone, the Galaxy S3!
It seems as though there is something badly wrong with the at least some part of the design if a bug of this flavor is possible(much less happening for reasons that even the vendor hasn't nailed down yet).
There are reasons to update/modify the firmware responsible for the first stages of the boot process; but not all that often(especially on a PC-class device, which has tons of both RAM and persistent mass storage available, this isn't some cost-reduced embedded device where the OS has to scribble configuration information in whatever bits of the teeny flash chip that also stores the bootloader).
Can anybody enlighten me as to why (outside of a BIOS update) a situation would arise where the kernel needs to scribble over the motherboard firmware, or where the firmware would be doing anything sufficiently drastic to itself based on input from the kernel that it wouldn't be recoverable?
Regardless of how this was (accidentally or not) triggered, is this a weakness in UEFI such that once one gains kernel-level access to the hardware, bricking a device that was booted using UEFI is trivial?
With BIOS laptops there usually was an emergency recovery mode where the BIOS reflashed itself from an image via USB floppy disk. Was an opportunity missed to make a similar setup mandatory in EUFI (but from a USB stick of course)?
When the copyright term is "forever minus a day", live every day like it's the last.
Microsoft is not only guilty of attempted hardware monopoly, but also willfully contributing to the e-waste problem; given that it's a notebook, most folks won't even try to replace the board (and it should just be a replaceable chip, but NOT ALLOWED), but will just throw the whole thing away. Criminal waste due to criminal greed. The EU needs to get their butts in gear and stop this garbage cold.
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..)
Facts do not cease to exist because they are ignored. - Aldous Huxley
That makes Apple a FOSS leader....
New Economic Perspectives
Mine got bricked booting Fedora 18 XFCE..
I tried to install Ubuntu 12.10 a few months ago, using the UEFI boot instead of the regular BIOS boot loading options on a Samsung laptop. The installer started, and all I got was a black screen. When I tried to turn it on again, all I got was a black screen. I assumed it was a hardware problem, and managed to get a replacement laptop. I then tried to do the same procedure again, and I also managed to brick the second laptop. Since the internal SSD is not serviceable, I was not able to resolve the issue, and Samsung was unable to help me in any way. I returned the second laptop, and then I disabled the ExpressCache from Windows before I wiped the system and installed Ubuntu Linux without using UEFI.
Any sufficiently advanced technology is indistinguishable from magic.
UEFI: Microsoft's way of giving you a UFIA
"Always forgive your enemies; nothing annoys them so much." - Oscar Wilde
It seems that Samsung will have to take the blame for this; that is, they should have tested for this. As it stands, it should be considered a manufacturing fault on their part. So the question is now, will the unlucky owners of Samsung bricks have them replaced under warranty?
Well, that's pretty lame if I have to keep updating it every 2 weeks.
This is why PC vendors should have never allowed Microsoft to control their hardware. Unfortunately, Microsoft's gain = consumer pain, as usual. I'm guessing that disabling the secure boot feature entirely in the BIOS will avoid the machine getting bricked? If I purchase any new machine that will be the first thing I'll do, along with throwing the Windows installation discs in the trash can.
I've read online that disabling UEFI will mean you can no longer boot from USB. This means on the Samsung Series 9 laptops (which have only USB, no DVD/CD drive) you couldn't install Linux at all. Is this true?
eMMC bug... :-\
Okay, first you have the eMMc bug in Galaxy note which would result in permanent brick on factory reset and wipe via custom recovery.
Then in Note 2 you started giving root to any app which told you to.
And now the notebooks are going bricky brick.
Whats with you and the love of bricks?
My Aurora : http://www.youtube.com/watch?v=o91ZsGwJYyg
FB : https://www.facebook.com/TanveersPhotography
Fear, Uncertainty and Doubt Ultimate Edition.
Excellent work; a tip of the hat to the usual suspects.
That the most recent kernel breaks user space on these notebooks?
I just have to comment on the sprint thing... Sprint is almost always late with their updates, look at the Nexus 4... Its a nexus device which gets updates (becaus of sprint) 1-2 months after other Nexus devices that are handled by Google. So I would not only point at Samsung.
Really weird - why would merely booting a device incur changes to non-volatile memory? There has been similar bugs with Intel's Trusted Execution Technology (probably more a fault on certain BIOS vendors) where merely trying out the technology, i.e. booting into the new mode, would cause the computer go into an endless reboot loop that persisted even across power-off etc. Apparently because some BIOS'es set a "remember to zeroize memory flag" but somehow fails to clear the flag as part of the zeroization!
Why is Canonical recommending booting into Linux AT ALL, with ANY image, when "just one boot from UEFI into Linux" can brick the laptop?
It seems to me that it is not safe to attempt to boot into Linux under ANY circumstances.
Why Am I Not Surprised?
Fugue for Aaron Swartz
Login first ... That's an increasingly common request. But frankly, I don't understand it. Why do you say that? I see several problems:
1. You can't mod up a login. /. readership.
2. You can mod up an anonymous post. And, doing so may be good for the
3. Maybe one of the following is going on: AC doesn't have an account / AC doesn't want an account / has his own mod points / would prefer to post anonymously this time only / just doesn't play the karma game.
UEFI is a trojan designed to piss off geeks.
Samsung laptops do NOT become bricks if booted via UEFI. Have you seen the things? Pavers or facade stones maybe, but I sure wouldn't build a wall or a nice barbecue with something that thin!
This is a hacked account, for which the owner can not be held responsible.
Its just a teething problem... You have new tech/software UEFI being deployed in a rush, by developers that are used to making small changes to BIOS "1976" dealing with a new system UEFI with limited time, training and experience. Don't forget they have management and shareholders that don't really know how much work this kind of thing takes and think all this just takes 15min and runs on magic.
Just give UEFI a little bit more time to mature before you pick-up the pitchforks.
looks like there's a temporary fix for this already.
someone has to compile it first though :)
seems the problem was the samsung specific bit of kernel loading whatsit was doing BIOS specific things even on EFI, and making a damn fool of itself in the process.
it's now wrapped in an "if EFI..."
http://www.theregister.co.uk/2013/01/31/ubuntu_uefi_bricking_samsung_laptops/
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Wow!! I remember that command from a spoof ICL machine - that and the Galactic Storage Device!
Reminds me of how lmsensors bricked some Thinkpads during the I2C probing process. It overwrote some bytes in the "security chip" and wrecked a checksum which prevented the machine from booting. IBMs answer was to replace the mainboard. You could reprogram the chip, but the information was hard, if ever, to get. Some guys offered reprogramming services for a hefty fee.
The main reason was that the security chip, wich was a extended I2C eeprom (24RF02) reacted differently to commands as its non-security counterpart.
Crivens! I kicked meself in me own heid!