Re: [RFC] UEFI Secure Boot on Xen Hosts

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

On Fri, May 01, 2020 at 01:59:59PM +0200, Daniel Kiper wrote:
> On Fri, May 01, 2020 at 12:27:17AM +0200, Marek Marczykowski-Górecki wrote:
> > On Wed, Apr 29, 2020 at 05:51:08PM -0500, Bobby Eshleman wrote:
> > > # Option #3: Lean on Grub2's LoadFile2() Verification
> > >
> > > Grub2 will provide a LoadFile2() method to subsequent programs that 
> > > supports
> > > signature verification of arbitrary files.  Linux is moving in the
> > > direction of using LoadFile2() for loading the initrd [2], and Grub2 will
> > > support verifying the signatures of files loaded via LoadFile2().
> >
> > This description gives me flashbacks to how xen.efi loads dom0
> > kernel+initramfs (Loaded Image Protocol). Practical issues encountered:
> >
> > 1. It works only when xen.efi is loaded via appropriate EFI boot
> > service directly. If xen.efi is loaded by a filesystem driver in
> > grub/other bootloader, it can't load dom0 kernel+initramfs.
> >
> > 2. Given variety of UEFI implementations and boot medias, it was almost
> > impossible to force bootloader to use the right file loading method
> > (cases like the same file accessible both via UEFI fs0: and via grub's
> > filesystem driver). Which means loading xen.efi via a bootloader (as
> > opposed to directly from UEFI) was hit or miss (mostly miss).
> >
> > 3. To avoid the above issue, one was forced to load xen.efi directly
> > from EFI. This gave up any possibility to manipulate xen cmdline, or
> > even choose system to boot in case of some EFI implementations.
> 
> Are you talking about GRUB chainloader command? If yes then use "set root=..."
> to select ESP before running the chainloader. 

This exactly resulted in issues in point 2. In many cases it ended up
accessing ESP via grub's own FAT driver.

> Of course the xen.cfg,
> kernel and initramfs have to live on ESP then. 

Which is another issue - ESP on ISO9660 is limited to 32MB. Which is a
very tight limit for initramfs of an installer image.

> Xen uses UEFI file system
> calls which understand FAT only. And if GRUB root points to non-FAT
> partition than Xen cannot read anything from it...
> 
> > 4. Even if one is lucky to boot xen.efi via grub2-efi, then still only
> > xen options could be modified. But not those for dom0.
> >
> > 5. It was impossible to load xen/kernel/initrd using fancy grub/ipxe
> > features like HTTP.
> 
> Why cannot you use multiboot2/module2 to load Xen from GRUB on x86 UEFI
> machines? It does not have issues discussed above. Additionally, the
> Multiboot2 protocol works on legacy BIOS machines too.

Yes, multiboot2 (now supported with UEFI too) solves all the above. I
want to avoid situation where we'd go back to the (subset of) state from
before multiboot2 on UEFI.

> 
> > In practice the above points mean:
> >
> > * To get a usable product, one is forced to enable all kind of
> >   workarounds (not only related to EFI) _in default configuration_,
> >   because otherwise there is very little chance to enable them only when
> >   needed.
> >
> > * If something goes wrong, in most cases you need to boot from
> >   alternative media (to edit xen.cfg, or efi variables). If you happen
> >   to forget your rescue usb stick, you are out of luck.
> >
> > So, please, can someone confirm the LoadFile2() approach wouldn't have
> > any of the above issues?
> 
> If it is done properly it should not.
> 
> Daniel

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: PGP signature