The 11/30/2023 21:51, Mark Brown wrote: > The concern Rick raised was that allowing user to pick the exact shadow > stack pointer would allow userspace to corrupt or reuse the stack of an > existing thread by starting a new thread with the shadow stack pointing > into the existing shadow stack of that thread. While in isolation note that this can be prevented by map_shadow_stack adding a token that clone3 verifies. > that's not too much more than what userspace could just do directly > anyway it might compose with other issues to something more "interesting" > (eg, I'd be a bit concerned about overlap with pkeys/POE though I've not > thought through potential uses in detail). > > > I'm not against clone3() getting a shadow_stack_size argument but asking > > some more questions. If we won't pass a pointer as well, is there any > > advantage in expanding this syscall vs a specific prctl() option? Do we > > need a different size per thread or do all threads have the same shadow > > stack size? A new RLIMIT doesn't seem to map well though, it is more > > like an upper limit rather than a fixed/default size (glibc I think uses > > it for thread stacks but bionic or musl don't AFAIK). > > I don't know what the userspace patterns are likely to be here, it's > possible a single value for each process might be fine but I couldn't > say that confidently. I agree that a RLIMIT does seem like a poor fit. user code can control the thread stack size per thread and different size per thread happens in practice (even in the libc e.g. timer_create with SIGEV_THREAD uses different stack size than the dns resolver helper thread). IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
