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