Re: [RFC] UEFI Secure Boot on Xen Hosts

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1: Type: text/plain, Size: 3572 bytes --]

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.

> - Would this interfere with the DomB proposal?  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.

-- 
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]