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?)
