Re: [PATCH v2 17/39] mm: Fixup places that call pte_mkwrite() directly
From: Kees Cook <hidden>
Date: 2022-10-03 18:24:20
Also in:
linux-arch, linux-doc, linux-mm, lkml
From: Kees Cook <hidden>
Date: 2022-10-03 18:24:20
Also in:
linux-arch, linux-doc, linux-mm, lkml
On Thu, Sep 29, 2022 at 03:29:14PM -0700, Rick Edgecombe wrote:
From: Yu-cheng Yu <redacted> 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(), which is the same as maybe_mkwrite() in logic and intention. Just change them to maybe_mkwrite(). - When userfaultfd is creating a PTE after userspace handles the fault it calls pte_mkwrite() directly. Teach it about pte_mkwrite_shstk() 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. Signed-off-by: Yu-cheng Yu <redacted>
Reviewed-by: Kees Cook <redacted> -- Kees Cook