[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b7ef38c9-1e87-468f-94a5-a3c7f209d200@sirena.org.uk>
Date: Wed, 2 Oct 2024 14:42:48 +0100
From: Mark Brown <broonie@...nel.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "brauner@...nel.org" <brauner@...nel.org>,
"dietmar.eggemann@....com" <dietmar.eggemann@....com>,
"shuah@...nel.org" <shuah@...nel.org>,
"Szabolcs.Nagy@....com" <Szabolcs.Nagy@....com>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"debug@...osinc.com" <debug@...osinc.com>,
"mgorman@...e.de" <mgorman@...e.de>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"rostedt@...dmis.org" <rostedt@...dmis.org>,
"hjl.tools@...il.com" <hjl.tools@...il.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"fweimer@...hat.com" <fweimer@...hat.com>,
"vschneid@...hat.com" <vschneid@...hat.com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"kees@...nel.org" <kees@...nel.org>,
"will@...nel.org" <will@...nel.org>,
"hpa@...or.com" <hpa@...or.com>,
"jannh@...gle.com" <jannh@...gle.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"yury.khrustalev@....com" <yury.khrustalev@....com>,
"bp@...en8.de" <bp@...en8.de>,
"wilco.dijkstra@....com" <wilco.dijkstra@....com>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"bsegall@...gle.com" <bsegall@...gle.com>,
"juri.lelli@...hat.com" <juri.lelli@...hat.com>,
"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3()
On Tue, Oct 01, 2024 at 11:03:10PM +0000, Edgecombe, Rick P wrote:
> On Tue, 2024-10-01 at 18:33 +0100, Mark Brown wrote:
> > My suspicion would be that if we're doing the pivot to a previously used
> > shadow stack we'd also be pivoting the regular stack along with it which
> > would face similar issues with having an unusual method for specifying
> > the stack top so I don't know how much we're really winning.
> I'm not so sure. The thing is a regular stack can be re-used in full - just set
> the RSP to the end and take advantage of the whole stack. A shadow stack can
> only be used where there is a token.
Yeah, I'm not sure how appealing it is trying to use a memory pool with
of shadow stacks - like you say you can't reset the top of the stack so
you need to keep track of that when the stack becomes unused. If the
users don't leave the SSP at the top of the stack then unless writes
have been enabled (which has security issues) then gradually the size of
the shadow stacks will be eroded which will need to be managed. You
could do it, but it's clearly not really how things are supposed to
work. The use case with starting a new worker thread for an existing in
use state seems much more appealing.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists