Ram Pai <linux...@us.ibm.com> writes:
> On Tue, Jun 19, 2018 at 10:40:13PM +1000, Michael Ellerman wrote:
>> Ram Pai <linux...@us.ibm.com> writes:
>>
>> > execute-only key is allocated dynamically. This is a problem. When a
>> > thread implicitly creates a execute-only key, and resets UAMOR for that
>> > key, the UAMOR value does not percolate to all the other threads. Any
>> > other thread may ignorantly change the permissions on the key. This can
>> > cause the key to be not execute-only for that thread.
>> >
>> > Preallocate the execute-only key and ensure that no thread can change
>> > the permission of the key, by resetting the corresponding bit in UAMOR.
>>
>> OK this is a non-ABI changing bug fix AFAICS.
>>
>> I'll add:
>>
>> Fixes: 5586cf61e108 ("powerpc: introduce execute-only pkey")
>> Cc: sta...@vger.kernel.org # v4.16+
>>
>> > diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
>> > index b681bec..1f2389f 100644
>> > --- a/arch/powerpc/mm/pkeys.c
>> > +++ b/arch/powerpc/mm/pkeys.c
>> > @@ -25,6 +25,7 @@
>> > #define IAMR_EX_BIT 0x1UL
>> > #define PKEY_REG_BITS (sizeof(u64)*8)
>> > #define pkeyshift(pkey) (PKEY_REG_BITS - ((pkey+1) * AMR_BITS_PER_PKEY))
>> > +#define EXECUTE_ONLY_KEY 2
>>
>> Do we ensure we have at least 3 keys anywhere?
>
> No. Good to add. Can this be different patch?
Yes please.
> However we do not have any systems with less than 16keys AFAICT.
It's controllable by firmware so we have between 0 and ∞ keys :)
But yeah you're right it's unlikely to be a bug anyone hits in practice.
cheers
