arch/powerpc/kernel/process.c | 10 +++++----- arch/powerpc/lib/vmx-helper.c | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-)
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. Shrikanth Hegde (1): powerpc: Fix kuap warnings on lazy/full preemption with tracing arch/powerpc/kernel/process.c | 10 +++++----- arch/powerpc/lib/vmx-helper.c | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) -- 2.47.3
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.
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();
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;
}
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.
> 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.
> 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;
> }
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;
>> }
>
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.
© 2016 - 2026 Red Hat, Inc.