Guest post by The title is pretty much self-explanatory – oh UEFI. “You can read more of what is known at H-Online, but the short summary is this: Samsung’s UEFI implementation appears to be faulty. It was most likely tested with Windows only and found to work, but thorough testing with other operating systems doesn’t appear to have been a priority – or perhaps a consideration at all. At present, the bug appears to affect Samsung 530U3C, 300E5C, NP700Z5C, NP700Z7C, and NP900X4C series laptops; if you have one of those laptops, we recommend you exercise extreme caution if you have a need to boot into a Linux environment.”
Long time ago, around 2008 I experimented a similar issue with a Fujitsu-Siemens laptop.
I think the Linux distribution was Fedora, and somehow it destroyed my flash BIOS.
Luckly reflashing with the tools available at the support section from Fujitsu-Siemens did the trick and I got the laptop running again.
Given Samung’s runaway success with mobiles and tablets thanks to the largely open source Linux/Android/more .. I am surprised they gave such little or no consideration at all.
Even moreso, given their cooling of relations with Microsoft.
Its not clear where exactly the bug is I don’t think. This apparently happens on some machines without uEFI. The problem is that bad data is written to the NVRAM. The BIOS/UEFI then tries to act on it, and crashes. Clearing the NVRAM by removing all power, including the cmos battery, solves the issue.
This is just another example of why this all needs to be open source.
That wouldn’t solve a thing. Open source, closed source, doesn’t matter. Honestly, people seem to think that open sourcing something is some sort of cure-all. If the bug is in the Linux kernel or associated drivers (and I’d say that’s a good place to start since no other os has reported an issue like this) then the thing’s already open sourced, and look what good it did.
Its not a cure all. But it does make fixing broken things a hell of a lot easier. It also makes spotting errors before they have this affect a lot easier. Its a matter of practicality not morality.
In point of fact, it does not. How many open source projects are out there that actually concentrate on fixing bugs? Most of the time, the 80/20 rule plagues them, and they end up implementing more features rather than fixing anything. Debugging and optimizing are not fun and, since most people who work on open source software are unpaid, they do not usually want to do that which is not fun. Every open source project I can think of that does concentrate even somewhat on fixes (the Linux kernel, Firefox, Chromium) has commercial developers working on them and the fixes come from there. Contrary to popular belief, there’s not an endless supply of talented programmers willing to fix bugs in other peoples’ projects for free. Speaking of that, as the kernel’s Samsung laptop driver has been identified as the problem, you already have your wish for this bug to be in an open source component. Again I ask you, what good did that do?
In this case it is a paid developer. Garrett worked for Red Hat until recently and he is the one in charge of uEFI for Linux. Its not just the driver that needs to be open source, but the BIOS too. Thats the whole point to UEFI. To standardize the way these machines work so its not just a guessing game.
But as a Linux hater you missed the point completely. Open source isn’t magically less buggy. It also doesn’t magically grow developers. But it does allow you to fix what is broken. Whens the last time you were able to patch Windows to fix a bug on your own. Oh thats right, NEVER!
Edited 2013-02-02 21:12 UTC
It would. The problem here is not the kernel code but understanding what on Earth this silly device is doing. If the source for that was known this would be a thread on the kernel list with some commits at the end for both the kernel and firmware.
Open source software is not the solution to everything. Open source software does not even come remotely close to guaranteeing anything works any better, and in many cases works worse (if it works at all).
If it’s not a complete lack of knowledge and/or experience, I seriously don’t understand why some people think open source software is some magical thing that somehow makes everything easier and/or better.
They have faith in the idea that there exists a limitless supply of genius problem-solvers who have the patience to solve the problem but not the patience to reverse-engineer object code to figure out what it’s doing.
A bit hyperbolic, but I don’t think having access to the source ever hurt troubleshooting efforts.
I guess that means people with these laptops would be best off using virtual machines.
It is defective and they need to either correct the mistake at their cost and pay a bit more for your troubles or you should be able to return the defective laptop.
In this case, since Linux is the only os to suffer this, I’d venture to say that the os is defective and not the laptop.
I would love to know why you got voted down.
It does seem likely at this stage that you are correct.
Edited 2013-02-02 16:23 UTC
Oh, come now, you already know why. I dared to criticize the amazing, wonderful, cannot possibly have any bugs, everyone should use it Linux. It’s not cool to do that, even when it’s true.
You probably got voted down for being a troll. If you bothered to look through the links, you would see that even if that driver were the problem, it was provided by Samsung. Second, its not the driver itself as much as the way that the driver interacts with the totally non standard way Samsung handles the BIOS. Like I mentioned above, writing to non permanent memory should not be able to brick a laptop.
It is still not fault UEFI is it? Which is what Thom was complaining about.
Edited 2013-02-03 16:21 UTC
Its not the fault of UEFI in general. The problem lies with Samsung and the way they handled things on certain laptops. Poor execution rather than poor design.
Because, as usual, neither he nor you read.
The problem here is the device itself is doing things that only Samsung truly knows about, and it diverges away from any kind of reasonably expected behaviour. It’s ACPI all over again. The Samsung kernel code was also built from Samsung’s own code and yet it still fails.
Edited 2013-02-03 21:57 UTC
No, its not the OS. If you read here:
http://mjg59.dreamwidth.org/22028.html
You will see that the cause of the problem is the arcane way Samsung handles the BIOS. If your software uses the same memory region that Samsung’s laptop thinks it should be using, you end up with corruption. Software writing to a non permanent memory should NEVER be able to brick your PC, regardless of the OS.
I’ll just chime in that the culprit is actually Samsung’s UEFI-implementation. Their implementation doesn’t follow the spec properly and handles some corner-cases in an unexpected way. Specifically, it apparently expects a 104-byte structure whereas Linux provides it with a standards-compliant 1024-byte structure and therefore it proceeds to crap all over itself and corrupt NVRAM. The odd thing is that most of the driver-code was provided by Samsung themselves.
Later on it the thread someone said that emptying the NVRAM is enough to fix some (all?) of the affected machines, but it still requires you to open the laptop and removing the NVRAM-battery for 30 seconds or disabling it otherwise if it’s soldered-on.
No need to look for a conspiracy against Linux here, really. When the UEFI and ACPI specs weight around 3000 pages together, it is to be expected that this kind of stupid bugs will emerge at some point. No human developer can implement something so horribly convoluted without making major mistakes at some point.
Sometimes I wish to know what happened to the people at Intel who wrote stuff like the MultiProcessor (MP) Specification of x86. You now, those fine-grained specs which focus on a small number of real-world problems, solve them well in a future-proof way, and explain the result clearly.
Perhaps that’s just the difference between Intel’s and Microsoft’s approaches to design, though. After all, the latter company is known for liking huge monolithic specs, and it seems to me that they had a strong influence on the development of UEFI. There are several design choices which make no sense otherwise, such as the use of PE executables – which only Windows natively uses – for kernel binaries, or the whole “one platform key to rule them all” Secure Boot concept.
Edited 2013-02-02 07:27 UTC
While people like to finger pointing to Microsoft, the company is no different than any other corporation.
Since 1999 I work for multinational enterprises and I have learned that you only interoperate if it is really required to do so. You don’t do that to be nice.
Why don’t they make sense? When Microsoft created them, each platform had their own format, most of them didn’t support dynamic linking and resource embedding.
The ELF format used by Linux didn’t originate with Linux. It was developed as a standardized cross-platform binary format.
The Wikipedia page doesn’t give a date, but given the age of the citations, It’s been around since at least 1995.
Here’s a reformatted copy of the Wikipedia article’s list of platforms which use it:
UNIX/Unix-like:
– Linux
– FreeBSD, NetBSD, OpenBSD, DragonFlyBSD
– Solaris, HP-UX, IRIX
– Syllable
– QNX Neutrino
– MINIX
Non-UNIX:
– OpenVMS for Itanium
– BeOS r4+, Haiku
– AmigaOS 4, MorphOS, AROS
Game Consoles:
– Playstation 2, 3, and PSP
– Dreamcast
– Gamecube, Wii
– GP2X
Mobile Devices:
– Samsung Bada
– Symbian OS v9 (sort of. E32Image is based on ELF)
– Sony Ericsson W800i, W610, W300, etc.
– Siemens SGOLD and SGOLD2 platforms
– Motorola E398, SLVR L7, v360, v3i, etc.
Microcontrollers:
– Atmel AVR (8-bit)
– Texas Instruments MSP430
If that’s not a de facto standard among everyone except Microsoft and Apple, then nothing qualifies.
As far as I can tell, Microsoft PE, Apple Mach-O, and the XCOFF format used in AIX are literally the only significant formats that haven’t been deprecated in favor of ELF.
I may be mistaken, but even if XCOFF was developed by IBM for AIX, I think it is a binary executable format that is to some extent compatible with PowerPC based hardware, such as Powermacs. And Mach-O became standard on OS X because it is inherited from NeXT, and was ultimately developed (along with the Mach microkernel) at Carnegie Mellon University.
I’m not sure I understand your intent in saying that. (As phrased, it feels like a bit of a non sequitur)
Yes, XCOFF is PPC compatible. According to the Wikipedia page, it was used by early versions of PPC MacOS and BeOS.
It’s an interesting bit of history, but it doesn’t really say anything good about the format since BeOS apparently switched to PE in r3 and then to ELF in r4 and beyond and, as far as I can tell, Apple invented PEF before switching to Mach-O for OSX.
As for Mach-O, definitely an interesting bit of history (I never thought to look up what NeXT used) but not really a persuasive statement.
Mach-O has a 256-entry limit on arbitrary sections that ELF doesn’t and ELF has a proposed extension for fat binaries that would probably be standard by now if any OS that used ELF saw it as more than just a way to waste disk space to make up for lack of a package manager.
Edited 2013-02-02 18:46 UTC
So what?
The PE format was introduced with Windows NT in 1993 before ELF appeared.
The first document describing its format is dated from 1994.
What is the business value for Microsoft to bother to change to ELF?
The point wasn’t about Microsoft switching to ELF from what they’re already using (though many of the OSes I listed did).
The point is that using PE for the successor to BIOS as opposed to ELF is an indication of how much input Microsoft had on the spec.
Heck, PE is a variation on the COFF format many of the UNIXes on that list switched away from.
Edited 2013-02-02 18:41 UTC
That’s what I meant, indeed.
Of course, Microsoft are free to use their own executable format in their OS if they want to, and they had reasons to create it back when they did.
But when pretty much everyone else has standardized on ELF, it sounds a little silly to have the successor of BIOS only support PE executables for kernel images. Unless you consider it as a design decision specifically taken so as to please Microsoft, of course.
Microsoft are not necessarily the only one to blame there either. I’m extremely curious of how decisions are taken in the UEFI committee, if nonsense like that can make its way into the spec without being subjected to some third-party scrutiny first. A careless feature inclusion process might also explain how this spec ended up becoming the huge monster that it is.
Edited 2013-02-03 10:56 UTC
Heh. Interesting that you equate a new hardware platform, that should have nothing to do with the operating system, with business value to Microsoft.