Linked by Thom Holwerda on Fri 23rd Sep 2011 22:22 UTC, submitted by kragil
Windows The story about how secure boot for Windows 8, part of UEFI, will hinder the use of non-signed binaries and operating systems, like Linux, has registered at Redmond as well. The company posted about it on the Building Windows 8 blog - but didn't take any of the worries away. In fact, Red Hat's Matthew Garrett, who originally broke this story, has some more information - worst of which is that Red Hat has received confirmation from hardware vendors that some of them will not allow you to disable secure boot.
Thread beginning with comment 490712
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

I won't comment on how to design such a system because I am not qualified to comment, and far brighter people than me have designed these systems.

Reply Parent Score: 2

Alfman Member since:


"I won't comment on how to design such a system because I am not qualified to comment, and far brighter people than me have designed these systems."

That's fine. But I actually do have the expertise to design such systems*. I have both theoretical knowledge of and practical experience with implementing PKI. Furthermore, I have first hand experience developing bootloaders from scratch on the x86, and I know exactly what goes on there. This topic is right up my alley.

For the moment, take my word that a secure booting facility could have been implemented generically to protect from bootloader malware without hard-coding MS/OEM keys into it. Assuming I am correct, then would you agree that that the inclusion of hardcoded MS/OEM keys is suspicious of an ulterior motive?

Edit: * No insult is intended by this, it just happens to be my domain ;)

Edited 2011-09-25 13:39 UTC

Reply Parent Score: 2

Alfman Member since:

It occurs to me that a lot of people may not understand how PKI based bootloader security works. So here is a quick overview:

At a high level, each subsystem in the bootsequence is responsible for authenticating the next piece. When UEFI loads the bootloader, it will compute a cryptographic hash against it and verify that it matches the hash in the bootloader metadata. This metadata is signed by one of microsoft's private signing keys. In order to maximize flexibility, these keys are themselves signed by one or more master keys (owned by MS/OEMs). It is these master keys which will be hard coded into the firmware.

So anyways, now the bootloader is verified to be microsoft's to the satisfaction of the bios, and the bootloader itself needs to load the OS kernel. The bootloader has full control of the system by this point, it's up to the bootloader to decide how to securely load the OS. The bootloader may implement it's own verification, or it can call upon UEFI to do it. Assuming both are bug free, then neither approach is more secure than the other, however placing the verification in the bootloader provides a lot more flexibility in terms of what it can do.

Once the kernel is loaded, the same general ideas apply to loading drivers. As for user mode apps, the situation is different, in theory the secure kernel should be able to run untrusted applications without risk of compromising itself, assuming the cpu+OS+drivers don't have any bugs.

Reply Parent Score: 3