On Wed, May 17, 2023 at 1:14 AM Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
>
> On 5/15/23 06:05, jeffxu@xxxxxxxxxxxx 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?
There are different options how we can address this:
1) having a generic mseal() API as Jeff mentioned
2) tagging all code pages with the pkey we're using
(would this affect memory sharing between processes?)
3) prevent this with seccomp + userspace validation
If we have pkey support, we will only create executable memory using
pkey_mprotect and everything else can be blocked with seccomp. This would still
allow turning R-X memory into RW- memory, but you can't change it back without
going through our codepath that has added validation.
There's a similar challenge with making RO memory writable. For this we'll need
to use approach 1) or 2) instead.
> 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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
