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.
Attachment:
signature.asc
Description: PGP signature
