The 08/24/2023 16:43, Catalin Marinas wrote: > Is there a use-case for the unlocked configuration to allow disabling > the GCS implicitly via a clone syscall? how would you handle clone or clone3 without gcs specified? (in the cases when clone creates a new thread with new stack) (1) fail. (2) allocate gcs. (3) disable gcs. the problem with (1) is that it requires changes to user code (this only affects code outside the libc doing something special since raw clone thread cannot call into the libc, all executing code have to be tightly controlled. i don't know how common this is, but i at least expect it in test code for system level tools like debuggers, strace, valgrind, qemu-system, seccomp filters etc. if it appears in actual use then that's a deployment issue for distros: note that changing clone to clone3 is non-trivial: it requires fallback logic and may have to deal with seccomp filters). problem with (2) is that the size policy and lifetime management is in the kernel then. (since only special cases are affected i guess that is ok, but i assumed we want to avoid this by moving to clone3 and user managed gcs). the problem with (3) is escaping the security measure, however it only applies to very special threads that can always decide to opt-in to gcs, so i don't see this as such a bad option and at least bw compat with existing code. (in my threat model the attacker cannot hijack clone syscalls as that seems stronger than hijacking return addresses.) so i guess the answer depends on how much headache failing raw clone may cause and i don't know that.
