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