On Mon, 2023-06-26 at 15:08 +0100, szabolcs.nagy@arm.com wrote:

The 06/22/2023 16:46, Edgecombe, Rick P wrote:

quoted

You previously said:

On Wed, 2023-06-21 at 12:36 +0100, szabolcs.nagy@arm.com wrote:

quoted

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.

I don't think I fully understand your point still. It would really help
if you could do a levelset summary, like I asked on other branches of
this thread.

quoted

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.

Adding alt shadow stack without moving the elf bit runs the risk of
regressions because of the old GCCs. But moving the elf bit is easy
(from the technical side at least). There were several threads about
this in the past.

So I don't think any harder than it is now.

(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.)

The x86 sigframe is pretty full AFAIK. There are already features that
require an opt in. It might be true that the alt shadow stack base and
size don't need to be protected like the previous SSP. I'd have to
think about it. It could be nice to optionally put some IBT stuff on
the shadow stack as well, which would require growing the frame, and at
that point the alt shadow stack stuff might as well go there too.