lkml.org 
[lkml]   [2022]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3] Support ESRT in Xen dom0
On Tue, Sep 20, 2022 at 06:09:49PM +0200, Ard Biesheuvel wrote:
> On Tue, 20 Sept 2022 at 17:54, Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 20.09.2022 17:36, Ard Biesheuvel wrote:
> > > On Mon, 19 Sept 2022 at 21:33, Demi Marie Obenour
> > > <demi@invisiblethingslab.com> 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.
> > >>
> > > 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()]

Should an OS uninstall any configuration tables that it does not
preserve if it ever plans to kexec()? Does Linux do this?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2022-09-22 03:55    [W:0.077 / U:0.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site