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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <616011cf17f1654ac3ad8757f0f33425b3af1ddd.camel@intel.com>
Date: Fri, 15 Aug 2025 16:37:29 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "kevin.brodsky@....com" <kevin.brodsky@....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 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?)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ