Slashdot Mirror

← Back to Stories (view on slashdot.org)

Samsung Laptop Bug Is Not Linux Specific

Posted by timothy on from the using-french-or-korean-does-it-too dept.

First time accepted submitter YurB writes "Matthew Garrett, a Linux kernel developer who was investigating the recent Linux-on-Samsung-in-UEFI-mode problem, has bricked a Samsung laptop using a test userspace program in Windows. The most fascinating part of the story is on what is actually causing the firmware boot failure: 'Unfortunately, it turns out that some Samsung laptops will fail to boot if too much of the [UEFI] variable storage space is used. We don't know what "too much" is yet, but writing a bunch of variables from Windows is enough to trigger it. I put some sample code here — it writes out 36 variables each containing a kilobyte of random data. I ran this as an administrator under Windows and then rebooted the system. It never came back.'"

10 of 215 comments (clear)

  1. memo to hardware producers by RichMan · · Score: 5, Interesting

    Embrace Linux as an additional test suite for your hardware.

    1. Re:memo to hardware producers by Anonymous Coward · · Score: 5, Interesting

      Add that script to the payload malware usually carries, and spread it around, a few thousands bricks later, the negative publicity is sure to kill this whole UEFI thing, or at least force the hardware makers to include linux in their testing.

    2. Re:memo to hardware producers by neonsignal · · Score: 5, Insightful

      The reason it was noticed on Linux is because a portion of this UEFI space is being used to keep a non-volatile copy of the most recent kernel log messages (so that on a crash event, it is easier to find out what happened).

    3. Re:memo to hardware producers by msauve · · Score: 5, Interesting

      "a portion of this UEFI space is being used to keep a non-volatile copy"

      The UEFI doesn't require the use of battery backed RAM ("the implementation of variable storage is not defined in this specification, variables must be persistent in most cases."), so such use can be expected end up making all the EEPROM based ones fail at some point. Doing frequent updates to EEPROMs isn't a good idea.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    4. Re:memo to hardware producers by Anonymous Coward · · Score: 5, Funny

      Well, yeah, that's why you have to force them. They're not going to brick their hardware voluntarily, are they?

    5. Re:memo to hardware producers by Anonymous Coward · · Score: 5, Interesting

      You probably didn't get the parent comment. If someone can brick a laptop using a simple hack within Windows, then Samsung (at least) better prepare their stock because it's gonna be an RMA nightmare very soon. And that's probably good for the anti-UEFI side

    6. Re:memo to hardware producers by xaxa · · Score: 5, Interesting

      Except these days malware is used more for profit (e.g. botnet construction) than random mayhem, and to do that you need to keep the host you just pwned alive.

      Perhaps put it in as a failure mode if the bot can't contact its server. That might dissuade the police from disabling the command server.

    7. Re: memo to hardware producers by Anonymous Coward · · Score: 5, Insightful

      Riiiiiight. Like there's nothing to be gained by an over zealous anti-UEFI coder writing a virus to accomplish what all the sound logic presented can not: making UEFI cost prohibitive due to RMA's and ad press.

    8. Re: memo to hardware producers by MaskedSlacker · · Score: 5, Insightful

      Right, instead of fucking up Windows (which they could have already done) they fuck up your firmware, and you honestly think end users would even know the damned difference. Pass the pipe please.

      Maybe you should stop smoking that, it's damaging your critical thinking skills.

      The users are not the one receiving a message in this scenario. The manufacturer is the one receiving the message. It works like this:

      1) Unethical hacker writes virus to brick Samsung laptops.
      2) Thousands of Samsung laptops get sent in under warranty for repair because they inexplicably (from the users' perspective) stopped booting.
      3) Samsung bean counters notice that UEFI models have an unacceptably high rate of failure under warranty.
      4) Samsung bean counters decide to kill UEFI models.

  2. Re:Not even a brick, not a story by mjg59 · · Score: 5, Informative

    Removing the CMOS battery didn't recover this system, which is pretty much what I'd expect - UEFI variables are typically stored in the same hardware as the firmware itself, and unplugging batteries doesn't kill your firmware.

    The system doesn't fail to boot. The system doesn't even complete its power-on self checks. The screen is never turned on. It never responds to keyboard input. It's bricked. This machine's not coming back to life without an SPI programmer.