| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAMj1kXH5tos5XVDUCcuEJG+fSNZBnY-xA1nb+Juu3H7AsM0DiQ@mail.gmail.com>
Date: Fri, 30 Sep 2022 18:25:53 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Demi Marie Obenour <demi@...isiblethingslab.com>
Cc: Juergen Gross <jgross@...e.com>,
Stefano Stabellini <sstabellini@...nel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
Kees Cook <keescook@...omium.org>,
Anton Vorontsov <anton@...msg.org>,
Colin Cross <ccross@...roid.com>,
Tony Luck <tony.luck@...el.com>,
Marek Marczykowski-Górecki
<marmarek@...isiblethingslab.com>, xen-devel@...ts.xenproject.org,
linux-kernel@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [PATCH v4 1/2] Avoid using EFI tables Xen may have clobbered
On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
<demi@...isiblethingslab.com> wrote:
>
> Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> EFI_BOOT_SERVICES_CODE, and EFI_BOOT_SERVICES_DATA may be clobbered by
> Xen before Linux gets to start using it. Therefore, Linux under Xen
> must not use EFI tables from such memory. Most of the remaining EFI
> memory types are not suitable for EFI tables, leaving only
> EFI_ACPI_RECLAIM_MEMORY, EFI_RUNTIME_SERVICES_DATA, and
> EFI_RUNTIME_SERVICES_CODE. When running under Xen, Linux should only
> use tables that are located in one of these types of memory.
>
> This patch ensures this, and also adds a function
> (xen_config_table_memory_region_max()) that will be used later to
> replace the usage of the EFI memory map in esrt.c when running under
> Xen. This function can also be used in mokvar-table.c and efi-bgrt.c,
> but I have not implemented this.
>
> Signed-off-by: Demi Marie Obenour <demi@...isiblethingslab.com>
> ---
> drivers/firmware/efi/efi.c | 8 +++++---
> drivers/xen/efi.c | 35 +++++++++++++++++++++++++++++++++++
> include/linux/efi.h | 9 +++++++++
> 3 files changed, 49 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index e4080ad96089abd7f84745dd8461c548bcbb7685..d344f3ff73d1c5ed0c67e3251a9502e66719741d 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -574,7 +574,6 @@ int __init efi_config_parse_tables(const efi_config_table_t *config_tables,
> unsigned long table;
> int i;
>
> - pr_info("");
Why are you removing these prints?
> for (i = 0; i < count; i++) {
> if (!IS_ENABLED(CONFIG_X86)) {
> guid = &config_tables[i].guid;
> @@ -585,7 +584,6 @@ int __init efi_config_parse_tables(const efi_config_table_t *config_tables,
>
> if (IS_ENABLED(CONFIG_X86_32) &&
> tbl64[i].table > U32_MAX) {
> - pr_cont("\n");
> pr_err("Table located above 4GB, disabling EFI.\n");
> return -EINVAL;
> }
> @@ -594,10 +592,14 @@ int __init efi_config_parse_tables(const efi_config_table_t *config_tables,
> table = tbl32[i].table;
> }
>
> +#ifdef CONFIG_XEN_EFI
We tend to prefer IS_ENABLED() for cases such as this one. That way,
the compiler always gets to see the code inside the conditional block,
which gives better build test coverage (even if CONFIG_XEN_EFI is
disabled).
> + if (efi_enabled(EFI_PARAVIRT) && !xen_config_table_memory_region_max(table))
So the question here is whether Xen thinks the table should be
disregarded or not. So let's define a prototype that reflects that
purpose, and let the implementation reason about how this should be
achieved.
So
if (IS_ENABLED(CONFIG_XEN_EFI) &&
efi_enabled(EFI_PARAVIRT) &&
xen_efi_config_table_valid(guid, table)
continue
I should note here, though, that EFI_PARAViRT is only set on x86 not
on other architectures that enable CONFIG_XEN_EFI so this will not
work anywhere else.
> + continue;
> +#endif
> +
> if (!match_config_table(guid, table, common_tables) && arch_tables)
> match_config_table(guid, table, arch_tables);
> }
> - pr_cont("\n");
> set_bit(EFI_CONFIG_TABLES, &efi.flags);
>
> if (efi_rng_seed != EFI_INVALID_TABLE_ADDR) {
> diff --git a/drivers/xen/efi.c b/drivers/xen/efi.c
> index d1ff2186ebb48a7c0981ecb6d4afcbbb25ffcea0..c2274ddfcc63304008ef0fd78fd9fa416f75d073 100644
> --- a/drivers/xen/efi.c
> +++ b/drivers/xen/efi.c
> @@ -28,6 +28,7 @@
> #include <xen/interface/platform.h>
> #include <xen/xen.h>
> #include <xen/xen-ops.h>
> +#include <xen/page.h>
>
> #include <asm/page.h>
>
> @@ -271,6 +272,40 @@ static void xen_efi_reset_system(int reset_type, efi_status_t status,
> }
> }
>
> +__init u64 xen_config_table_memory_region_max(u64 addr)
It is more idiomatic for Linux to put __init after the return type.
And if we adopt my suggestion above, this becomes
bool __init xen_efi_config_table_valid(const efi_guid_t *guid, u64 table)
Alternatively, you could pass the string identifier of the table
instead of the guid (or both) to print in the diagnostic message.
> +{
> + static_assert(XEN_PAGE_SHIFT == EFI_PAGE_SHIFT,
> + "Mismatch between EFI_PAGE_SHIFT and XEN_PAGE_SHIFT");
Is this the only place where this matters? And this never happens on x86, right?
> + 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 = addr,
> + .u.efi_info.mem.size = U64_MAX - addr,
> + }
> + };
> + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
> + int rc = HYPERVISOR_platform_op(&op);
> +
> + if (rc) {
> + pr_warn("Failed to lookup header %llu in Xen memory map: error %d\n",
> + (unsigned long long)addr, rc);
> + return 0;
> + }
> +
> + switch (info->mem.type) {
> + case EFI_RUNTIME_SERVICES_CODE:
> + case EFI_RUNTIME_SERVICES_DATA:
> + case EFI_ACPI_RECLAIM_MEMORY:
If we are listing all memory types that Xen preserves, you might add
EFI_RESERVED_MEMORY here. Otherwise, please only list the ones that
you need to permit explicitly.
> + return info->mem.addr + info->mem.size;
> + default:
> + pr_warn("Table %llu is in memory of type %d, ignoring it\n",
> + (unsigned long long)addr, info->mem.type);
> + return 0;
> + }
> +}
> +
> /*
> * Set XEN EFI runtime services function pointers. Other fields of struct efi,
> * e.g. efi.systab, will be set like normal EFI.
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index d2b84c2fec39f0268324d1a38a73ed67786973c9..fc81e4b984398cdb399e7886b2cae7f33bf91613 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -1324,4 +1324,13 @@ struct linux_efi_coco_secret_area {
> /* 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)
>
> +#ifdef CONFIG_XEN_EFI
Please drop this #ifdef
> +/*
> + * Returns the end of the memory region containing the given config table,
> + * or 0 if the given address does not reside in memory that can validly
> + * contain EFI configuration tables.
> + */
> +__init u64 xen_config_table_memory_region_max(u64 addr);
You can drop the __init here
> +#endif
> +
> #endif /* _LINUX_EFI_H */
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> Invisible Things Lab
>
Powered by blists - more mailing lists