Re: [PATCH v11 25/25] x86/cet/shstk: Add arch_prctl functions for shadow stack
From: Dave Hansen <hidden>
Date: 2020-09-10 02:18:11
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 3:08 PM, Yu, Yu-cheng wrote:
After looking at this more, I found the changes are more similar to mprotect() than madvise(). We are going to change an anonymous mapping to a read-only mapping, and add the VM_SHSTK flag to it. Would an x86-specific mprotect(PROT_SHSTK) make more sense? One alternative would be requiring a read-only mapping for madvise(MADV_SHSTK). But that is inconvenient for the application.
Why? It's just: mmap()/malloc(); mprotect(PROT_READ); madvise(MADV_SHSTK); vs. mmap()/malloc(); mprotect(PROT_SHSTK); I'm not sure a single syscall counts as inconvenient. I don't quite think we should use a PROT_ bit for this. It seems like the kind of thing that could be fragile and break existing expectations. I don't care _that_ strongly though.