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 490716
To view parent comment, click here.
To read all comments associated with this story, please click here.
Alfman
Member since:
2011-01-28

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