On Fri, Sep 30, 2022 at 06:36:11PM +0200, Ard Biesheuvel wrote: > On Fri, 30 Sept 2022 at 01:02, 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.17, 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 replaces the ESRT with a copy in memory that it has > > reserved. Such memory is currently of type EFI_RUNTIME_SERVICES_DATA, > > but in the future it will be of type EFI_ACPI_RECLAIM_MEMORY. This > > ensures that the ESRT can safely be accessed by the OS. > > > > When running as a Xen dom0, use the new > > xen_config_table_memory_region_max() function to determine if Xen has > > reserved the ESRT and, if so, find the end of the memory region > > containing it. This allows programs such as fwupd which require the > > ESRT to run under Xen, and so makes fwupd support in Qubes OS possible. > > > > Signed-off-by: Demi Marie Obenour <demi@xxxxxxxxxxxxxxxxxxxxxx> > > Why do we need this patch? I'd expect esrt_table_exists() to return > false when patch 1/2 is applied. efi_enabled(EFI_MEMMAP) is false under Xen, so there needs to be an alternative way to get the end of the memory region containing the ESRT. That is what this patch provides. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
