* Ben Hutchings: > However, there is now a blog post from Microsoft that supports what > Matthew Garrett has been saying for a while - they may revoke the > signature on a boot loader if signature verification is not extended to > the kernel, including any mechanism to chain-load another kernel: > > http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-uefi-ca-signing-policy-updates.aspx > (specifically point 5(b)) > > This implies that when Secure Boot is enabled, only signed kernels and > modules can be loaded and other features that allow code injection such > as kexec, hibernation and /dev/mem must be disabled.
We also need to use an EV certificate in the shim—not just for submission to Microsoft, but also for the certificate that signs GRUB and the kernel (item 6 (a)). The Terms & Conditions of existing EV code-signing CAs do not permit a code-signing end-entity certificate to be used for signing another certificate, so we'd directly have to embed the end-entity certificate used to sign GRUB and the kernel into the shim—or we'd have to ship the EV root CA, but that would extend complete trust to that CA. If we embed the end-entity certificate, we need to submit a new shim to Microsoft for signing each time the certificate changes (say, because the previous certificate expired after a year). Furthermore, we need to store the keys for all EV certificates (both the certificate used for submission, and the certificate embedded in the shim) in devices that meet at least FIPS 140 Level 2. Such devices that are affordable, support secure, remote operation, and are compatible with free software environments are difficult to find. (But perhaps we can find a DD who agrees to keep the keys in his or her home and manually signs our kernels, using Windows if necessary.) I'm not sure if we can sign sid kernels because of the requirement to sign production quality code only. With KVM, we can boot another operating system after executing unauthenticated (userspace) code, so the new policy seems to force us to disable KVM per item 5 (b) (or extended Secure Boot to qemu-kvm, which is practically impossible at present because we do not have a signed userspace). Obviously, one can still start a virtualized environment without hardware support, and I don't know what this means for compliance. I wonder why Microsoft no longer wants to sign GPLv3 code (such as GRUB 2). It could be due to plans to make Secure Boot mandatory eventually. Right now, it is possible to comply with the GPLv3 license requirements because users can switch off Secure Boot, either at the BIOS level or through the MokManager loophole. This does not affect us because we rarely ship hardware with Debian pre-installed, and if we do, we can make use of the general GPLv3 opt-out clause. But it would affect some of our users. There is also a significant technical limitation: The current shim/grub/kernel combination is totally untested as far as revocation is concerned. Fedora does not blacklist kernels with known root-to-ring-0 escalation vulnerabilities. This means that you can just downgrade the kernel to a known-vulnerable version and lose all protections allegedly provided by Secure Boot (as far as the Linux side is concerned). On the other hand, no one really wants to fix this because it would mean that users cannot downgrade kernels anymore to deal with regressions. In short, I think it is very hard for us to comply with the new Microsoft guidelines. It is also politically problematic because once we comply, Microsoft could try to claim that mandatory Secure Boot is not locking out anyone (because it's not just Fedora anymore). We could still do our own thing under a root we control, but then we have to decide if we want to cross-certify everyone else. We should probably continue the discussion on debian-project because it's not just about the kernel or technical issues. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878uurexq8....@mid.deneb.enyo.de
