linux-kernel - Re: [PATCH 0/1] powerpc: Fix kuap warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fe9b9c66-d1cd-4570-91fa-54329d8c6a37@linux.ibm.com>
Date: Fri, 9 Jan 2026 17:49:08 +0530
From: Shrikanth Hegde <sshegde@...ux.ibm.com>
To: "Christophe Leroy (CS GROUP)" <chleroy@...nel.org>
Cc: riteshh@...ux.ibm.com, 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 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;
> }