== EFI in Debian == Please take notes here What do we do? Two parts to this: EFI boot itself * easy - not trivial, not implemented in installer/debian-cd yet. * SMOP Secure boot * what's the least bad way? Others: * 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 New hardware for x86 shipping to run Windows8, enabling SecureBoot by default for Windows certification. Ordinary users will need support to work through access errors: it's not clear how to disable SecureBoot (it will be different in different devices) and, even though it will be possible for users to install their own keys it's unclear how to do so. The EFI spec seems to require it, but it might not be a MUST nor very clear how it would (or not) be possible to do it. Changes within EFI in future ---------------------------- 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 ====== What are the limitations on extra keys? Is another key useful? * could be unlikely to get a response * actual space within the firmware is limited Any one binary can only be signed by one key. Linux Foundation to sign a generic bootloader? 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. Corporate customers may also require that SecureBoot is not turned off. Derivatives will expect to be able to use Debian as a base. May be able to treat a signed bootloader as non-free. Try to support both users and derivatives at the same time but it disables our standard install media without SecureBoot first being disabled. EFI support is still required in Debian Installer - BIOS won't be available in future machines.