Weekly Edition
Return to the Announcements page
| |||||||||||||
A pair of UEFI updates
Matthew Garrett has posted a summary of currently-known
problems with UEFI-based machines and Linux. "Some Lenovos will
only boot Windows or Red Hat Enterprise Linux. I recommend drinking,
because as far as I know they haven't actually got around to doing anything
useful about this yet."
Meanwhile, James Bottomley has put up a report on his work with the Linux Foundation's secure boot loader. "The upshot of all of this is you can now use Pre-BootLoader with Gummiboot (as demoed at LCA2013). To boot, you have to add two hashes: one for Gummiboot itself and one for the kernel you’re booting, but actually this is a good thing because now you have a single security policy controlling all of your boot sequence. Gummiboot itself has also been patched to recognise a failure due to secure boot and pop up a helpful message telling you which hash to enrol." (Log in to post comments)
A pair of UEFI updates Posted Feb 2, 2013 18:05 UTC (Sat) by theophrastus (guest, #80847) [Link]
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]
A pair of UEFI updates Posted Feb 2, 2013 23:11 UTC (Sat) by dlang (✭ supporter ✭, #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 (✭ supporter ✭, #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 (✭ supporter ✭, #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
A pair of UEFI updates Posted Feb 3, 2013 22:25 UTC (Sun) by tonyblackwell (subscriber, #43641) [Link]
James Bottomley gave a very informative LCA2013 look into ways of dealing with this. In terms of the practical issues (how do we live in the hardware world we are in, how do we install linux on W8 UEFI secure boot systems?) he seems to be most of the way there. See his blog - I think there should be signed binaries available in the next week or 2 if I understood James correctly.
Lenovo now looking into the problem? Posted Feb 4, 2013 8:47 UTC (Mon) by jmayer (subscriber, #595) [Link]
Down in the comments of mjg's blog entry is a remark by somenone who claims to be of Lenovo's support that they are now looking into the problem.
Lenovo now looking into the problem? Posted Feb 4, 2013 14:03 UTC (Mon) by bersl2 (subscriber, #34928) [Link]
Yes, and they also replied to @mjg59 a while back on Twitter as well about it. But you'd think that a string comparison would be easy to find and remove.
I'm with mjg on this, and then some: I've given up on UEFI working on this generation of Thinkpad. As long as BIOS emulation remains viable, my laptop boots to Linux. Fix it next time, Lenovo.
|
|||||||||||||