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:

quoted

On Thu, Nov 30, 2023 at 07:00:58PM +0000, Catalin Marinas wrote:

quoted

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.

quoted

quoted

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?

quoted

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.