Re: EFI BoF at DebConf
On Tue, Jul 31, 2012 at 02:28:28PM -0700, Steve Langasek wrote: On Tue, Jul 31, 2012 at 02:40:25PM -0600, Paul Wise wrote: One thing I don't think anyone has discussed yet is how key transitions will work, if a distro-specific key is compromised, is the OS able to update the SB keys? Any OS will be able to push signed updates to the DB and DBX variables, adding new trusted keys or revoking keys / individual binaries. However, the only signed updates that will be accepted by the firmware are those signed by keys already trusted /by the firmware/ (i.e., those present in the kEK). This means that in general, if you have a compromised key or compromised binary, you need to go back to the CA (i.e., whoever is providing a trust path back to KEK for you) and ask them to issue a revocation. Ah, right. I'd missed that part of the spec and I wasn't clear how revocation is meant to work. ... FWIW the UEFI working group seems to consider it an oversight that only one signature is allowed per binary, and work is afoot to correct this. But as with other issues, it's probably too late to make a difference for the first iteration of hardware. ACK. :-( -- Steve McIntyre, Cambridge, UK.st...@einval.com C++ ate my sanity -- Jon Rabone -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120804153338.gk32...@einval.com
Re: EFI BoF at DebConf
On Fri, Jul 20, 2012 at 4:34 PM, Steve McIntyre wrote: Here's a summary of what we discussed in the EFI BoF [1] last week (9th July). Thanks to the awesome efforts of the DebConf video team, the video of the session is already online [2] in case you missed it. I've also attached the Gobby notes that were taken during the session. Again, thanks to the people who took part - we had a useful discussion. One thing I don't think anyone has discussed yet is how key transitions will work, if a distro-specific key is compromised, is the OS able to update the SB keys? Any one binary can only be signed by one key. Would it be possible/useful to circumvent this limitation by making copies of the binary and then signing them? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6EGV4vOSw2KeQgJVQqrZsf=r6wy0gzswuodqjqewsh...@mail.gmail.com
Re: EFI BoF at DebConf
On Tue, Jul 31, 2012 at 02:40:25PM -0600, Paul Wise wrote: Here's a summary of what we discussed in the EFI BoF [1] last week (9th July). Thanks to the awesome efforts of the DebConf video team, the video of the session is already online [2] in case you missed it. I've also attached the Gobby notes that were taken during the session. Again, thanks to the people who took part - we had a useful discussion. One thing I don't think anyone has discussed yet is how key transitions will work, if a distro-specific key is compromised, is the OS able to update the SB keys? Any OS will be able to push signed updates to the DB and DBX variables, adding new trusted keys or revoking keys / individual binaries. However, the only signed updates that will be accepted by the firmware are those signed by keys already trusted /by the firmware/ (i.e., those present in the kEK). This means that in general, if you have a compromised key or compromised binary, you need to go back to the CA (i.e., whoever is providing a trust path back to KEK for you) and ask them to issue a revocation. Any one binary can only be signed by one key. Would it be possible/useful to circumvent this limitation by making copies of the binary and then signing them? It's certainly straightforward to take copies of a single binary and have it signed by multiple keys. It's even straightforward to remove one signature from a binary and replace it with another. What's not straightforward is to provide a single boot image that can reasonably make use of such things, since UEFI boots by looking for a single well-known path to boot from. FWIW the UEFI working group seems to consider it an oversight that only one signature is allowed per binary, and work is afoot to correct this. But as with other issues, it's probably too late to make a difference for the first iteration of hardware. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
EFI BoF at DebConf
[ Please note the cross-post and Reply-To ] Hi folks, Here's a summary of what we discussed in the EFI BoF [1] last week (9th July). Thanks to the awesome efforts of the DebConf video team, the video of the session is already online [2] in case you missed it. I've also attached the Gobby notes that were taken during the session. Again, thanks to the people who took part - we had a useful discussion. UEFI - background = Newer PCs are now coming with a BIOS replacement (UEFI). This provides a very different set of firmware interfaces to the traditional BIOS that will require different boot methods. For now, PC motherboards are continuing to ship with legacy BIOS support but this won't last forever. In Debian, we need to make sure we build in support for UEFI in various places: * debian-installer * boot CDs (both installer and live) * boot loader(s) There is also a second part to this puzzle: Microsoft's Secure Boot specification. 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, although they will also be required (on x86 systems) to include a method for end users to disable Secure Boot somehow. Buyers of Windows systems based on ARM CPUs will *not* get the same freedom. Supporting UEFI === We already have some of the necessary components in Debian, but we need to make sure that we support things all the way from initial CD/USB/network boot through installation and partitioning to installing an EFI-capable boot loader. People are planning on tackling this, hopefully in time for the Wheeze release. This should not be *too* difficult, we hope. Most of the session was taken up by discussion of... Secure Boot (or should that be Restricted Boot?) == We're most likely too late to do much about this in Debian for Wheezy. There's a lot of work that would be needed, and a lot of decisions to be taken. I was hoping that this BoF might be the venue for those decisions, but that was too optimistic about what might happen in a 45-minute session. What we should expect: if Debian does not implement SB, then users wishing to install Debian on MS-certified hardware will have a much more awkward experience than previously, needing to navigate through the firmware setup interface on their machine to find the place to disable SB before. Only then will they be able to boot install/live media. It will be difficult for us to help much on this front. What others have done/said about SB === * Fedora - RedHat * Everything signed * Full signing of the kernel stack. You even have to sign modules, so it complicates stuff for things like DKMS. * Ubuntu - Canonical * not persuaded that it is safe to use GPLv3 bootloaders - differs from FSF view of the issue under best current legal advice with respect to their pre-installed requirements in-house. * for now avoids going the path of fully signing the kernel stack * for now: prevent the user to have anything to do with BIOS, SecureBoot key handling, etc. * FSF * Tend to think that GPLv3 issues (such as risking the obligation to release private key content) are either not an issue or that the license can be changed to avoid them http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web 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. No clarity on how users can install their own keys, down to particular vendor variability. Part of the spec but not necessarily implemented by vendors - best effort only and might not work for all. Likelihood of changes in MS requirements via public pressure vs pressure on OEMs? MS are not an implementor, certifier instead. Working with individual OEMs won't provide 100% coverage. Some clarifications have been made as a result of bad press from the initial announcements. Note: MS trying to implement a different mechanism / monopoly play on ARM, including no requirement for SecureBoot to be capable of being disabled on ARM. Increasing deployment of ARM devices will become important. Makes Windows phones much less appealing as hackable devices. Larger customers may be able to stipulate particular configurations or OS-less hardware but this isn't just a hobbyist problem. Reasons behind the spec include virus protection which is being pushed by some of the larger customers for the hardware. HP want users to run what they want to run but also take into account requirements from the same customers about protecting what does run. Debian and SB? == What are the limitations on extra keys? Is another key useful? * could be unlikely to get a
Re: EFI BoF at DebConf
Hi On Saturday 21 July 2012, Steve McIntyre wrote: […] Likelihood of changes in MS requirements via public pressure vs pressure on OEMs? MS are not an implementor, certifier instead. Working with individual OEMs won't provide 100% coverage. Some clarifications have been made as a result of bad press from the initial announcements. That ship has sailed, the first secure boot enabled consumer systems are already shipping[1] and windows 8 is about to go gold in roughly two weeks. Therefore both the specification and the first generation of its implementation can be considered to be set in stone by now. Regards Stefan Lippers-Hollmann [1] http://www.h-online.com/open/news/item/Aldi-PC-becomes-first-retail-PC-with-UEFI-Secure-Boot-1635893.html -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207210126.34209.s@gmx.de
Re: EFI BoF at DebConf
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
