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: <77bc051d-b2c9-4e3a-b956-be8879048e20@sirena.org.uk>
Date: Wed, 21 Aug 2024 13:45:47 +0100
From: Mark Brown <broonie@...nel.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "dietmar.eggemann@....com" <dietmar.eggemann@....com>,
	"juri.lelli@...hat.com" <juri.lelli@...hat.com>,
	"shuah@...nel.org" <shuah@...nel.org>,
	"Szabolcs.Nagy@....com" <Szabolcs.Nagy@....com>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	"debug@...osinc.com" <debug@...osinc.com>,
	"mgorman@...e.de" <mgorman@...e.de>,
	"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
	"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>,
	"vincent.guittot@...aro.org" <vincent.guittot@...aro.org>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"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>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH RFT v9 4/8] fork: Add shadow stack support to clone3()

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.

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

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

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)