On 15/08/2025 18:37, Edgecombe, Rick P wrote: > On Fri, 2025-08-15 at 09:55 +0100, Kevin Brodsky wrote: >> diff --git a/include/linux/mm.h b/include/linux/mm.h >> index d9371d992033..4880cb7a4cb9 100644 >> --- a/include/linux/mm.h >> +++ b/include/linux/mm.h >> @@ -34,6 +34,7 @@ >> #include <linux/slab.h> >> #include <linux/cacheinfo.h> >> #include <linux/rcuwait.h> >> +#include <linux/kpkeys.h> >> >> struct mempolicy; >> struct anon_vma; >> @@ -2979,6 +2980,8 @@ static inline bool __pagetable_ctor(struct ptdesc >> *ptdesc) >> >> __folio_set_pgtable(folio); >> lruvec_stat_add_folio(folio, NR_PAGETABLE); >> + if (kpkeys_protect_pgtable_memory(folio)) >> + return false; >> return true; >> } > It seems like this does a kernel range shootdown for every page table that > gets > allocated? If so it throws a pretty big wrench into the carefully managed TLB > flush minimization logic in the kernel. > > Obviously this is much more straightforward then the x86 series' page table > conversion batching stuff, but TBH I was worried that even that was going to > have a performance hit. I think how to efficiently do direct map permissions > is > the key technical problem to solve for pkeys security usages. They can switch > on > and off fast, but applying the key is just as much of a hit as any other > kernel > memory permission. (I assume this works the similarly to x86's?)
The benchmarking results (see cover letter) don't seem to point to a major performance hit from setting the pkey on arm64 (worth noting that the linear mapping is PTE-mapped on arm64 today so no splitting should occur when setting the pkey). The overhead may well be substantially higher on x86. I agree this is worth looking into, though. I will check the overhead added by set_memory_pkey() specifically (ignoring pkey register switches), and maybe try to allocate page tables with a dedicated kmem_cache instead, reusing this patch [1] from my other kpkeys series. A kmem_cache won't be as optimal as a dedicated allocator, but batching the page freeing may already improve things substantially. - Kevin [1] https://lore.kernel.org/linux-hardening/20250815090000.2182450-4-kevin.brod...@arm.com/
