[Top][All Lists]

[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: Michael Chang
Subject: Re: Discuss support for the linux kernel's EFI Handover Protocol on x86 and ARM
Date: Tue, 22 Jan 2019 14:24:49 +0800
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Jan 14, 2019 at 01:42:29PM -0500, Peter Jones wrote:
> 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.

Thanks for the clarification. Neverthelast it sounds to me the same
thing can be *misused* for mass key provisioning in the factroy.

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

Glad to hear that you'll revive it and continue to move on. :)


> -- 
>   Peter
> _______________________________________________
> Grub-devel mailing list
> address@hidden

reply via email to

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