On 11/23/2017 04:00 PM, Dave Hansen wrote: > On 11/23/2017 12:11 AM, Vlastimil Babka wrote: >>> No, the default is clearly 0 and documented to be so. The PROT_EXEC >>> emulation one should be inaccessible in all the APIs so does not even >>> show up as *being* a key in the API. The fact that it's implemented >>> with pkeys should be pretty immaterial other than the fact that you >>> can't touch the high bits in PKRU. >> So, just to be sure, if we call pkey_mprotect() with 0, will it blindly >> set 0, or the result of arch_override_mprotect_pkey() (thus equivalent >> to call with -1) ? I assume the latter? > > It's supposed to set 0. > > -1 was, as far as I remember, an internal-to-the-kernel-only thing to > tell us that a key came from *mprotect()* instead of pkey_mprotect(). So, pkey_mprotect(..., 0) will set it to 0, regardless of PROT_EXEC. pkey_mprotect(..., -1) or mprotect() will set it to 0-or-PROT_EXEC-pkey. Can't shake the feeling that it's somewhat weird, but I guess it's flexible at least. So just has to be well documented. > -- > To unsubscribe from this list: send the line "unsubscribe linux-api" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
