[RFC] UEFI Secure Boot on Xen Hosts

[Bobby Eshleman <bobbyeshleman@xxxxxxxxx>]

Hey all,

We're looking to develop UEFI Secure Boot support for grub-loaded Xen and
ultimately for XCP-ng (I'm on the XCP-ng team at Vates).

In addition to carrying the chain-of-trust through the entire boot sequence
into dom0, we would also like to build something akin to Linux's Lockdown for
dom0 and its privileged interfaces.

It appears that there are various options and we'd like to discuss them with
the community.

# Option #1: PE/COFF and Shim

Shim installs a verification protocol available to subsequent programs via EFI
boot services.  The protocol is called SHIM_LOCK and it is currently supported
by xen.efi.

Shim requires the payload under verification to be a PE/COFF executable.  In
order to support both shim and maintain the multiboot2 protocol, Daniel Kiper's
patchset [1]  (among other things) incorporates the PE/COFF header
into xen.gz and adds dom0 verification via SHIM_LOCK in
efi_multiboot2().

There appears that some work will be needed on top of this patchset, but not
much as it seems most of the foot work has been done.

AFAIK, the changes needed in GRUB for this approach are already upstream (the
shim_lock module is upstream), and shim would go untouched.

# Option #2: Extended Multiboot2 and Shim

Another approach that could be taken is to embed Xen's signature into a
new multiboot2 header and then modify shim to support it.  This would
arguably be more readable than embedding the PE/COFF header, would add
value to shim, and would fit nicely with the mb2 header code that
already exists in Xen.  The downside being that it would require a shim
fork.  Grub2 would be unchanged.

I'm not familliar with Microsoft's signing process.  I do know they
support template submissions based on shim, and I'm not sure if such a
big change would impact their approval process.

# 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 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?
- 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.

We'd just like to get the conversation going on this topic before we
dive too far into implementing something.  Are any of these approaches a
hard no for upstreaming?  Do any stand out as best candidates?  Any
feedback / questions / criticisms would be greatly appreciated.

Thanks,
Bobby Eshleman


# References

1. Daniel Kiper's patchset:
    https://lists.xenproject.org/archives/html/xen-devel/2018-06/msg01292.html
2. Linux loading initrd with LoadFile2():
    https://lkml.org/lkml/2020/2/17/331
3. The vendor media guid for initrd:
    
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/efi/libstub/efi-stub-helper.c#n311