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 490369
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Comment by ronaldst
by Brendan on Thu 22nd Sep 2011 16:29 UTC in reply to "RE[4]: Comment by ronaldst"
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