From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A2CB931A069 for ; Fri, 9 Jan 2026 12:54:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767963251; cv=none; b=VqB+lSdD+wywlBKz7ZIiDwIVU/RreK89iOCA6Brf09iCsl1A+LEjOwVEsOB38R6csZ7gVfaeQ9B9NogeiEREcKDFGGMqtwI+KLV78WzNmC3ozUk3DjOz3A56mVngKFGD1ESv8iq8fjrEckuGOeSOs8nALCi7LrMZnhPGLD6CHN0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767963251; c=relaxed/simple; bh=/jSn7D7gYks/WiVctkdadSm4g9WcWCWBKKGC88gdReI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=MGsNpiul4Ym0/ZVBN9uhrNWiWKDm2X5b7QZ5+CK9qoWvQFQJfGVBzLm8g5n8yP/Nfb4PcI50apHgyABVjfR+u5klrIZUV+2TM6bseFYjEYlH0D4D3KFEcbv8oNjD0FCuze2iJg4TCJTo7IJQnkyXGK5/DSwHk1W2hwHvPwKO/O4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qJqTBR3O; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qJqTBR3O" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34E00C4CEF1; Fri, 9 Jan 2026 12:54:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1767963251; bh=/jSn7D7gYks/WiVctkdadSm4g9WcWCWBKKGC88gdReI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qJqTBR3OJiA8fsJwCRuRysPDMeQ68a9epeJqavR+Wunf9b7uAqT0+aexwoExnYnXm jZRfD0C4sebk/wO5AbiwAZQWaQKCU1hgZ4cACmuX0vCKxsdfjNC6YhoH50zy1FuvS7 F1Qz0oQY2LK/WZnhdmgmm2HnceDiYi9BY26XMW4k9WjQf7j86ujaO1I1l0Vu6lhrtG 5jsg0D49lkTPIQWnsNRQs7rR++bAvJlMKP1oFXGUWg6m1aEskVH9+t+0nQM/5yIofs 8H4QaWFpuN9n4dtYKZgAWMmvp8vijPvCA6861nhNkZ9jZIV7mpJALhIVujPqlzqqf8 7v5QV8FEGV1LQ== Message-ID: <336d274e-c831-4af9-ae65-42908b3c2c61@kernel.org> Date: Fri, 9 Jan 2026 13:54:06 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/1] powerpc: Fix kuap warnings To: Shrikanth Hegde Cc: riteshh@linux.ibm.com, linux-kernel@vger.kernel.org, hbathini@linux.ibm.com, maddy@linux.ibm.com, linuxppc-dev@lists.ozlabs.org, rostedt@goodmis.org, mhiramat@kernel.org, Nicholas Piggin References: <20260109064917.777587-1-sshegde@linux.ibm.com> Content-Language: fr-FR From: "Christophe Leroy (CS GROUP)" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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; >> } >