Samsung Laptop Bug Is Not Linux Specific 215
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.'"
Re:They didn't get the memo (Score:3, Informative)
Re:memo to hardware producers (Score:5, Informative)
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.
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.
Comment removed (Score:2, Informative)
Re:Not even a brick, not a story (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.
Re:Unlimited Supply of Laptops? (Score:4, Informative)
UEFI data is apparently stored in NAND. Non-volatile.
No idea if there is some way to flash it, but if it's sufficiently hardwired into the board then it's entirely possible you're SOL and have to buy new hardware. Yes, this is idiotic.
Re:memo to hardware producers (Score:5, Informative)
Re:Does windows crash if it has 0 temp space or 0 (Score:4, Informative)
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.
Re:Unlimited Supply of Laptops? (Score:5, 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 ...
Re:memo to hardware producers (Score:1, Informative)
Re:Free Laptops? (Score:4, Informative)
Well, yes, in a way, they are intentionally bricking their laptops. And I would hope they can get a new one under warranty.
Reason being of course that they are trying to figure out what causes Linux to brick those laptops. And to figure that out, first of all you need to figure out what triggers that bug. Unfortunately in this case the triggering of that bug means you're destroying a perfectly good piece of hardware.
Only when you know exactly what causes a bug, can you start figuring out how to fix it. The problem seemed to be Linux related - now it's proven that is not the case, the actual bug is in the UEFI. It's not a Linux bug, it can be triggered using any OS. Windows software may do this as well - and I can really think of people wanting to write data into UEFI memory, particularly those in the malware/DRM business - and as a result bricking the machine.
And now it's up to Samsung to actually fix their UEFI firmware code.
Re:memo to hardware producers (Score:2, Informative)
Yes and no. I mean, yeah, it's a replacement for BIOS, but it's really not a version 2 in that it's a new design, as opposed to a rewrite of the old BIOS design. The 1981 IBM PC BIOS literally was the hardware driver layer for MS-DOS. That's all gone now, as is any use of the now-quaint CPU modes required by the DOS environment. The only way to get any of it back is by using a BIOS "compatibility module", an optional wedge of EFI application code that emulates classic BIOS interfaces.
EFI is designed to support some rather sophisticated application software running in the EFI environment using EFI as its only "OS". For example, Apple's recent Macs have a feature called "Internet Restore", which lets you install OS X over the Internet without physical media or even a restore partition. It's implemented entirely in their EFI firmware.
Re:memo to hardware producers (Score:5, Informative)
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).