From: Dave Hansen > Sent: 09 February 2022 22:24 > > On 1/30/22 13:18, Rick Edgecombe wrote: > > 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 > > > > 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. > > > 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)
