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