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.khrustalev@arm.com Reviewed-by: Rick Edgecombe rick.p.edgecombe@intel.com Reviewed-by: Catalin Marinas catalin.marinas@arm.com Signed-off-by: Mark Brown broonie@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