On Mon, Jun 09, 2025 at 01:54:05PM +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 the 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. 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. > > 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>
LGTM. I've tested this change on the FVP model along with my Glibc patch series [1] and confirm that it works fine. The Glibc patch is at RFC stage and will require more work, but it's enough to test this series. Tested-by: Yury Khrustalev <yury.khrusta...@arm.com> [1]: https://inbox.sourceware.org/libc-alpha/20250610151320.885131-1-yury.khrusta...@arm.com/ Thanks, Yury
