On 9/9/2020 4:29 PM, Dave Hansen wrote:
On 9/9/20 4:25 PM, Yu, Yu-cheng wrote:
On 9/9/2020 4:11 PM, Dave Hansen wrote:
On 9/9/20 4:07 PM, Yu, Yu-cheng wrote:
What if a writable mapping is passed to madvise(MADV_SHSTK)? Should
that be rejected?
It doesn't matter to me. Even if it's readable, it _stops_ being even
directly readable after it's a shadow stack, right? I don't think
writes are special in any way. If anything, we *want* it to be writable
because that indicates that it can be written to, and we will want to
write to it soon.
But in a PROT_WRITE mapping, all the pte's have _PAGE_BIT_RW set. To
change them to shadow stack, we need to clear that bit from the pte's.
That will be like mprotect_fixup()/change_protection_range().
The page table hardware bits don't matter. The user-visible protection
effects matter.
For instance, we have PROT_EXEC, which *CLEARS* a hardware NX PTE bit.
The PROT_ permissions are independent of the hardware.
Same for shadow stack here. We consider shadow stack "writable", but we
want to clear _PAGE_BIT_RW, which is set for the PTEs of the other type
of "writable" mapping. To change a writable data mapping to a writable
shadow stack mapping, we need to call change_protection_range().
I don't think the interface should be influenced at *all* by what whacko
PTE bit combinations we have to set to get the behavior.
