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:
  • MS says: (Score:3, Insightful)

    by Nyder (754090) on Wednesday January 30, 2013 @11:17AM (#42737721) Journal

    UEFI is working as intended.

    • Re: (Score:2, Interesting)

      by Anonymous Coward
      You might be confusing UEFI with other firmware based software "features"... as Linux supported (U)EFI 2 years before MS did in server products, 8 years before MS did in desktop versions of OS, and 12 years before MS finally got aroudn to supporting it for 32 bit systems. The fact UEFI can include extra things like secure boot isn't a problem of UEFI, but of those that choose to include such an option. The BIOS interface was overdue for being updated/replaced
      • Re:MS says: (Score:5, Insightful)

        by fuzzyfuzzyfungus (1223518) on Wednesday January 30, 2013 @12:31PM (#42738497) Journal

        The BIOS interface was overdue for being updated/replaced

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

        • 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,

          • Re:MS says: (Score:4, Insightful)

            by fuzzyfuzzyfungus (1223518) on Wednesday January 30, 2013 @03:59PM (#42741329) Journal

            Mac UEFI is, if anything, even weirder than the usual flavor. Apple laptops running Apple EFI in order to boot OSX work; because Apple makes all of them and none of the parts is dumb enough to lean on the other parts in an unexpected way; but once you try something different, life gets exciting(the, er, interesting transition between 32 bit and 64 bit EFI 1.x was good fun as well).

            This fellow [dreamwidth.org] used to do EFI-related work for Redhat and is interesting reading on the matter. UEFI is a bloated bear of a 'standard', that makes ACPI look like a brutally efficient paragon of elegance, and things tend to go downhill from there once a vendor gets their sloppy hands all over it...

            • by dfghjk (711126)

              Macs don't implement UEFI, they implement EFI. Their implementation is only "weird" until you realize that they implemented a spec *before* it became UEFI.

              You continue to demonstrate that your opinions of UEFI come from ignorance.

        • Realistically, what more do you need from what the BIOS already does?
          Processor available: check
          RAM available (and optional quick check): check
          Network boot / disk boot available / USB boot: check
          minimal power management: check
          password protection / boot device selection without having to change boot order in BIOS: check

          Hand everything else off to the OS boot sector / boot sequence.

          Personally I think having the winflash utilities is a very stupid idea too. It's just another way for something to go wrong when w

        • by dfghjk (711126)

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

          It is not "tantamount" to a second OS, not even remotely, and saying so just proves that you don't know what that means. UEFI provides an extension mechanism to enable a variety of things that are potentially needed for booting, that is all. "BIOS features like ACPI" are absolutely mandatory for the ar

    • by MoonFog (586818)
      I`m expecting mine back from service the coming few days. I guess I`m looking forward to hearing whether or not this is covered by the warranty..
  • by pushing-robot (1037830) on Wednesday January 30, 2013 @11:21AM (#42737753)

    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.

  • Bricked device (Score:5, Insightful)

    by P-niiice (1703362) on Wednesday January 30, 2013 @11:26AM (#42737821)
    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.
    • 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..)

    • Re:Bricked device (Score:5, Insightful)

      by Hatta (162192) on Wednesday January 30, 2013 @12:26PM (#42738461) Journal

      A true brick is always the manufacturers fault. Software should never be able to do anything irreversible to hardware. If there's flashable firmware that could be corrupted, keep a ROM copy that can be used by setting a jumper. Anything less is pure negligence.

      • by niiler (716140)

        I agree with you only...

        It is a laptop... On many of my laptops, setting jumpers is only possible by taking the whole dang thing apart, and laptops are much harder to disassemble (correctly) than are desktops. On my old Toshiba Satellite, I have to strip it to the frame to get to the CMOS battery (which, in theory, will never go bad).

        I just hope Samsung can figure this out. I was starting to like their products.

        • by sjames (1099)

          That is a second design flaw. They should have had an access panel allowing you to easily access the CMOS battery and any jumpers needed fro recovery.

      • Software should never be able to do anything irreversible to hardware.

        not always true. an audio chip I work with, these days, needs to have a special sequence of turn-on done (power supply bring-up and reset, plus errata sent to the chip) and if you don't manage that, you DO fry the chip. software can really do this if the driver is not properly written. or, if someone got access to the chip's registers, they could turn one part off and the other part *would* burn. literally burn and fry.

        • by cellocgw (617879)

          Software should never be able to do anything irreversible to hardware.

          not always true. an audio chip I work with, these days, needs to have a special sequence of turn-on done (power supply bring-up and reset, plus errata sent to the chip) and if you don't manage that, you DO fry the chip.

          Methinks you misunderstand the meaning of "should." The whole point is that the hardware design should never, ever EVER DAMMIT be such that bad software command sequences cause physical damage. In your example, there's no excuse for not having zeners and switches (or the hard-coded firmware equivalent) which unequivocally block an undesirable voltage from getting through.

        • by jafac (1449)

          I *think* that with a Dell laptop I have; (purchased last year) - there is no way to back-rev the BIOS if you update it. You can't set it back to factory. So you could theoretically flash the bios and brick it. This is what the ppl on the laptop forum say. Of course, at Dell's website, they pretty much say don't power it on, or you're taking your life into your own hands. . . .

        • by Hatta (162192)

          an audio chip I work with, these days, needs to have a special sequence of turn-on done (power supply bring-up and reset, plus errata sent to the chip) and if you don't manage that, you DO fry the chip.

          That chip is badly designed. There is absolutely no reason it has to be that way, except shitty design. That is 100% the manufacturers fault.

      • by countach (534280)

        You would think so, but the apple DVD drives only allow you to change DVD region 3 times, and this is deliberate.

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

    • Re:"One time"? (Score:5, Insightful)

      by Anonymous Coward on Wednesday January 30, 2013 @11:40AM (#42737963)

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

      Why do people say "hundreds of years" when there's been a shorter word for it for centuries?

    • Why do people say "one time" when there's been a shorter word for it for hundreds of years? Damn Fugees...

      Don't blame the Fugees. That's a Justin Bieber song.

  • by Andy Dodd (701) <atd7@corne[ ]edu ['ll.' in gap]> 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.)

    • That makes Apple a FOSS leader....

  • by fuzzyfuzzyfungus (1223518) on Wednesday January 30, 2013 @11:37AM (#42737953) Journal

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

  • by MoonFog (586818) on Wednesday January 30, 2013 @12:17PM (#42738355)
    Mine got bricked booting Fedora 18 XFCE..
  • 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.
  • UEFI: Microsoft's way of giving you a UFIA

    • by MoonFog (586818)
      To repeat what others have said; don`t confuse UEFI and secure boot. Although Microsoft is certainly pushing the secure boot bit, Intel were the masterminds behind UEFI.
  • 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?

  • Why Am I Not Surprised?

The biggest mistake you can make is to believe that you are working for someone else.

Working...