From: Hsin-Te Yuan <yuanhsinte@chromium.org>
To: Tzung-Bi Shih <tzungbi@kernel.org>,
Brian Norris <briannorris@chromium.org>,
Julius Werner <jwerner@chromium.org>
Cc: chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org,
Yidi Lin <yidilin@google.com>,
Hsin-Te Yuan <yuanhsinte@chromium.org>
Subject: [PATCH v2] firmware: google: coreboot_table: skip no-map CBMEM entries
Date: Fri, 17 Jul 2026 08:41:26 +0000 [thread overview]
Message-ID: <20260717-coreboot-v2-1-8f8b389e3758@chromium.org> (raw)
From: Yidi Lin <yidilin@google.com>
On ARM64 platforms, certain reserved memory regions (like those used
by pKVM) are marked with the 'no-map' property. This indicates that
the host kernel is forbidden from creating a structural mapping for
these regions.
The coreboot table may describe CBMEM entries that overlap with or are
entirely contained within these no-map regions. Attempting to populate
these entries as devices and subsequently remapping them can lead to
system crashes or security violations.
Refine the coreboot table population logic to verify that each CBMEM
entry resides in 'Known Good' memory before creating a device. An
entry is only considered safe if it is entirely System RAM or entirely
standard Reserved memory (tagged with IORES_DESC_RESERVED).
This dual-check ensures that:
1. On ARM64, no-map regions are filtered out as they are IORESOURCE_MEM
(see request_standard_resources() in arch/arm64/kernel/setup.c).
2. On x86, standard reserved regions (IORES_DESC_RESERVED) remain
supported.
Signed-off-by: Yidi Lin <yidilin@google.com>
Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
---
Changes in v2:
- Rephrase the commit message and code comment to be clear.
- Link to v1: https://lore.kernel.org/r/20260714-coreboot-v1-1-f59754d71b55@chromium.org
---
drivers/firmware/google/coreboot_table.c | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/google/coreboot_table.c b/drivers/firmware/google/coreboot_table.c
index e63933ff6747..993056a739ad 100644
--- a/drivers/firmware/google/coreboot_table.c
+++ b/drivers/firmware/google/coreboot_table.c
@@ -13,8 +13,10 @@
#include <linux/err.h>
#include <linux/init.h>
#include <linux/io.h>
+#include <linux/ioport.h>
#include <linux/kernel.h>
#include <linux/device-id/coreboot.h>
+#include <linux/mm.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
@@ -123,7 +125,7 @@ static int coreboot_table_populate(struct device *dev, void *ptr, resource_size_
ptr_end = ptr + len;
ptr_entry = ptr + header->header_bytes;
- for (i = 0; i < header->table_entries; i++) {
+ for (i = 0; i < header->table_entries; i++, ptr_entry += entry->size) {
if (ptr_entry + sizeof(*entry) > ptr_end)
return -EINVAL;
entry = ptr_entry;
@@ -147,6 +149,26 @@ static int coreboot_table_populate(struct device *dev, void *ptr, resource_size_
switch (device->entry.tag) {
case LB_TAG_CBMEM_ENTRY:
+ /*
+ * Skip entries that are not exclusively System RAM or
+ * Reserved memory.
+ * On ARM64, no-map regions are filtered out as they are
+ * IORESOURCE_MEM (see request_standard_resources() in
+ * arch/arm64/kernel/setup.c).
+ * On x86, CBMEM often resides in standard reserved regions
+ * (IORES_DESC_RESERVED).
+ */
+ if (region_intersects(device->cbmem_entry.address,
+ device->cbmem_entry.entry_size,
+ IORESOURCE_SYSTEM_RAM,
+ IORES_DESC_NONE) != REGION_INTERSECTS &&
+ region_intersects(device->cbmem_entry.address,
+ device->cbmem_entry.entry_size,
+ IORESOURCE_MEM,
+ IORES_DESC_RESERVED) != REGION_INTERSECTS) {
+ kfree(device);
+ continue;
+ }
dev_set_name(&device->dev, "cbmem-%08x",
device->cbmem_entry.id);
break;
@@ -155,8 +177,6 @@ static int coreboot_table_populate(struct device *dev, void *ptr, resource_size_
break;
}
- ptr_entry += entry->size;
-
ret = device_register(&device->dev);
if (ret) {
dev_warn(dev, "failed to register coreboot device: %d\n", ret);
---
base-commit: 3b029c035b34bbc693405ddf759f0e9b920c27f1
change-id: 20260714-coreboot-41aca4c383bc
Best regards,
--
Hsin-Te Yuan <yuanhsinte@chromium.org>
next reply other threads:[~2026-07-17 8:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-17 8:41 Hsin-Te Yuan [this message]
2026-07-20 2:56 ` Tzung-Bi Shih
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=20260717-coreboot-v2-1-8f8b389e3758@chromium.org \
--to=yuanhsinte@chromium.org \
--cc=briannorris@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=jwerner@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tzungbi@kernel.org \
--cc=yidilin@google.com \
/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
all inboxes | Powered by JetHome®