[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