[RFC] UEFI Secure Boot on Xen Hosts

[RFC] UEFI Secure Boot on Xen Hosts

[Bobby Eshleman]

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

Re: [RFC] UEFI Secure Boot on Xen Hosts

[Jan Beulich]

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

Re: [RFC] UEFI Secure Boot on Xen Hosts

[Daniel Kiper]

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

Re: [RFC] UEFI Secure Boot on Xen Hosts

[Ard Biesheuvel]

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

Re: [RFC] UEFI Secure Boot on Xen Hosts

[Bobby Eshleman]

On Thu, Apr 30, 2020 at 01:41:12PM +0200, Ard Biesheuvel wrote:
> On Thu, 30 Apr 2020 at 13:15, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > 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.

This seems reasonable to me and I can't think of any good reason right
now, if we go down this path, to not just extend the initrd media device
path (as opposed to creating one that is Xen-specific).  It definitely
beats having a GUID per boot module since the number of modules changes
per Xen deployment, so there would need to be some range of GUIDs
representing modules specifically for Xen, and some rules as to how they
are mapped to real files.

It does seem simpler to ask the loader for "dom0's kernel" or "dom1's
initrd" and to have the loader use these references to grab real files.

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

Roger that.


Thanks,

-Bobby

Re: [RFC] UEFI Secure Boot on Xen Hosts

[Ard Biesheuvel]

On Tue, 5 May 2020 at 23:58, Bobby Eshleman <bobbyeshleman@gmail.com> wrote:
>
> On Thu, Apr 30, 2020 at 01:41:12PM +0200, Ard Biesheuvel wrote:
> > On Thu, 30 Apr 2020 at 13:15, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> > > 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.
>
> This seems reasonable to me and I can't think of any good reason right
> now, if we go down this path, to not just extend the initrd media device
> path (as opposed to creating one that is Xen-specific).  It definitely
> beats having a GUID per boot module since the number of modules changes
> per Xen deployment, so there would need to be some range of GUIDs
> representing modules specifically for Xen, and some rules as to how they
> are mapped to real files.
>
> It does seem simpler to ask the loader for "dom0's kernel" or "dom1's
> initrd" and to have the loader use these references to grab real files.
>

Yes. And note that using a single GUID + File component is easier on
the implementation too: the protocol implementation has to be
registered only once, and the single callback that exists will be
invoked with different values for 'FilePath', corresponding with
different values for File(). For example, in [0], this maps to the
check at line 120, where we currently only consider the
'end-of-device-path' terminator type to be valid, but this could
easily be extended to parse the contents of a subsequent file node and
resolve it to grab some actual contents.

[0] https://github.com/u-boot/u-boot/commit/ec80b4735a593961fe701cc3a5d717d4739b0fd0


> > One thing to keep in mind, though, is that this protocol goes away
> > after ExitBootServices().
> >
>
> Roger that.
>
>
> Thanks,
>
> -Bobby

Re: [RFC] UEFI Secure Boot on Xen Hosts

[Marek Marczykowski-Górecki]

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

Re: [RFC] UEFI Secure Boot on Xen Hosts

[Christopher Clark]

On Thu, Apr 30, 2020 at 3:28 PM Marek Marczykowski-Górecki
<marmarek@invisiblethingslab.com> wrote:
>
> 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.

I agree with this point.

>
> > - Would this interfere with the DomB proposal?

Yes, it looks like it would.

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

I'd better clarify this about DomB since it is not quite accurate for
the current work in progress: We're aiming to implement it as a
dom0less mode for x86, where the initial domains are loaded by Xen
itself from the modules provided by the bootloader. A single domain,
(DomB), will then run first, alone, with the opportunity to measure or
validate and then unpause the other initial domains if it chooses to
do so.
So that will mean that support for more modules will be needed.

thanks

Christopher

Re: [RFC] UEFI Secure Boot on Xen Hosts

[Daniel Kiper]

On Fri, May 01, 2020 at 12:27:17AM +0200, Marek Marczykowski-Górecki wrote:
> 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.

Are you talking about GRUB chainloader command? If yes then use "set root=..."
to select ESP before running the chainloader. Of course the xen.cfg,
kernel and initramfs have to live on ESP then. Xen uses UEFI file system
calls which understand FAT only. And if GRUB root points to non-FAT
partition than Xen cannot read anything from it...

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

Why cannot you use multiboot2/module2 to load Xen from GRUB on x86 UEFI
machines? It does not have issues discussed above. Additionally, the
Multiboot2 protocol works on legacy BIOS machines too.

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

If it is done properly it should not.

Daniel

Re: [RFC] UEFI Secure Boot on Xen Hosts

[Marek Marczykowski-Górecki]

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

On Fri, May 01, 2020 at 01:59:59PM +0200, Daniel Kiper wrote:
> On Fri, May 01, 2020 at 12:27:17AM +0200, Marek Marczykowski-Górecki wrote:
> > 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.
> 
> Are you talking about GRUB chainloader command? If yes then use "set root=..."
> to select ESP before running the chainloader. 

This exactly resulted in issues in point 2. In many cases it ended up
accessing ESP via grub's own FAT driver.

> Of course the xen.cfg,
> kernel and initramfs have to live on ESP then. 

Which is another issue - ESP on ISO9660 is limited to 32MB. Which is a
very tight limit for initramfs of an installer image.

> Xen uses UEFI file system
> calls which understand FAT only. And if GRUB root points to non-FAT
> partition than Xen cannot read anything from it...
> 
> > 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.
> 
> Why cannot you use multiboot2/module2 to load Xen from GRUB on x86 UEFI
> machines? It does not have issues discussed above. Additionally, the
> Multiboot2 protocol works on legacy BIOS machines too.

Yes, multiboot2 (now supported with UEFI too) solves all the above. I
want to avoid situation where we'd go back to the (subset of) state from
before multiboot2 on UEFI.

> 
> > 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?
> 
> If it is done properly it should not.
> 
> Daniel

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

Re: [RFC] UEFI Secure Boot on Xen Hosts

[Bobby Eshleman]

On Wed, Apr 29, 2020 at 05:51:08PM -0500, Bobby Eshleman wrote:
> 
> # Option #1: PE/COFF and Shim
> 

... snip ...

> 
> # Option #3: Lean on Grub2's LoadFile2() Verification
> 

... snip ...

It's safe to say that the options boiled down to #1 and #3.  Seeing as how we
may not be able to start playing with the new Grub functionality for some time,
and also seeing as how the security properties of each approach are very
similar, I think that option #1 is probably the best path for what we are
looking to achieve in supporting UEFI SB.  With out any strong objections
against this, that'll be the path we start heading down (starting with Daniel's
patch set) and will be hoping to get upstream.

If possible, the implementation would support both SHIM_LOCK and LoadFile2(),
potentially by one falling back to other upon reporting a security violation,
or detecting the functionality provided by Grub in some manner...  but this
will be easier to evaluate after seeing how the LoadFile2() mechanism will
work.

If LoadFile2() proves itself a better approach, we would not be opposed to
moving in that direction when it is available.

I started joining community calls shortly after the intent of 'docs/design'
was discussed there.  Is this a change that merits a 'docs/design' RFC?

Best regards,
Bobby