[PATCH 0/1] powerpc: Fix kuap warnings

[Christophe Leroy (CS GROUP)]

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;
>> }
>