Re: [RFC] UEFI Secure Boot on Xen Hosts

[Ard Biesheuvel <ardb@xxxxxxxxxx>]

On Thu, 30 Apr 2020 at 13:15, Daniel Kiper <daniel.kiper@xxxxxxxxxx> wrote:
>
> 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?
>

Well, if you are passing multiple files that are not interchangeable,
each bootloader will need to do something, right? It could be another
GUID, or we could extend the initrd media device path to take
discriminators.

So today, we have

VendorMedia(5568e427-68fc-4f3d-ac74-ca555231cc68)

which identifies /the/ initrd on Linux. As long as this keeps working
as intended, I have no objections extending this to

VendorMedia(5568e427-68fc-4f3d-ac74-ca555231cc68)/File(...)

etc, if we can agree that omitting the File() part means the unnamed
initrd, and that L"initrd" is reserved as a file name. That way, you
can choose any abstract file name you want, but please note that the
loader still needs to provide some kind of mapping of how these
abstract file names relate to actual files selected by the user.

One thing to keep in mind, though, is that this protocol goes away
after ExitBootServices().



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