[PATCH v5 05/10] powerpc: Add a framework for Kernel Userspace Access Protection

Michael Ellerman mpe at ellerman.id.au
Wed Mar 20 23:57:24 AEDT 2019

Christophe Leroy <christophe.leroy at c-s.fr> writes:
> Le 08/03/2019 à 02:16, Michael Ellerman a écrit :
>> From: Christophe Leroy <christophe.leroy at c-s.fr>
>> This patch implements a framework for Kernel Userspace Access
>> Protection.
>> Then subarches will have the possibility to provide their own
>> implementation by providing setup_kuap() and
>> allow/prevent_user_access().
>> Some platforms will need to know the area accessed and whether it is
>> accessed from read, write or both. Therefore source, destination and
>> size and handed over to the two functions.
>> mpe: Rename to allow/prevent rather than unlock/lock, and add
>> read/write wrappers. Drop the 32-bit code for now until we have an
>> implementation for it. Add kuap to pt_regs for 64-bit as well as
>> 32-bit. Don't split strings, use pr_crit_ratelimited().
>> Signed-off-by: Christophe Leroy <christophe.leroy at c-s.fr>
>> Signed-off-by: Russell Currey <ruscur at russell.cc>
>> Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
>> ---
>> v5: Futex ops need read/write so use allow_user_acccess() there.
>>      Use #ifdef CONFIG_PPC64 in kup.h to fix build errors.
>>      Allow subarch to override allow_read/write_from/to_user().
> Those little helpers that will just call allow_user_access() when 
> distinct read/write handling is not performed looks overkill to me.
> Can't the subarch do it by itself based on the nullity of from/to ?
> static inline void allow_user_access(void __user *to, const void __user 
> *from,
> 				     unsigned long size)
> {
> 	if (to & from)
> 		set_kuap(0);
> 	else if (to)
> 		set_kuap(AMR_KUAP_BLOCK_READ);
> 	else if (from)
> 		set_kuap(AMR_KUAP_BLOCK_WRITE);
> }

You could implement it that way, but it reads better at the call sites
if we have:

	allow_write_to_user(uaddr, sizeof(*uaddr));
	allow_user_access(uaddr, NULL, sizeof(*uaddr));

So I'm inclined to keep them. It should all end up inlined and generate
the same code at the end of the day.


More information about the Linuxppc-dev mailing list