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

21 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 CheshireDragon · · Score: 4, Informative

      I believe you misread the article. Taking Linux out of the equation still caused the problem.
      I think the reason why it was most commonly found in Linux is that you can have several different variables to boot the system. Especially if you are one of those super custom freaks. :P
      It needs to rewrite as: "Embrace a full test of the UEFI" or "Check storage limits on the UEFI"

      Why they wouldn't put more storage on the UEFI, as cheap as it is, boggles my mind.

      --
      "That's right...I said it."
    3. 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).

    4. 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
    5. 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?

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

    7. Re:memo to hardware producers by DarwinSurvivor · · Score: 4, Informative

      UEFI is much more than secure-boot. There are a lot of "hacks" required right now to make BIOS work properly for modern scenerios. the 4 partition limit is a good example, we have to use "logical" partitions within a bigger physical partition to get around this bullshit at the moment, UEFI fixes that. It also adds a LOT of other functionality such as much more powerful configuration interfaces that can supply graphics (temperature meters, etc), handle mouse input and drive system speakers directly.

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

    9. Re:memo to hardware producers by RichMan · · Score: 4, Insightful

      > The title of the article is "Samsung Laptop Bug Is Not Linux Specific" for fuck's sake. Learn to read.

      Sorry, but you need to learn to think.....

      Sure the bug is not Linux specific. But Linux was the first to expose it. If they had tested on Linux they would have known it was broken and could have fixed it before releasing the hardware.
      That is my point. Linux gives more hardware coverage and can expose bugs that might not be found otherwise. Linux provides a pretty much free test load for the hardware.

      Any test house should be very very happy to have a pretty much free (only cost is small time to setup boot) second test suite for the hardware.

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

    11. Re:memo to hardware producers by tlhIngan · · Score: 4, Informative

      I've never really understood the purpose of the UEFI though.

      Think of it this way - the PC boots the same way today as it did 30 years ago. The BIOS reads the first sector ot the first hard drive at a specific location in low memory and jumps there. Now, in most cases, that is a standard MBR loader - it reads the partition table (also embedded in the first sector - great design, eh?), the calculates where the next sector (the first sector of the partition) should be ont he disk. It calls the BIOS to load that into another location in RAM, then jumps into it. That one hopefully loads more of itself so it can then load the OS. All this happens in 16 bit real mode.

      EFI boot allows the loader to reside in a special EFI storage partition, where it can find the OS loader, and then the OS loader can directly, instead of chain loading various sectors all over the place (and often having to have a bootstrap loader be the one to fit in 512 bytes, that loads the main part of the boot loader - think the nasty hack that is grub's stage 1/2/2.5/etc loader and think how much nicer it would be if the BIOS would just read it off the disk)

      In fact, practically all PCs sold have an EFI/UEFI bootloader by default - Intel has been shipping them for many years now (prior to 2006 - when Apple introduced the Intel Macs, even - probably the first experience most people have with EFI). What's been happening is that the EFI loader has been calling into the BIOS emulation layer to perform the BIOS legacy boot.

      Basically, its a more advanced bootloader because really, initializing hardware is getting more complex. Think stuff like USB for example - it requires a lot of high level integration in order to work, and stuff like EFI can make it much easier to do so because it's like a mini OS. Plus getting rid of the 512 byte loader limitation.

      Finally, (U)EFI is a joint collaboration between Microsoft and Intel - Intel created several technologies, including the GPT (which is required if you want a >3TB drive to be useful and not truncated to 3TB - MBR is useless at this point - and important if you're running huge RAID arrays)., while using others from Microsoft (the on-disk EFI partition is... FAT32, and the binaries it loads are PE COFF exe's).

    12. 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. They didn't get the memo by Anonymous Coward · · Score: 4, Funny

    it writes out 36 variables each containing a kilobyte of random data

    36k clearly isn't enough for anyone.

  3. Re:Unlimited Supply of Laptops? by mjg59 · · Score: 4, Interesting

    30-day hassle-free return policy.

  4. OS boot entries are in NV storage by AdamRosas · · Score: 4, Interesting

    So installing too many operating system will result in a brick, Windows in particular uses a lot of NV storage for it's boot entry, be careful when using BCDEDIT.exe...

  5. Re:Unlimited Supply of Laptops? by pushing-robot · · Score: 4, Funny

    I might be confused, but don't kernel devs normally destroy their instruments at the end of each show?

    --
    How can I believe you when you tell me what I don't want to hear?
  6. 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.

  7. Re:Forgot one detail... by isorox · · Score: 4, Funny

    Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4 ...I'm sure someone will hit it (even now :-).

    Why would I want to switch to virtual desktop 4?

  8. Re:Free Laptops? by Skapare · · Score: 4, Insightful

    These steps are actually NOT supposed to brick them. It is thus a proven manufacturing defect. So Samsung is obligated to "repair or replace". An external (JTAG) reflash of the ROM should be able to fix it. Samsung should also fix it by reprogramming the ROM code to perform UEFI correctly.

    --
    now we need to go OSS in diesel cars
  9. Re:Unlimited Supply of Laptops? by Kaldaien · · Score: 4, Informative

    You can almost certainly re-program it using a JTAG interface... Samsung can do this at the factory if you return it to them. JTAG is not intended for consumer use, though. My old university had a JTAG probe and several adapters to interface with various hardware vendors proprietary interfaces - without this we would have had several multi-thousand dollar bricks in our hardware lab :)

    I would hope that Samsung would have the decency to admit a flaw in their design and provide the reprogramming free of charge, but ...