Re: [PATCH RFC 00/19] mm: Add __GFP_UNMAPPED

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

On 05/03/2026 16:58, Brendan Jackman wrote:
> On Thu Mar 5, 2026 at 2:51 PM UTC, Kevin Brodsky wrote:
>> [...]
>> This approach seems very interesting to me, and I wonder if it could be
>> applied to another use-case.
>>
>> I am working on a security feature to protect page table pages (PTPs)
>> using pkeys [1]. This relies on all PTPs being mapped with a specific
>> pkey (in the direct map). That requires changing a mapping attribute
>> rather than making it invalid, but AFAICT this is essentially the same
>> problem as the one you're trying to solve.
> Yeah, I think so:
>
> 1. The fragmentation issues seem exactly the same.

I believe so.

> 2. The TLB flushing issues are probably also basically the same, I
> assume you need to flush the TLB when you convert a page to use for
> pagetables, and without allocator integration that can happen pretty
> often and in hot paths. Correct?

Indeed. Up until v5 [2] no special allocator was used - the pkey was set
at the page level every time a PTP was allocated or freed. Clearly
suboptimal, and doesn't work at all if large mappings are used due to
the risk of recursion.

>> There are however extra challenges with mapping PTPs with special
>> attributes. The main one, which you mention in patch 17, is that
>> splitting the direct map may require allocating PTPs, which may lead to
>> recursion.
>>
>> [1] introduces a dedicated page table allocator on top of the buddy
>> allocator, which attempts to cache PMD-sized blocks if possible. It
>> ensures that no recursion occurs by using a special flag when allocating
>> PTPs while splitting the direct map, and keeping a reserve of pages
>> specifically for that situation (patch 15 and 24). 
> Right, and actually just today someone pointed out mm/execmem.c to me, I
> think execmem_cache_populate() is basically doing the same thing
> (although it's also creating a separate virtual mapping).

Ah interesting I didn't know about that cache. It does have
similarities, and the motivation seems similar too.

>> There is also special
>> handling for early page tables (essentially keeping track of them and
>> setting their pkey once we can split the direct map).
>>
>> Do you think that this freetype infrastructure could be used for that
>> purpose, instead of introducing a layer on top of the buddy allocator? 
> Yes!!! 100% definitely, my code certainly solves all your problems...

Almost ;)

>> I
>> expect that much of the special handling for allocating PTPs can be kept
>> separate. Ensuring that protected pages are always available to split
>> the direct map may be difficult though... This is deeply embedded in the
>> allocator I proposed.
> ...Oh, hm, well, um, good point. Thinking aloud a bit...
>
> The way this series dodges the question is (copying from the code
> comments in patch 17 for convenient reading):
>
> 1) - The direct map starts out fully mapped at boot. (This is not really
>  *   an assumption" as its in direct control of page_alloc.c).
>  *
> 2) - Once pages in the direct map are broken down, they are not
>  *   re-aggregated into larger pages again.
>  *
> 3) - Pagetables are never allocated with __GFP_UNMAPPED.
>  *
>  * Under these assumptions, a pagetable might need to be allocated while
>  * _unmapping_ stuff from the direct map during a __GFP_UNMAPPED
>  * allocation. But, the allocation of that pagetable never requires
>  * allocating a further pagetable.
>
> In other words, we might need to allocate while we allocate (which is
> fine because I have to do locking shenanigans anyway due to x86 TLB
> shootdown requirements), but there's no further recursion after that.
>
> Can we come up with an analogue for protected PTPs? Point 3) is
> the inflexible one, and we obviously can't say "PTPs are never allocated
> as PTPs". But if we invert it and _also_ invert point 1) I think we get
> something that works in principle:
>
> 1) The direct map starts out _fully protected_ (i.e. we treat everything
>    as if it's a pagetable at first).
>
> 2) We assume the direct map doesn't get reaggregated once we've broken
>    things down to serve PTP allocations
>
> 3) PTPs are always PTPs...
>
> But... this is a bit silly, since what it means is we'll then go through
> ~all the pagetblocks in the system (except the ones that _are_ actually
> used for PTPs) and flip their pkey, breaking down the physmap to
> pageblock granularity as we go. And... if we're gonna do that, we might
> as well just say the physmap has to be at pageblock granularity to begin
> with.

Having to change the pkey of every pageblock when allocating it for
anything but page tables seems rather unreasonable... And in case of
memory pressure, where fragmentation is high, we may not have any
protected pageblock left. The allocator I proposed falls back to order-2
allocations if necessary (which is sufficient to replenish the page
reserve even if PMD+PTE pages are allocated for splitting).

> (Could we do that? Maybe - Mike Rapoport has previously argued that
> physmap fragmentation is not a very big deal, so I guess the question
> is whether we're ready to really lean into that analysis, it would be
> quite painful if it turned out to be wrong).
>
> Another potential "dodge": Is it really important that the PTPs are
> always protected from the very moment they are created?
> Coz this feature still seems pretty useful even if there's an awkward
> fallback case where, under specific memory pressure patterns, we
> temporarily use unprotected pagetables to set up protected pagetables.
> That still makes exploiting a pagetable overwrite an order of magnitude
> harder than before, right? Similar to how there's probably ways to
> exploit bugs if you can get them to race with the intended pagetable
> update paths that flip the pkey register, or if you can get a ROP chain
> to flip that register for you or whatever.

I considered this - I agree that having page tables unprotected inside a
small window may be acceptable, considering that this is hardening and
not bullet-proof isolation. That said, I'm not sure it helps all that
much. You'd need a mechanism to defer setting the pkey for those PTPs.
Once you decide to set the pkey, you may very well end up splitting the
direct map again, deferring new PTPs... This could go on, and every time
fragmentation increases. I think it is really desirable to have that
reserve of pages so that splitting the direct map does not become
recursive (whether deferred or not).

- Kevin

[2]
https://lore.kernel.org/linux-hardening/20250815085512.2182322-1-kevin.brodsky@arm.com/