Forgot your password?
typodupeerror
Bug Windows Hardware Linux

Samsung Laptop Bug Is Not Linux Specific 215

Posted by timothy
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.'"
This discussion has been archived. No new comments can be posted.

Samsung Laptop Bug Is Not Linux Specific

Comments Filter:
  • by RichMan (8097) on Saturday February 09, 2013 @05:55PM (#42845975)

    Embrace Linux as an additional test suite for your hardware.

    • by Anonymous Coward on Saturday February 09, 2013 @06:03PM (#42846013)

      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.

      • by iced_773 (857608)
        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.
        • by xaxa (988988) on Saturday February 09, 2013 @07:30PM (#42846583)

          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.

      • by gmuslera (3436)

        Considering all the times that malware was included in drivers disks, could be interesting that the ones for Samsung laptops have included a hardware killer trojan. Or, more up to date, that trojan appears masked as an update on Samsung site or Microsoft marketplace.

        That would be preferable than to have a random trojan or exploit that runs at whatever time and put in doubt that it could be manufacturer or owners fault. If someone have to pay the full cost of this is the manufacturer, not the consumer, and

      • by wvmarle (1070040)

        And maybe, just maybe, people would start to wake up again to the real threats of malware, and would demand higher levels of security. Not likely, but you never know.

      • by jamesh (87723)

        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.

        I don't understand. How is my botnet supposed to make me money if all the machines don't boot?

      • Re: (Score:3, Insightful)

        by silanea (1241518)

        [...] the negative publicity is sure to kill this whole UEFI thing, [...]

        This is becoming increasingly annoying: Why the hell is there so much hate for UEFI? I run Linux Mint and Windows 7 in a dual-boot setup and frankly I have come to love the speed at which my rig boots since switching to a pure UEFI setup. For whatever reason BIOS-based configurations on the same hardware took ages in comparison. I like UEFI. I do not want anyone to kill it.

        Now, SecureBoot, that is a different beast. I see quite a few uses, eg. preventing 'bad people' from booting anything I did not preappro

    • by CheshireDragon (1183095) on Saturday February 09, 2013 @06:09PM (#42846037) Homepage
      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.
      • by neonsignal (890658) on Saturday February 09, 2013 @06:19PM (#42846085)

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

        • Ah OK, thanks for clearing my eyeballs on that one. :) Went back, re-read and understand it more now.
          I've never really understood the purpose of the UEFI though. I thought it was a dumb idea a while back when I first heard about it. I guess it is time I go freshen up my computer skills a bit. I been out of the game for over a decade. :/
          • by DarwinSurvivor (1752106) on Saturday February 09, 2013 @07:17PM (#42846507)
            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.
            • by jedidiah (1196)

              The 4 partition limit? Really? That's like something that only 1% of the 1% care about. All of your other examples are similarly completely unexciting.

              BIOS may be ancient and ugly and still require you to [gasp] still use a keyboard but they don't seem to be bricking machines.

              • by rahvin112 (446269)

                BIOS is incapable of handling boot storage larger than 3TB. Given the persistent increase in storage overtime and that Laptops right now are coming with 1TB, it's just a matter of a few years before BIOS can no longer be used without limiting storage to 3TB.

                • by drinkypoo (153816)

                  BIOS is incapable of handling boot storage larger than 3TB.

                  Is that a fact? Or can it only address 3TB on it? Your boot partition has to be in the first 3TB? Doesn't sound like a problem to me. I'd love to replace the BIOS with Coreboot with a grub payload, and maybe someday I will try, but only because it is so goddamned slow. I don't need to fully initialize all my hardware before I boot.

            • What does UEFI do that coreboot doesn't other than Secure Boot?

            • by wvmarle (1070040)

              Isn't UEFI just a BIOS v2? It has the same basic purpose (bootstrap the system, so it can start loading the OS from an external memory). That's BIOS plus added functionality, including a thorough break from all legacy restrictions. And of course a new name to not leave a bad taste.

          • by tlhIngan (30335) <<slashdot> <at> <worf.net>> on Sunday February 10, 2013 @02:27AM (#42848515)

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

        • by msauve (701917) on Saturday February 09, 2013 @06:45PM (#42846269)
          "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.
          • by Kaldaien (676190)

            Yeah, not to mention the latency involved in writing to EEPROM. You would pretty much have to do it asynchronously to keep it from becoming a bottleneck, which then invalidates the usefulness -- since there is no guarantee that the last log message(s) completely written to UEFI was the last message generated. I implemented something similar in a custom VxWare boot loader, which wrote boot status to on-board flash memory, but it did so synchronously at a limited number of application-defined checkpoints.

            I do

            • by pjt33 (739471)

              My understanding of Matthew Garrett's blog post is that it only writes to UEFI variable storage on a kernel crash, which (hopefully!) isn't a frequent occurrence.

      • by sdsucks (1161899)

        I believe you misread the article. Taking Linux out of the equation still caused the problem.

        Uh, testing under this distro and version of linux WOULD have caught the bug, right? It's not unexpectable that a samsung laptop would have ubuntu installed.

        Just because the bug was reproduced under Windows doesn't mean it would have ever occurred accidentally there. I'm guessing you have never been involved in any kind of testing - software or otherwise.

    • by PolygamousRanchKid (1290638) on Saturday February 09, 2013 @06:11PM (#42846055)

      How about a warning sticker?

      "Warning: UEFI Inside!"

    • by marcello_dl (667940) on Saturday February 09, 2013 @06:49PM (#42846311) Homepage Journal

      "Embrace linux" requires not much of an effort. That's why PC that were made before linux got popular happily run it.
      "Don't throttle linux" fits more the situation, IMHO.

    • by wvmarle (1070040)

      If only you had read the headline of the summary you would've known that it is not related to Linux as such.

      Linux is just doing something to the UEFI (writing data to the UEFI memory) that is fully within the specs and which UEFI explicitly has been designed for to support. It is just that Windows normally doesn't use this feature. Yet bricking using Windows is just as easy or even easier than bricking using Linux.

  • by Anonymous Coward on Saturday February 09, 2013 @05:58PM (#42845989)

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

    36k clearly isn't enough for anyone.

  • Does windows crash if it has 0 temp space or 0 ram free real+VM?

    Or at least in older vers? or on systems with very low ram.

    • That's what swap space is for (aka the pagefile on Windows).

      Your system will try to dump memory into swap space. If you don't have swap space, on Linux at least, processes will fail to run and you'll get some messages in dmesg that you're running out of available RAM.

      Depending on the application, the application that is trying to allocate memory may crash.

      I have yet to see a full system hault brcause of it though.

      • by Dwedit (232252)

        I've seen Windows machines run out of handles. First you see applications not drawing properly, or missing buttons, then you see windows failing to be created. When it tries to create the window, it fails, then you hear the "Critical Stop" sound played instead of a dialog appearing.

        Sometimes, it won't even create menus, so you can't right-click on a program in your taskbar and close it, but you can still activate the window and press Alt+F4 to close the program.

        Once your system gets into that state, start

      • by xaxa (988988)

        I have yet to see a full system hault brcause of it though.

        Last time I discussed it, Linux would kill a heuristically-chosen process (the "OOM Killer", it will avoid killing a process owned by root, balanced by killing something using lots of RAM and maybe CPU, I can't remember). Windows will crash.

        Both behaviours are acceptable. Arguably, the Linux one is worse in some cases -- it might leave the system in an unnoticed but inconsistent state.

        • by whoever57 (658626) on Saturday February 09, 2013 @08:07PM (#42846797) Journal

          That's not what the OOM killer is for. Linux will allow over-commitment of memory (programs can malloc more memory (RAM plus swap) than is available). If all the malloc'ed memory is actually used, this can lead to more memory having been allocated than is available. This is when the OOM killer starts work killing tasks.

          This behavior can be modified by changing the values in /proc/sys/vm/overcommit_ratio and /proc/sys/vm/overcommit_memory.

          As an experiment, I wrote a little progrem that malloc'ed 200MB chunks of memory. I ran this on a Linux box with 2GB of RAM and all the SWAP disabled. The program could malloc 3GB of RAM before the allocation requests failed.

          • by amorsen (7485)

            As an experiment, I wrote a little progrem that malloc'ed 200MB chunks of memory. I ran this on a Linux box with 2GB of RAM and all the SWAP disabled. The program could malloc 3GB of RAM before the allocation requests failed.

            You were running on 32 bit? You will hit the same limit whether you have 256MB or 16GB then.

            • by whoever57 (658626)

              You were running on 32 bit? You will hit the same limit whether you have 256MB or 16GB then.

              Sorry, what? You are saying that a 32-bit machine with no swap and 256MB or RAM would allow 3GB of memory to malloc'ed? I don't think so. My point was that with a total of 2GB of memory in the system (2GB RAM and zero swap), a program can malloc 3GB.

              • by mjg59 (864833)

                You can malloc() as much as you want until you run out of address space. That's 3GB on 32-bit systems, no matter how much RAM you have. Things will only go wrong if you attempt to use it for anything.

                • by whoever57 (658626)
                  Sorry, but no. My tests showed that the amount of memory you can malloc() is dependent on the values in /proc/sys/vm/overcommit_ratio and /proc/sys/vm/overcommit_memory
                  • by mjg59 (864833)

                    I'm sorry, you're right - I was under the impression that overcommit_memory defaulted to permissive rather than heuristic allocation. However, overcommit_ratio is also ignored by default.

    • Windows 7 and 8 give you messages that you are running low on memory. I'm not 100 percent sure, but I think they kill the largest userspace program (though this just might be the program dying from lack of ram). Running out of (disk) space is generally the bigger problem, linux doesn't like to log you in if it cannot syslog the attempt to disk.

  • by AdamRosas (2775561) on Saturday February 09, 2013 @06:17PM (#42846077)
    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...
  • We all know perfectly well that malware makers will start including a module that purposefully bricks Samsung laptops so that extortionists can threaten to wipe out a batch of corporate-owned laptops in one blow if the company refuses to cough up a substantial amount. No matter how this affair plays out, I can't see it ending well for Samsung.

    • Why does this only affect Samsung computers? Did they do something extra stupid to the UEFI in their computers that other vendors didn't?

      • by Deliveranc3 (629997) <deliverance.level4@org> on Saturday February 09, 2013 @07:05PM (#42846431) Journal
        Just guessing from experience with Koreans, but... chances are they followed Microsoft or Intel specifications properly. Other companies probably just copied a binary and use it as a black box.
      • by Forever Wondering (2506940) on Saturday February 09, 2013 @07:22PM (#42846529)
        From the scant details, it appears Samsung didn't provide enough storage [of whatever type] to be able to store the UEFI variables that one could reasonably be expected to store. And/or when that storage ran out [or hit a percentage threshold], simply failed to prevent the bricking with a limit check and refuse to store the new information [returning an error code instead]. It's unclear what's truly happening, but it seems that the extra UEFI data goes somewhere and scribbles on some NV memory that it shouldn't [which may have nothing to do with secure boot].
        • From the scant details, it appears Samsung didn't provide enough storage [of whatever type] to be able to store the UEFI variables that one could reasonably be expected to store. And/or when that storage ran out [or hit a percentage threshold], simply failed to prevent the bricking with a limit check and refuse to store the new information [returning an error code instead].

          That would imply that this bug may be present in many/most/all UEFI implementations, with others merely having higher limits.

          It als

          • by wvmarle (1070040)

            That'd be easy to test using the script posted. Just increase the 36-variable number to something much bigger, and write write write until something breaks.

            FTA, UEFI specs say there should be at least 64 kB of memory available for writing data to. So start with that. This shoud ALWAYS work - 36 kB is well under that limit. Some UEFI systems may have more than that available of course, fill that up as well.

            And when the memory is full, try to write some more.

            Now honestly I have no idea what UEFI specs say it'

            • by JWSmythe (446288)

              The spec may say that there should be at least 64K available, but that doesn't mean that it is. That is available for something to write into, so if the UEFI already writes something there, 36K or less could fill it.

              It actually seems to be a forewarning of future problems. 28K have already been used up by something, it's already 44% through its life. If it's a fairly new machine, that doesn't look so good for it's longevity. Since I don't have a problem machine in front of

          • That would imply that this bug may be present in many/most/all UEFI implementations, with others merely having higher limits.

            The important thing is the limit check. It seems that Samsung's BIOS doesn't have one. The question is which BIOS is Samsung using [and what BIOSes are other vendors using]? For example, I believe Dell's BIOS was originally Phoenix, but now they roll their own. So, if Samsung used a slightly customized version of Phoenix [or AMI], the bug may indeed be in other vendors' products. If Samsung rolled their own, or heavily customized a Phoenix/AMI BIOS, it may be Samsung's problem alone.

            Matt's test progr

        • buffer overrun? and when the storage gets full it starts to over write other config data with junk.

        • What I find sort of alarming is that excessive scribbling causes the firmware to fail, rather than to fall back to some sort of sane failsafe state.

          It sounds like Samsung managed to make things brittle enough to be the first to fail under real-world conditions; but, no matter how much storage you provide, somebody could always demand more. You'd hope that the firmware would either behave sensibly as the storage fills up(and stop accepting requests for more) or at least fail sensibly and wipe or truncate the

  • by Groo Wanderer (180806) <charlie@noSpam.semiaccurate.com> on Saturday February 09, 2013 @06:29PM (#42846147) Homepage

    He forgot the line, "Try it yourself and see." :)

    Reminds me of the old IRC days when n00bs would ask what the command was to get channel admin privelages. "+++ATH" was the normal answer. :)

                            -Charlie

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

    • Re: (Score:2, Funny)

      by harrkev (623093)

      Don't forget about telling noobs about the great warez site at 127.0.0.1.

    • by Skapare (16644)

      They were probably at home. You know the old saying "don't do this at home, boys and girls". Later on they can take the laptop to a restaurant where it is safe to do it.

  • (char)rand();

    Extremely minor nitpick, but converting an out-of-range value to a signed integral type causes implementation-defined behaviour (which could include raising a signal).

    It's pretty safe to say that Microsoft will never release a compiler that breaks this, but portability could be maximised by making 'testdata' be 'unsigned char' and removing the cast in the quoted code (out-of-range conversions of unsigned integral types causes the value to be reduced using modular arithmetic - no cast is required or desire

  • by Fencepost (107992) on Saturday February 09, 2013 @08:32PM (#42846955) Journal
    Interesting. Does this mean that before too long there's going to be a nice glut of Samsung laptops being sold as refurbs? Replace, reflash, resell?
  • by manu0601 (2221348) on Saturday February 09, 2013 @10:52PM (#42847627)
    That remind me of an assembly language course I took at the University, where we had to implement a mathematical algorithm in x86 assembly. My implementation bricked the PC, leaving it with a BIOS unable to boot or to enter setup. I never understood how it did it, but I now suspect that removing the battery for a while would have cured the disease.
    • by mikael (484)

      Easy enough to do with early days DOS programming. PC's would cache various disk drive information in unprotected system memory (disk type, number of sectors, number of tracks, number of platters, clusters/sectors chains of open files), then write that stuff back when the file was closed. Anything that corrupted this area of memory would make the PC unbootable. Things could be well and truly messed up if you didn't use the same memory model as third-party API's (tiny, small, medium, large, huge), so 32-bit

  • by gweihir (88907) on Sunday February 10, 2013 @01:02AM (#42848165)

    The Linux folks actually read and understand the documentation and then use the mechanisms described. The Windows-folks are usually not so capable.

"More software projects have gone awry for lack of calendar time than for all other causes combined." -- Fred Brooks, Jr., _The Mythical Man Month_

Working...