On Mon, 2023-03-06 at 17:31 +0100, Florian Weimer wrote: > Ideally, we would implement the backtrace function (in glibc) as just > a > shadow stack copy. But this needs to follow the chain of alternate > stacks, and it may also need some form of markup for signal handler > frames (which need program counter adjustment to reflect that a > *non-signal* frame is conceptually nested within the previous > instruction, and not the function the return address points to). In the alt shadow stack case, the shadow stack sigframe will have a special shadow stack frame with a pointer to the shadow stack stack it came from. This may be a thread stack, or some other stack. This writeup in the v2 of the series has more details and analysis on the signal piece: https://lore.kernel.org/lkml/20220929222936.14584-1-rick.p.edgecombe@xxxxxxxxx/ So in that design, you should be able to backtrace out of a chain of alt stacks. > But I > think we can add support for this incrementally. Yea, I think so too. > > I assume there is no desire at all on the kernel side that > sigaltstack > transparently allocates the shadow stack? It could have some nice benefit for some apps, so I did look into it. > Because there is no > deallocation function today for sigaltstack? Yea, this is why we can't do it transparently. There was some discussion up the thread on this.
