From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 16222EDEC12 for ; Wed, 4 Mar 2026 05:40:32 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [127.0.0.1]) by lists.ozlabs.org (Postfix) with ESMTP id 4fQhMy4Mv8z2yLH; Wed, 04 Mar 2026 16:40:30 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1772602830; cv=none; b=bJkKID0SPKrZyv8UNeowryFSlzfGIJRWrFcgGbSTS0KBvUVQWXhJc4PPQr3dPL8nqNyUnxlPfWeEOidwnirJaOoDhx3da2+1MyMItnqrPRnNtRzLeFapnyzVg77lAQXoORpKk1ToQ53zHGUstjcRAvTJbBBjRxqYQtLI/lG51bkaBtQR2D2l2Qet30XPxDiEBuo1Kmog/CkOcaCmR+6PSFyZXS3/lHnUOfSiq71aC2Kf8BOZO4q1WqWyspLfyKqEJyKU7skrrCQlzEaQo5xBg8pRbhdFGiWwN0zZhVra7erRSNnPRd+kvuuTD6evpngKSq5Jo47Ygc4RaEAcfsyDBA== ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1772602830; c=relaxed/relaxed; bh=67A3pg0hTc457nxQyZL20oNAkSnV71N39tvCJxtr63U=; h=Content-Type:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To; b=KH8XmqATSP96y2+rYP+EHVyF+ROP8GAWbWePd4j6OQ6/LfjgDMYhf7LCS28G7h5bQXwYdSJuaVKSqqfcHlg0AjvogzIaAjcxTxKIBxKLDxFzvtUBlzNmhu5wMgg5BtEWTnJJHduSlVd6KfeWEfD9bN+AhR1KZrAqgMaMF+DiIvIjzdqkpYaWBmcUuzvbgtZq2FA4bs7IlI6cX02d14N/VtRvxVU5pgrfQE1pj484KEavTsWOdfCV/Qt41PGuZ241md6DRU4MbHMS+cbDCvT/+dkncl0yLJ9TPGSlM31zDUsi1174VDq64PHxQq/7aQrOp3lpYmx5eR5uSehYlvvcVA== ARC-Authentication-Results: i=1; lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=J+6MjSuA; dkim-atps=neutral; spf=pass (client-ip=148.163.158.5; helo=mx0b-001b2d01.pphosted.com; envelope-from=sayalip@linux.ibm.com; receiver=lists.ozlabs.org) smtp.mailfrom=linux.ibm.com Authentication-Results: lists.ozlabs.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=J+6MjSuA; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linux.ibm.com (client-ip=148.163.158.5; helo=mx0b-001b2d01.pphosted.com; envelope-from=sayalip@linux.ibm.com; receiver=lists.ozlabs.org) Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4fQhMx5Xxxz2xjQ for ; Wed, 04 Mar 2026 16:40:29 +1100 (AEDT) Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 623DnGt1902068; Wed, 4 Mar 2026 05:40:25 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=67A3pg0hTc457nxQyZL20oNAkSnV71 N39tvCJxtr63U=; b=J+6MjSuAOLSo0YGthDO8w7pAi5OL2BoATlix4Wh40WExTw tbZIiDg0t8qSqeyUguvv2USp8fCd4jlpTZeng6hLaJh13xiZQxwI0gFpWOZzrlBC l4TKjTJcBaV+00lkZq9ZxVq/VlQXN+TamnofaK9qkmny11CDAfc+v2dgwvgdE0Fu jCLbLX+xvjGGd/9XEQ5dBKo1zcZf4SU/gg3YaOSJsMaQYUIwRbtoXim4GRNLxO91 gDCLJRzpCRitqWHplrWQwr3ttbah23yzLp3tvsy7fOFpevMWfDkf3Tsg186V+uB+ se9fAuMJd1x9y9cBz91CuhwPJf4MjLuvOPHjJjUQ== Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4cksk3wpye-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Mar 2026 05:40:24 +0000 (GMT) Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.18.1.2/8.18.1.2) with ESMTP id 6244CMTL029112; Wed, 4 Mar 2026 05:40:23 GMT Received: from smtprelay05.wdc07v.mail.ibm.com ([172.16.1.72]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 4cmaps5j10-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Mar 2026 05:40:23 +0000 Received: from smtpav04.dal12v.mail.ibm.com (smtpav04.dal12v.mail.ibm.com [10.241.53.103]) by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 6245eL7V16974544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 4 Mar 2026 05:40:22 GMT Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C7B0B5805E; Wed, 4 Mar 2026 05:40:21 +0000 (GMT) Received: from smtpav04.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 766795805A; Wed, 4 Mar 2026 05:40:18 +0000 (GMT) Received: from [9.124.213.19] (unknown [9.124.213.19]) by smtpav04.dal12v.mail.ibm.com (Postfix) with ESMTP; Wed, 4 Mar 2026 05:40:18 +0000 (GMT) Content-Type: multipart/alternative; boundary="------------GHleoKl5wnNKoyutiC0QQZSY" Message-ID: <54350add-111e-4905-b3ed-6f3771485769@linux.ibm.com> Date: Wed, 4 Mar 2026 11:10:16 +0530 X-Mailing-List: linuxppc-dev@lists.ozlabs.org List-Id: List-Help: List-Owner: List-Post: List-Archive: , List-Subscribe: , , List-Unsubscribe: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] powerpc: fix KUAP warning in VMX usercopy path To: "Christophe Leroy (CS GROUP)" , linuxppc-dev@lists.ozlabs.org, maddy@linux.ibm.com Cc: aboorvad@linux.ibm.com, sshegde@linux.ibm.com, riteshh@linux.ibm.com, hbathini@linux.ibm.com, ming.lei@redhat.com, csander@purestorage.com, czhong@redhat.com, venkat88@linux.ibm.com References: <20260228135319.238985-1-sayalip@linux.ibm.com> <65abe055-38b4-44ec-a7a0-7b4161677ead@kernel.org> <5eaa620f-17cb-4ecb-a1bd-eadc7df81574@kernel.org> Content-Language: en-IN From: Sayali Patil In-Reply-To: X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: Uz3yIKYWRfbamkjUZccu-4h6PO06FfPc X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMzA0MDA0NCBTYWx0ZWRfX2UGNbVXtoyw7 7ULRmKyqCG0AaXYD9QKOw0ahezD7HMBybb+oojbMGxFcseKHflOZJD2Nsoy8WvSpjYlN8K/LPCe dtxnnC+rlkCDW9HfFBvgDfIgSgFO+zQsVEiwX749uLBcPJ+oHSJSRowDz5en9/Wg0lHrFs64x9X DyuRTBIPeEYZaq7lN1Qjo94pnNBm9OKSl+k69tnvLZygCAuSi91KjsKGspFx7d8pmvQXdF0KYk6 eV1SbYXEanEwgCtdq2dEbxSom7lwoaXacx3tRHjzbnyI0HpFkUi3b0tbKx+Y3q5taZ+y3PZEf+s r0KYKVwDBYxzjAUHLRyQJJnM7SCdOSoSrRm7MJaMxxBVsQCGUQXsHNN9qetkUN5AM2r0JbfJalM xMxzYSCzpqvc4WgSqxolJPF7Dmx8Sv7ofWOVr0TWQEK0vpnaSIq9eO0FPtqtalW0yrgcFIJ85yO kMZMhpr5oSJ1jKq3KBw== X-Authority-Analysis: v=2.4 cv=csCWUl4i c=1 sm=1 tr=0 ts=69a7c5c8 cx=c_pps a=bLidbwmWQ0KltjZqbj+ezA==:117 a=bLidbwmWQ0KltjZqbj+ezA==:17 a=Yq5XynenixoA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=Y2IxJ9c9Rs8Kov3niI8_:22 a=r77TgQKjGQsHNAKrUKIA:9 a=VwQbUJbxAAAA:8 a=VnNF1IyMAAAA:8 a=GnkZ_gDUXG9Slg1T1qcA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=Ck1fYXvvQn9X3tL3HtgA:9 a=GaGYhJaVusYNV2fb:21 a=_W_S_7VecoQA:10 X-Proofpoint-GUID: Uz3yIKYWRfbamkjUZccu-4h6PO06FfPc X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-03-04_02,2026-03-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 priorityscore=1501 suspectscore=0 malwarescore=0 adultscore=0 clxscore=1015 bulkscore=0 phishscore=0 spamscore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2603040044 This is a multi-part message in MIME format. --------------GHleoKl5wnNKoyutiC0QQZSY Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 03/03/26 20:47, Christophe Leroy (CS GROUP) wrote: > Hi once more, > > Le 03/03/2026 à 16:10, Christophe Leroy (CS GROUP) a écrit : >> Hi Again, >> >> Le 03/03/2026 à 15:57, Christophe Leroy (CS GROUP) a écrit : >>> Hi, >>> >>> Le 03/03/2026 à 10:19, Sayali Patil a écrit : >>>> >>>> On 02/03/26 16:42, Christophe Leroy (CS GROUP) wrote: >>>>> >>>> Hi Christophe, >>>> Thanks for the review. >>>> With the suggested change, we are hitting a compilation error. >>>> >>>> The issue is related to how KUAP enforces the access direction. >>>> allow_user_access() contains: >>>> >>>> BUILD_BUG_ON(!__builtin_constant_p(dir)); >>>> >>>> which requires that the access direction is a compile-time constant. >>>> If we pass a runtime value (for example, an unsigned long), the >>>> __builtin_constant_p() check fails and triggers the following build >>>> error. >>>> >>>> Error: >>>> In function 'allow_user_access', inlined from >>>> '__copy_tofrom_user_vmx' at arch/powerpc/lib/vmx-helper.c:19:3: >>>> BUILD_BUG_ON failed: !__builtin_constant_p(dir) 706 >>>> >>>> >>>> The previous implementation worked because allow_user_access() was >>>> invoked with enum >>>> constants (READ, WRITE, READ_WRITE), which satisfied the >>>> __builtin_constant_p() requirement. >>>> So in this case, the function must be called with a compile-time >>>> constant to satisfy KUAP. >>>> >>>> Please let me know if you would prefer a different approach. >>>> >>> >>> Ah, right, I missed that. The problem should only be in vmx-helper.c >>> >> >> Thinking about it once more, I realised that powerpc does not define >> INLINE_COPY_FROM_USER nor INLINE_COPY_TO_USER. >> >> This means that raw_copy_from_user() and raw_copy_to_user() will in >> really not be called much. Therefore __copy_tofrom_user_vmx() could >> remain in uaccess.h as static __always_inline allthough it requires >> exporting enter_vmx_usercopy() and exit_vmx_usercopy(). > > That would result in something like: > > static __always_inline bool will_use_vmx(unsigned long n) > { >     return IS_ENABLED(CONFIG_ALTIVEC) && > cpu_has_feature(CPU_FTR_VMX_COPY) && >            n > VMX_COPY_THRESHOLD; > } > > static __always_inline unsigned long > raw_copy_tofrom_user(void __user *to, const void __user *from, > unsigned long n, unsigned long dir) > { >     unsigned long ret; > >     if (will_use_vmx(n) && enter_vmx_usercopy()) { >         allow_user_access(to, dir); >         ret = __copy_tofrom_user_power7_vmx(to, from, size); >         prevent_user_access(dir); >         exit_vmx_usercopy(); > >         if (unlikely(ret)) { >             allow_user_access(to, dir); >             ret = __copy_tofrom_user_base(to, from, size); >             prevent_user_access(dir); >         } >         return ret; >     } >     allow_user_access(to, dir); >     ret = __copy_tofrom_user(to, from, n); >     prevent_user_access(dir); >     return ret; > } > > > Christophe > Thanks Christophe for the review and suggestions. We have incorporated  these changes in v3. v3: https://lore.kernel.org/all/20260304053506.118632-1-sayalip@linux.ibm.com/ --------------GHleoKl5wnNKoyutiC0QQZSY Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 03/03/26 20:47, Christophe Leroy (CS GROUP) wrote:
Hi once more,

Le 03/03/2026 à 16:10, Christophe Leroy (CS GROUP) a écrit :
Hi Again,

Le 03/03/2026 à 15:57, Christophe Leroy (CS GROUP) a écrit :
Hi,

Le 03/03/2026 à 10:19, Sayali Patil a écrit :

On 02/03/26 16:42, Christophe Leroy (CS GROUP) wrote:

Hi Christophe,
Thanks for the review.
With the suggested change, we are hitting a compilation error.

The issue is related to how KUAP enforces the access direction.
allow_user_access() contains:

BUILD_BUG_ON(!__builtin_constant_p(dir));

which requires that the access direction is a compile-time constant.
If we pass a runtime value (for example, an unsigned long), the
__builtin_constant_p() check fails and triggers the following build error.

Error:
In function 'allow_user_access', inlined from '__copy_tofrom_user_vmx' at arch/powerpc/lib/vmx-helper.c:19:3:
BUILD_BUG_ON failed: !__builtin_constant_p(dir) 706


The previous implementation worked because allow_user_access() was invoked with enum
constants (READ, WRITE, READ_WRITE), which satisfied the __builtin_constant_p() requirement.
So in this case, the function must be called with a compile-time constant to satisfy KUAP.

Please let me know if you would prefer a different approach.


Ah, right, I missed that. The problem should only be in vmx-helper.c


Thinking about it once more, I realised that powerpc does not define INLINE_COPY_FROM_USER nor INLINE_COPY_TO_USER.

This means that raw_copy_from_user() and raw_copy_to_user() will in really not be called much. Therefore __copy_tofrom_user_vmx() could remain in uaccess.h as static __always_inline allthough it requires exporting enter_vmx_usercopy() and exit_vmx_usercopy().

That would result in something like:

static __always_inline bool will_use_vmx(unsigned long n)
{
    return IS_ENABLED(CONFIG_ALTIVEC) && cpu_has_feature(CPU_FTR_VMX_COPY) &&
           n > VMX_COPY_THRESHOLD;
}

static __always_inline unsigned long
raw_copy_tofrom_user(void __user *to, const void __user *from, unsigned long n, unsigned long dir)
{
    unsigned long ret;

    if (will_use_vmx(n) && enter_vmx_usercopy()) {
        allow_user_access(to, dir);
        ret = __copy_tofrom_user_power7_vmx(to, from, size);
        prevent_user_access(dir);
        exit_vmx_usercopy();

        if (unlikely(ret)) {
            allow_user_access(to, dir);
            ret = __copy_tofrom_user_base(to, from, size);
            prevent_user_access(dir);
        }
        return ret;
    }
    allow_user_access(to, dir);
    ret = __copy_tofrom_user(to, from, n);
    prevent_user_access(dir);
    return ret;
}


Christophe 

Thanks Christophe for the review and suggestions. We have incorporated  these changes in v3.
v3: https://lore.kernel.org/all/20260304053506.118632-1-sayalip@linux.ibm.com/  --------------GHleoKl5wnNKoyutiC0QQZSY--