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. :) Thanks, Michael > > -- > Peter > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
