On 11/24/2017 12:29 AM, Dave Hansen wrote:
Although weird, the thought here was that pkey_mprotect() callers are new and should know about the interactions with PROT_EXEC. They can also*get* PROT_EXEC semantics if they want. The only wart here is if you do: mprotect(..., PROT_EXEC); // key 10 is now the PROT_EXEC key
I thought the PROT_EXEC key is always 1?
pkey_mprotect(..., PROT_EXEC, key=3); I'm not sure what this does. We should probably ensure that it returns an error.
Without protection key support, PROT_EXEC would imply PROT_READ with an ordinary mprotect. I think it makes sense to stick to this behavior. It is what I have documented for glibc:
<https://sourceware.org/ml/libc-alpha/2017-11/msg00841.html> Thanks, Florian -- To unsubscribe from this list: send the line "unsubscribe linux-x86_64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
