Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM

[Ard Biesheuvel]

On Mon, 14 Jan 2019 at 08:30, Michael Chang <address@hidden> wrote:
>
> On Fri, Jan 11, 2019 at 03:17:54PM +0100, Ard Biesheuvel wrote:
> > On Fri, 11 Jan 2019 at 11:58, Leif Lindholm <address@hidden> wrote:
> > >
> > > On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote:
> > > > > Am 10.01.2019 um 09:12 schrieb Michael Chang <address@hidden>:
> > > > >
> > > > > Hi,
> > > > >
> > > > > With the advent of new verifier framework and shim lock protocol 
> > > > > support
> > > > > to the grub's community, we are driving to the world of UEFI Secure
> > > > > Boot, well, almost ..
> > > > >
> > > > > There is a missing piece in the puzzle remaining, that is booting 
> > > > > linux
> > > > > kernel via it's own EFI Handover Protocol's entry.
> >
> > I don't understand what this means.
>
> From me it means 'maybe' we have to consider common linuxefi loader for
> ARM and x86 architectures to boot in UEFI Secure Boot with shim-lock
> protocol. It doesn't mean switching over from linux to linuxefi
> completely, just offering it as another boot command (like linux16 for
> legacy pc bios), and let the distribution choose what to do.
>

The ARM and arm64 kernels expect to be invoked as an UEFI loader,
i.e., via the PE/COFF entry point with the system table pointer in x1.
Adding any infrastructure at all to the kernel to permit it to be
booted from UEFI/GRUB in a slightly different way is not maintainable,
and the stub<->kernel boot protocol is an implementation detail and I
am not comfortable promoting that to something bootloaders implement
directly.

> >
> > > Strictly speaking,
> > > > > the interface is not part of the UEFI Secure Boot, but we have to use 
> > > > > it
> > > > > to avoid problem of using UEFI LoadImage Protocol, which will not work
> > > > > with shim and it's Machine Owner Key (MOK) as they are not part of
> > > > > firmware's KEK and db.
> > > >
> >
> > The 'problem' of using the UEFI LoadImage protocol is the whole point
> > of secure boot. Shim and GRUB essentially bypasses UEFI secure boot
> > entirely, but in a controlled way.
>
> By far we don't know what UEFI Secure Boot support in ARM will be like.
> There is rumor that Microsoft will also host signing service for ARM
> secure boot, so the situation is simialr to the beginning of x86, and is
> reasonle to relate it to shim since it was requested to satisfy that.
>

Microsoft does host signing services for ARM, yes. But that does not
mean we have to lock ourselves into using it as the only signing
service.

> >
> > > > So really dumb question here: What if we didn't use the MS key? What
> > > > if instead, we just provide a SUSE/openSUSE key and give customers
> > > > the ability to sign their own grub+Linux binaries?
> > > >
> > > > Then we would only need to lobby with platform vendors to include
> > > > our public key in the delivered Keystore in parallel and everything
> > > > would "just work".
> > > >
> > > > The only reason shim needs to provide its own key management is that
> > > > on most x86 systems, we (and customers) don't have control over the
> > > > keystore, right? We can just push to not have that problem on ARM.
> > >
> > > Sure. That's a valid (and I think Ard would say preferable) decision,
> > > and should "just work" with upstream GRUB. But that's for each distro
> > > to decide.
> > >
> > > > Am I missing anything?
> > >
> > > As I understand it, there was a concern with the wording in UEFI
> > > 2.(3?, 4?) that made it possible to interpret it such that only one key
> > > had to be supported.
> > >
> > > It all comes down to who wants to make sure the key is already in
> > > shipped systems..
> > >
> >
> > I will repeat the same thing I have been saying since 2013: carrying
> > over Shim to other architectures is a mistake. We could have a simple
> > and clean secure boot architecture on arm64, where the firmware
> > authenticates GRUB, and GRUB calls LoadImage() which authenticates the
> > kernel against the firmware keys. All we need for that is to ensure
> > that the distros get their act together, and work with the industry to
> > get Redhat, Canonical and Suse keys into the KEK and/or db databases
> > by default.
>
> I agree that technically it results better and clean boot stack. The
> challege is on that do we consider to host central authority responsible
> for the key signing and code review in lieu of vendor? Or do we agree to
> trust whatever key giving out to the vendor? For x86, I think currently
> microsoft takes the responsiblity to code review and authenicate the
> identity of key owner and that costs a lot effort.
>

But whick key owner? What if whatever Microsoft signs is entirely
uninteresting to me? For the server use case, it is highly likely that
I only care about the distro key, and nothing else. Having to carry
Microsoft's key because all the distros conspired to make that the
only basket I can put my eggs in sounds like a bad idea from security
pov.

Shim is a fix for a problem that does not currently exist on ARM.
Let's not create it ourselves.

> >
> > Instead, we are having this discussion again, how we can circumvent
> > authentication checks so that GRUB can load what are essentially
> > unverified binaries (from the POV of the firmware), authenticated
> > against certificates that are kept in unauthenticated UEFI variables.
> > Canonical is even shipping a GRUB with cosmic and disco now that is
> > signed with their master key, and happily boots anything if shim is
> > not loaded, which makes it impossible to ever move to a model where
> > the canonical key is in the UEFI db rather than in the MOK database.
>
> The point of having MOK is that once anything goes wrong with grub, we
> can just revoke MOK and we don't need to walk through the nightmare of
> revoking firmware's key.
>

Or revoke GRUB?

> IMHO we also need to think about misc shim features can be moved to
> grub2 if necessary.
>

Yes.

> >
> > So I strongly suggest that you make things work without shim, relying
> > on a monolithic distro signed GRUB which authenticates against the
> > UEFI database only. Should the need ever arise, we can always
> > introduce shim at a later date.
>
> OK, that seems to answer my question above. And again I think what's
> missing for current grub is efi handover protocol support, which doesn't
> conflict with existing LoadImage boot entry. (we run in circle again).
>
> >
> > In fact, if I were running a shrink wrapped distro and did not have to
> > rely on MS signed option ROMs, I wouldn't even want the MS key in my
> > UEFI db if all I want to run is SUSE.
>
> Yes, same here. :) That's why in openSUSE we provided option to disable
> shim installation and use pristine grub2-install, of course in this case
> users are on their own when things are not working.
>

So non-shim boot is going to be a second class citizen?