On Fri, Sep 23, 2022 at 12:14:50AM +0200, Ard Biesheuvel wrote: > On Thu, 22 Sept 2022 at 20:12, Demi Marie Obenour > <demi@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Thu, Sep 22, 2022 at 05:05:43PM +0200, Ard Biesheuvel wrote: > > > On Thu, 22 Sept 2022 at 16:56, Demi Marie Obenour > > > <demi@xxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Thu, Sep 22, 2022 at 08:12:14AM +0200, Jan Beulich wrote: > > > > > On 22.09.2022 03:09, Demi Marie Obenour wrote: > > > > > > 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. > > > > > > > > > > While perhaps in principle possible, this would require special casing > > > > > in Xen. Except for the memory the initrd comes in, we don't directly > > > > > hand memory to Dom0. Instead everything goes through the page allocator > > > > > first. Plus if we really were convinced boot services memory needed > > > > > retaining, then it would also need retaining across kexec (and hence > > > > > shouldn't be left to Dom0 to decide what to do with it). > > > > > > > > So how should dom0 handle the various EFI tables other than the ESRT? > > > > Right now most uses of these tables in Linux are not guarded by any > > > > checks for efi_enabled(EFI_MEMMAP) or similar. If some of them are in > > > > EfiBootServicesData memory, they might be corrupted before Linux gets > > > > them. > > > > > > Yes, this is an annoying oversight of the EFI design: the config > > > tables are <guid, address> tuples, and the size of the table is > > > specific to each table type. So without knowing the GUID, there is no > > > way you can reserve the right size. > > > > > > Perhaps you could implement something like a hypercall in > > > efi_arch_mem_reserve(), which is called by the EFI code to reserve > > > regions that are in boot services memory but need to remain reserved? > > > This is used for all config tables that it knows or cares about. > > > > On versions of Xen that support spawning multiple domains at boot > > (instead of just dom0) this will be racy. What about refusing to use > > tables in EfiBootServicesData when running under Xen unless a hypercall > > indicates that Xen has reserved all EfiBootServicesData memory? Where > > could such a check be placed? > > You could stick a check inside the for loop in > efi_config_parse_tables() to cross reference every table address > against the memory map when running on Xen, and disregard it if it > doesn't meet your criteria. > > I take it the issue is not limited to x86? Indeed the issue is cross-platform. For Qubes OS, I wonder if a safer approach would be to reserve all EfiBootServicesData memory by default. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab
Attachment:
signature.asc
Description: PGP signature
