Hi Steve, Thanks for the summary of the EFI BoF. If you don't mind, I'm going to piggy-back on this to provide a bit more info about Secure Boot. Some of this is just expanding on your notes with clarifications; other bits are new information I've gleaned while attending the UEFI Summer Summit this week. But don't ask me to remember which parts are which, as it's all run a bit together in my head. ;)
With many of my comments, I may be giving the impression that I think things aren't that bad and that everything will be ok with Secure Boot. I am in fact very concerned about Secure Boot; we have some significant challenges ahead for continued after-market compatibility with commodity machines as a result of this change. But to meet those challenges, we need to be focused on the issues that are actually going to cause a problem. For instance, I *don't* think we should be worried that machines will go out the door with the Windows 8 logo on them while failing to correctly implement SB (including the disable and customization capabilities). The Microsoft team working on this are quite serious about getting it right, and they do have a compliance testing process that exercises the SB aspect of the requirements. So while there may be a machine or two slipping through to market that don't support SB in the required manner, these would be bugs - and I have every reason to believe Microsoft will be open to bug reports about them. The things that are worrying me, and that I therefore think we need to focus on, are the areas where the Win8 requirements *don't* cover us. On Fri, Jul 20, 2012 at 11:34:13PM +0100, Steve McIntyre wrote: > There is also a second part to this puzzle: Microsoft's Secure Boot > specification. Nitpick: Secure Boot is part of the UEFI specification; the part here that's Microsoft's is the policy around how SB is to be used. > System vendors wanting MS certification for their hardware (i.e. just > about all vendors) will be required to ship their hardware with Secure > Boot enabled by default Bearing in mind that they're only required to do this for Windows 8 certification. Some machines may ship with Windows 8 preinstalled, but not have SB enabled and thus not be certified; some may continue to ship with Windows 7; some server machines may (at least in the short term) come with firmware that doesn't implement Secure Boot. And some vendors may ship with Windows 8 preinstalled but fail the Win8 certification requirements because they've managed to not actually support disabling SB and/or updating keys. Small comfort that this will result in them not being able to use the Windows 8 logo if it means we won't be able to use the machines at all. Ironically this last bit means that the Windows 8 logo may wind up being the *best* indicator of Linux compatibility for UEFI hardware. Only time will tell what we see in the market. > Future UEFI SB changes > ====================== > Comes down to MS certification requirements as to what actually ships. > Must be possible to disable SecureBoot but will practically be done via > access to the firmware: usability obstacle. More than just a practical implementation detail, it's by design that you will only be able to disable SecureBoot via the firmware. To allow a UEFI application to disable SecureBoot for you noninteractively would almost completely undermine the security model. Now, I can't actually think of a way that a UEFI application that *only* disabled SB could be used to compromise a machine remotely; but it's in the Windows 8 reqs that the firmware must not allow SB to be disabled programmatically. (System.Fundamentals.Firmware.UEFISecureBoot 18) > No clarity on how users can install their own keys, down to particular > vendor variability. James Bottomley appears to be addressing this: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git Provided you can get the machine into setup mode or custom mode in the first place (which is supposed to be guaranteed by the Win8 reqs), the tools here should allow you to non-interactively install your own keys without resorting to the vendor's firmware UI. > Part of the spec but not necessarily implemented by vendors - best effort > only and might not work for all. FWIW, my understanding is that MS's logo compliance testing is expected to catch this case. > It is quite possible that one or more OEM's will simply not bother to > implement the option to disable SecureBoot or put it in but not adequately > test it. Current certification requires a switch to be available but no > requirement for this to be obvious. Turned off, the machine cannot or may > not be able dual-boot Windows8 depending if turning it off means switching > firmware to BIOS compatibility mode or just not cheching the signature > from EFI. Hmm, I don't remember this being discussed during the BoF. I think it's clear from context that when the Win8 requirements speak of disabling Secure Boot, they mean not enforcing Secure Boot /while still providing an EFI environment/. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120721023249.ga2...@virgil.dodds.net
