How to survive a UEFI BOOT-OF-DEATH on Samsung laptops Former Red Hatter Matthew Garrett, who cleared Linux's name when the open-source kernel appeared to cause shiny new Samsung laptops to destroy themselves, has offered a survival guide to avoid similar catastrophes. Nebula programmer Garrett this week warned that Samsung laptops may brick themselves if the computer's UEFI …
From what I have been reading on this it sounds more like they have the replace the board because the CMOS gets boinked. Yes I know its UEFI but it does seem that theres either a flaw in the coding for this or something Samsung introduced. My guess its a mix of both due to Samsung is always finding new things to do all the time to stay bleeding edge. I may have missed it but I cant wait to see what the ultimate fallout from this is.
Could be wrong on my guess but something tells me Im probably on the right track
They don't follow the UEFI specifications. They let the firmware do crazy data rewrites in a nonsense fashion.
UEFI clearly has some serious design issues itself BUT manufacturers engineers and programmers nowadays seem a bunch of novice college students if not little kids.
Where are the real BIOS programmers ? They fired all of them with the economic crisis because they were too expensive ?
The IT sector is collapsing fast.. more and more dumb people promoting themselves as computer wizards and actually knowing very little if any at all.
Which is why you have a tiny rom which can do recovery like the (old?) cisco boxes where you could upload a new ios via kermit over a serial terminal connection.
I guess these days it would be "boot from USB" rather than onboard flash.
Icon: Lessons not learnt.
But that was not because these problems did not exist. It was for two reasons:
One, manufacturers bend over whatever is necessary to run Windows, so they never released anything that could remotely causes Windows any kind of trouble. Since a lot of releases ago, Windows basically ignores the BIOS after the first stage of booting, that is, takes over HW management on its own. And with the relatively slow pace of Windows releases, it was also relatively easy to make sure the machine booted.
Bear in mind that the BIOS from the original PC was cloned with a clean room implementation back in the days of PC compatibles fighting with IBM, but for a long, long time, standards were defined by the PC BIOS implementation.
That was if you lived in Windows land. In Linux land, kernel writers have always struggled with odd BIOSes, building compatibility tables with board IDs and all sorts of hacks, all because BIOSes were not that careful with complying with their specifications since Windows was not going to use them anyway.
The second reason is that not until long ago, the people that had to deal with those BIOS problems were a small minority of Linux users. Then Apple switched to Intel. And Google started to sell the Chromebook. And suddenly, it was not just Windows using the BIOS and finding what the Linux kernel developers had suffered during all that time. That's what created UEFI.
So now instead of having weird BIOS doing whatever they want -nobody can ask you to follow a standard when there isnt's one- but instead we have a weird UEFI implementations ignoring the standard.
Kelly Smith, who wrote the early Tandon clone-BIOS, and worked on Phoenix BIOS, died several years ago.
Not many of my old friends have survived the decades.. and the new generation of software programmers tend to work in a team... not as loners, solely responsible for whether their BIOS worked, or not...
>You've never used any of the more "creative" Award BIOSes, then -- or AMI's graphical abomination, then, I take it.
During some projects in the 80's and early 90's I had to get close to the BIOS for a couple of projects (OS's: DOS, Windows, OS/2, Novell Netware, SCO Unix, SunOS 386) but yes generally I just used a variety of PC's. But whilst I was aware of some compatibility issues and problems requiring BIOS revisions, I'm not aware of any problems in the same category as the Samsung UEFI brick the machine bug.
Given the nature of my work, yes it is unlikely that I used some of the more "creative" BIOSes, but then I didn't take much notice of the source of the BIOS in PC's from the variety of PC vendors targeting the business market who's systems I used.
How can you hate a BIOS which will allow you to surf youtube and farcebook without booting windows? Well mainly farcebook. Or how about how pretty they look and the ability to change the boot picture to whatever you want? Actually changed it on a friends laptop to a rather interesting picture of two guys.....the giggles the whole group of us gave him everytime he booted it up made me cry with laughter. Finally gave him a hint on how to fix it. Ahh i miss hanging out with those guys but sadly with two slipped disks in my back now I cant work, stand, sit, lay down or sleep very well anymore. God I hate having this issue at 31....
If you bought a Dell or HP and never added anything to it maybe.
Something like an ASUS motherboard BIOS would be FULL of problems for the first few versions, but even a Dell Optiplex 960 had a Display port that didn't work. With version 06 Bios it would work if you plugged in the monitor after Windows booted, it was not until version 08 of the bios that it would boot with a Display Port and VGA monitor plugged in.
Shouldn't Samsung be fixing their dodgy UEFI implementation instead? If the kernel gets patched to work around the issue doesn't that send a signal to Samsung that what they've done is ok and that the onus is on the software not to break the machine?
And if there's a way to do it on windows, how long before there's a virus out in the wild that exploits this?
Do Samsung care, have they even acknowledged the issue?
What do Samsung do when someone returns a bricked laptop (a) in and (b) out of warranty?
You can tell the manufaturers you want to do business with from the ones you don't, by how they handle a problem such as this one. You don't want to be told to <go away>, and to have to sue your supplier for supplying goods that were not fit for purpose. Which defition this bug amply fulfills: the machine claimed to offer UEFUI boot, but broke the specification in a way that causes catastrophic failure.
I'm asking, not suggesting anything. I really don't know.
Unfortunately, if the machine was sold with Windows pre-installed, then Samsung supplied "goods that were fit for purpose". That you choose to use them for a different purpose isn't Samsung's _legal_ responsibility, though it's obviously in their best interest to resolve the issue.
There's no question that Samsung is responsible for the bug, but it's not so clear that they are (legally) responsible if your actions actually trigger the problem.
Outside of the user accessible modes of the CPU the BIOS also loads the "service mode" which contains parts for emulating legacy devices for USB, so your operating system without USB support can still use your USB keyboard and mouse. There are lots of things that work that way.
In principle a "smarter BIOS" might be good. For example OpenFirmware can do some useful things like architecture independent device drivers (stored as Forth source code on the ROM of the device).
The main problems with UEFI are that it doesn't have the flexibility of OpenFirmware and that it's a huge mess about the same size of the Linux kernel. (without device drivers in both cases)
Damned if I know. I do know that in the experimentation of getting Linux onto a dual-drive Acer laptop recently, I removed the original windows drive to discover that Linux had (reasonably sensibly) re-used the existing Windows EFI partition, so it wouldn't boot; just the usual bios warning.
Reinserting the drive allowed me to boot into Linux (which was what I wanted) but the F2 to see the bios options hasn't been seen since...
This is because the low IQ, marginal competence UEFI programmers make assumptions on the OS that will be running on top of it, instead of just providing a reliable, standards compliant interface that would allow OS to handle the rest. UEFI is a serious matter but unfortunately it is being left to the same bunch of sub-brilliant programmers who have gave us wave after wave of half arsed BIOS implementations.
That phrase actually means "I just guessed."
One of my co-workers, before I retired, regularly messed up his programming. When asked "why did you do that?" while looking at some egregiously bad code, his reply was often "I assumed (such and such)."
Of course, his assumptions were usually wrong.
In fact, whenever he hit a tough bit of code to write, he'd often take the lazy way out and "assume" that nobody ever made a mistake, that you didn't need to be wary of user input errors, and other variations on avoiding hard thinking or, horror of horrors, going and asking somebody who knew what they were doing.
"I assumed (such and such)."
Which if I recall past reports was the case here. The events which filled the UEFI with 'crash data' or whatever, which then caused it to fail to boot, was brought about by a driver poking about in memory to try to figure what hardware was out there. Done on the assumption this was okay and would have no bad consequences.
The UEFI should not have been affected, the failing is ultimately in Samsung's camp, but it was this 'reckless poking' which provoked the UEFI to be filled and then crash and burn.
Agree with you except for the word reckless here. There is nothing reckless in allowing code to read and write to memory locations, after all this is how computers work and yes, it is a normal assumption to believe the UEFI code has been written by sane, competent programmers.
Yooowwwch!!
That's bad. And funny, too, since I do distinctly recall lots of people saying "Linux shouldn't brick the machine", and "Serves you right for running that OS"... or posts to that effect.
Now the truth is out, and it's buggy firmware after all. More to the point, the buggy firmware can be triggered from within the machine's native OS.
Not designed to run Linux you say? If this is the metric people measure that criteria by, then it's clearly not designed to run Windows either.
> More to the point, the buggy firmware can be triggered from within the machine's native OS.
STOP PRESS, shock, horror, the native OS can write to memory.
Sure the memory happens to be a peripheral, but I mean I don't honest get why people are making such a big deal of the OS which is running. It's just a memory address ...
This time it was not the Linux people who started this skirmish about the superior OS.
Now that we have proof that you can do that from Windows too, it's just like you say a memory address and we should not make such a big deal of the OS that is running.
AC 18:41 - Yeah. 'cos if the problem had been seen in Windows first Linux users wouldn't have been gloating. Just as they never have in the past. Too bad you whine when the tables are turned. If you can't take it, grow up and don't dish it out. And don't forget that achieving this effect from a custom app written for Windows isn't the same as the kernel driver doing it after an oops without the user telling it to. Does Windows do it? Dunno. Do you?
"Yeah. 'cos if the problem had been seen in Windows first Linux users wouldn't have been gloating."
Not to get into a game of who started what, but the entire blame and cause of the incident was Samsung and their bodged implementation of UEFI. This was patently clear to anyone reading the original article and yet it invited claims of "ooh, Linux is crap!" for spurious reasons.
This was never a Linux thing, and the only people who thought otherwise were ardent Windows fans.
"Not to get into a game of who started what, but the entire blame and cause of the incident was Samsung and their bodged implementation of UEFI."
I'll agree with that. So far so good.
"This was patently clear to anyone reading the original article and yet it invited claims of "ooh, Linux is crap!" for spurious reasons."
Actually, it wasn't spurious given the info in the article. Even the update on the article states,
"It's now thought the boot-time crash is linked to the Samsung UEFI firmware and its interaction with the kernel's Samsung laptop driver and efivars module."
All Windows have done is crow the same way Linux fans do in the reverse situation. My beef is that Linux fans can't take it, that's all.
"This was never a Linux thing, and the only people who thought otherwise were ardent Windows fans."
Until someone's PC is bricked out of the blue by another OS - well, yes it is. If I wanted to be fanboyish about it I could argue that Garrett has found a flaw which could do the same in Windows but hasn't, written something to make it happen and compared apples to oranges so he can say Windows might do it as well. Then the Linux club misinterprets it, wilfully or otherwise. Application != OS, after all. I'm not denying it's Samsung's fault, just wishing for a bit more maturity from people who are always first to point the finger when something blows up under Windows. But then I'm also wishing for a bazillion pounds.
AC with the long response - it was clear it was a Samsung problem. For *any* hardware to irrevocably brick itself due to the software running on it is a faulty bit of hardware, regardless of what the trigger point was.
My point is that if this were a laptop that bricked while running Windows, the story wouldn't even mention the OS. Even if it did, it would take a special kind of leap to blame Windows.
Bit disingenuous. From the first day it was obviously the interaction between Samsung's EFI implementation and Linux. People should be more careful about their usage of "first day" and "original article." As a fan, have you tested OpenFirmware on the same hardware/disitribution combo? People who have working PCs might like to know of an alternative?
Me? I'd go into a local retailer and arrange to brick every Samsung piece of kit I could find (handy little USB key in pocket). Wonderful demonstration it might be. The store puts a new one on display and in 5 hours, it too doesn't work. Maybe a big retail chain could make the proper complaint.
If it were only that easy!
Look, if Microsoft had its way, the BIOS would keep saying "Must...only...boot...Windows", which is what UEFI is all about anyway.
Gone are the days when you would dial the IPL device into the console and let it rip. It was much easier then, and you could even boot from Mag tape, or (showing my age) Punch cards.
it got broken because deep in someone's psyche, the fact registered that this was writable storage and could be updated.
i suspect that if the samsung's head of dev had been told, "this code will be immutably burnt into the next 4 million chips", and not "this chip is like a flash drive", quality might have been higher. Hardware companies tend to focus quite well when the prospect of a mass recall is on the cards.
"The effects of safe-guards on software quality" - there are a good few PhD theses in that topic, from psychology to CompSci.
And supposing the crash was due to a bug in the VFS or block device layer? You propose to use aforementioned VFS and block device layers to try and record a dump caused by a bug in the VFS or block device layers.
Yep, that'll work nicely … if your aim is to generate recursive loops.
NV-RAM isn't the best place, no, and it should not be a default, but rather something you turn on if you get problems. Provided data doesn't get corrupted by storing it there, it shouldn't brick the device either.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
