The 07/10/2023 22:56, Edgecombe, Rick P wrote: > On Mon, 2023-07-10 at 17:54 +0100, szabolcs.nagy@xxxxxxx wrote: > > in short the only important change for v1 is shstk sizing. > > I tried searching through this long thread and AFAICT this is a new > idea. Sorry if I missed something, but your previous answer on this(3) > seemed concerned with the opposite problem (oversized shadow stacks). > > Quoted from a past mail: > On Mon, 2023-07-03 at 19:19 +0100, szabolcs.nagy@xxxxxxx wrote: ... > > - tiny thread stack but big sigaltstack (musl libc, go). and 4 months earlier: > Date: Fri, 3 Mar 2023 16:30:37 +0000 > Subject: Re: [PATCH v7 01/41] Documentation/x86: Add CET shadow stack description > > Looking at this again, I'm not sure why a new rlimit is needed. It > > seems many of those points were just formulations of that the clone3 > > stack size was not used, but it actually is and just not documented. If > > you disagree perhaps you could elaborate on what the requirements are > > and we can see if it seems tricky to do in a follow up. > > - tiny thread stack and deep signal stack. > (note that this does not really work with glibc because it has > implementation internal signals that don't run on alt stack, > cannot be masked and don't fit on a tiny thread stack, but > with other runtimes this can be a valid use-case, e.g. musl > allows tiny thread stacks, < pagesize.) ... that analysis was wrong: it considered handling any signals at all, but if the stack overflows due to a recursive call with empty stack frames then the stack gets used up at the same rate as the shadow stack and since the signal handler on the alt stack uses the same shadow stack that can easily overflow too independently of the stack size. this is a big deal as it affects what operations the libc can support and handling stack overflow is a common requirement. i originally argued for a fix using separate alt shadow stacks, but since it became clear that does not work for the x86 v1 abi i am recommending the size increase. with shadow stack size = stack size + 1 page, libc can document a depth limit for the alt stack that works. (longjumping back to the alt stack is still broken though, but that's rarely a requirement) > Also glibc would have to size ucontext shadow stacks with an additional yes, assuming glibc wants to support sigaltstack. > page as well. I think it would be good to get some other signs of > interest on this tweak due to the requirements for glibc to participate > on the scheme. Can you gather that quickly, so we can get this all > prepped again? i can cc libc-alpha. the decision is for x86 shadow stack linux abi to use shadow stack size = stack size or shadow stack size = stack size + 1 page as default policy when alt stack signals use the same shadow stack, not a separate one. note: smallest stack frame size is 8bytes, same as the shadow stack entry. on a target where smallest frame size is 2x shadow stack entry size, the formula would use (stack size / 2). note: there is no api to change the policy from userspace at this point.