Re: [PATCH v8 0/5] arm64: support FEAT_BBM level 2 and large block mapping when rodata=full

[Ryan Roberts <ryan.roberts@arm.com>]

On 17/03/2026 09:29, Kevin Brodsky wrote:
> On 17/03/2026 10:13, Ryan Roberts wrote:
>>>>> Another option would be to initially map by pte then collapse to
>>>>> block mappings
>>>>> once we have determined that all cpus support BBML2_NOABORT. We
>>>>> originally opted
>>>>> not to do that because it's a tax on symetric systems. But we could
>>>>> throw in the
>>>>> towel if it's the least bad solution we can come up with for solving
>>>>> this. I
>>>>> think it might help some of Kevin's use cases too?
>>>> May be an option too. When we discussed this there was no usecase for
>>>> direct mapping collapse. But if we can have multiple usecases, it may
>>>> be worth it. 
>> I could imagine that if user space creates and destroys lots of secretmem areas,
>> then it will completely split the linear map to ptes and that will never recover
>> currently. So I think in the long term, having the ability to collapse would be
>> useful. I just don't particularly like forcing symetric systems to map by pte
>> initially (which is slow) only to collapse later (which will cost even more
>> time). But it does feel inherrently more robust.
> 
> Now that you spell it out, I'm realising this would actually make things
> pretty complicated for protected page tables. In that series, page
> tables for the linear map are allocated by a separate memblock-based
> allocator [1], tracking the allocated ranges to set their pkey later.
> There's a strong assumption that these page tables are never freed.
> 
> If we initially PTE-mapped the linear map and then later collapsed it,
> that assumption clearly wouldn't hold. 

Sorry I don't understand why the assumptions change? All I'm proposing is walkng
the linear map to find compatible PTEs and collapsing them into the biggest
possible blocks. The pages aren't being freed, they are just being mapped
differently (which can be done live for BBML2_NOABORT). PTEs with different
pkeys would be considered incompatible, so we would end up with a boundary in
the leaf mappings at that point.

> It could be handled by poking
> holes in the tracked ranges, but it gets ugly and increases fragmentation.

You'd still want page tables to be allocated from contiguous physical (and
virtual) memory so that the boundaries where pkeys change are minimized.

I guess I've misunderstood something...

> 
> On the whole I'm not sure there's a sufficiently good argument to always
> have the linear map PTE-mapped initially.
> 
> - Kevin
> 
> [1]
> https://lore.kernel.org/linux-hardening/20260227175518.3728055-19-kevin.brodsky@arm.com/
>