Re: [PATCH 0/5] Guarded Userspace Access Prevention on Radix

[Christophe LEROY <christophe.leroy@c-s.fr>]

Le 01/11/2018 à 04:54, Russell Currey a écrit :
> On Wed, 2018-10-31 at 17:58 +0100, LEROY Christophe wrote:
>> Russell Currey <ruscur@russell.cc> a écrit :
>>
>>> On Fri, 2018-10-26 at 18:29 +0200, LEROY Christophe wrote:
>>>> Russell Currey <ruscur@russell.cc> a écrit :
>>>>
>>>>> Guarded Userspace Access Prevention is a security mechanism
>>>>> that
>>>>> prevents
>>>>> the kernel from being able to read and write userspace
>>>>> addresses
>>>>> outside of
>>>>> the allowed paths, most commonly copy_{to/from}_user().
>>>>>
>>>>> At present, the only CPU that supports this is POWER9, and only
>>>>> while using
>>>>> the Radix MMU.  Privileged reads and writes cannot access user
>>>>> data
>>>>> when
>>>>> key 0 of the AMR is set.  This is described in the "Radix Tree
>>>>> Translation
>>>>> Storage Protection" section of the POWER ISA as of version 3.0.
>>>>
>>>> It is not right that only power9 can support that.
>>>
>>> It's true that not only P9 can support it, but there are more
>>> considerations under hash than radix, implementing this for radix
>>> is a
>>> first step.
>>
>> I don't know much about hash, but I was talking about the 8xx which
>> is
>> a nohash ppc32. I'll see next week if I can do something with it on
>> top of your serie.
> 
> My small brain saw the number 8 and assumed you were talking about
> POWER8, I didn't know what 8xx was until now.
> 
> Working on a refactor to make things a bit more generic, and removing
> the radix name and dependency from the config option.

In signal_32.c and signal_64.c, save_user_regs() calls __put_user() to 
modify code, then calls flush_icache_range() on user addresses.

Shouldn't flush_icache_range() be performed with userspace access 
protection unlocked ?

Christophe