Re: [RFC] UEFI Secure Boot on Xen Hosts

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

Adding Ard...

On Thu, Apr 30, 2020 at 09:01:45AM +0200, Jan Beulich wrote:
> 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.

Here you have to change the Multiboot2 protocol and singing tools too.
So, I do not consider this as a viable solution.

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

s/for release in/after release/

> > 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

Maybe partially but certainly there will be some differences...

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

AIUI yes but Ard, who designed this new boot protocol, may say more
about that.

Anyway, the advantage of this new protocol is that it uses UEFI API to
load and execute PE kernel and its modules. This means that it will be
architecture independent. However, IIRC, if we want to add new modules
types to the Xen then we have to teach all bootloaders in the wild about
new GUIDs. Ard, am I correct?

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

Daniel