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