On 2/10/22 15:40, Edgecombe, Rick P wrote:

On Thu, 2022-02-10 at 15:07 -0800, Andy Lutomirski wrote:

quoted

On Thu, Feb 10, 2022 at 2:44 PM Dave Hansen [off-list ref]
wrote:

quoted

On 1/30/22 13:18, Rick Edgecombe wrote:

quoted

INCSSP(Q/D) increments shadow stack pointer and 'pops and
discards' the
first and the last elements in the range, effectively touches
those memory
areas.

The maximum moving distance by INCSSPQ is 255 * 8 = 2040 bytes
and
255 * 4 = 1020 bytes by INCSSPD.  Both ranges are far from
PAGE_SIZE.
Thus, putting a gap page on both ends of a shadow stack prevents
INCSSP,
CALL, and RET from going beyond.

What is the downside of not applying this patch?  The shadow stack
gap
is 1MB instead of 4k?

That, frankly, doesn't seem too bad.  How badly do we *need* this
patch?

Like just using VM_SHADOW_STACK | VM_GROWSDOWN to get a regular stack
sized gap? I think it could work. It also simplifies the mm->stack_vm
accounting.

Seems not crazy.  Do we want automatically growing shadow stacks?  I 
don't really like the historical unix behavior where the main thread has 
a sort-of-infinite stack and every other thread has a fixed stack.

It would no longer get a gap at the end though. I don't think it's
needed.

I may have missed something about the oddball way the mm code works, but 
it seems if you have a gap at one end of every shadow stack, you 
automatically have a gap at the other end.