linux-hardening - Re: [RFC PATCH v5 13/18] mm: Map page tables with privileged pkey

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b6579c2a-2262-4279-81a5-8235092bea13@arm.com>
Date: Mon, 18 Aug 2025 18:02:44 +0200
From: Kevin Brodsky <kevin.brodsky@....com>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
 "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Cc: "maz@...nel.org" <maz@...nel.org>, "luto@...nel.org" <luto@...nel.org>,
 "willy@...radead.org" <willy@...radead.org>,
 "mbland@...orola.com" <mbland@...orola.com>,
 "david@...hat.com" <david@...hat.com>,
 "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
 "rppt@...nel.org" <rppt@...nel.org>, "joey.gouly@....com"
 <joey.gouly@....com>, "akpm@...ux-foundation.org"
 <akpm@...ux-foundation.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "catalin.marinas@....com" <catalin.marinas@....com>,
 "Weiny, Ira" <ira.weiny@...el.com>, "vbabka@...e.cz" <vbabka@...e.cz>,
 "pierre.langlois@....com" <pierre.langlois@....com>,
 "jeffxu@...omium.org" <jeffxu@...omium.org>,
 "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
 "lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
 "kees@...nel.org" <kees@...nel.org>,
 "ryan.roberts@....com" <ryan.roberts@....com>,
 "tglx@...utronix.de" <tglx@...utronix.de>,
 "jannh@...gle.com" <jannh@...gle.com>,
 "peterz@...radead.org" <peterz@...radead.org>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>, "will@...nel.org" <will@...nel.org>,
 "qperret@...gle.com" <qperret@...gle.com>,
 "linux-mm@...ck.org" <linux-mm@...ck.org>,
 "broonie@...nel.org" <broonie@...nel.org>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [RFC PATCH v5 13/18] mm: Map page tables with privileged pkey

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.brodsky@arm.com/