Thread (123 messages) 123 messages, 12 authors, 2018-08-14

Re: [RFC PATCH v2 16/27] mm: Modify can_follow_write_pte/pmd for shadow stack

From: Yu-cheng Yu <hidden>
Date: 2018-07-17 23:04:25
Also in: linux-api, linux-doc, linux-mm, lkml

On Wed, 2018-07-11 at 11:29 +0200, Peter Zijlstra wrote:
On Tue, Jul 10, 2018 at 03:26:28PM -0700, Yu-cheng Yu wrote:
quoted
There are three possible shadow stack PTE settings:

  Normal SHSTK PTE: (R/O + DIRTY_HW)
  SHSTK PTE COW'ed: (R/O + DIRTY_HW)
  SHSTK PTE shared as R/O data: (R/O + DIRTY_SW)
I count _2_ distinct states there.
quoted
Update can_follow_write_pte/pmd for the shadow stack.
So the below disallows can_follow_write when shstk && _PAGE_DIRTY_SW,
but this here Changelog doesn't explain why. Doesn't even get close.
Can we add the following to the log:

When a SHSTK PTE is shared, it is (R/O + DIRTY_SW); otherwise it is
(R/O + DIRTY_HW).

When we (FOLL_WRITE | FOLL_FORCE) on a SHSTK PTE, the following
must be true:

  - It has been COW'ed at least once (FOLL_COW is set);
  - It still is not shared, i.e. PTE is (R/O + DIRTY_HW);
Also, the code is a right mess :/ Can't we try harder to not let this
shadow stack stuff escape arch code.
We either check here if the VMA is SHSTK mapping or move the logic
to pte_dirty().  The latter would be less obvious.  Or can we
create a can_follow_write_shstk_pte()?

Yu-cheng
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help