[PATCH 19/25] powerpc: implementation for arch_vma_access_permitted()
Michael Ellerman
mpe at ellerman.id.au
Wed Oct 25 02:48:00 AEDT 2017
Ram Pai <linuxram at us.ibm.com> writes:
> diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
> index 24589d9..21c3b42 100644
> --- a/arch/powerpc/mm/pkeys.c
> +++ b/arch/powerpc/mm/pkeys.c
> @@ -320,3 +320,46 @@ bool arch_pte_access_permitted(u64 pte, bool write, bool execute)
> return pkey_access_permitted(pte_to_pkey_bits(pte),
> write, execute);
> }
> +
> +/*
> + * We only want to enforce protection keys on the current process
> + * because we effectively have no access to AMR/IAMR for other
> + * processes or any way to tell *which * AMR/IAMR in a threaded
> + * process we could use.
This comment doesn't match the code, or at least is confusing to me.
A "threaded process" is two tasks that have the same mm. ie. where
current->mm == vma->mm.
And in that case we *do* enforce protection, based on the AMR/IAMR of
the current thread.
> + * So do not enforce things if the VMA is not from the current
> + * mm, or if we are in a kernel thread.
> + */
> +static inline bool vma_is_foreign(struct vm_area_struct *vma)
> +{
> + if (!current->mm)
> + return true;
> + /*
> + * if the VMA is from another process, then AMR/IAMR has no
> + * relevance and should not be enforced.
> + */
> + if (current->mm != vma->vm_mm)
> + return true;
ie. threaded processes end up here, because they *do* share an mm.
> +
> + return false;
> +}
> +
> +bool arch_vma_access_permitted(struct vm_area_struct *vma,
> + bool write, bool execute, bool foreign)
> +{
> + int pkey;
> +
> + if (!pkey_inited)
> + return true;
> +
> + /* allow access if the VMA is not one from this process */
> + if (foreign || vma_is_foreign(vma))
> + return true;
> +
> + pkey = vma_pkey(vma);
> +
> + if (!pkey)
> + return true;
I think I'd prefer if we didn't special case key 0, instead just let it
go through to pkey_access_permitted().
> +
> + return pkey_access_permitted(pkey, write, execute);
> +}
cheers
More information about the Linuxppc-dev
mailing list