The 06/22/2023 16:46, Edgecombe, Rick P wrote: > You previously said: > > On Wed, 2023-06-21 at 12:36 +0100, szabolcs.nagy@xxxxxxx wrote: > > as far as i can tell the current unwinder handles shstk unwinding > > correctly across signal handlers (sync or async and > > cleanup/exceptions > > handlers too), i see no issue with "fixed shadow stack signal frame > > size of 8 bytes" other than future extensions and discontinous shstk. > > I took that to mean that you didn't see how the the existing unwinder > prevented alt shadow stacks. Hopefully we're all on the same page now. well alt shstk is discontinous. there were two separate confusions: - your mention of fnon-call-exception threw me off since that is a very specific corner case. - i was talking about an unwind design that can deal with altshstk which requires ssp switch. (current uwinder does not support this, but i assumed we can add that now and ignore old broken unwinders). you are saying that alt shstk support needs additional shstk tokens in the signal frame to maintain alt shstk state for the kernel. i think now we are on the same page. > BTW, when alt shadow stack's were POCed, I hadn't encountered this GCC > behavior yet. So it was assumed it could be bolted on later without > disturbing anything. If Linus or someone wants to say we're ok with > breaking these old GCCs in this way, the first thing I would do would > be to pad the shadow stack signal frame with room for alt shadow stack > and more. I actually have a patch to do this, but alas we are already > pushing it regression wise. sounds like it will be hard to add alt shstk later. (i think maintaining alt shstk state on the stack instead of shstk should work too. but if that does not work, then alt shstk will require another abi opt-in.)
