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

[Michael Chang]

On Mon, Jan 14, 2019 at 11:22:23AM +0100, Alexander Graf wrote:
> On 01/14/2019 10:14 AM, Michael Chang wrote:
> > On Mon, Jan 14, 2019 at 08:07:34AM +0100, Ard Biesheuvel wrote:
> > > On Mon, 14 Jan 2019 at 05:58, Michael Chang <address@hidden> wrote:
> > > > On Fri, Jan 11, 2019 at 10:58:54AM +0000, Leif Lindholm 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. 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.
> > > > > > 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.
> > > > It will work as far as it goes. I think part of the reason shim was used
> > > > is that early x86 UEFI Secure Boot shipped without function to disable
> > > > it and also no way to enter setup mode. It is then become some sort of
> > > > vendor lock-in and has legal concern to the open source software like
> > > > grub if it gets signed to prevent from freely distributed. If ARM
> > > > provides setup mode and user has the freedom to manipulate on the
> > > > firmware stores then I think shim may not be necessary.
> > > > 
> > > > > > Am I missing anything?
> > > > As time goes by shim has also evolved to do the work than it was
> > > > expected originally. Here listed some of related features to consider
> > > > when we get rid of shim or the MOK key store it manages. I don't know
> > > > ARM folks consider these real issue or not, just for information.
> > > > 
> > > > 1. Key revocation: To revoke a key in db would require the authenticate
> > > > varaible support in linux, I didn't know its status much yet. And also
> > > > it means each distro requires to work with vendor to get its variable
> > > > signed, compared with shim that each disto could revoke their key
> > > > indendently it brings way more complex and overhead in the process.
> > > > 
> > > If the distro's key is in KEK, the distro can sign revocation updates 
> > > directly.
> > Yes. Anyhow it is still new to distro, either to deliver the key to
> > vendor directly as KEK, or revoke them with authenticate var updates
> > both would require close collaboration between vendors and distro.
> 
> If we sign our own grub with the old and new key and then have a grub module
> to revoke the old key once booted with the new key, we should be all good,
> no?

The revoked old key will be added to dbx that will block execution of
image carrying old signatures. I think in this case grub will not be
able to run because of that.

> Of course that would require a grub module to do so, but I don't see that as
> a big problem to write?

I don't know if upstream is still holding any opposition to 'writing to
nvram' from grub. There seems to have patch proposed for that but did
not get merged. From me I don't foresee problem of implementing that
feature to grub.

> 
> > 
> > > > 2. Some distribution may be using kernel module signing which chains to
> > > > the MOK store as it is easier to updat from the OS.
> > > > 
> > > Pardon my ignorance, but I thought MOK keys were only updatable at
> > > boot time? So why is it easier to update a MOK key than it is to
> > > update db directly?
> > AFAIK, MOK is copied to kernel keyring during boot time so it is
> > accessible during run time. The point of using MOK is that 3rd party can
> > just sign their kernel modules and enroll pubilc cert via the shim UI.
> > It doesn't require them to own any KEK to the firmware.
> 
> Can we have a similar mechanism for modifying the KEK from within grub? Then
> users could add their own keys using that as well.

>From me it looks promising as the signed variable can be a file and we
implement grub command for writing it (to KEK or db). This operation can
also be done from linux directly as authenticated variable is accessible
through run time service.

It means there's other channel to make 3rd-party key to the firmware. If
the system is shipped with pre-configured keys, and if it has been
signed/trusted by one of the KEK or PK then the process of enrolling is
out-of-box to the user in an automateed manner which can also work with
package update. If not users can also learn the trick of enrolling it
through the firmare's boot menu. It may not be necessary for bootloader
to support that imho.

> 
> So all that's needed at that point is to somehow pass the KEK keys to the
> kernel for attestation down the chain. Can we read out the keys from grub?

I think Yes.

> Or is there an RTS for it?

I thin yes, we can use RTS (Run Time Service) to access KEK and db.

> 
> > 
> > > > 3. The Shim's fallback mode has been used to recreate boot entries after
> > > > firmware update for x86, not sure if that any problem for ARM.
> > > > 
> > > It thought fallback was a separate binary? If the distros sign that,
> > > there is no reason we couldn't load it straight from a Boot#### or
> > > PlatformRecovery#### entry.
> > Wouldn't those entry be lost after firmware update like all others?
> > 
> > And also without any boot entry firmware will pick default boot path,
> > that is grub may be loaded so we need to implant some logic to run
> > fallback.efi to recreate boot entry including 'new' default then reboot
> > to it.
> 
> How about we just install grub in the default boot path?

If ARM don't consider multiple os boot an issue then certainly it is the
best case to use default boot path.

> I personally think we really don't need fallback.efi either - it makes much
> more sense to move that functionality into grub if grub is what we want to
> boot anyway.

Agreed.

Thanks,
Michael

> 
> 
> Alex
> 
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel