From: Dave Hansen

Sent: 09 February 2022 22:24

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.

This is a pretty close copy of the instruction reference text for
INCSSP.  I'm feeling rather dense today, but that's just not making any
sense.

The pseudocode is more sensible in the SDM.  I think this needs a better
explanation:

	The INCSSP instruction increments the shadow stack pointer.  It
	is the shadow stack analog of an instruction like:

		addq	$0x80, %rsp

	However, there is one important difference between an ADD on
	%rsp and INCSSP.  In addition to modifying SSP, INCSSP also
	reads from the memory of the first and last elements that were
	"popped".  You can think of it as acting like this:

	READ_ONCE(ssp);       // read+discard top element on stack
	ssp += nr_to_pop * 8; // move the shadow stack
	READ_ONCE(ssp-8);     // read+discard last popped stack element

quoted

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.

... That maximum distance, combined with an a guard pages at the end of
a shadow stack ensures that INCSSP will fault before it is able to move
across an entire guard page.

quoted

Thus, putting a gap page on both ends of a shadow stack prevents INCSSP,
CALL, and RET from going beyond.

Do you need a real guard page?
Or is it just enough to ensure that the adjacent page isn't another
shadow stack page?

Any other page will cause a fault because the PTE isn't readonly+dirty.

I'm not sure how common single page allocates are in Linux.
But adjacent shadow stacks may be rare anyway.
So a check against both adjacent PTE entries would suffice.
Or maybe always allocate an even (or odd) numbered page.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)