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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ