lkml.org 
[lkml]   [2022]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 17/39] mm: Fixup places that call pte_mkwrite() directly
On Thu, Sep 29, 2022 at 03:29:14PM -0700, Rick Edgecombe wrote:
> From: Yu-cheng Yu <yu-cheng.yu@intel.com>
>
> 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 <yu-cheng.yu@intel.com>

Reviewed-by: Kees Cook <keescook@chromium.org>

--
Kees Cook

\
 
 \ /
  Last update: 2022-10-03 20:25    [W:1.270 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site