Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack
From: Dave Hansen <hidden>
Date: 2020-09-10 02:26:29
Also in:
linux-arch, linux-doc, linux-mm, lkml
Possibly related (same subject, not in this thread)
- 2020-09-02 · Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack · Dave Martin <Dave.Martin@arm.com>
- 2020-09-01 · Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack · Yu, Yu-cheng <hidden>
- 2020-09-01 · Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack · H.J. Lu <hidden>
- 2020-09-01 · Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack · Florian Weimer <hidden>
- 2020-09-01 · Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack · Dave Hansen <hidden>
On 9/9/20 4:25 PM, Yu, Yu-cheng wrote:
On 9/9/2020 4:11 PM, Dave Hansen wrote:quoted
On 9/9/20 4:07 PM, Yu, Yu-cheng wrote:quoted
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. 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.