Re: [RFC] UEFI Secure Boot on Xen Hosts

[Christopher Clark <christopher.w.clark@xxxxxxxxx>]

On Thu, Apr 30, 2020 at 3:28 PM Marek Marczykowski-Górecki
<marmarek@xxxxxxxxxxxxxxxxxxxxxx> 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.
>
> 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.
>
> 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?
>
> > This is set
> > for release in GRUB 2.06 sometime in the latter half of 2020.
> >
> > In Xen, this approach could be used for loading dom0 as well, offering a 
> > very
> > simple verified load interface.
> >
> > Currently the initrd argument passed from Linux to LoadFile2() is a vendor
> > media device path GUID [3].
> >
> > Changes to Xen:
> > - Xen would need to pass these device paths to Grub
> > - Xen would be changed to load dom0 with the LoadFile2() interface via boot 
> > services
> >
> > Changes to Grub:
> > - Xen dom0 kernel/initrd device paths would need to be introduced to Grub
> >
> > Potential Issues:
> > - How will Xen handle more boot modules than just a dom0 and dom0
> >   initrd?
> > - Would each boot module need a unique vendor guid?
>
> Both above points applies for example to loading dom0
> kernel+initrd+microcode update+xsm.

I agree with this point.

>
> > - Would this interfere with the DomB proposal?

Yes, it looks like it would.

> > I suspect not because
> > the DomB proposal suggests launching DomUs from an already booted
> > DomB, at which point other means could be used.
>
> domB probably not, but what about dom0less, where multiple domains are
> loaded by Xen itself? I know dom0less currently is ARM only (not sure
> how that relates to EFI, if at all), but I think in general it would be
> good to plan for supporting more modules.

I'd better clarify this about DomB since it is not quite accurate for
the current work in progress: We're aiming to implement it as a
dom0less mode for x86, where the initial domains are loaded by Xen
itself from the modules provided by the bootloader. A single domain,
(DomB), will then run first, alone, with the opportunity to measure or
validate and then unpause the other initial domains if it chooses to
do so.
So that will mean that support for more modules will be needed.

thanks

Christopher