linux-kernel - Re: [RFC 00/14] Dynamic Kernel Stacks

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: <Zfhblk609XJn5clL@casper.infradead.org>
Date: Mon, 18 Mar 2024 15:19:50 +0000
From: Matthew Wilcox <willy@...radead.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: David Laight <David.Laight@...lab.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Kent Overstreet <kent.overstreet@...ux.dev>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"x86@...nel.org" <x86@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
	"brauner@...nel.org" <brauner@...nel.org>,
	"bristot@...hat.com" <bristot@...hat.com>,
	"bsegall@...gle.com" <bsegall@...gle.com>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"dianders@...omium.org" <dianders@...omium.org>,
	"dietmar.eggemann@....com" <dietmar.eggemann@....com>,
	"eric.devolder@...cle.com" <eric.devolder@...cle.com>,
	"hca@...ux.ibm.com" <hca@...ux.ibm.com>,
	"hch@...radead.org" <hch@...radead.org>,
	"jacob.jun.pan@...ux.intel.com" <jacob.jun.pan@...ux.intel.com>,
	"jgg@...pe.ca" <jgg@...pe.ca>,
	"jpoimboe@...nel.org" <jpoimboe@...nel.org>,
	"jroedel@...e.de" <jroedel@...e.de>,
	"juri.lelli@...hat.com" <juri.lelli@...hat.com>,
	"kinseyho@...gle.com" <kinseyho@...gle.com>,
	"kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
	"lstoakes@...il.com" <lstoakes@...il.com>,
	"luto@...nel.org" <luto@...nel.org>,
	"mgorman@...e.de" <mgorman@...e.de>,
	"mic@...ikod.net" <mic@...ikod.net>,
	"michael.christie@...cle.com" <michael.christie@...cle.com>,
	"mingo@...hat.com" <mingo@...hat.com>,
	"mjguzik@...il.com" <mjguzik@...il.com>,
	"mst@...hat.com" <mst@...hat.com>,
	"npiggin@...il.com" <npiggin@...il.com>,
	"peterz@...radead.org" <peterz@...radead.org>,
	"pmladek@...e.com" <pmladek@...e.com>,
	"rick.p.edgecombe@...el.com" <rick.p.edgecombe@...el.com>,
	"rostedt@...dmis.org" <rostedt@...dmis.org>,
	"surenb@...gle.com" <surenb@...gle.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"urezki@...il.com" <urezki@...il.com>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"vschneid@...hat.com" <vschneid@...hat.com>
Subject: Re: [RFC 00/14] Dynamic Kernel Stacks

On Mon, Mar 18, 2024 at 11:09:47AM -0400, Pasha Tatashin wrote:
> The TLB load is going to be exactly the same as today, we already use
> small pages for VMA mapped stacks. We won't need to have extra
> flushing either, the mappings are in the kernel space, and once pages
> are removed from the page table, no one is going to access that VA
> space until that thread enters the kernel again. We will need to
> invalidate the VA range only when the pages are mapped, and only on
> the local cpu.

No; we can pass pointers to our kernel stack to other threads.  The
obvious one is a mutex; we put a mutex_waiter on our own stack and
add its list_head to the mutex's waiter list.  I'm sure you can
think of many other places we do this (eg wait queues, poll(), select(),
etc).