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

lucas_maximus,

"As I said ... there will be shitty manufacturers that would give you this option ... where they don't care about their customers ... and there will be those that do. That is my answer to your question."

No, you didn't answer my questions.

I get the impression that you don't care that secure boot has the potential to harm linux adoption. If that is your opinion, then ok, you are part of the majority of people who may very well remain unaffected by this change. It is true that linux users are a fraction of the market.

However, you cannot reasonably dismiss the concerns of hardcoding MS keys into the bios on behalf of those of us who are regular linux users at home. We are the ones affected by this change, even if you are not. We don't want artificially restricted hardware, new or used, that prevents us from running our OS of choice. The vast majority of us started by running linux on a previously windows machine. Microsoft still hasn't addressed whether dual booting will be possible. It isn't at all unreasonable for us to object when our interests are at stake, even though yours are not.

I'll ask once again: If it were up to you to design an ideal secure boot feature, would you design secure boot by hardcoding exclusive MS/OEM keys into it? Or would you enable the owner to override those keys?

Seeing as you keep avoiding the question, I'll take the liberty of answering it for you: It depends on who the feature is being designed to protect, microsoft or the owner.

Reply Parent Score: 3

lucas_maximus Member since:
2009-08-18

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:
2011-01-28

lucas_maximus,

"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:
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