Re: [PATCH 0/1] powerpc: Fix kuap warnings

[Shrikanth Hegde <sshegde@linux.ibm.com>]

Hi Christophe.

On 1/9/26 6:24 PM, Christophe Leroy (CS GROUP) wrote:
> Hi Shrikanth,
> 
> Le 09/01/2026 à 13:19, Shrikanth Hegde a écrit :
>> Hi Christophe.
>>
>> On 1/9/26 1:41 PM, Christophe Leroy (CS GROUP) wrote:
>>>
>>>
>>> Le 09/01/2026 à 07:49, Shrikanth Hegde a écrit :
>>>> Recently stumbled upon these kuap warnings. This happens with
>>>> preempt=full/lazy kernel with function tracing enabled. What irked
>>>> me was kernel compilation was getting failed when i had tracing
>>>> enabled. It doesn't fail everytime. While running stress-ng memory 
>>>> class
>>>> it threw same warnings. So that helped to narrow it down.
>>>> So one possible way is to disable tracing for these enter/exit
>>>> vmx_usercopy. That seems to fix the bug/warnings. But that will make
>>>> them as non trace-able. If there is a better way to fix these 
>>>> warning while
>>>> keeping them as trace-able, please let me know.
>>>>
>>>> Anyone with insights on amr, vmx and tracing, please advise.
>>>
>>> The main principle with KUAP is to not call subfunctions once 
>>> userspace access enabled. There are a few exceptions like 
>>> __copy_tofrom_user() that are allowed in order to optimise large 
>>> copies. However this needs to be handled very carefully, and in 
>>> principle we don't expect __copy_tofrom_user() to call other functions.
>>>
>>
>> I didn't understand. My knowledge is quite limited in this space.
>> Could you please explain how this will help us avoid the warnings?
>> or are you saying we have more callsites which needs to worked upon.
> 
> Read tools/objtool/Documentation/objtool.txt section "Objtool warning" 
> item 9.
> 
> Unfortunately powerpc doesn't yet implement objtool to detect it, but 
> the principle applies anyway.
> 
>>
>>> So it might require wider rework but we should narrow as much as 
>>> possible the period during which access to userspace is opened, with 
>>> something like:
>>>
>>> raw_coy_to_user_power7()
>>> {
>>>      enter_vmx_usercopy();
>>
>> I think the problem is when it comes here, it has some AMR state, but
>> it is preemptible. So shouldn't call schedule IIUC.
> 
> See commit 00ff1eaac129 ("powerpc: Fix reschedule bug in KUAP-unlocked 
> user copy")
> 
> The problem is because enter_vmx_usercopy() is called _after_ 
> allow_write_to_user() which changes AMR.
> 
> If you call enter_vmx_usercopy() _before_ allow_write_to_user() and call 
> exit_vmx_usercopy() _after_ prevent_write_to_user() the problem is solved.
> 
>>
>>>      allow_write_to_user(to, n);
>>>      ret = __copy_tofrom_user_power7();
>>>      prevent_write_to_user(to, n);
>>>      exit_vmx_usercopy();
>>>      return ret;
>>> }
>>>
>>> raw_copy_to_user()
>>> {
>>>      if (cpu_has_feature(CPU_FTR_VMX_COPY))
>>>          raw_copy_to_user_power7();
>>>
>>>      allow_write_to_user(to, n);
>>>      ret = __copy_tofrom_user(to, (__force const void __user *)from, n);
>>>      prevent_write_to_user(to, n);
>>>      return ret;
>>> }
>>
> 

Sorry, I forgot to update.

I spoke to ritesh a while ago and someone with better knowledge in
this area will work on a proper fix for this.