On Mon, 14 Jan 2019 at 08:30, Michael Chang <mch...@suse.com> wrote: > > On Fri, Jan 11, 2019 at 03:17:54PM +0100, Ard Biesheuvel wrote: > > On Fri, 11 Jan 2019 at 11:58, Leif Lindholm <leif.lindh...@linaro.org> > > wrote: > > > > > > On Thu, Jan 10, 2019 at 09:59:38AM +0100, Alexander Graf wrote: > > > > > Am 10.01.2019 um 09:12 schrieb Michael Chang <mch...@suse.com>: > > > > > > > > > > Hi, > > > > > > > > > > With the advent of new verifier framework and shim lock protocol > > > > > support > > > > > to the grub's community, we are driving to the world of UEFI Secure > > > > > Boot, well, almost .. > > > > > > > > > > There is a missing piece in the puzzle remaining, that is booting > > > > > linux > > > > > kernel via it's own EFI Handover Protocol's entry. > > > > I don't understand what this means. > > From me it means 'maybe' we have to consider common linuxefi loader for > ARM and x86 architectures to boot in UEFI Secure Boot with shim-lock > protocol. It doesn't mean switching over from linux to linuxefi > completely, just offering it as another boot command (like linux16 for > legacy pc bios), and let the distribution choose what to do. >
The ARM and arm64 kernels expect to be invoked as an UEFI loader, i.e., via the PE/COFF entry point with the system table pointer in x1. Adding any infrastructure at all to the kernel to permit it to be booted from UEFI/GRUB in a slightly different way is not maintainable, and the stub<->kernel boot protocol is an implementation detail and I am not comfortable promoting that to something bootloaders implement directly. > > > > > Strictly speaking, > > > > > the interface is not part of the UEFI Secure Boot, but we have to use > > > > > it > > > > > to avoid problem of using UEFI LoadImage Protocol, which will not work > > > > > with shim and it's Machine Owner Key (MOK) as they are not part of > > > > > firmware's KEK and db. > > > > > > > > The 'problem' of using the UEFI LoadImage protocol is the whole point > > of secure boot. Shim and GRUB essentially bypasses UEFI secure boot > > entirely, but in a controlled way. > > By far we don't know what UEFI Secure Boot support in ARM will be like. > There is rumor that Microsoft will also host signing service for ARM > secure boot, so the situation is simialr to the beginning of x86, and is > reasonle to relate it to shim since it was requested to satisfy that. > Microsoft does host signing services for ARM, yes. But that does not mean we have to lock ourselves into using it as the only signing service. > > > > > > So really dumb question here: What if we didn't use the MS key? What > > > > if instead, we just provide a SUSE/openSUSE key and give customers > > > > the ability to sign their own grub+Linux binaries? > > > > > > > > Then we would only need to lobby with platform vendors to include > > > > our public key in the delivered Keystore in parallel and everything > > > > would "just work". > > > > > > > > The only reason shim needs to provide its own key management is that > > > > on most x86 systems, we (and customers) don't have control over the > > > > keystore, right? We can just push to not have that problem on ARM. > > > > > > Sure. That's a valid (and I think Ard would say preferable) decision, > > > and should "just work" with upstream GRUB. But that's for each distro > > > to decide. > > > > > > > Am I missing anything? > > > > > > 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.. > > > > > > > I will repeat the same thing I have been saying since 2013: carrying > > over Shim to other architectures is a mistake. We could have a simple > > and clean secure boot architecture on arm64, where the firmware > > authenticates GRUB, and GRUB calls LoadImage() which authenticates the > > kernel against the firmware keys. All we need for that is to ensure > > that the distros get their act together, and work with the industry to > > get Redhat, Canonical and Suse keys into the KEK and/or db databases > > by default. > > I agree that technically it results better and clean boot stack. The > challege is on that do we consider to host central authority responsible > for the key signing and code review in lieu of vendor? Or do we agree to > trust whatever key giving out to the vendor? For x86, I think currently > microsoft takes the responsiblity to code review and authenicate the > identity of key owner and that costs a lot effort. > But whick key owner? What if whatever Microsoft signs is entirely uninteresting to me? For the server use case, it is highly likely that I only care about the distro key, and nothing else. Having to carry Microsoft's key because all the distros conspired to make that the only basket I can put my eggs in sounds like a bad idea from security pov. Shim is a fix for a problem that does not currently exist on ARM. Let's not create it ourselves. > > > > Instead, we are having this discussion again, how we can circumvent > > authentication checks so that GRUB can load what are essentially > > unverified binaries (from the POV of the firmware), authenticated > > against certificates that are kept in unauthenticated UEFI variables. > > Canonical is even shipping a GRUB with cosmic and disco now that is > > signed with their master key, and happily boots anything if shim is > > not loaded, which makes it impossible to ever move to a model where > > the canonical key is in the UEFI db rather than in the MOK database. > > The point of having MOK is that once anything goes wrong with grub, we > can just revoke MOK and we don't need to walk through the nightmare of > revoking firmware's key. > Or revoke GRUB? > IMHO we also need to think about misc shim features can be moved to > grub2 if necessary. > Yes. > > > > So I strongly suggest that you make things work without shim, relying > > on a monolithic distro signed GRUB which authenticates against the > > UEFI database only. Should the need ever arise, we can always > > introduce shim at a later date. > > OK, that seems to answer my question above. And again I think what's > missing for current grub is efi handover protocol support, which doesn't > conflict with existing LoadImage boot entry. (we run in circle again). > > > > > In fact, if I were running a shrink wrapped distro and did not have to > > rely on MS signed option ROMs, I wouldn't even want the MS key in my > > UEFI db if all I want to run is SUSE. > > Yes, same here. :) That's why in openSUSE we provided option to disable > shim installation and use pristine grub2-install, of course in this case > users are on their own when things are not working. > So non-shim boot is going to be a second class citizen? _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
