Re: [RFC] UEFI Secure Boot on Xen Hosts

[Jan Beulich <jbeulich@xxxxxxxx>]

On 30.04.2020 00:51, Bobby Eshleman wrote:
> 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.

A shim fork doesn't look desirable, which would rule out #2 unless there
is an option there to avoid the fork.

If the potential issues listed for #3 can be suitably addressed, I can't
currently see a reason to prefer either of the two remaining options; I
vaguely recall though that Daniel's change for #1 didn't look overly
appealing, but perhaps this can be taken care of.

Jan