Re: [PATCH RFC v9 14/25] mm: kpkeys: Protect vmemmap page tables

[Kevin Brodsky <kevin.brodsky@arm.com>]

On 18/08/2026 16:08, Kevin Brodsky wrote:
> 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:

Another issue that my friendly AI identified: using
kpkeys_physmem_pgtable_alloc() for vmemmap breaks the main assumption in
the previous patch, which is that those early page table pages are
contiguous. vmemmap backing pages and the PTPs that map them are
allocated serially, which means that we end up scattering vmemmap PTPs
in the middle of vmemmap backing pages. As a result we could run out of
space to track the early ranges to protect.

This was much less of an issue in RFC v6 [1] as early PTPs were
allocated in PMD-sized chunks. This removed most of the fragmentation
and allowed us to track all these early ranges without extra logic.

That said, allocating these pages in blocks adds complexity that isn't
really justified when we require the direct map to be PTE-mapped.
Considering David's comments on patch 13, the plan for the next version
[2] is instead to revert to the even earlier approach of walking all the
kernel page tables during early boot. This simplifies the whole series,
but it will need to be overhauled when we try to support block mappings
again.

- Kevin

[1]
https://lore.kernel.org/all/20260227175518.3728055-19-kevin.brodsky@arm.com/
[2]
https://lore.kernel.org/all/7af32e98-f2ab-4961-9e3c-72b8a21416c0@arm.com/