Slashdot Mirror


Matthew Garrett Has a Fix To Prevent Bricked UEFI Linux Laptops

hypnosec writes "UEFI guru Matthew Garrett, who cleared the Linux kernel in Samsung laptop bricking issues, has come to rescue beleaguered users by offering a survival guide enabling them to avoid similar issues. According to Garrett, storage space constraints in UEFI storage variables is the reason Samsung laptops end up bricking themselves. Garrett said that if the storage space utilized by the UEFI firmware is more than 50 percent full, the laptop will refuse to start and ends up being bricked. To prevent this from happening, he has provided a Kernel patch."

8 of 74 comments (clear)

  1. more than 50 per cent full = fail is bad by Joe_Dragon · · Score: 5, Insightful

    more than 50 per cent full = fail is bad and Samsung needs to come out with a bios update to fix that.

    1. Re:more than 50 per cent full = fail is bad by broken_chaos · · Score: 4, Insightful

      They didn't even test the UEFI nvram (not a partition) filling up. If they had, they would have seen that, oh, wow, it bricks the laptop entirely.

    2. Re:more than 50 per cent full = fail is bad by ais523 · · Score: 4, Informative

      The same bug can brick Samsung laptops on Windows too. It's just that it was noticed on Linux first.

      --
      (1)DOCOMEFROM!2~.2'~#1WHILE:1<-"'?.1$.2'~'"':1/.1$.2'~#0"$#65535'"$"'"'&.1$.2'~'#0$#65535'"$#0'~#32767$#1"
    3. Re:more than 50 per cent full = fail is bad by fuzzyfuzzyfungus · · Score: 4, Insightful

      It was probably very well intentioned - to avoid the UEFI partition becoming full and causing errors.

      Are you not seeing the insanity of avoiding errors caused by being 100% full by bricking the device at 50% full?

      More broadly, for what possible reason would Samsung handle UEFI storage in such a fucked-up way? How many decades now have we had computers with some sort of mass-storage device that had to be treated sanely?

  2. Re:Bad Unified Extensible Firmware Interface...or? by Sir_Sri · · Score: 4, Interesting

    ---The UEF Interface seems to work just fine with Win OS and iOS. How is that a bios problem?

    Samsungs implementation of UEFI is the problem, not the UEFI specification. No, it's not a 'bios' problem, UEFI replaced bios, but Samsung seems to have done something odd in their implementation of UEFI.

    "---Gee wonder why the great mass migration to Linux hasn't happened?

    Well sure, that has always been an issue. Linux apparently isn't important enough for companies to bother testing for it, which means it only works with contrived hacks, which means no one uses it, which means companies don't think it's important enough to bother testing for it.

  3. No...Bad Unified Extensible Firmware Interface by tuppe666 · · Score: 4, Informative

    The UEF Interface seems to work just fine with Win OS and iOS. How is that a bios problem?

    http://www.pcworld.com/article/2027819/not-just-linux-windows-can-brick-samsung-laptops-too.html No bad on Windows too.

    Please don't quote other peoples comments as fact, I suggest you check out the reply to it.

    As for the Mass Migration to Linux, that happened with Android, which is set to become the most installed OS this year.

  4. Re:When you go Linux.... by Cito · · Score: 4, Informative

    You can sometimes on many "bricked" devices like linksys router bricks after borking a dd-wrt install
    and on the samsung laptops as well by playing with the jtag

    http://en.wikipedia.org/wiki/Joint_Test_Action_Group

    most stuff has jtag support and in some cases you can use the jtag header to unbrick a device.

    I've unbricked an old WRT54GL after a screwup I did on an older dd-wrt install few years ago using jtag.

    it's not something a normal user would be able to do or have confidence in doing, so yea in most cases the normal user will never unbrick.

  5. Re:Bad Unified Extensible Firmware Interface...or? by fluffy99 · · Score: 4, Informative

    It's been demonstrated that this bug can be elicited from Windows as well. And Windows expects to be able to write even more info than Linux was. Linux was just the first to expose the problem by trying to use UEFI variables to hold kernel panic info (Apple does something similar). IT didn't help that the UEFI driver itself caused the kernel panic, after which the kernel writes some debug log info to the UEFI to support later postmortem analysis.