All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory Price <gourry@gourry.net>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	x86@kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Dave Young <dyoung@redhat.com>,
	Usama Arif <usamaarif642@gmail.com>,
	Jiri Slaby <jirislaby@kernel.org>,
	Breno Leitao <leitao@debian.org>
Subject: Re: [PATCH 1/5] efi/memattr: Fix thinko in table size sanity check
Date: Sun, 29 Mar 2026 13:51:54 -0400	[thread overview]
Message-ID: <aclmumCA5ADfT7-Z@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <20260326132655.1733873-8-ardb+git@google.com>

On Thu, Mar 26, 2026 at 02:26:57PM +0100, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> While it is true that each PE/COFF runtime driver in memory can
> generally be split into 3 different regions (the header, the code/rodata
> region and the data/bss region), each with different permissions, it
> does not mean that 3x the size of the memory map is a suitable upper
> bound. This is due to the fact that all runtime drivers could be
> coalesced into a single EFI runtime code region by the firmware, and if
> the firmware does a good job of keeping the fragmentation down, it is
> conceivable that the memory attributes table has more entries than the
> EFI memory map itself.
> 
> So instead, base the sanity check on whether the descriptor size matches
> the EFI memory map's descriptor size (which is not mandated by the spec
> but extremely unlikely to differ in practice), and whether the size of
> the whole table does not exceed 2 MiB.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

The 2MB limit is a bit odd to me - but then i don't see a legitimate
reason to need 50k+ entries here unless the system is doing something
absolutely nutty - it would mean a wildly fragmented system and most
likely an indicator of a bug rather than a legitimately intended
configuration.

Otherwise, this does seem like a better check regardless.

Reviewed-by: Gregory Price <gourry@gourry.net>


  reply	other threads:[~2026-03-29 17:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-26 13:26 [PATCH 0/5] x86/efi: Re-enable memory attributes table for kexec Ard Biesheuvel
2026-03-26 13:26 ` [PATCH 1/5] efi/memattr: Fix thinko in table size sanity check Ard Biesheuvel
2026-03-29 17:51   ` Gregory Price [this message]
2026-03-31  7:07     ` Ard Biesheuvel
2026-03-26 13:26 ` [PATCH 2/5] x86/efi: Gather initial memory reservation and table handling logic Ard Biesheuvel
2026-03-29 17:53   ` Gregory Price
2026-03-26 13:26 ` [PATCH 3/5] x86/efi: Defer the call to efi_memattr_init() Ard Biesheuvel
2026-03-26 13:27 ` [PATCH 4/5] efi: Use efi_mem_reserve() to reserve the memory attribute table Ard Biesheuvel
2026-03-26 13:27 ` [PATCH 5/5] x86/efi: Drop kexec quirk for the EFI memory attributes table Ard Biesheuvel
2026-03-29 17:55 ` [PATCH 0/5] x86/efi: Re-enable memory attributes table for kexec Gregory Price
2026-03-30 10:53 ` Dave Young

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=aclmumCA5ADfT7-Z@gourry-fedora-PF4VCD3F \
    --to=gourry@gourry.net \
    --cc=ardb+git@google.com \
    --cc=ardb@kernel.org \
    --cc=dyoung@redhat.com \
    --cc=jirislaby@kernel.org \
    --cc=leitao@debian.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=usamaarif642@gmail.com \
    --cc=x86@kernel.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.