linux-kernel - Re: [PATCH RFT v11 0/8] fork: Support shadow stacks in 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: <ZyJFfngdWBXidczc@arm.com>
Date: Wed, 30 Oct 2024 14:41:02 +0000
From: Yury Khrustalev <yury.khrustalev@....com>
To: Mark Brown <broonie@...nel.org>
CC: "Rick P. Edgecombe" <rick.p.edgecombe@...el.com>, Deepak Gupta
	<debug@...osinc.com>, Szabolcs Nagy <Szabolcs.Nagy@....com>, "H.J. Lu"
	<hjl.tools@...il.com>, Florian Weimer <fweimer@...hat.com>, Thomas Gleixner
	<tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
	<bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, <x86@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>,
	"Juri Lelli" <juri.lelli@...hat.com>, Vincent Guittot
	<vincent.guittot@...aro.org>, Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>, Mel
 Gorman <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>,
	"Christian Brauner" <brauner@...nel.org>, Shuah Khan <shuah@...nel.org>,
	<linux-kernel@...r.kernel.org>, Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>, <jannh@...gle.com>, Wilco Dijkstra
	<wilco.dijkstra@....com>, <linux-kselftest@...r.kernel.org>,
	<linux-api@...r.kernel.org>, Kees Cook <kees@...nel.org>, Shuah Khan
	<skhan@...uxfoundation.org>
Subject: Re: [PATCH RFT v11 0/8] fork: Support shadow stacks in clone3()

On Wed, Oct 30, 2024 at 02:08:59PM +0000, Mark Brown wrote:
> On Sat, Oct 05, 2024 at 11:31:27AM +0100, Mark Brown wrote:
> > The kernel has recently added support for shadow stacks, currently
> > x86 only using their CET feature but both arm64 and RISC-V have
> > equivalent features (GCS and Zicfiss respectively), I am actively
> > working on GCS[1].  With shadow stacks the hardware maintains an
> > additional stack containing only the return addresses for branch
> > instructions which is not generally writeable by userspace and ensures
> > that any returns are to the recorded addresses.  This provides some
> > protection against ROP attacks and making it easier to collect call
> > stacks.  These shadow stacks are allocated in the address space of the
> > userspace process.
> 
> Does anyone have any thoughts on this?  I reworked things to specify the
> address for the shadow stack pointer rather than the extent of the stack
> as Rick and Yuri suggested, otherwise the only change from the prior
> version was rebasing onto the arm64 GCS support since that's queued in
> -next.  I think the only substantial question is picking the ABI for
> specifying the shadow stack.

I will need more time to review this as both my primary and shadow stacks
are full with other work. At a glance, I cannot offer any informed opinion
for choosing ABI atm. Apologies for the delay.

Kind regards,
Yury