[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <26372850-476d-457f-ba97-9119cf81d376@linux.ibm.com>
Date: Mon, 26 Jan 2026 19:24:19 +0530
From: Shrikanth Hegde <sshegde@...ux.ibm.com>
To: "Christophe Leroy (CS GROUP)" <chleroy@...nel.org>, riteshh@...ux.ibm.com
Cc: linux-kernel@...r.kernel.org, hbathini@...ux.ibm.com, maddy@...ux.ibm.com,
linuxppc-dev@...ts.ozlabs.org, rostedt@...dmis.org,
mhiramat@...nel.org, Nicholas Piggin <npiggin@...il.com>
Subject: Re: [PATCH 0/1] powerpc: Fix kuap warnings
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.
Powered by blists - more mailing lists