On Fri, Dec 02, 2022 at 04:35:45PM -0800, Rick Edgecombe wrote: > From: Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx> > > The x86 Control-flow Enforcement Technology (CET) feature includes a new > type of memory called shadow stack. This shadow stack memory has some > unusual properties, which requires some core mm changes to function > properly. > > With the introduction of shadow stack memory there are two ways a pte can > be writable: regular writable memory and shadow stack memory. > > In past patches, maybe_mkwrite() has been updated to apply pte_mkwrite() > or pte_mkwrite_shstk() depending on the VMA flag. This covers most cases > where a PTE is made writable. However, there are places where pte_mkwrite() > is called directly and the logic should now also create a shadow stack PTE > in the case of a shadow stack VMA. > > - do_anonymous_page() and migrate_vma_insert_page() check VM_WRITE > directly and call pte_mkwrite(). Teach it about pte_mkwrite_shstk() > > - When userfaultfd is creating a PTE after userspace handles the fault > it calls pte_mkwrite() directly. Teach it about pte_mkwrite_shstk() > > To make the code cleaner, introduce is_shstk_write() which simplifies > checking for VM_WRITE | VM_SHADOW_STACK together. > > In other cases where pte_mkwrite() is called directly, the VMA will not > be VM_SHADOW_STACK, and so shadow stack memory should not be created. > - In the case of pte_savedwrite(), shadow stack VMA's are excluded. > - In the case of the "dirty_accountable" optimization in mprotect(), > shadow stack VMA's won't be VM_SHARED, so it is not nessary. > > Tested-by: Pengfei Xu <pengfei.xu@xxxxxxxxx> > Tested-by: John Allen <john.allen@xxxxxxx> > Signed-off-by: Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx> Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx> -- Kees Cook
