On Fri, 2020-02-07 at 18:31 +0000, Ard Biesheuvel wrote: > On Fri, 7 Feb 2020 at 16:20, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Fri, 2020-02-07 at 12:23 +0000, Ard Biesheuvel wrote: > > > On Fri, 7 Feb 2020 at 09:22, Laszlo Ersek <lersek@xxxxxxxxxx> > > > wrote: > > > > > > > > On 02/07/20 10:09, Laszlo Ersek wrote: > > > > [...] > > > > > For example, virt-install's "--location" option "can > > > > > recognize certain distribution trees and fetches a bootable > > > > > kernel/initrd pair to launch the install". It would be nice > > > > > to keep that working for older distros. > > > > > > > > > > I think LoadFile[2] can co-exist with SimpleFs. > > > > > > > > > > I also think that the "try SimpleFs first, fall back to > > > > > LoadFile[2] second" requirement applies only to the UEFI boot > > > > > manager, and not to the kernel's EFI stub. IOW in the new > > > > > approach the kernel is free to ignore (abandon) the old > > > > > approach for good. > > > > > > > > ... But that might not be good for compatibility with grub > > > > and/or the platform firmware, from the kernel's own > > > > perspective, perhaps?... > > > > > > > > Who is supposed to produce LoadFile2 with the new VenMedia > > > > devpath? > > > > > > > > > > What I am ultimately after is a generic GRUB that uses > > > LoadImage+Startimage for starting the kernel on all > > > architectures, > > > > For most boots, we need to pivot to the MoK. A long time ago, I > > proposed updating the platform security policy to do an override to > > allow MoK to become the security verifier (actually principally so > > I could get the gummiboot bootloader to work with the MoK method): > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/t > > ree/lib/security_policy.c > > > > And I believe all the pivot bootloaders now do this, but the fear > > was always this looks a bit like hackery that might not work in > > some UEFI implementations. Since we don't really rely on it (shim > > link loads after signature verification) we don't know whether the > > assumption does break or not. We'll need to get much more > > comfortable with the security override before we can let grub do a > > simple load+start. > > > > I'd like to do something much simpler: let shim override LoadImage > and StartImage, Actually, the non-shim bootloaders really don't want to do that: the whole point of being able to use LoadImage is that you don't need to know how to load a PECOFF binary or check its signature. Overriding the security protocol allows updating the signature check, but if you look at the current efitools implementation it uses the pkcs7 protocol to avoid having to include crypto code. I've got the pecoff code they'd need in my uefi library: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/lib/pecoff.c But it's a lot of code for things that pride themselves on being tiny. > and in their implementations, fall back to the firmware > ones if necessary. > > > > and is able to load the initrd from anywhere in an arch agnostic > > > manner. > > > > I think the use case might not really be grub, it's gummiboot, or > > systemd-boot as its now called: > > > > No it is definitely GRUB. GRUB today needs to attach to the shim > protocol, perform the authentication, measure the payload etc etc, > which means it knows far too much about the internals of shim or the > fact that it even exists. The shim protocol and shim are fairly separate. I agree it means grub has to load and know the two entry points for context and verify but they're very far removed for the inner workings of shim. Obviously, my non-shim loader has to supply them for grub, so this is the implementation: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/lib/shim_protocol.c It's only 50 lines. The other thing to consider is that crypto code is huge. Shim currently includes it (although it could avoid this by using the pkcs7 verifier protocol trick I use ... I should push that harder) and it adds about 1M of static code. Grub does not have this code, so either grub uses shim and its code to do the signature verification or grub will have to include the additional 1M as well ... I think using shim via the protocol is preferable. > My ideal bootflow would be where the OS installer looks at the > firmware's db/dbx, doesn't bother to install shim if the OS vendor's > cert is there, and uses the exact same GRUB regardless of whether > shim is part of the bootflow or not. That's not enough. The whole point of MoK is that the user may have done their own key addition, so you could be in the situation where the vendor cert is present in db but the user has a MoK override for boot and if you assume presence of the vendor cert means you can use loadimage, this will fail because the MoK cert isn't in db ... unless you've added the MoK key via the security protocol override. > One of the things impeding this is the fact that we cannot load the > initrd from anywhere when using loadimage+startimage. unless initrd becomes a PECOFF binary, it can never be loaded by loadimage ... I thought you were still letting the kernel load it via LoadFile2? (assuming you are and that the above is just a typo). James
