On Thu, Nov 30, 2023 at 11:37:42PM +0000, Edgecombe, Rick P wrote:
On Thu, 2023-11-30 at 21:51 +0000, Mark Brown wrote:
On Thu, Nov 30, 2023 at 07:00:58PM +0000, Catalin Marinas wrote:
explicitly request a new shadow stack. There was some corner case with IIRC posix_nspawn() mentioned where the heuristics aren't what we want for example.
Can't posix_spawn() pass in a shadow stack size into clone3 to get a new shadow stack after this series?
Yes, the above was addressing Catalin's suggestion that we add stack size control separately to clone3() instead - doing that would remove the ability to explicitly request a new stack unless we add a flag to clone3() at which point we're back to modifying clone3() anyway.
Another dumb question on arm64 - is GCSPR_EL0 writeable by the user? If yes, can the libc wrapper for threads allocate a shadow stack via map_shadow_stack() and set it up in the thread initialisation handler before invoking the thread function?
We would need a syscall to allow GCSPR_EL0 to be written.
I think the problem with doing this is signals. If a signal is delivered to the new thread, then it could push to the old shadow stack before userspace gets a chance to switch. So the thread needs to start on a new shadow/stack.
That's an issue, plus using a syscall just wouldn't work with a security model that locked down writes to the pointer which does seem like something people would reasonably want to deploy.