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]

Date: Mon, 18 Mar 2024 12:57:32 -0400
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: David Laight <David.Laight@...lab.com>
Cc: Matthew Wilcox <willy@...radead.org>, "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

> I think you'll need to broadcast an invalidate.
> Consider:
> CPU A: task allocates extra pages and adds something to some list.
> CPU B: accesses that data and maybe modifies it.
>         Some page-table walk setup ut the TLB.
> CPU A: task detects the modify, removes the item from the list,
>         collapses back the stack and sleeps.
>         Stack pages freed.
> CPU A: task wakes up (on the same cpu for simplicity).
>         Goes down a deep stack and puts an item on a list.
>         Different physical pages are allocated.
> CPU B: accesses the associated KVA.
>         It better not have a cached TLB.
>
> Doesn't that need an IPI?

Yes, this is annoying. If we share a stack with another CPU, then get
a new stack, and share it again with another CPU we get in trouble.
Yet, IPI during context switch would kill the performance :-\

I wonder if there is a way to optimize this scenario like doing IPI
invalidation only after stack sharing?

Pasha