[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9843cdfb-6cc6-40b1-94b3-768c48351945@sirena.org.uk>
Date: Wed, 30 Oct 2024 14:08:59 +0000
From: Mark Brown <broonie@...nel.org>
To: "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>
Cc: linux-kernel@...r.kernel.org, Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, jannh@...gle.com,
Yury Khrustalev <yury.khrustalev@....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 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.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists