On 03/10/2022 19:30, Kees Cook wrote:
> On Thu, Sep 29, 2022 at 03:29:15PM -0700, Rick Edgecombe wrote:
>> [...]
>> +unsigned long stack_guard_start_gap(struct vm_area_struct *vma)
>> +{
>> + if (vma->vm_flags & VM_GROWSDOWN)
>> + return stack_guard_gap;
>> +
>> + /*
>> + * Shadow stack pointer is moved by CALL, RET, and INCSSP(Q/D).
>> + * INCSSPQ moves shadow stack pointer up to 255 * 8 = ~2 KB
>> + * (~1KB for INCSSPD) and touches the first and the last element
>> + * in the range, which triggers a page fault if the range is not
>> + * in a shadow stack. Because of this, creating 4-KB guard pages
>> + * around a shadow stack prevents these instructions from going
>> + * beyond.
>> + *
>> + * Creation of VM_SHADOW_STACK is tightly controlled, so a vma
>> + * can't be both VM_GROWSDOWN and VM_SHADOW_STACK
>> + */
> Thank you for the details on how the size choice is made here! :)
(In case anyone is hankering for some premature optimisation...)
You don't actually need a hole to create a guard. Any mapping of type
!= shstk will do.
If you've got a load of threads, you can tightly pack stack / shstk /
stack / shstk with no holes, and they each act as each other guard pages.
~Andrew
