Forgot your password?
typodupeerror
Bug Linux

Linux: Booting Via UEFI Can Brick Samsung Notebooks 232

Posted by Unknown Lamer
from the like-openfirmware-only-it-sucks dept.
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."
This discussion has been archived. No new comments can be posted.

Linux: Booting Via UEFI Can Brick Samsung Notebooks

Comments Filter:
  • by Imagix (695350) on Wednesday January 30, 2013 @11:28AM (#42737845)
    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.)
  • by Andy Dodd (701) <atd7@nOspaM.cornell.edu> on Wednesday January 30, 2013 @11:32AM (#42737901) Homepage

    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)

    by Anonymous Coward on Wednesday January 30, 2013 @11:47AM (#42738029)
    Looks like you are confusing UEFI with secure boot stuff. BIOS was kind of a legacy mess, and it was about time the interface got updated. UEFI is that replacement. You can get a UEFI setup without the secure boot stuff.
  • by caveat (26803) on Wednesday January 30, 2013 @11:52AM (#42738079)

    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..)

  • by Anonymous Coward on Wednesday January 30, 2013 @12:07PM (#42738247)

    yeah, to the tune of 500k a year to the linux foundation alone.

  • by SorcererX (818515) on Wednesday January 30, 2013 @12:31PM (#42738503) Homepage
    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.
  • Re:MS says: (Score:4, Informative)

    by Bengie (1121981) on Wednesday January 30, 2013 @12:36PM (#42738577)
    I know I'm not being sensible, but Linux didn't run one of my games properly 10 years ago, it fck'd up and I will never use Linux and will advise people away from it. /sarc

    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.
  • by Mikawo (1897602) on Wednesday January 30, 2013 @12:57PM (#42738825)

    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)

    by blueg3 (192743) on Wednesday January 30, 2013 @01:39PM (#42739433)

    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)

    by maccodemonkey (1438585) on Wednesday January 30, 2013 @03:34PM (#42740901)

    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,

Never make anything simple and efficient when a way can be found to make it complex and wonderful.

Working...