On Tue, May 16, 2023 at 4:14 PM Dave Hansen dave.hansen@intel.com wrote:
On 5/15/23 06:05, jeffxu@chromium.org wrote:
--- a/arch/x86/mm/pkeys.c +++ b/arch/x86/mm/pkeys.c @@ -20,7 +20,7 @@ int __execute_only_pkey(struct mm_struct *mm) /* Do we need to assign a pkey for mm's execute-only maps? */ if (execute_only_pkey == -1) { /* Go allocate one to use, which might fail */
execute_only_pkey = mm_pkey_alloc(mm);
execute_only_pkey = mm_pkey_alloc(mm, 0); if (execute_only_pkey < 0) return -1; need_to_set_mm_pkey = true;In your threat model, what mechanism prevents the attacker from modifying executable mappings?
I was trying to figure out if the implicit execute-only pkey should have the PKEY_ENFORCE_API bit set. I think that in particular would probably cause some kind of ABI breakage, but it still reminded me that I have an incomplete picture of the threat model.
Yes. The main reason for not adding it now is the ABI breakage. As a next step, we could potentially develop mseal(), which fits more to the code segment. The PKEY_ENFORCE_API allows munmap(), so the user case is slightly different.
I will leave the threat model / V8 specific question to Stephan.