All of lore.kernel.org
 help / color / mirror / Atom feed
From: Demi Marie Obenour <demi@invisiblethingslab.com>
To: Ard Biesheuvel <ardb@kernel.org>, linux-efi@vger.kernel.org
Cc: xen-devel@lists.xenproject.org, "Peter Jones" <pjones@redhat.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Oleksandr Tyshchenko" <oleksandr_tyshchenko@epam.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Anton Vorontsov" <anton@enomsg.org>,
	"Colin Cross" <ccross@android.com>,
	"Tony Luck" <tony.luck@intel.com>,
	"Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Subject: Re: [PATCH v2 4/6] efi: memmap: Disregard bogus entries instead of returning them
Date: Mon, 3 Oct 2022 11:18:06 -0400	[thread overview]
Message-ID: <Yzr9R2ziBAJgzAqR@itl-email> (raw)
In-Reply-To: <20221003112625.972646-5-ardb@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 3253 bytes --]

On Mon, Oct 03, 2022 at 01:26:23PM +0200, Ard Biesheuvel wrote:
> The ESRT code currently contains some sanity checks on the memory
> descriptor it obtains, but these can only trigger when the descriptor is
> invalid (if at all).
> 
> So let's drop these checks, and instead, disregard descriptors entirely
> if the start address is misaligned, or the number of pages reaches
> beyond the end of the address space. Note that the memory map as a whole
> could still be inconsistent, i.e., multiple entries might cover the same
> area, or the address could be outside of the addressable VA space, but
> validating that goes beyond the scope of these helpers.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>  drivers/firmware/efi/efi.c  | 13 +++++++------
>  drivers/firmware/efi/esrt.c | 18 +-----------------
>  2 files changed, 8 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 11857af72859..55bd3f4aab28 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -461,19 +461,20 @@ int efi_mem_desc_lookup(u64 phys_addr, efi_memory_desc_t *out_md)
>  	efi_memory_desc_t *md;
>  
>  	if (!efi_enabled(EFI_MEMMAP)) {
> -		pr_err_once("EFI_MEMMAP is not enabled.\n");
> +		pr_warn_once("EFI_MEMMAP is not enabled.\n");
>  		return -EINVAL;
>  	}
>  
> -	if (!out_md) {
> -		pr_err_once("out_md is null.\n");
> -		return -EINVAL;
> -        }
> -

Nit: this seems unrelated.

>  	for_each_efi_memory_desc(md) {
>  		u64 size;
>  		u64 end;
>  
> +		/* skip bogus entries */
> +		if ((md->phys_addr & (EFI_PAGE_SIZE - 1)) ||
> +		    (md->phys_addr > 0 &&
> +		     (md->num_pages > (U64_MAX - md->phys_addr + 1) >> EFI_PAGE_SHIFT)))
> +			continue;

Should this also check if md->num_pages is 0?  Also, should this check
be part of for_each_efi_memory_desc()?

> +
>  		size = md->num_pages << EFI_PAGE_SHIFT;
>  		end = md->phys_addr + size;
>  		if (phys_addr >= md->phys_addr && phys_addr < end) {
> diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c
> index 2a2f52b017e7..8f86f2b0734b 100644
> --- a/drivers/firmware/efi/esrt.c
> +++ b/drivers/firmware/efi/esrt.c
> @@ -247,9 +247,6 @@ void __init efi_esrt_init(void)
>  	int rc;
>  	phys_addr_t end;
>  
> -	if (!efi_enabled(EFI_MEMMAP))
> -		return;
> -
>  	pr_debug("esrt-init: loading.\n");
>  	if (!esrt_table_exists())
>  		return;
> @@ -263,21 +260,8 @@ void __init efi_esrt_init(void)
>  		return;
>  	}
>  
> -	max = efi_mem_desc_end(&md);
> -	if (max < efi.esrt) {
> -		pr_err("EFI memory descriptor is invalid. (esrt: %p max: %p)\n",
> -		       (void *)efi.esrt, (void *)max);
> -		return;
> -	}
> -
> +	max = efi_mem_desc_end(&md) - efi.esrt;
>  	size = sizeof(*esrt);
> -	max -= efi.esrt;
> -
> -	if (max < size) {
> -		pr_err("ESRT header doesn't fit on single memory map entry. (size: %zu max: %zu)\n",
> -		       size, max);
> -		return;
> -	}

This can still happen if the ESRT pointer is very very close to the end
of a memory map entry, unless there is another check that handles
such cases.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-10-03 15:18 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-03 11:26 [PATCH v2 0/6] efi/x86: Avoid corrupted config tables under Xen Ard Biesheuvel
2022-10-03 11:26 ` [PATCH v2 1/6] efi: Move EFI fake memmap support into x86 arch tree Ard Biesheuvel
2022-10-03 11:26 ` [PATCH v2 2/6] efi: memmap: Move manipulation routines " Ard Biesheuvel
2022-10-03 11:26 ` [PATCH v2 3/6] efi: xen: Set EFI_PARAVIRT for Xen dom0 boot on all architectures Ard Biesheuvel
2022-10-03 11:26 ` [PATCH v2 4/6] efi: memmap: Disregard bogus entries instead of returning them Ard Biesheuvel
2022-10-03 15:18   ` Demi Marie Obenour [this message]
2022-10-03 15:57     ` Ard Biesheuvel
2022-10-03 11:26 ` [PATCH v2 5/6] efi: xen: Implement memory descriptor lookup based on hypercall Ard Biesheuvel
2022-10-03 15:29   ` Demi Marie Obenour
2022-10-03 15:59     ` Ard Biesheuvel
2022-10-03 16:04       ` Marek Marczykowski-Górecki
2022-10-03 16:22       ` Demi Marie Obenour
2022-10-03 16:37         ` Ard Biesheuvel
2022-10-03 17:04           ` Marek Marczykowski-Górecki
2022-10-03 17:04             ` Marek Marczykowski-Górecki
2022-10-03 17:57             ` Demi Marie Obenour
2022-10-03 18:01               ` Marek Marczykowski-Górecki
2023-01-15 13:31                 ` Marek Marczykowski-Górecki
2022-11-19  1:10             ` Demi Marie Obenour
2022-10-03 11:26 ` [PATCH v2 6/6] efi: Apply allowlist to EFI configuration tables when running under Xen Ard Biesheuvel
2022-12-06 23:19   ` Demi Marie Obenour
2023-01-19 19:03 ` [PATCH v3 0/5] efi: Support ESRT " Demi Marie Obenour
2023-01-19 19:03   ` [PATCH v3 1/5] efi: memmap: Disregard bogus entries instead of returning them Demi Marie Obenour
2023-01-19 19:03   ` [PATCH v3 2/5] efi: xen: Implement memory descriptor lookup based on hypercall Demi Marie Obenour
2023-01-19 19:03   ` [PATCH v3 3/5] efi: Apply allowlist to EFI configuration tables when running under Xen Demi Marie Obenour
2023-01-19 19:03   ` [PATCH v3 4/5] efi: Actually enable the ESRT " Demi Marie Obenour
2023-01-19 19:04   ` [PATCH v3 5/5] efi: Warn if trying to reserve memory " Demi Marie Obenour
2023-01-23  7:30   ` [PATCH v3 0/5] efi: Support ESRT " Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yzr9R2ziBAJgzAqR@itl-email \
    --to=demi@invisiblethingslab.com \
    --cc=anton@enomsg.org \
    --cc=ardb@kernel.org \
    --cc=ccross@android.com \
    --cc=jgross@suse.com \
    --cc=keescook@chromium.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=marmarek@invisiblethingslab.com \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=pjones@redhat.com \
    --cc=sstabellini@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.