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.'"
memo to hardware producers (Score:5, Interesting)
Embrace Linux as an additional test suite for your hardware.
Re:memo to hardware producers (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.
Re: (Score:2)
Re:memo to hardware producers (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.
Re: (Score:3)
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
Re: (Score:2)
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.
Re: (Score:2)
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)
[...] 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
Re:memo to hardware producers (Score:5, Funny)
Well, yeah, that's why you have to force them. They're not going to brick their hardware voluntarily, are they?
Re:memo to hardware producers (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
Re: (Score:3)
Luckily, the whole "cause havok for the heck of it" virus craze kind of died out years ago.
If theres no money to be had, theres no real threat except from people you know "pranking" you.
Re: memo to hardware producers (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.
Re: memo to hardware producers (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.
Re: memo to hardware producers (Score:4, Insightful)
[..]
I'm going to pick option B however, where RMAs for the model are denied because everyone knows those users destroyed their hardware using that nasty Linux program, and they're not going to get a replacement or refund at all.
[...]
In case you didn't RTFS: The laptop was bricked by using a program running on Windows.
Re: (Score:3)
You think there are a significant number of repair places who routinely pull hard drives from dead devices for forensic/cause analysis? If the idea is to suggest there are smart bean counters, I guess that's no more silly.
If my goal were to prove Linux is responsible for the problem, regardless of reality--which is the idea I'm parodying here in case you're not sure--I would brick one using a live CD. In an ideal situation for Samsung, not only would they not give the RMAs out, asking for one due to this p
Re: (Score:3)
Re: (Score:3)
Because no one on teh Internets ever does something for the lulz. And just to make a political/economic point by trashing something or raising a bit of hell.
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.
Re:memo to hardware producers (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).
Re: (Score:3)
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.
Re:memo to hardware producers (Score:5, Informative)
Re: (Score:2)
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.
Re: (Score:3)
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.
Re: (Score:3)
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.
Re: (Score:3)
What does UEFI do that coreboot doesn't other than Secure Boot?
Re: (Score:2)
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.
Re: (Score:3)
I am sure there is a BIOS writer somewhere who is a proficient assembly guru. I have never had the chance to use any system he wrote code for.
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).
Re:memo to hardware producers (Score:5, Interesting)
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.
Re: (Score:3)
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
Re: (Score:3)
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.
Re: (Score:2)
Modern EEPROM can be written to on the order of up to 1 million times before failing. However, at the same time, modern defective kernel modules can spam kernel messages fast enough to make me weary of simply streaming the kernel log straight to EEPROM :)
Re: (Score:3)
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.
Re:memo to hardware producers (Score:4, Funny)
How about a warning sticker?
"Warning: UEFI Inside!"
Re:memo to hardware producers (Score:4, Interesting)
"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.
Re:memo to hardware producers (Score:4, Insightful)
Linux runs happily on all sorts of crappy hardware because somewhere, at some point, a linux dev did a lot of heavy lifting to make that happen, not because linux magically works with all hardware.
Re: (Score:3)
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.
Re:memo to hardware producers (Score:5, 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.
They didn't get the memo (Score:4, Funny)
it writes out 36 variables each containing a kilobyte of random data
36k clearly isn't enough for anyone.
Re: (Score:3, Informative)
Re: (Score:3)
Does windows crash if it has 0 temp space or 0 ram (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
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
Re:Does windows crash if it has 0 temp space or 0 (Score:4, Interesting)
Re: (Score:2)
Re: (Score:2)
Which is far better than this UEFI issue as Windows while misbehaving doesn't crash, and can actually be recovered (and if you don't know how, a simple reboot will fix it ).
Re: (Score:2)
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.
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: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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.
OS boot entries are in NV storage (Score:4, Interesting)
Extortionist Heaven (Score:2)
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.
Re: (Score:2)
Why does this only affect Samsung computers? Did they do something extra stupid to the UEFI in their computers that other vendors didn't?
Re:Extortionist Heaven (Score:4, Interesting)
Re: (Score:2)
Re:Extortionist Heaven (Score:4, Insightful)
Re: (Score:3)
That would imply that this bug may be present in many/most/all UEFI implementations, with others merely having higher limits.
It als
Re: (Score:2)
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'
Re: (Score:3)
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
Re: (Score:3)
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? (Score:2)
buffer overrun? and when the storage gets full it starts to over write other config data with junk.
Re: (Score:3)
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
Forgot one detail... (Score:3)
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
Re: (Score:2)
Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4 ...I'm sure someone will hit it (even now :-).
Re:Forgot one detail... (Score:5, 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?
Re: (Score:2)
That's Ctrl+Alt+F4
Re: (Score:2)
That would be Virtual Terminal (VT) 4, not Desktop 4.
Re: (Score:2)
Alt F4 is still wrong though. It's still the "quit" function. I tested it on a linux box.
Re: (Score:3)
Only for you people using a GUI. Real men read Slashdot from a text console with lynx. Insane people read it with telnet and a script to parse the HTML for text mode viewing. I hear even RMS has started using graphical web browsers on occasion, so I guess that trick may work on him now. :)
Re: (Score:2, Funny)
Don't forget about telling noobs about the great warez site at 127.0.0.1.
Re: (Score:2)
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.
Sample C code has implementation-defined behaviour (Score:2)
(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
Hm. Good supply of refurbs? (Score:3)
Old recipe (Score:3)
Re: (Score:3)
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
Difference between Windows and Linux developers: (Score:4, Insightful)
The Linux folks actually read and understand the documentation and then use the mechanisms described. The Windows-folks are usually not so capable.
Re: (Score:2, Informative)
Re: (Score:3)
Unfortunately not in this case.
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: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:Unlimited Supply of Laptops? (Score:5, Interesting)
30-day hassle-free return policy.
Re:Unlimited Supply of Laptops? (Score:5, Funny)
I might be confused, but don't kernel devs normally destroy their instruments at the end of each show?
Re: (Score:3, Funny)
Re:Unlimited Supply of Laptops? (Score:4, Funny)
I might be confused, but don't kernel devs normally destroy their instruments at the end of each show?
Well, when on the Ed Sullivan Show, they have been known to pack explosives into the drum memory.
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: (Score:2)
Re: (Score:2)
Sorry, but if removing the battery or otherwise resetting the NVRAM to factory defaults resolves the issue, that's not even remotely "bricked".
Non-Volatile Random Access Memmory
Look up the first part and you'll figure out why removing the battery won't fix it.
Re: (Score:2)
Sorry, but if removing the battery or otherwise resetting the NVRAM to factory defaults resolves the issue, that's not even remotely "bricked".
Non-Volatile Random Access Memmory
Look up the first part and you'll figure out why removing the battery won't fix it.
"Or otherwise". Even though they were wrong about it not being bricked in this instance, to be fair the AC wasn't completely clueless. Some hardware includes procedures to recover from bad NVRAM data.
Re: (Score:2)
---
Some systems have a small reset switch on the motherboard for this purpose that is supposed to reset it to factory default when removing the battery [which might only be used for the system time-of-day clock chip] wouldn't work.
Whether the UEFI data is being stored in the CMOS area, or,
Re:Free Laptops? (Score:5, 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.
Re: (Score:2)
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: (Score:3)
Re: (Score:2)
Samsung was claiming this is a Linux problem. This needs to be shown to be either a problem with UEFI directly or Samsung's implementation.
The important thing here is that this bug may exist in other hardware with different thresholds. UEFI is just like BIOS in that the only difference between a Phoenix Bios on Dell and a Phoenix BIOS on Samsung is a couple minor changes because of hardware differences. By releasing the code into the wild they are FORCING the parties responsible to fix the problem or face a
Re: (Score:3)
Indeed. I suspect the only reason we see UEFI in practice are Microsofts desperate attempts to slow the spread of Linux by making it to hard to install it for the average user. That "secure boot" is everything but secure has been adequately demonstrated already. That Microsoft has tried despicable and immoral practices like this before is also well known.