| Message ID | 20221002095626.484279-5-ardb@kernel.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | efi/x86: Avoid corrupted config tables under Xen | expand |
On Sun, Oct 02, 2022 at 11:56:25AM +0200, Ard Biesheuvel wrote: > As it turns out, Xen does not guarantee that EFI bootservices data > regions in memory are preserved, which means that EFI configuration > tables pointing into such memory regions may be corrupted before the > dom0 OS has had a chance to inspect them. > > Demi Marie reports that this is causing problems for Qubes OS when it > attempts to perform system firmware updates, which requires that the > contents of the ESRT configuration table are valid when the fwupd user > space program runs. > > However, other configuration tables such as the memory attributes > table or the runtime properties table are equally affected, and so we > need a comprehensive workaround that works for any table type. > > So let's first disregard all EFI configuration tables except the ones > that are known (or can be expected) to reside in memory regions of a > type that Xen preserves, i.e., ACPI tables (which are passed in > EfiAcpiReclaimMemory regions) and SMBIOS tables (which are usually > passed in EfiRuntimeServicesData regions, even though the UEFI spec only > mentions this as a recommendation). Then, cross reference unknown tables > against either the EFI memory map (if available) or do a Xen hypercall > to determine the memory type, and allow the config table if the type is > one that is guaranteed to be preserved. > > Future patches can augment the logic in this routine to allow other > table types based on the size of the allocation, or based on a table > specific header size field. > > Co-developed-by: Demi Marie Obenour <demi@invisiblethingslab.com> > Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > --- > drivers/firmware/efi/efi.c | 7 ++ > drivers/xen/efi.c | 69 ++++++++++++++++++++ > include/linux/efi.h | 2 + > 3 files changed, 78 insertions(+) > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > index 11857af72859..e8c0747011d7 100644 > --- a/drivers/firmware/efi/efi.c > +++ b/drivers/firmware/efi/efi.c > @@ -556,6 +556,13 @@ static __init int match_config_table(const efi_guid_t *guid, > > for (i = 0; efi_guidcmp(table_types[i].guid, NULL_GUID); i++) { > if (!efi_guidcmp(*guid, table_types[i].guid)) { > + if (IS_ENABLED(CONFIG_XEN_EFI) && > + !xen_efi_config_table_is_usable(guid, table)) { > + if (table_types[i].name[0]) > + pr_cont("(%s=0x%lx) ", > + table_types[i].name, table); > + return 1; > + } > *(table_types[i].ptr) = table; > if (table_types[i].name[0]) > pr_cont("%s=0x%lx ", > diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c > index d1ff2186ebb4..3f1f365b37d0 100644 > --- a/drivers/xen/efi.c > +++ b/drivers/xen/efi.c > @@ -292,3 +292,72 @@ void __init xen_efi_runtime_setup(void) > efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; > efi.reset_system = xen_efi_reset_system; > } > + > +static const efi_guid_t cfg_table_allow_list[] __initconst = { > + ACPI_20_TABLE_GUID, > + ACPI_TABLE_GUID, > + SMBIOS_TABLE_GUID, > + SMBIOS3_TABLE_GUID, > +}; This allowlist seems redundant. Either the tables are already in memory that Xen will preserve or they aren’t. In both cases the subsequent code will do the right thing.
On Sun, 2 Oct 2022 at 18:28, Demi Marie Obenour <demi@invisiblethingslab.com> wrote: > > On Sun, Oct 02, 2022 at 11:56:25AM +0200, Ard Biesheuvel wrote: > > As it turns out, Xen does not guarantee that EFI bootservices data > > regions in memory are preserved, which means that EFI configuration > > tables pointing into such memory regions may be corrupted before the > > dom0 OS has had a chance to inspect them. > > > > Demi Marie reports that this is causing problems for Qubes OS when it > > attempts to perform system firmware updates, which requires that the > > contents of the ESRT configuration table are valid when the fwupd user > > space program runs. > > > > However, other configuration tables such as the memory attributes > > table or the runtime properties table are equally affected, and so we > > need a comprehensive workaround that works for any table type. > > > > So let's first disregard all EFI configuration tables except the ones > > that are known (or can be expected) to reside in memory regions of a > > type that Xen preserves, i.e., ACPI tables (which are passed in > > EfiAcpiReclaimMemory regions) and SMBIOS tables (which are usually > > passed in EfiRuntimeServicesData regions, even though the UEFI spec only > > mentions this as a recommendation). Then, cross reference unknown tables > > against either the EFI memory map (if available) or do a Xen hypercall > > to determine the memory type, and allow the config table if the type is > > one that is guaranteed to be preserved. > > > > Future patches can augment the logic in this routine to allow other > > table types based on the size of the allocation, or based on a table > > specific header size field. > > > > Co-developed-by: Demi Marie Obenour <demi@invisiblethingslab.com> > > Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com> > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > --- > > drivers/firmware/efi/efi.c | 7 ++ > > drivers/xen/efi.c | 69 ++++++++++++++++++++ > > include/linux/efi.h | 2 + > > 3 files changed, 78 insertions(+) > > > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > > index 11857af72859..e8c0747011d7 100644 > > --- a/drivers/firmware/efi/efi.c > > +++ b/drivers/firmware/efi/efi.c > > @@ -556,6 +556,13 @@ static __init int match_config_table(const efi_guid_t *guid, > > > > for (i = 0; efi_guidcmp(table_types[i].guid, NULL_GUID); i++) { > > if (!efi_guidcmp(*guid, table_types[i].guid)) { > > + if (IS_ENABLED(CONFIG_XEN_EFI) && > > + !xen_efi_config_table_is_usable(guid, table)) { > > + if (table_types[i].name[0]) > > + pr_cont("(%s=0x%lx) ", > > + table_types[i].name, table); > > + return 1; > > + } > > *(table_types[i].ptr) = table; > > if (table_types[i].name[0]) > > pr_cont("%s=0x%lx ", > > diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c > > index d1ff2186ebb4..3f1f365b37d0 100644 > > --- a/drivers/xen/efi.c > > +++ b/drivers/xen/efi.c > > @@ -292,3 +292,72 @@ void __init xen_efi_runtime_setup(void) > > efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; > > efi.reset_system = xen_efi_reset_system; > > } > > + > > +static const efi_guid_t cfg_table_allow_list[] __initconst = { > > + ACPI_20_TABLE_GUID, > > + ACPI_TABLE_GUID, > > + SMBIOS_TABLE_GUID, > > + SMBIOS3_TABLE_GUID, > > +}; > > This allowlist seems redundant. Either the tables are already in memory > that Xen will preserve or they aren’t. In both cases the subsequent > code will do the right thing. Will it? Currently, Xen simply accepts all ACPI and SMBIOS tables, regardless of what type of memory region they reside in (if any). So what will happen with buggy firmware where the ACPI or SMBIOS tables are not covered by the memory map at all? Currently, this works fine but now, it will be rejected. And without ACPI tables, the boot will not get far enough to even inform the user what is wrong. And SMBIOS tables are used for platform quirks, which means they might be essential for a platform to boot as well.
On Sun, Oct 02, 2022 at 11:22:58PM +0200, Ard Biesheuvel wrote: > On Sun, 2 Oct 2022 at 18:28, Demi Marie Obenour > <demi@invisiblethingslab.com> wrote: > > > > On Sun, Oct 02, 2022 at 11:56:25AM +0200, Ard Biesheuvel wrote: > > > As it turns out, Xen does not guarantee that EFI bootservices data > > > regions in memory are preserved, which means that EFI configuration > > > tables pointing into such memory regions may be corrupted before the > > > dom0 OS has had a chance to inspect them. > > > > > > Demi Marie reports that this is causing problems for Qubes OS when it > > > attempts to perform system firmware updates, which requires that the > > > contents of the ESRT configuration table are valid when the fwupd user > > > space program runs. > > > > > > However, other configuration tables such as the memory attributes > > > table or the runtime properties table are equally affected, and so we > > > need a comprehensive workaround that works for any table type. > > > > > > So let's first disregard all EFI configuration tables except the ones > > > that are known (or can be expected) to reside in memory regions of a > > > type that Xen preserves, i.e., ACPI tables (which are passed in > > > EfiAcpiReclaimMemory regions) and SMBIOS tables (which are usually > > > passed in EfiRuntimeServicesData regions, even though the UEFI spec only > > > mentions this as a recommendation). Then, cross reference unknown tables > > > against either the EFI memory map (if available) or do a Xen hypercall > > > to determine the memory type, and allow the config table if the type is > > > one that is guaranteed to be preserved. > > > > > > Future patches can augment the logic in this routine to allow other > > > table types based on the size of the allocation, or based on a table > > > specific header size field. > > > > > > Co-developed-by: Demi Marie Obenour <demi@invisiblethingslab.com> > > > Signed-off-by: Demi Marie Obenour <demi@invisiblethingslab.com> > > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org> > > > --- > > > drivers/firmware/efi/efi.c | 7 ++ > > > drivers/xen/efi.c | 69 ++++++++++++++++++++ > > > include/linux/efi.h | 2 + > > > 3 files changed, 78 insertions(+) > > > > > > diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c > > > index 11857af72859..e8c0747011d7 100644 > > > --- a/drivers/firmware/efi/efi.c > > > +++ b/drivers/firmware/efi/efi.c > > > @@ -556,6 +556,13 @@ static __init int match_config_table(const efi_guid_t *guid, > > > > > > for (i = 0; efi_guidcmp(table_types[i].guid, NULL_GUID); i++) { > > > if (!efi_guidcmp(*guid, table_types[i].guid)) { > > > + if (IS_ENABLED(CONFIG_XEN_EFI) && > > > + !xen_efi_config_table_is_usable(guid, table)) { > > > + if (table_types[i].name[0]) > > > + pr_cont("(%s=0x%lx) ", > > > + table_types[i].name, table); > > > + return 1; > > > + } > > > *(table_types[i].ptr) = table; > > > if (table_types[i].name[0]) > > > pr_cont("%s=0x%lx ", > > > diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c > > > index d1ff2186ebb4..3f1f365b37d0 100644 > > > --- a/drivers/xen/efi.c > > > +++ b/drivers/xen/efi.c > > > @@ -292,3 +292,72 @@ void __init xen_efi_runtime_setup(void) > > > efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; > > > efi.reset_system = xen_efi_reset_system; > > > } > > > + > > > +static const efi_guid_t cfg_table_allow_list[] __initconst = { > > > + ACPI_20_TABLE_GUID, > > > + ACPI_TABLE_GUID, > > > + SMBIOS_TABLE_GUID, > > > + SMBIOS3_TABLE_GUID, > > > +}; > > > > This allowlist seems redundant. Either the tables are already in memory > > that Xen will preserve or they aren’t. In both cases the subsequent > > code will do the right thing. > > Will it? Currently, Xen simply accepts all ACPI and SMBIOS tables, > regardless of what type of memory region they reside in (if any). > > So what will happen with buggy firmware where the ACPI or SMBIOS > tables are not covered by the memory map at all? Currently, this works > fine but now, it will be rejected. And without ACPI tables, the boot > will not get far enough to even inform the user what is wrong. And > SMBIOS tables are used for platform quirks, which means they might be > essential for a platform to boot as well. If the tables are not in the memory map at all, I recommend add_taint(TAINT_FIRMWARE_WORKAROUND) but otherwise continuing to boot. If the tables are somewhere nonsensical, then the platform is FUBAR anyway. Linux alone might be able to work by reserving the memory, but under Xen that does not work.
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c index 11857af72859..e8c0747011d7 100644 --- a/drivers/firmware/efi/efi.c +++ b/drivers/firmware/efi/efi.c @@ -556,6 +556,13 @@ static __init int match_config_table(const efi_guid_t *guid, for (i = 0; efi_guidcmp(table_types[i].guid, NULL_GUID); i++) { if (!efi_guidcmp(*guid, table_types[i].guid)) { + if (IS_ENABLED(CONFIG_XEN_EFI) && + !xen_efi_config_table_is_usable(guid, table)) { + if (table_types[i].name[0]) + pr_cont("(%s=0x%lx) ", + table_types[i].name, table); + return 1; + } *(table_types[i].ptr) = table; if (table_types[i].name[0]) pr_cont("%s=0x%lx ", diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c index d1ff2186ebb4..3f1f365b37d0 100644 --- a/drivers/xen/efi.c +++ b/drivers/xen/efi.c @@ -292,3 +292,72 @@ void __init xen_efi_runtime_setup(void) efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; efi.reset_system = xen_efi_reset_system; } + +static const efi_guid_t cfg_table_allow_list[] __initconst = { + ACPI_20_TABLE_GUID, + ACPI_TABLE_GUID, + SMBIOS_TABLE_GUID, + SMBIOS3_TABLE_GUID, +}; + +bool __init xen_efi_config_table_is_usable(const efi_guid_t *guid, + unsigned long table) +{ + u32 memtype; + int i, rc; + + if (!efi_enabled(EFI_PARAVIRT)) + return true; + + for (i = 0; i < ARRAY_SIZE(cfg_table_allow_list); i++) { + if (!efi_guidcmp(*guid, cfg_table_allow_list[i])) + return true; + } + + if (efi_enabled(EFI_MEMMAP)) { + /* check against the EFI memory map */ + efi_memory_desc_t md; + + rc = efi_mem_desc_lookup(table, &md); + if (rc) { + pr_warn("Failed to lookup header 0x%lx in EFI memory map (%d)\n", + table, rc); + return false; + } + memtype = md.type; + } else { + /* check against the Xen hypercall */ + struct xen_platform_op op = { + .cmd = XENPF_firmware_info, + .u.firmware_info = { + .type = XEN_FW_EFI_INFO, + .index = XEN_FW_EFI_MEM_INFO, + .u.efi_info.mem.addr = table, + .u.efi_info.mem.size = U64_MAX - table, + } + }; + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; + + rc = HYPERVISOR_platform_op(&op); + if (rc) { + pr_warn("Failed to lookup header 0x%lx in Xen memory map (%d)\n", + table, rc); + return false; + } + memtype = info->mem.type; + } + + switch (memtype) { + case EFI_RUNTIME_SERVICES_CODE: + case EFI_RUNTIME_SERVICES_DATA: + case EFI_ACPI_RECLAIM_MEMORY: + case EFI_RESERVED_TYPE: + return true; + case EFI_BOOT_SERVICES_DATA: + break; + default: + return false; + } + + return false; +} diff --git a/include/linux/efi.h b/include/linux/efi.h index 256e70e42114..6edc627798b6 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -1351,4 +1351,6 @@ struct linux_efi_initrd { /* Header of a populated EFI secret area */ #define EFI_SECRET_TABLE_HEADER_GUID EFI_GUID(0x1e74f542, 0x71dd, 0x4d66, 0x96, 0x3e, 0xef, 0x42, 0x87, 0xff, 0x17, 0x3b) +bool xen_efi_config_table_is_usable(const efi_guid_t *, unsigned long table); + #endif /* _LINUX_EFI_H */