Linked by Thom Holwerda on Wed 21st Sep 2011 22:06 UTC, submitted by kragil
Windows After the walled garden coming to the desktop operating system world, we're currently witnessing another potential nail in the coffin of the relatively open world of desktop and laptop computing. Microsoft has revealed [.pptx] that as part of its Windows 8 logo program, OEMs must implement UEFI secure boot. This could potentially complicate the installation of other operating systems, like Windows 7, XP, and Linux.
Thread beginning with comment 490313
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Comment by ronaldst
by lemur2 on Thu 22nd Sep 2011 05:53 UTC in reply to "RE[3]: Comment by ronaldst"
Member since:

Brenden, "Whether or not it's anti-user depends on who has the keys." Precisely. Some people here are assuming that the keys must be hard coded into the bios such that only operating systems approved by the vendors can be run. I really don't know if that is the intentions of UEFI secure boot or not...if it is, well users are screwed. Not only won't we have control, but now the security of our own computers becomes dependent upon third parties who control the master keys. Ideally this feature should be designed to work for users rather than against us. All keys could be manageable through the bios on powerup, and then remain locked after boot so they cannot be tampered with later on. Then we could use our own individual/corporate key to sign the keys of whichever OS vendors we want to trust on our computers or lans. Of course, for normal users, this would all be setup at the factory...but at least the control over which operating systems are allowed to run lies with us as users rather than the manufacturer or microsoft. Also there is another risk, that even if users can manage their own keys, a powerful vendor might coerce users to delete keys of it's competitors in order to load itself. Therefor I'd hope that this feature is designed in such a way that the list of approved keys can be kept secret from discriminatory operating systems.

According to Red Hat's Matthew Garret, the keys are stored as part of the system firmware.

"if we self-sign, it's still necessary to get our keys included by every OEM."

This says that user's don't have the ability to say what OSes they wish to boot, but rather the OEMs determine which vendor's OS the hardware can boot by including the OS vendor's key in the system firmware.

If OEM's historical record of lack of supporting Linux via ACPI is any indication, this isn't going to happen. Linux simply won't be bootable by any hardware with UEFI Secure boot enabled.

Edited 2011-09-22 05:59 UTC

Reply Parent Score: 3

RE[5]: Comment by ronaldst
by Alfman on Thu 22nd Sep 2011 06:16 in reply to "RE[4]: Comment by ronaldst"
Alfman Member since:


"According to Red Hat's Matthew Garret, the keys are stored as part of the system firmware."

I am really afraid that you and he may be right. The feature may be deliberately designed to work against the owner.

In theory, a bootloader that loads linux directly or can chainload into grub will probably be signed (although not necessarily the version you want). It's asinine that linux would have to boot through proprietary/locked software.

"The extension of Microsoft’s OS monopoly to hardware would be a disaster, with increased lock-in, decreased consumer choice and lack of space to innovate."

Edit: it's not just linux either, all BSDs and other independent platforms would be at a loss too. There is no way independent OS developers will be able to get their keys signed by all the manufacturers.

Edited 2011-09-22 06:24 UTC

Reply Parent Score: 6

RE[5]: Comment by ronaldst
by Brendan on Thu 22nd Sep 2011 16:29 in reply to "RE[4]: Comment by ronaldst"
Brendan Member since:


First, UEFI is unlike a normal BIOS in that you can have "UEFI applications" (e.g. various tools and utilities); and the "Secure Boot" stuff applies to *ALL* executables, including UEFI drivers, UEFI applications and UEFI boot loaders. This means that the firmware can have a utility that allows the user to manage keys, and the firmware may be supplied with one key for that utility (and any keys needed for supplied device drivers) and nothing else. In that case the end-user would need to add keys for Windows8 (if the OEM didn't already do it) and/or anything else they want to allow (or disallow).

Secondly, there's a blacklist. If the firmware refused to execute anything that isn't in it's whitelist, then there'd be no point having a blacklist. It's possible that if the executable is in the whitelist then it's allowed to execute, if the executable is in the blacklist it's refused, and if the executable is not on either list the firmware pops up a (password protected?) "Unknown executable, allow/disallow?" prompt.

Third, there's no central authority for keys. This means that anyone can use any key, and build scripts for open source boot loaders (e.g. GRUB2, elilo) could just generate a certificate using a randomly generated key. The end user would need to add the key to their whitelist; either manually (via. some utility) or semi-automatically (if there's some sort of "allow/disallow" prompt). It's not like you have to pay a company like DigiNotor for each public key, and not like open source boot loaders would be forced to have a specific key (and forced to do something to prevent root-kit authors from finding out what their key is).

Basically all I'm saying is that nobody knows how it's going to implemented by firmware authors and/or OEMs; and therefore it's too early to determine if it's a good thing or a bad thing.

I still hope it's going to be a good thing, and that open source boot loaders (and open source OSs) will be able to use it to protect users from malicious code.

Of course I'm sceptical too; and not just because UEFI Secure Boot could be implemented badly by firmware authors and OEMs. There's an unfortunate tendency in certain open source projects (e.g. GRUB) to assume that anything intended to improve security (TPM, drive encryption, etc) is inherently "evil"; and based on these incorrect assumptions the projects deny the end user the ability (dare I say "deny the freedom") to choose to use something that improves their own security if they want to.

- Brendan

Reply Parent Score: 4

RE[5]: Comment by ronaldst
by l3v1 on Fri 23rd Sep 2011 05:28 in reply to "RE[4]: Comment by ronaldst"
l3v1 Member since:

According to Red Hat's Matthew Garret, the keys are stored as part of the system firmware.

Well then, linux pros will become firmware-hacking pros as well. What man has put together, man can pull apart.

Reply Parent Score: 2