grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ard Biesheuvel
Subject: Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM
Date: Mon, 14 Jan 2019 10:57:10 +0100

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.

> >
> > > >
> > > > > > 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.


> >
> > > >
> > > > 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?


> >
> > > 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]