Christophe Leroy <christophe.le...@csgroup.eu> writes:
> Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
>> Reviewed-by: Sandipan Das <sandi...@linux.ibm.com>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.ku...@linux.ibm.com>
>> ---
>> arch/powerpc/mm/book3s64/pkeys.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/book3s64/pkeys.c
>> b/arch/powerpc/mm/book3s64/pkeys.c
>> index f747d66cc87d..84f8664ffc47 100644
>> --- a/arch/powerpc/mm/book3s64/pkeys.c
>> +++ b/arch/powerpc/mm/book3s64/pkeys.c
>> @@ -257,7 +257,12 @@ void __init setup_kuep(bool disabled)
>> #ifdef CONFIG_PPC_KUAP
>> void __init setup_kuap(bool disabled)
>> {
>> - if (disabled || !early_radix_enabled())
>> + if (disabled)
>> + return;
>> + /*
>> + * On hash if PKEY feature is not enabled, disable KUAP too.
>> + */
>> + if (!early_radix_enabled() && !early_mmu_has_feature(MMU_FTR_PKEY))
>
> pkey_early_init_devtree() bails out without setting MMU_FTR_PKEY with
> the following:
>
> /*
> * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
> */
> if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
> return;
>
>
>
> Why would it be impossible to do KUAP in that case ? KUAP doesn't
> require updating SPRN_AMR with MSR[PR] = 1
You're right, it would be possible to do KUAP in that case.
That's an artifact of KUAP being implemented using PKEYs on hash. For
the PKEYs user-visible API we want AMR to be user controlled.
It's possible we could untangle all that, allowing KUAP to be
implemented on earlier CPUs, but I'm not sure it's going to be high on
anyone's todo list.
cheers
