Matthew Garrett Has a Fix To Prevent Bricked UEFI Linux Laptops
hypnosec writes "UEFI guru Matthew Garrett, who cleared the Linux kernel in Samsung laptop bricking issues, has come to rescue beleaguered users by offering a survival guide enabling them to avoid similar issues. According to Garrett, storage space constraints in UEFI storage variables is the reason Samsung laptops end up bricking themselves. Garrett said that if the storage space utilized by the UEFI firmware is more than 50 percent full, the laptop will refuse to start and ends up being bricked. To prevent this from happening, he has provided a Kernel patch."
more than 50 per cent full = fail is bad and Samsung needs to come out with a bios update to fix that.
So all I have to do now is checkout the latest git, build the right kernel with the right drivers and replace the one in the laptop's protected storage area. There are probably 5 persons capable of doing this on their bricked laptops.
n/t
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
---The UEF Interface seems to work just fine with Win OS and iOS. How is that a bios problem?
Samsungs implementation of UEFI is the problem, not the UEFI specification. No, it's not a 'bios' problem, UEFI replaced bios, but Samsung seems to have done something odd in their implementation of UEFI.
"---Gee wonder why the great mass migration to Linux hasn't happened?
Well sure, that has always been an issue. Linux apparently isn't important enough for companies to bother testing for it, which means it only works with contrived hacks, which means no one uses it, which means companies don't think it's important enough to bother testing for it.
Just sue on the small claims court.
You pay like 35 pounds to issue the legal challenge, and you almost automatically win because the problem is due to a defective product.
Samsung on the other hand will have to show as represented by some lawyer, and has to pay everything.
If it doesn't show, they will get a decision by default, which is almost the same...
Why do you think companies do replace items like that instead of flatly refusing?
Because they can't afford the bad publicity and the continuously court auditions.
Besides, don't even try to do a class action... is way more fun to have the company to run amok between 1000 court rooms almost at the same time...
BTW i'm not a lawyer and this is not legal advise. :)
The UEF Interface seems to work just fine with Win OS and iOS. How is that a bios problem?
http://www.pcworld.com/article/2027819/not-just-linux-windows-can-brick-samsung-laptops-too.html No bad on Windows too.
Please don't quote other peoples comments as fact, I suggest you check out the reply to it.
As for the Mass Migration to Linux, that happened with Android, which is set to become the most installed OS this year.
You can sometimes on many "bricked" devices like linksys router bricks after borking a dd-wrt install
and on the samsung laptops as well by playing with the jtag
http://en.wikipedia.org/wiki/Joint_Test_Action_Group
most stuff has jtag support and in some cases you can use the jtag header to unbrick a device.
I've unbricked an old WRT54GL after a screwup I did on an older dd-wrt install few years ago using jtag.
it's not something a normal user would be able to do or have confidence in doing, so yea in most cases the normal user will never unbrick.
It's been demonstrated that this bug can be elicited from Windows as well. And Windows expects to be able to write even more info than Linux was. Linux was just the first to expose the problem by trying to use UEFI variables to hold kernel panic info (Apple does something similar). IT didn't help that the UEFI driver itself caused the kernel panic, after which the kernel writes some debug log info to the UEFI to support later postmortem analysis.
The fix is in the wrong place. Is basically broken hardware, something that run as root/admin (intended or not) could brick them at any time. Is a problem just waiting to happen, avoiding them is the right solution.
procedure. Some ARM chips have bootstrap code that will talk to a usb device (i.e. looks like a serial port, sort of), and there is a program that lets you load the initial software no matter what's in flash. That usb port might just be a header or a bunch of pads on the cpu.
With other devices you have to go into a jtag port, (i.e. a header or perhaps just solder pads) load a tiny program into ram, and use THAT to program the flash.
If they build them with empty flash, there has to be a way to do the initial load. If they build them with programmed flash, it might not be possible without unsoldering the flash chip(s) or something like that.
Third time apk spam has gotten through my HOSTS file. PROOF apk is a liar yet again!
Seriously. Anything they can write code for will be buggy, insecure and crap.
Obviously APK filled his hosts files with backdoors before distributing them to ensure he doesn't block himself.
If they can, they weren't bricked in the first place. That's what "bricked" means.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
You have got way too much time on your hands.
In the free world the media isn't government run; the government is media run.
According to Garrett, storage space constraints in UEFI storage variables is the reason Samsung laptops end up bricking themselves.
Is? Is?
systemd is Roko's Basilisk.
I never knew that thats what JTAG stood for. Sounds much cooler than "debugging interface", more like its a team of crack hackers who spend their friday nights chilling with the DevGru (Seal Team 6) guys.
---The UEF Interface seems to work just fine with Win OS and iOS. How is that a bios problem?
Perhaps a car analogy will help. Imagine there is a bridge that semi trucks hit when they try to go under, but a cars and pickups do not. Without more facts, one can't really say if the problem is that the trucks are too tall or the bridge is too short. In this case, they investigated and discovered the bridge was built shorter than the bridge building rules require. The short-term fix is to post "no semi" signs and use less-tall trucks to get to the other side. The proper fix is to jack up the bridge.
The patch announced today is the "less-tall truck".
It amazes me, because every system I've seen that uses UEFI introduces some pretty incredible epic failures across the board.
What really boggles my mind is that we had an awesome CLI based firmware environment eons ago going by the name of "Open Firmware" (or OpenBoot). Sun's boxes ran it, even Apple's old PowerPC rigs had an OF console accessible by CMD-OPT-O-F (if I'm not mistaken). OF really was pretty elegant and clean, more importantly it seemed to work really well.
Is there some reason Open Firmware hasn't been ported to x86 and placed into widespread use?
Why is it that we have to put up with this atrocity known as UEFI? It just seems like one of the most convoluted and horribly implemented systems. Kind of reminds me of the EISA days, actually, which left me screaming for a box with some sane firmware and a hardware architecture that wasn't explicitly designed to boot CP/M and DOS.
The name is a contrast to the Divided Test Action Group, which collapsed because of internecine squabbling that led to layoffs, punch ups in the parking lot and eventually drive by shootings.
Brian Damage, their former CTO, is currently serving fourteen life sentences in a SuperMax prison for a flame thrower revenge attack on the Floor 6.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Are you not seeing the insanity of avoiding errors caused by being 100% full by bricking the device at 50% full?
Reactor explosion timer destroyed. Reactor Explosion Uncertainty Emergency Preemption Protocol activated. This facility will self-destruct in two minutes.
Bricked for us means the customer can't do anything and it has to come back to us (the factory), and we've got to connect it up to our equipment and redo the initial load. If they're built with programmed flash, that means replacing a chip, which with modern manufacturing processes is a dicey operation.
If they can, they weren't bricked in the first place. That's what "bricked" means.
Yay! Can we get into an argument as to what bricked means?
I have a friend with a reflow station, so I can replace busted chips. So *your* hardware isn't *truly* bricked. Etc.
SJW n. One who posts facts.
Oh, golly. Samsung didn't fully understand the tech they're working with and implemented it in a braindead way that enters an embarassing failure mode almost immediately after hitting the market. Between this and /dev/exynos-mem I think I'll stop trusting Samsung with anything involving firmware for the time being...
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
No, the problem is that on the approach to the bridge is a sign "height limitation 3m", but actually the bridge has only 1.5m clearance. Cars still pass, but even the tiniest lorry will bump into it.
Please ban this idiot away with some regex magic!
Yay! Can we get into an argument as to what bricked means?
Yay! Let's make it a relative term. I've got a friend who's an idiot. For him, hitting the off switch "bricks" the phone, cause he can't figure out how to fix it from that state.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face