Re: [PATCH v3] Support ESRT in Xen dom0

[Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx>]

On Wed, Sep 21, 2022 at 10:34:04PM +0200, Jan Beulich wrote:
> On 20.09.2022 18:09, Ard Biesheuvel wrote:
> > On Tue, 20 Sept 2022 at 17:54, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> >>
> >> On 20.09.2022 17:36, Ard Biesheuvel wrote:
> >>> On Mon, 19 Sept 2022 at 21:33, Demi Marie Obenour
> >>> <demi@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> >>>>
> >>>> fwupd requires access to the EFI System Resource Table (ESRT) to
> >>>> discover which firmware can be updated by the OS.  Currently, Linux does
> >>>> not expose the ESRT when running as a Xen dom0.  Therefore, it is not
> >>>> possible to use fwupd in a Xen dom0, which is a serious problem for e.g.
> >>>> Qubes OS.
> >>>>
> >>>> Before Xen 4.16, this was not fixable due to hypervisor limitations.
> >>>> The UEFI specification requires the ESRT to be in EfiBootServicesData
> >>>> memory, which Xen will use for whatever purposes it likes.  Therefore,
> >>>> Linux cannot safely access the ESRT, as Xen may have overwritten it.
> >>>>
> >>>> Starting with Xen 4.17, Xen checks if the ESRT is in EfiBootServicesData
> >>>> or EfiRuntimeServicesData memory.  If the ESRT is in EfiBootServicesData
> >>>> memory, Xen allocates some memory of type EfiRuntimeServicesData, copies
> >>>> the ESRT to it, and finally replaces the ESRT pointer with a pointer to
> >>>> the copy.  Since Xen will not clobber EfiRuntimeServicesData memory,
> >>>> this ensures that the ESRT can safely be accessed by the OS.  It is safe
> >>>> to access the ESRT under Xen if, and only if, it is in memory of type
> >>>> EfiRuntimeServicesData.
> >>>>
> >>>
> >>> Thanks for the elaborate explanation. This is really helpful.
> >>>
> >>> So here, you are explaining that the only way for Xen to prevent
> >>> itself from potentially clobbering the ESRT is by creating a
> >>> completely new allocation?
> >>
> >> There are surely other ways, e.g. preserving BootServices* regions
> >> alongside RuntimeServices* ones. But as the maintainer of the EFI
> >> code in Xen I don't view this as a reasonable approach.
> > 
> > Why not?
> 
> Because it's against the intentions the EFI has (or at least had)
> for this memory type. Much more than EfiAcpiReclaimMemory this
> type is intended for use as ordinary RAM post-boot.

What about giving that memory to dom0?  dom0’s balloon driver will give
anything dom0 doesn’t wind up using back to Xen.

> >>> TBH I still don't think this is a scalable approach. There are other
> >>> configuration tables that may be passed in EFI boot services memory,
> >>> and MS especially were pushing back in the UEFI forum on adding table
> >>> types that were passed in anything other the EfiBootServicesData.
> >>
> >> Within Xen we might abstract the approach currently implemented in
> >> case more such pieces of data appear.
> >>
> >> While I can easily believe MS might be advocating for this model,
> >> I view it as problematic not only for Xen. How would you pass on
> >> this information across kexec, for example, without introducing
> >> further producer-consumer dependencies requiring separate protocols
> >> to be followed?
> >>
> > 
> > In this case, I don't think this is unreasonable for configuration
> > tables, which only have a GUID and a base address. If the OS knows the
> > GUID, and knows how to interpret the contents, it can decide for
> > itself whether or not to preserve it. If it doesn't know the GUID, the
> > memory is just treated as available memory [after EBS()]
> > 
> > I personally think reclaimable memory is more suitable for these
> > cases, which is why I am willing to consider that as well. Note that
> > the EFI spec now also mandates device trees on ARM to be passed via
> > EfiAcpiReclaimMemory, simply because it is the memory type suitable
> > for firmware tables that only the OS consumes.
> 
> We do preserve EfiAcpiReclaimMemory, for the simple reason that with
> Xen "the OS" is ambiguous: Is that Xen or Dom0? Most of ACPI is
> handled by Dom0, so we can't very well discard the data before Dom0
> starts. (This then also matters for what you've said in the earlier
> paragraph. In particular the sets of known GUIDs may be dissimilar
> for Xen and the Dom0 kernel. Considering your other remark about
> fragmentation you might agree that preserving in-place is not very
> desirable.)
> 
> Especially with DT mandated to use EfiAcpiReclaimMemory I'm willing
> to consider using that type for the storing of ESRT (and whatever
> else may appear along these lines). Demi, you may want to check for
> both types in your Linux side patch ...

EfiAcpiReclaimMemory does seem like a better choice.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature