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] [day] [month] [year] [list]
Message-ID: <Zv7AvSvcilHV1kSs@arm.com>
Date: Thu, 3 Oct 2024 17:05:17 +0100
From: Yury Khrustalev <yury.khrustalev@....com>
To: Christian Brauner <brauner@...nel.org>
CC: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>, Florian Weimer
	<fweimer@...hat.com>, "broonie@...nel.org" <broonie@...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>, "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>, "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 05:12:38PM +0200, Christian Brauner wrote:
> > Thanks for the info!
> > 
> > > 
> > > My preference is to keep the api consistent and require a stack_size for
> > > shadow stacks as well.
> > 
> > Did you catch that a token can be at a different offsets location on the stack
> > depending on args passed to map_shadow_stack? So userspace will need something
> > like the code above, but that adjusts the 'shadow_stack_size' such that the
> > kernel looks for the token in the right place. It will be even weirder if
> > someone uses clone3 to switch to a stack that has already been used, and pivoted
> > off of, such that a token was left in the middle of the stack. In that case
> > userspace would have to come up with args disconnected from the actual size of
> > the shadow stack such that the kernel would be cajoled into looking for the
> > token in the right place.
> > 
> > A shadow stack size is more symmetric on the surface, but I'm not sure it will
> > be easier for userspace to handle. So I think we should just have a pointer to
> > the token. But it will be a usable implementation either way.
> 
> Maybe it's best to let glibc folks decide what is better/more ergonomic for them.

I agree that it would be better to just have a pointer to the token.

My preference would be to avoid having obscure additional arguments that may end up
having misleading name or bear some hidden functionality. If kernel is not going to
use stack size as such, then users should not have to provide it.

Thanks,
Yury

PS Apologies for delayed reply


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ