From: Kevin Brodsky <kevin.brodsky@arm.com>
To: linux-hardening@vger.kernel.org
Cc: Kevin Brodsky <kevin.brodsky@arm.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
"David Hildenbrand (Arm)" <david@kernel.org>,
Ira Weiny <ira.weiny@intel.com>, Jann Horn <jannh@google.com>,
Jeff Xu <jeffxu@chromium.org>, Joey Gouly <joey.gouly@arm.com>,
Kees Cook <kees@kernel.org>, Linus Walleij <linusw@kernel.org>,
Marc Zyngier <maz@kernel.org>, Mark Brown <broonie@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Maxwell Bland <mbland@motorola.com>,
"Mike Rapoport (IBM)" <rppt@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Pierre Langlois <pierre.langlois@arm.com>,
Quentin Perret <qperret@google.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Vlastimil Babka <vbabka@kernel.org>,
Will Deacon <will@kernel.org>,
Yang Shi <yang@os.amperecomputing.com>,
Yeoreum Yun <yeoreum.yun@arm.com>,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
x86@kernel.org, Lorenzo Stoakes <ljs@kernel.org>,
Thomas Gleixner <tglx@kernel.org>
Subject: [PATCH RFC v8 14/24] mm: kpkeys: Protect vmemmap page tables
Date: Tue, 26 May 2026 12:16:03 +0100 [thread overview]
Message-ID: <20260526-kpkeys-v8-14-eaaacdacc67c@arm.com> (raw)
In-Reply-To: <20260526-kpkeys-v8-0-eaaacdacc67c@arm.com>
When the kpkeys_hardened_pgtables feature is enabled, make sure that
vmemmap page tables are protected by using:
* The standard pagetable_alloc() if the buddy allocator is
available, as it already allocates protected memory.
* The memblock-based kpkeys allocator for early allocations.
These allocators are not NUMA-aware, so the page tables may be
allocated on any node. This could potentially incur some overhead on
large NUMA systems.
The arm64 hotplug code is also amended to use a matching
pagetable_free(), ensuring that the pkey is reset when the page
tables are freed. x86 already uses pagetable_free() on that path.
Unlike in vmemmap_alloc_block(), __GFP_RETRY_MAYFAIL is not used as
it isn't justified for allocating page tables - this disables the
OOM and we do not have a fallback if we fail to allocate page
tables. See previous discussion linked below.
Link: https://lore.kernel.org/all/38d2a358-4146-bfc9-2a4f-68ce02f75c94@suse.cz/
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
This is a minimal patch to protect vmemmmap page tables. More work
may be needed here:
* Restoring NUMA awareness
* Moving the arm64 change to a separate commit?
* General refactoring of how these page tables are allocated: since
we are not using the standard per-level functions (e.g.
pmd_alloc()), we are not calling pagetable_*_ctor() or
ptdesc_set_kernel(). [Maybe that doesn't matter because these page
tables can only be freed via vmemmap_free()?]
---
arch/arm64/mm/mmu.c | 2 +-
mm/sparse-vmemmap.c | 33 +++++++++++++++++++++++++--------
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 493310cf0486..dc69553d6326 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -1441,7 +1441,7 @@ static void free_hotplug_page_range(struct page *page, size_t size,
static void free_hotplug_pgtable_page(struct page *page)
{
- free_hotplug_page_range(page, PAGE_SIZE, NULL);
+ pagetable_free(page_ptdesc(page));
}
static bool pgtable_range_aligned(unsigned long start, unsigned long end,
diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
index 6eadb9d116e4..c93f5b9f4a26 100644
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@ -184,13 +184,29 @@ pte_t * __meminit vmemmap_pte_populate(pmd_t *pmd, unsigned long addr, int node,
return pte;
}
-static void * __meminit vmemmap_alloc_block_zero(unsigned long size, int node)
+static void * __meminit vmemmap_alloc_pgtable(int node)
{
- void *p = vmemmap_alloc_block(size, node);
+ void *p;
+
+ if (slab_is_available()) {
+ gfp_t gfp = GFP_KERNEL | __GFP_ZERO;
+ struct ptdesc *ptdesc = pagetable_alloc(gfp, 0);
+
+ return ptdesc ? ptdesc_address(ptdesc) : NULL;
+ }
+
+ if (kpkeys_hardened_pgtables_early_enabled()) {
+ phys_addr_t phys = kpkeys_physmem_pgtable_alloc();
+
+ p = phys ? phys_to_virt(phys) : NULL;
+ } else {
+ p = __earlyonly_bootmem_alloc(node, PAGE_SIZE, PAGE_SIZE,
+ __pa(MAX_DMA_ADDRESS));
+ }
if (!p)
return NULL;
- memset(p, 0, size);
+ memset(p, 0, PAGE_SIZE);
return p;
}
@@ -199,7 +215,7 @@ pmd_t * __meminit vmemmap_pmd_populate(pud_t *pud, unsigned long addr, int node)
{
pmd_t *pmd = pmd_offset(pud, addr);
if (pmd_none(*pmd)) {
- void *p = vmemmap_alloc_block_zero(PAGE_SIZE, node);
+ void *p = vmemmap_alloc_pgtable(node);
if (!p)
return NULL;
kernel_pte_init(p);
@@ -212,7 +228,7 @@ pud_t * __meminit vmemmap_pud_populate(p4d_t *p4d, unsigned long addr, int node)
{
pud_t *pud = pud_offset(p4d, addr);
if (pud_none(*pud)) {
- void *p = vmemmap_alloc_block_zero(PAGE_SIZE, node);
+ void *p = vmemmap_alloc_pgtable(node);
if (!p)
return NULL;
pmd_init(p);
@@ -225,7 +241,7 @@ p4d_t * __meminit vmemmap_p4d_populate(pgd_t *pgd, unsigned long addr, int node)
{
p4d_t *p4d = p4d_offset(pgd, addr);
if (p4d_none(*p4d)) {
- void *p = vmemmap_alloc_block_zero(PAGE_SIZE, node);
+ void *p = vmemmap_alloc_pgtable(node);
if (!p)
return NULL;
pud_init(p);
@@ -238,7 +254,7 @@ pgd_t * __meminit vmemmap_pgd_populate(unsigned long addr, int node)
{
pgd_t *pgd = pgd_offset_k(addr);
if (pgd_none(*pgd)) {
- void *p = vmemmap_alloc_block_zero(PAGE_SIZE, node);
+ void *p = vmemmap_alloc_pgtable(node);
if (!p)
return NULL;
pgd_populate_kernel(addr, pgd, p);
@@ -351,10 +367,11 @@ static __meminit struct page *vmemmap_get_tail(unsigned int order, struct zone *
* memmap_init().
*/
- p = vmemmap_alloc_block_zero(PAGE_SIZE, node);
+ p = vmemmap_alloc_block(PAGE_SIZE, node);
if (!p)
return NULL;
+ memset(p, 0, PAGE_SIZE);
tail = virt_to_page(p);
zone->vmemmap_tails[idx] = tail;
--
2.51.2
next prev parent reply other threads:[~2026-05-26 11:18 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 11:15 [PATCH RFC v8 00/24] pkeys-based page table hardening Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 01/24] mm: Introduce kpkeys Kevin Brodsky
2026-05-26 13:17 ` Linus Walleij
2026-05-27 8:24 ` Kevin Brodsky
2026-06-16 15:32 ` David Hildenbrand (Arm)
2026-06-16 15:19 ` David Hildenbrand (Arm)
2026-05-26 11:15 ` [PATCH RFC v8 02/24] set_memory: Introduce set_memory_pkey() stub Kevin Brodsky
2026-06-16 15:41 ` David Hildenbrand (Arm)
2026-05-26 11:15 ` [PATCH RFC v8 03/24] arm64: mm: Enable overlays for all EL1 indirect permissions Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 04/24] arm64: Introduce por_elx_set_pkey_perms() helper Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 05/24] arm64: Implement asm/kpkeys.h using POE Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 06/24] arm64: set_memory: Implement set_memory_pkey() Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 07/24] arm64: Context-switch POR_EL1 Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 08/24] arm64: Initialize POR_EL1 register on cpu_resume() Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 09/24] arm64: Enable kpkeys Kevin Brodsky
2026-05-26 11:15 ` [PATCH RFC v8 10/24] memblock: Move INIT_MEMBLOCK_* macros to header Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 11/24] mm: kpkeys: Introduce kpkeys_hardened_pgtables feature Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 12/24] mm: kpkeys: Protect regular page tables Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 13/24] mm: kpkeys: Introduce early page table allocator Kevin Brodsky
2026-05-26 11:16 ` Kevin Brodsky [this message]
2026-05-26 11:16 ` [PATCH RFC v8 15/24] mm: kpkeys: Introduce hook for protecting static page tables Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 16/24] arm64: kpkeys: Implement arch_supports_kpkeys_early() Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 17/24] arm64: kpkeys: Support KPKEYS_CTX_PGTABLES Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 18/24] arm64: kpkeys: Ensure the linear map can be modified Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 19/24] arm64: kpkeys: Protect early page tables Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 20/24] arm64: kpkeys: Protect init_pg_dir Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 21/24] arm64: kpkeys: Guard page table writes Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 22/24] arm64: kpkeys: Batch KPKEYS_CTX_PGTABLES switches Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 23/24] arm64: kpkeys: Enable kpkeys_hardened_pgtables support Kevin Brodsky
2026-05-26 11:16 ` [PATCH RFC v8 24/24] mm: Add basic tests for kpkeys_hardened_pgtables Kevin Brodsky
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=20260526-kpkeys-v8-14-eaaacdacc67c@arm.com \
--to=kevin.brodsky@arm.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=ira.weiny@intel.com \
--cc=jannh@google.com \
--cc=jeffxu@chromium.org \
--cc=joey.gouly@arm.com \
--cc=kees@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=luto@kernel.org \
--cc=maz@kernel.org \
--cc=mbland@motorola.com \
--cc=peterz@infradead.org \
--cc=pierre.langlois@arm.com \
--cc=qperret@google.com \
--cc=rick.p.edgecombe@intel.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=tglx@kernel.org \
--cc=vbabka@kernel.org \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=yang@os.amperecomputing.com \
--cc=yeoreum.yun@arm.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 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.