On Mon, 14 Jan 2019 at 10:53, Michael Chang <mch...@suse.com> wrote: > > On Mon, Jan 14, 2019 at 08:41:21AM +0100, Ard Biesheuvel wrote: > > 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. > > Hm. But that doesn't help if Microsoft requests shim. In the end we have > to maintain two different methods for ARM. My question here is couldn't > we just pick one of them and never look back ? >
Of course. So let's go without shim. > > > > > > > > > > > > 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. > > I am absoutely agree with you, if possible we should avoid shim for ARM > at all. But the problem remains what Microsoft will do and what should > we do as a respond. Will it be like the situation in x86 or will it be > different ? In any case current grub has been working for the case > without Microsoft signs and we are exploring other requrests for Secure > Boot. > Why does it matter so much what Microsoft will do? If they sign things you care about, you put their key in KEK. If not, you don't. > > > > > > > > > > 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? > > Which do you mean: grub's binary or key ? I think binary doesn't help as > it has been distributed, so we need to revoke its signing key to > prohibit it from running afterwards. > > Do I misunderstand your problem ? > I guess I am misunderstanding your problem. If anything is wrong which can be fixed by revocation, why is it not possible to revoke whatever is actually broken? > > > > > 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? > > Sorry I did not make it clear. Don't get me wrong. It is limited to some > issue related with x86 32bit boot entry and also the setup process > varies by vendors, and we couldn't trouble shoot much if the problem > related to firmware, like some production firmware do not support > multi-signed image and differnt tends to intepret x509 requirement (As a > community project, it is hard to get attendtion from commercial vendor > for such requests). > OK. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
