public inbox for linux-efi@vger.kernel.org
 help / color / mirror / Atom feed
From: Usama Arif <usamaarif642@gmail.com>
To: linux-efi@vger.kernel.org, devel@edk2.groups.io,
	kexec@lists.infradead.org
Cc: ardb@kernel.org, hannes@cmpxchg.org, dyoung@redhat.com,
	x86@kernel.org, linux-kernel@vger.kernel.org, leitao@debian.org,
	gourry@gourry.net, kernel-team@meta.com,
	Usama Arif <usamaarif642@gmail.com>
Subject: [RFC 1/2] efi/memattr: Use desc_size instead of total size to check for corruption
Date: Wed,  8 Jan 2025 21:53:36 +0000	[thread overview]
Message-ID: <20250108215957.3437660-2-usamaarif642@gmail.com> (raw)
In-Reply-To: <20250108215957.3437660-1-usamaarif642@gmail.com>

The commit in [1] introduced a check to see if EFI memory attributes
table was corrupted. It assumed that efi.memmap.nr_map remains
constant, but it changes during late boot.
Hence, the check is valid during cold boot, but not in the subsequent
kexec boot.

This is best explained with an exampled. At cold boot, for a test
machine:
efi.memmap.nr_map=91,
memory_attributes_table->num_entries=48,
desc_size = 48
Hence, the check introduced in [1] where 3x the size of the
entire EFI memory map is a reasonable upper bound for the size of this
table is valid.

In late boot __efi_enter_virtual_mode calls 2 functions that updates
efi.memmap.nr_map:
- efi_map_regions which reduces the `count` of map entries
  (for e.g. if should_map_region returns false) and which is reflected
  in efi.memmap by __efi_memmap_init.
  At this point efi.memmap.nr_map becomes 46 in the test machine.
- efi_free_boot_services which also reduces the number of memory regions
  available (for e.g. if md->type or md->attribute is not the right value).
  At this point efi.memmap.nr_map becomes 9 in the test machine.
Hence when you kexec into a new kernel and pass efi.memmap, the
paramaters that are compared are:
efi.memmap.nr_map=9,
memory_attributes_table->num_entries=48,
desc_size = 48
where the check in [1] is no longer valid with such a low efi.memmap.nr_map
as it was reduced due to efi_map_regions and efi_free_boot_services.

A more appropriate check is to see if the description size reported by
efi and memory attributes table is the same.

[1] https://lore.kernel.org/all/20241031175822.2952471-2-ardb+git@google.com/

Fixes: 8fbe4c49c0cc ("efi/memattr: Ignore table if the size is clearly bogus")
Reported-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Usama Arif <usamaarif642@gmail.com>
---
 drivers/firmware/efi/memattr.c | 16 ++++++----------
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/firmware/efi/memattr.c b/drivers/firmware/efi/memattr.c
index c38b1a335590..d3bc161361fb 100644
--- a/drivers/firmware/efi/memattr.c
+++ b/drivers/firmware/efi/memattr.c
@@ -40,21 +40,17 @@ int __init efi_memattr_init(void)
 		goto unmap;
 	}
 
-
 	/*
-	 * Sanity check: the Memory Attributes Table contains up to 3 entries
-	 * for each entry of type EfiRuntimeServicesCode in the EFI memory map.
-	 * So if the size of the table exceeds 3x the size of the entire EFI
-	 * memory map, there is clearly something wrong, and the table should
-	 * just be ignored altogether.
+	 * Sanity check: the Memory Attributes Table desc_size and
+	 * efi.memmap.desc_size should match.
 	 */
-	size = tbl->num_entries * tbl->desc_size;
-	if (size > 3 * efi.memmap.nr_map * efi.memmap.desc_size) {
-		pr_warn(FW_BUG "Corrupted EFI Memory Attributes Table detected! (version == %u, desc_size == %u, num_entries == %u)\n",
-			tbl->version, tbl->desc_size, tbl->num_entries);
+	if (efi.memmap.desc_size != tbl->desc_size) {
+		pr_warn(FW_BUG "Corrupted EFI Memory Attributes Table detected! (version == %u, table desc_size == %u, efi.memmap.desc_size == %lu, table num_entries == %u)\n",
+			tbl->version, tbl->desc_size, efi.memmap.desc_size, tbl->num_entries);
 		goto unmap;
 	}
 
+	size = tbl->num_entries * tbl->desc_size;
 	tbl_size = sizeof(*tbl) + size;
 	memblock_reserve(efi_mem_attr_table, tbl_size);
 	set_bit(EFI_MEM_ATTR, &efi.flags);
-- 
2.43.5


  reply	other threads:[~2025-01-08 22:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-08 21:53 [RFC 0/2] efi/memattr: Fix memory corruption and warning issues Usama Arif
2025-01-08 21:53 ` Usama Arif [this message]
2025-01-09 15:45   ` [RFC 1/2] efi/memattr: Use desc_size instead of total size to check for corruption Ard Biesheuvel
2025-01-09 16:36     ` Usama Arif
2025-01-10  7:21       ` Ard Biesheuvel
2025-01-10 10:53         ` Usama Arif
2025-01-10 17:25           ` Ard Biesheuvel
2025-01-13  2:33           ` Dave Young
2025-01-13 11:27             ` Usama Arif
2025-01-13 12:00               ` Usama Arif
2025-01-20 10:27                 ` Usama Arif
2025-01-20 10:32                   ` Ard Biesheuvel
2025-01-20 10:50                     ` Usama Arif
2025-01-20 11:29                       ` Ard Biesheuvel
2025-01-20 11:48                         ` Usama Arif
2025-01-22  5:36                           ` Dave Young
2025-01-22 11:50                             ` Usama Arif
2025-01-08 21:53 ` [RFC 2/2] efi/memattr: add efi_mem_attr_table as a reserved region in 820_table_firmware Usama Arif
2025-01-09 16:15   ` Ard Biesheuvel
2025-01-09 16:32     ` Usama Arif
2025-01-09 16:47       ` Gregory Price
2025-01-10  7:32       ` Ard Biesheuvel
2025-01-10 11:36         ` Breno Leitao
2025-01-10 17:33           ` Ard Biesheuvel
2025-01-10 14:31         ` Usama Arif
2025-01-10 15:50           ` Usama Arif
2025-01-10  2:50   ` Dave Young
2025-01-10 11:12     ` Usama Arif
2025-01-10 11:18       ` Dave Young
2025-01-10 11:20         ` Dave Young
2025-01-10 11:42           ` Usama Arif

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=20250108215957.3437660-2-usamaarif642@gmail.com \
    --to=usamaarif642@gmail.com \
    --cc=ardb@kernel.org \
    --cc=devel@edk2.groups.io \
    --cc=dyoung@redhat.com \
    --cc=gourry@gourry.net \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@meta.com \
    --cc=kexec@lists.infradead.org \
    --cc=leitao@debian.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox