linux-kernel - Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3()

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: <5464b915b52bf3b91ec70201736479a5347838af.camel@intel.com>
Date: Wed, 21 Aug 2024 15:54:49 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "broonie@...nel.org" <broonie@...nel.org>
CC: "dietmar.eggemann@....com" <dietmar.eggemann@....com>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
	"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>, "vincent.guittot@...aro.org"
	<vincent.guittot@...aro.org>, "fweimer@...hat.com" <fweimer@...hat.com>,
	"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>, "linux-api@...r.kernel.org"
	<linux-api@...r.kernel.org>, "vschneid@...hat.com" <vschneid@...hat.com>,
	"brauner@...nel.org" <brauner@...nel.org>, "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>, "catalin.marinas@....com"
	<catalin.marinas@....com>, "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 Wed, 2024-08-21 at 13:45 +0100, Mark Brown wrote:
> On Wed, Aug 21, 2024 at 01:45:16AM +0000, Edgecombe, Rick P wrote:
> > On Wed, 2024-08-21 at 01:19 +0100, Mark Brown wrote:
> 
> > > I think it's going to be strange one way or another, either you specify
> > > a size that we don't currently really use or you have two things both
> > > called stacks which are described differently.
> 
> > I would guess users of raw clone3 calls would be able to handle that kind of
> > variation.
> 
> Oh, I'm sure people could cope either way - it's more a question of
> clarity and not causing people go do needless investigations to try to
> figure out what's going on than anything else.

Yes, it won't be a disaster either way.

> 
> > I was just trying to figure out why there is both the pointer and size for
> > normal stacks. It seems that one usage is that you don't have to worry about
> > whether your arch's stack grows up or down. But otherwise, the previous
> > clone's
> > didn't need the size. Before clone3 the stack size users seem to be kernel
> > threads, so when they unified the infrastructure behind kernel_clone_args,
> > stack_size was needed for the struct. Could it be that it just leaked to
> > userspace for that reason? I don't know, but I would think a tweak to such a
> > fundamental syscall should have some purposeful design behind it.
> 
> It's entirely possible it just leaked.  My own attempts to dig through
> the archives haven't turned up anything on the subjecti either, it seems
> to have been there from the get go and just gone in without comment.
> Equally it could just be that people felt that this was a more tasteful
> way of specifying stacks, or that some future use was envisioned.

Ok, well I'm suspicious, but won't object over it. The rest seems settled from
my side. I may try to attract some other x86 attention to that CMPXCHG helper,
but otherwise.

> 
> > >   I suppose we could call
> > > a single parameter shadow_stack_pointer?  Though I do note that as you
> > > indicated we've been going for some time and this is the first time it
> > > came up...
> 
> > Sorry for that. I looked through all the old threads expecting to find
> > discussion, but couldn't find an answer. Is clone3 support a dependency for
> > arm
> > shadow stacks?
> 
> Catalin didn't want to merge the arm64 support without clone3(), and
> there's code dependencies as a result.  I could unpick it and reverse
> the ordering so long as the arm64 maintainers are OK with that since the
> overlap is in the implementation of copy_thread() and some of the
> dependency patches.