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

[Peter Jones]

On Mon, Jan 14, 2019 at 08:07:34AM +0100, Ard Biesheuvel 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.

It is a separate binary, but your deployment method here is way off -
the whole point is that it just rebuilds Boot#### entries from the CSV
file in your vendor directory.  Anyway, it's tiny and only tangentially
related to shim - it just happens to be built from the same tree because
that's where I happened to put it.

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

On x86 land revocations are distributed by UEFI posting them to their
website, but obviously that's only workable because we have a common
signer.  But it's also only *needed* because we have a common root of
trust in the signing chain.

-- 
  Peter