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

[Michael Chang]

On Mon, Jan 14, 2019 at 10:57:10AM +0100, Ard Biesheuvel wrote:
> On Mon, 14 Jan 2019 at 10:53, Michael Chang <address@hidden> wrote:
> >
> > On Mon, Jan 14, 2019 at 08:41:21AM +0100, Ard Biesheuvel wrote:
> > > 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.
> >
> > Hm. But that doesn't help if Microsoft requests shim. In the end we have
> > to maintain two different methods for ARM. My question here is couldn't
> > we just pick one of them and never look back ?
> >
> 
> Of course. So let's go without shim.

OK. :)

> 
> > >
> > > > >
> > > > > > > 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.
> >
> > I am absoutely agree with you, if possible we should avoid shim for ARM
> > at all. But the problem remains what Microsoft will do and what should
> > we do as a respond. Will it be like the situation in x86 or will it be
> > different ? In any case current grub has been working for the case
> > without Microsoft signs and we are exploring other requrests for Secure
> > Boot.
> >
> 
> Why does it matter so much what Microsoft will do? If they sign things
> you care about, you put their key in KEK. If not, you don't.

Somehow I get the impression that Microsoft would like to have full
control to the Secure Boot, that's why they are actively hosting the
signing service to audit every piece running without security risk. If
any other KEK installed, then it can be used to bypass their audit
process and depending on their willing to accept. Once a signed loader
is found compromised, it can also be used to chainload and compromise
Windows as well.

Of course I could be terribly wrong.

> 
> 
> > >
> > > > >
> > > > > 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?
> >
> > Which do you mean: grub's binary or key ? I think binary doesn't help as
> > it has been distributed, so we need to revoke its signing key to
> > prohibit it from running afterwards.
> >
> > Do I misunderstand your problem ?
> >
> 
> I guess I am misunderstanding your problem. If anything is wrong which
> can be fixed by revocation, why is it not possible to revoke whatever
> is actually broken?

Becuase it is released so before you revoke it, it may have been saved
and used as off-line copy by hacker to attack the system. (Again, I
might be over-thinking the problem so feel free to corret me.) 

Thanks,
Michael


> 
> 
> > >
> > > > 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?
> >
> > Sorry I did not make it clear. Don't get me wrong. It is limited to some
> > issue related with x86 32bit boot entry and also the setup process
> > varies by vendors, and we couldn't trouble shoot much if the problem
> > related to firmware, like some production firmware do not support
> > multi-signed image and differnt tends to intepret x509 requirement (As a
> > community project, it is hard to get attendtion from commercial vendor
> > for such requests).
> >
> 
> OK.
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel