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: 27+ 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-05-26 11:15 ` [PATCH RFC v8 02/24] set_memory: Introduce set_memory_pkey() stub Kevin Brodsky
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$(echo .)com \
--cc=akpm@linux-foundation$(echo .)org \
--cc=broonie@kernel$(echo .)org \
--cc=catalin.marinas@arm$(echo .)com \
--cc=dave.hansen@linux$(echo .)intel.com \
--cc=david@kernel$(echo .)org \
--cc=ira.weiny@intel$(echo .)com \
--cc=jannh@google$(echo .)com \
--cc=jeffxu@chromium$(echo .)org \
--cc=joey.gouly@arm$(echo .)com \
--cc=kees@kernel$(echo .)org \
--cc=linusw@kernel$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-hardening@vger$(echo .)kernel.org \
--cc=linux-mm@kvack$(echo .)org \
--cc=ljs@kernel$(echo .)org \
--cc=luto@kernel$(echo .)org \
--cc=maz@kernel$(echo .)org \
--cc=mbland@motorola$(echo .)com \
--cc=peterz@infradead$(echo .)org \
--cc=pierre.langlois@arm$(echo .)com \
--cc=qperret@google$(echo .)com \
--cc=rick.p.edgecombe@intel$(echo .)com \
--cc=rppt@kernel$(echo .)org \
--cc=ryan.roberts@arm$(echo .)com \
--cc=tglx@kernel$(echo .)org \
--cc=vbabka@kernel$(echo .)org \
--cc=will@kernel$(echo .)org \
--cc=willy@infradead$(echo .)org \
--cc=x86@kernel$(echo .)org \
--cc=yang@os$(echo .)amperecomputing.com \
--cc=yeoreum.yun@arm$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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