Plan of action for Secure Boot support

[Florian Weimer]

* Ben Hutchings:

>> 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).
>
> Presumably actual code signatures never expire (or rather, expiry should
> not be checked) - as that would mean mandatory upgrades just to keep a
> machine bootable.

It's not a technical issue.  The CA/subscriber agreement doesn't
permit making new signatures after the certificate has expired.

>> 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).
>
> MS can go and stick their collective head in a blender if they expect us
> to do that.

The usualy argument against disabling KVM is that in order to get KVM
support, you need to activate it in the BIOS.  I haven't seen enough
machines to tell if this is actually true.

>> 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.
>
> Well, that would be almost all of them, right?

Yes, it would apply to all but the latest kernel.

>> 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.
>
> I expect MS doesn't blacklist their old kernel versions, for exactly the
> same reason.  Or do they?

It's not clear to me what Microsoft's objectives are.  Kernel signing
might not be required if they only want to save the cost of read-only
recovery media.  Their installation/recovery kernel does not appear to
be equivalent to the real thing, and vulnerabilities in it would not
matter as long as the signature checking works (for both kernel and
userspace code) and no code with useful vulnerabilities runs before
user interaction.

There's an expectation nowadays that Secure Boot can protect against
careful implants, which is clearly not true on Linux because you could
just target the initrd or any of the early boot scripts, without the
need for any exploits.  Even on Windows, Secure Boot is unlikely to be
able to help against unknown implants (or malware injected into the
boot process), but it's likely that it enables a reliable recovery
path once malware is detectable (and before the malware can, in turn,
detect the detection—it's just like Core War).

Part of the problem is that Microsoft is extremely tight-lipped about
their objectives and policies.  As a result, we pick up isolated
aspects and assume they reflect an overarching grand plan.  But so
far, things we once took for granted (like the $99 fee to get started)
turned out to be just temporary.

>> 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).
>
> Because there are no Linux distributions made by anyone but RH, SUSE,
> Canonical and Debian?

I might not be up to date on this, but I think only Fedora promoted
Secure Boot, and likely did more for the broad acceptance of the
concept as such than Microsoft.  It's also pretty clear that
Microsoft's recent policy changes are partly influenced by Fedora's
Secure Boot capabilities.

Other distributions either didn't try very hard (no signature checking
after ExitBootServices, which is a valid interpretation of the UEFI
Secure Boot specification, but not compatible with Microsoft Secure
Boot) or explicitly decided against joining the Microsoft Secure Boot
ecosystem.