On Aug 17, 2021, at 12:53 PM, Borislav Petkov [off-list ref] wrote:

On Tue, Aug 17, 2021 at 11:24:29AM -0700, Yu, Yu-cheng wrote:

quoted

Indeed, this can be looked at in a few ways.  We can visualize pte_write()
as 'CPU can write to it with MOV' or 'CPU can write to it with any opcodes'.
Depending on whatever pte_write() is, copy-on-write code can be adjusted
accordingly.

Can be?

I think you should exclude shadow stack pages from being writable
and treat them as read-only. How the CPU writes them is immaterial -
pte/pmd_write() is used by normal kernel code to query whether the page
is writable or not by any instruction - not by the CPU.

And since normal kernel code cannot write shadow stack pages, then for
that code those pages are read-only.

If special kernel code using shadow stack management insns needs
to modify a shadow stack, then it can check whether a page is
pte/pmd_shstk() but that code is special anyway.

Hell, a shadow stack page is (Write=0, Dirty=1) so calling it writable
                 ^^^^^^^
is simply wrong.

But it *is* writable using WRUSS, and it’s also writable by CALL, WRSS, etc.

Now if the mm code tries to write protect it and expects sensible semantics, the results could be interesting. At the very least, someone would need to validate that RET reading a read only shadow stack page does the right thing.

Thx.

-- 
Regards/Gruss,
   Boris.

https://people.kernel.org/tglx/notes-about-netiquette