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

[Peter Jones <pjones@redhat.com>]

On Mon, Jan 14, 2019 at 05:14:21PM +0800, Michael Chang wrote:
> > > 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?

A firmware update *shouldn't* clobber that, but that model isn't right
in any case.  We still have to use the default boot path for that,
because it handles the case where you replace a failed mainboard, the
case where a vendor ships a firmware that clobbers boot variables for
years on end (though currently that case is broken until I implement
boot loop detection.)

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

You also don't always want to just boot directly after going through the
fallback case, either.  Even if you implemented this in grub you'd want
a reboot after fixing the boot variables, because the value in PCR[1] on
tpm2 will be incorrect until after a reboot.

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

If I'm thinking of what you're thinking of, the issue was one
*signature* in the binary, rather than one *key* in db.  The short
version of the story is the PE spec doesn't explicitly say the
signatures are an array, and MS hadn't interpreted it that way until I
interpreted it as one, so their version of "multiple signatures" was
done through creative x509 countersigning structures.  These days
signtool.exe implements the same thing pesign does, and treats the
signature entry in the binary as an array of aligned WIN_CERTIFICATE
structs, with one signature each.

None of that is really relevant here, though.

> > > > It all comes down to who wants to make sure the key is already
> > > > in shipped systems..
> > >
> > > Do you think all vendors and distro will have to use common secure
> > > channel to communicate the key distribution related issues ?
> > 
> > Define 'secure'. I don't think the distros should be sharing any
> > secrets with the vendor, but I guess they would have to establish some
> > kind of trust if the any keys get installed in the factory.
> > This is similar to how you get your public key hash fused into your
> > silicon when you order secure parts from a silicon vendor.
> 
> True. It reminds me UEFI used to propose the Audit mode for the factory
> usage,

"Factory usage" isn't the use case that was discussed for Audit Mode.
The point of it is to ship server-class hardware in a state where during
initial deployment you can switch to using your site-specific keys and
hashes of individual binaries (i.e. option ROMs) you need in order to do
your own signing, without having to have a prior enrolled KEK entry.

We should really implement support for it everywhere.

> and if I remember correctly TPM is required to ensure everything
> is not tampered in factory. But TBH I have lost track of it since it has
> no real demand for linux distro.

TPM is not required for audit mode at all.  What *is* needed is to
expose to userland the data in the IEIT config table - the log of what
got verified for Secure Boot with which keys and hashes.  I wrote some
code for this last year, but got mired down in how EFI config table
handling in general works.  I'll ask Javier Martinez to have a look at
reviving that, along with the work he's already to expose the tpm2 log
properly, since they are generally useful together.

-- 
  Peter