> On Aug 17, 2021, at 12:53 PM, Borislav Petkov <bp@xxxxxxxxx> wrote: > > On Tue, Aug 17, 2021 at 11:24:29AM -0700, Yu, Yu-cheng wrote: >> 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
