User: Password:
|
|
Subscribe / Log in / New account

A pair of UEFI updates

A pair of UEFI updates

Posted Feb 2, 2013 18:05 UTC (Sat) by theophrastus (guest, #80847)
Parent article: A pair of UEFI updates

Over 24 hours and no deep insights (nor vituperationing) here??
(this looks like a job for captain-ignorance to attempt motivation)

So there's code that's been added to the ROM (or firmware or BIOS (or CPU microcode?)) of UEFI boxes that is the source of these restrictions ("enhanced security features"). In response to this so far we've had some cunning experts figure out a few ways around it; and a few others that seem to have at least partly capitulated to this obvious industry grab to restrict our hardware freedoms. Thus, (my moronic), question: why hasn't some vast linux genius (and i know they're out there) yet produced a patch to flash the BIOS to rid us of this scourge? ("because you moron! Intel has the microcode checking secret checksums that make this utterly impossible, you idiot!") [wink]


(Log in to post comments)

A pair of UEFI updates

Posted Feb 2, 2013 23:11 UTC (Sat) by dlang (subscriber, #313) [Link]

> why hasn't some vast linux genius (and i know they're out there) yet produced a patch to flash the BIOS to rid us of this scourge?

They have, it's known as coreboot and it completely replaces the motherboard BIOS

A pair of UEFI updates

Posted Feb 2, 2013 23:52 UTC (Sat) by Trelane (subscriber, #56877) [Link]

But can you program it in forth?

</joke>

A pair of UEFI updates

Posted Feb 3, 2013 0:16 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

No matter how much people keep saying this, it isn't true. The number of machines where coreboot provides a complete replacement for the system firmware is tiny. It'll generally have little to no support for anything beyond basic system functionality. It has almost zero support for TPMs. Support for modern GPUs is marginal, so it's unhelpful for most systems with integrated graphics. In almost every case it would be easier for you to hack your existing firmware than it would be to attempt to get Coreboot running, except you'll hit exactly the same problem you would with Coreboot - systems are unlikely to accept unsigned flash updates, so you'll need a physical SPI programmer to get it onto your system.

But let's imagine a future where system vendors do the additional work to get Coreboot up to scratch for their boards and ship it from the factory. How different would it be to the present day? Well, the good news is that you'd get the source code (hurray!). The bad news is that nothing else would be different. The systems would still be UEFI based. They'd still implement Secure Boot. You still wouldn't be able to reflash them with a modified version. There'd still be bugs that Linux would have to work around. It's a net win, but not a huge one.

A pair of UEFI updates

Posted Feb 3, 2013 0:24 UTC (Sun) by dlang (subscriber, #313) [Link]

hacking every version of every motherboards BIOS to disable secure boot would be considerably more effort than porting coreboot to each motherboard.

looking at just one version of BIOS for one motherboard, hacking the BIOS is less work, but once you get coreboot running, future changes are much simpler.

I'm not saying that either is a practical option (in addition to what you listed, the manpower required is unreasonable.

but the post I was replying to was asking why some linux person didn't just create a new BIOS version to solve this problem. They have, but they solution does not run on many systems.

A pair of UEFI updates

Posted Feb 3, 2013 0:32 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

Nonsense. There's somewhere in the region of 6 secure boot implementations in existence, and most of those are probably based on Intel's. Decompress the firmware image (which is in a conveniently documented format), identify the code block containing the security policy, flip the value, regenerate the checksums, put it back together and then leave it up to the user to figure out how to actually flash it. I can promise you that this is easier than figuring out how a given board's embedded controller is supposed to interface with anything.

A pair of UEFI updates

Posted Feb 3, 2013 0:43 UTC (Sun) by dlang (subscriber, #313) [Link]

now you have to do that not only for every motherboard, you have to do it for every BIOS revision released for that motherboard. And when new BIOS updates are released, you have to re-do the hack.

you are talking as if the secure boot is a nicely delineated chunk of the BIOS, when everything is just the optimized binary blob, the location of this chunk may vary from BIOS to BIOS.

the source code implementations may be few, but the resulting binary chunks will vary a lot more.

A pair of UEFI updates

Posted Feb 3, 2013 0:55 UTC (Sun) by mjg59 (subscriber, #23239) [Link]

"you are talking as if the secure boot is a nicely delineated chunk of the BIOS, when everything is just the optimized binary blob"

That hasn't been true for a long time. It's completely untrue when it comes to UEFI.

A pair of UEFI updates

Posted Feb 3, 2013 5:23 UTC (Sun) by theophrastus (guest, #80847) [Link]

Thank you both. (i think we always learn more watching a spirited discussion than if everyone just tediously agrees)

i lost track of LinuxBIOS and am glad to see that work on it continues. of course, i was thinking more of an unlikely... -patch- to remove, or jumper around, UEFI, instead of the full nuclear option; but that might be the only way in the final analysis. as long as hardware makers are willing manufacture to suit a narrow, (yet fat), market.

A pair of UEFI updates

Posted Feb 3, 2013 11:22 UTC (Sun) by khim (subscriber, #9252) [Link]

You can not "jump around" UEFI because it's the only thing there is.

BIOS is emulated on top of UEFI, not the other way around. Which means that all the hardware is initialized in the UEFI.

A pair of UEFI updates

Posted Feb 5, 2013 9:30 UTC (Tue) by rvfh (subscriber, #31018) [Link]

Reminds me of all the modified firmware for DVD players to nuke the region and macrovision... We used to flash anything off the net at the time :-S


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds