Linked by Howard Fosdick on Thu 6th Dec 2012 05:26 UTC
OSNews, Generic OSes With computers now shipping with UEFI Secure Boot enabled, users of any OS other than Windows 8 will want to know how to circumvent it. Jesse Smith of DistroWatch tells how he did it here. The Linux Foundation describes its approach here. If you want to boot an OS other than Windows 8, you'll want to figure this out before you buy that new computer.
Thread beginning with comment 544413
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Fedora Shim
by Alfman on Thu 6th Dec 2012 15:20 UTC in reply to "Fedora Shim"
Alfman
Member since:
2011-01-28

Brendan,

"I think Fedora are also planning to create a 'shim'. The basic idea is that it's signed with Microsoft's key, and boots other boot loaders."

It's not exactly that simple. Because of the way secure boot was designed (for 3rd party control rather than security), it cannot pass control back to users without compromising security.

Consider that malware could exploit this and install the unrestricted bootloader (signed by microsoft's key) and then install a backdoor through the unrestricted bootloader. This would break secure boot's security on every secure boot desktop in the world and not just your desktop. Now MS would be forced to admit that secure boot is permanently broken, or it would revoke Fedora's key and break legitimate linux installs everywhere.


This is another reason I hate microsoft's secure boot design. Even if they had the best of intentions, it creates a single point of failure. One bug or leak breaks everybody's secure boot security worldwide. It just reaffirms how secure boot has been designed for 3rd party control rather than security.


The shim you referred to can only run locked down versions of linux running signed components. It's probably ok for normal users, but it's not the same free/open linux kernel that we're fond of. We'll become dependent upon Fedora provided kernels, and they'll become dependent upon MS, all so that home users can dual boot a restricted linux on their own machines.

Reply Parent Score: 8

RE[2]: Fedora Shim
by bornagainenguin on Fri 7th Dec 2012 05:53 in reply to "RE: Fedora Shim"
bornagainenguin Member since:
2005-08-07

Alfman posted...

This is another reason I hate microsoft's secure boot design. Even if they had the best of intentions, it creates a single point of failure. One bug or leak breaks everybody's secure boot security worldwide. It just reaffirms how secure boot has been designed for 3rd party control rather than security.


Which is exactly why the hacking scene needs to get on breaking this single point of failure as hard and spectacularly as they can, then release something that crashes every system running "secure boot" in such a way to make it clear that it is worse than useless at what it was ostensibly designed to do. Better yet it needs to crash the hardware in such a way the OEMs are liable and it costs them enough pain they instinctively shy away from any future types of such systems. Maybe then it would make the whole thing go away again...

--bornagainpenguin

Reply Parent Score: 5

RE[3]: Fedora Shim
by ssokolow on Fri 7th Dec 2012 13:01 in reply to "RE[2]: Fedora Shim"
ssokolow Member since:
2010-01-21

Alfman posted...
"This is another reason I hate microsoft's secure boot design. Even if they had the best of intentions, it creates a single point of failure. One bug or leak breaks everybody's secure boot security worldwide. It just reaffirms how secure boot has been designed for 3rd party control rather than security.


Which is exactly why the hacking scene needs to get on breaking this single point of failure as hard and spectacularly as they can, then release something that crashes every system running "secure boot" in such a way to make it clear that it is worse than useless at what it was ostensibly designed to do. Better yet it needs to crash the hardware in such a way the OEMs are liable and it costs them enough pain they instinctively shy away from any future types of such systems. Maybe then it would make the whole thing go away again...

--bornagainpenguin
"

Shouldn't be too hard when you have a modular firmware that's essentially an OS unto itself. (as complex as an OS kernel, high-level programming interface, standard library of helper functions, its own drivers for things like the network card, facilities for storing what (depending on the vendor) could potentially be megabytes of data in on-motherboard non-volatile storage, etc.)

I'm hoping for the day when a piece of malware comes out that waits for its creator to inform it of a 0-day exploit, then exploits Windows and UEFI to set up shop as a UEFI rootkit and resist all attempts to remove it without desoldering the flash chip and replacing it.

It'd be a fiasco worse than the Intel FDIV bug and it's completely possible because:

1. Every motherboard manufacturer is using Intel's reference implementation of UEFI with their own modules added in. It's effectively a monoculture like Windows. Hardware variations don't really matter.

2. They discover new bugs in the reference implementation quite often. It's like Windows in that way too.

Edited 2012-12-07 13:11 UTC

Reply Parent Score: 5

RE[3]: Fedora Shim
by Alfman on Fri 7th Dec 2012 15:55 in reply to "RE[2]: Fedora Shim"
Alfman Member since:
2011-01-28

bornagainenguin,

Implementation bugs can be a problem. I was actually referring to how we effectively have one key (microsoft's) controlling the hardware/firmware secure features on every consumer computer from now on is an inherently poor security design. This is not something a competent standards security engineer could have signed off on unless there were ulterior motives. Of course they were working for microsoft so there you go.

I agree that finding an implementation vulnerability will be an embarrassment, but realistically what do we think will happen? I believe they'll just fix the implementation & release patches, and then continue down the same path.

Edited 2012-12-07 16:00 UTC

Reply Parent Score: 3