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: <CA+CK2bDFUekHnh=XqLcLJS-VgTMrTRWPm4xgmXHWgFCd9JXYmw@mail.gmail.com>
Date: Mon, 18 Mar 2024 11:30:42 -0400
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Matthew Wilcox <willy@...radead.org>
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:19 AM Matthew Wilcox <willy@...radead.org> wrote:
>
> 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).

Hm, it means that stack is sleeping in the kernel space, and has its
stack pages mapped and invalidated on the local CPU, but access from
the remote CPU to that stack pages would be problematic.

I think we still won't need IPI, but VA-range invalidation is actually
needed on unmaps, and should happen during context switch so every
time we go off-cpu. Therefore, what Brian/Andy have suggested makes
more sense instead of kernel/enter/exit paths.

Pasha

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ