On Thu, Sep 18, 2025 at 01:38:53PM +0100, Will Deacon wrote: > On Tue, Sep 16, 2025 at 12:12:09AM +0100, Mark Brown wrote: > > Unlike with the normal stack there is no API for configuring the shadow > > stack for a new thread, instead the kernel will dynamically allocate a > > new shadow stack with the same size as the normal stack. This appears to > > be due to the shadow stack series having been in development since > > before the more extensible clone3() was added rather than anything more > > deliberate. > > > > Add a parameter to clone3() specifying a shadow stack pointer to use > > for the new thread, this is inconsistent with the way we specify the > > normal stack but during review concerns were expressed about having to > > identify where the shadow stack pointer should be placed especially in > > cases where the shadow stack has been previously active. If no shadow > > stack is specified then the existing implicit allocation behaviour is > > maintained. > > > > If a shadow stack pointer is specified then it is required to have an > > architecture defined token placed on the stack, this will be consumed by > > the new task, the shadow stack is specified by pointing to this token. If > > no valid token is present then this will be reported with -EINVAL. This > > token prevents new threads being created pointing at the shadow stack of > > an existing running thread. On architectures with support for userspace > > pivoting of shadow stacks it is expected that the same format and placement > > of tokens will be used, this is the case for arm64 and x86. > > > > If the architecture does not support shadow stacks the shadow stack > > pointer must be not be specified, architectures that do support the > > feature are expected to enforce the same requirement on individual > > systems that lack shadow stack support. > > > > Update the existing arm64 and x86 implementations to pay attention to > > the newly added arguments, in order to maintain compatibility we use the > > existing behaviour if no shadow stack is specified. Since we are now > > using more fields from the kernel_clone_args we pass that into the > > shadow stack code rather than individual fields. > > > > Portions of the x86 architecture code were written by Rick Edgecombe. > > > > Acked-by: Yury Khrustalev <yury.khrusta...@arm.com> > > Reviewed-by: Rick Edgecombe <rick.p.edgeco...@intel.com> > > Reviewed-by: Catalin Marinas <catalin.mari...@arm.com> > > Signed-off-by: Mark Brown <broo...@kernel.org> > > --- > > arch/arm64/mm/gcs.c | 47 +++++++++++++++++++- > > arch/x86/include/asm/shstk.h | 11 +++-- > > arch/x86/kernel/process.c | 2 +- > > arch/x86/kernel/shstk.c | 53 ++++++++++++++++++++--- > > include/asm-generic/cacheflush.h | 11 +++++ > > include/linux/sched/task.h | 17 ++++++++ > > include/uapi/linux/sched.h | 9 ++-- > > kernel/fork.c | 93 > > ++++++++++++++++++++++++++++++++++------ > > 8 files changed, 217 insertions(+), 26 deletions(-) > > It would be great if Christian could give this the thumbs up, given that > it changes clone3(). I think the architecture parts are all ready at this > point.
ah, I may have spoken too soon :/ Catalin pointed me at this glibc thread: https://marc.info/?l=glibc-alpha&m=175811917427562 which sounds like they're not entirely on board with the new ABI. Will
