On Tue, Sep 20, 2022 at 06:09:49PM +0200, 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. > > >> > > > 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
Attachment:
signature.asc
Description: PGP signature
