Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp2685477pxp; Mon, 7 Mar 2022 22:46:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJyChn6syoxcpFBfeIhm0Z+IalE9il/x3gZaoDS/XJon8tRROdjbY8JvzN+DJciKEFe1zzsx X-Received: by 2002:a17:90a:2ec2:b0:1bc:8bdd:8cfc with SMTP id h2-20020a17090a2ec200b001bc8bdd8cfcmr3093847pjs.237.1646721977204; Mon, 07 Mar 2022 22:46:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646721977; cv=none; d=google.com; s=arc-20160816; b=s1wkzDrr3EH7DOxRifOoJp9NcDhi7euNS7V15RwQ7mnEHRJAx5BUOZwin2tK+AilOx 3jXMT+VcmCg7PsfNM/fkqO3iG/ohqG8UXKcP2Sqnve4UDhpOz4YsKCRvTmRDzvq7tHkk GwQImFeua4VGC3La2si+NIOSOMjjImx3lFHV+sBuAs3ou8bIdxCM7h44LJIXJUIqaSyz 7xhWv4K6vXd6bygonAsEgkpMUi9efm6EfrtYrLHmg64j3HMaG01N+lhAJOX08XoFisQ4 UEek4wAFfwE8ZO3v8McOOVMsqEUFcmXZ+wacdpbNJSj0pbBLtpPcrNSzDiQbvtBNJ/Xw lQag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=TN256zp3BwXNBuMSx7qvBc8exC2Uxves0zq9UuKmvk0=; b=DUyXL1hryxqSKh/7orjEMuwsH6Mf7EASWzEQhd0r+LdEHsK6GV3fIMLQ+G3kgH1JEy PA7XimZV44swjawdCyCYoaHopxMLcX3UdoUHQisvsshoBJf+/ZeiniO84DIO6p4U0U4E p2HnkVWqU5Ntgmy1OfPDP0ELPOgPG5imK8Vma43InnQTOiD8vfFe8XLOmz0hzvt4LuP8 VrwEtBdVsQgHpgymLizNfOce2icmT4iT+r9ODppKahdxpbFxcAHdDxQjiDN/bwjK9IEo hgFQ5jzF7RQyA2/j2f1od4Daoq2GUJd5uM884BBDHLX1Pb95PDuX0NTq5vtK0uh2UQ5B md0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=nzMqpy0Q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ob3-20020a17090b390300b001bd14e01f63si1603083pjb.81.2022.03.07.22.46.03; Mon, 07 Mar 2022 22:46:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=nzMqpy0Q; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241038AbiCGS1K (ORCPT + 99 others); Mon, 7 Mar 2022 13:27:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234218AbiCGS1J (ORCPT ); Mon, 7 Mar 2022 13:27:09 -0500 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A5D3939A8 for ; Mon, 7 Mar 2022 10:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1646677574; x=1678213574; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=5qzlM+F2KLwaOV5DOusddqPgYoFFoImJzYDRDku6N50=; b=nzMqpy0QBf7aC2utAcDtfOzFhdYJtnU9dmXWPDqnjveplOtFoo/5TOwl 4ptA1PE3/g5OxLvWOg5hUhlJ95wAoZ75Pv5to+EydidflviXiie7pXEmH sSXaMKsrf2Bqm8gnRwmrBa10YP7ghVF/19k6IExKNhu6LySwhTfcLmbPa oRhO4GItumOE6UDDvQnFoLmzZeEgKeXjkh/nPFafrlPMYK5svePjeWjRu gd/nwLwwntrZwMhXU1YPsrtjq/0+Plqd1DH7s1feZFR5PGfKjjQPfzBMX i2aWGhljp36WIKGJZVn3vqKv+4kXiEJlnNaCcDANrbFj8xllw/Mk8TyJ3 w==; X-IronPort-AV: E=McAfee;i="6200,9189,10279"; a="254404728" X-IronPort-AV: E=Sophos;i="5.90,162,1643702400"; d="scan'208";a="254404728" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Mar 2022 10:26:13 -0800 X-IronPort-AV: E=Sophos;i="5.90,162,1643702400"; d="scan'208";a="641428749" Received: from sonalsha-mobl.amr.corp.intel.com (HELO localhost) ([10.212.67.25]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Mar 2022 10:26:13 -0800 Date: Mon, 7 Mar 2022 10:26:12 -0800 From: Ira Weiny To: "Aneesh Kumar K.V" Cc: Michael Ellerman , Dave Hansen , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] pkeys: Make pkey unsigned in arch_set_user_pkey_access() Message-ID: References: <20220304210543.3490880-1-ira.weiny@intel.com> <878rtmtfgs.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878rtmtfgs.fsf@linux.ibm.com> X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 07, 2022 at 12:30:03PM +0530, Aneesh Kumar K.V wrote: > ira.weiny@intel.com writes: > > > From: Ira Weiny > > > > The WARN_ON check in arch_set_user_pkey_access() in the x86 architecture > > fails to check for an invalid negative value. > > > > A simple check for less than 0 would fix this issue however, in the call > > stack below arch_set_user_pkey_access() the pkey should never be > > negative on any architecture. It is always best to use correct types > > when possible. x86 only supports 16 keys while ppc supports 32, u8 is > > therefore large enough for all current architectures and likely those in > > the future. > > Should we do that as a separate patch? ie, now convert the variable to > unsigned int and later switch all the variables to u8? Maybe. > because what we > now have is confusing. > > static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot, > unsigned long pkey) > static inline u64 pkey_to_vmflag_bits(u16 pkey) > This looks like a good cleanup as well. Why not convert arch_calc_vm_prot_bits() and pkey_to_vmflag_bits() to u8? (In another patch.) This is all a result of this PKS conversation: https://lore.kernel.org/lkml/Yg8C6UkgfBmQlPSq@iweiny-desk3/ That started me down the path of trying to figure out why 'int' was used for PKRU and I realized that negative values had meaning there which did not apply to me with PKS. So at some point a conversion needs to be made between a 'conceptual pkey' (int) and a real pkey (unsigned) IHMO. It's no bit deal to split this patch into one which converts to unsigned and then another to u8 (or u16 if there is some arch which may need it that big). However, digging more: Is there a reason u16 was used in pkey_to_vmflag_bits()? How about in __pkru_allows_read() in the x86 code? If possible I think u8 should be standardized but I'm ok with u16 if that is preferred. Also, am I missing something in init_amr() and init_iamr()? I think I could have gone farther and changed init_amr() and init_iamr() right? From what I can see the argument to use unsigned long vs u8 (or u16) is some expectation that pkeys will grow beyond 256 in number. From what I can see I don't think that is going to happen. So do we need to do this in two steps? Ira > > > > > Change the type of the pkey passed to arch_set_user_pkey_access() to u8. > > > > To: Dave Hansen > > To: Michael Ellerman > > Cc: Aneesh Kumar K.V > > Signed-off-by: Ira Weiny > > --- > > arch/powerpc/include/asm/pkeys.h | 4 ++-- > > arch/powerpc/mm/book3s64/pkeys.c | 2 +- > > arch/x86/include/asm/pkeys.h | 4 ++-- > > arch/x86/kernel/fpu/xstate.c | 2 +- > > include/linux/pkeys.h | 2 +- > > 5 files changed, 7 insertions(+), 7 deletions(-) > > > > diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h > > index 59a2c7dbc78f..e70615a1da9b 100644 > > --- a/arch/powerpc/include/asm/pkeys.h > > +++ b/arch/powerpc/include/asm/pkeys.h > > @@ -143,9 +143,9 @@ static inline int arch_override_mprotect_pkey(struct vm_area_struct *vma, > > return __arch_override_mprotect_pkey(vma, prot, pkey); > > } > > > > -extern int __arch_set_user_pkey_access(struct task_struct *tsk, int pkey, > > +extern int __arch_set_user_pkey_access(struct task_struct *tsk, u8 pkey, > > unsigned long init_val); > > > > -static inline int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, > > +static inline int arch_set_user_pkey_access(struct task_struct *tsk, u8 pkey, > > unsigned long init_val) > > { > > if (!mmu_has_feature(MMU_FTR_PKEY)) > > diff --git a/arch/powerpc/mm/book3s64/pkeys.c b/arch/powerpc/mm/book3s64/pkeys.c > > index 753e62ba67af..c048467669df 100644 > > --- a/arch/powerpc/mm/book3s64/pkeys.c > > +++ b/arch/powerpc/mm/book3s64/pkeys.c > > @@ -333,7 +333,7 @@ static inline void init_iamr(int pkey, u8 init_bits) > > * Set the access rights in AMR IAMR and UAMOR registers for @pkey to that > > * specified in @init_val. > > */ > > -int __arch_set_user_pkey_access(struct task_struct *tsk, int pkey, > > +int __arch_set_user_pkey_access(struct task_struct *tsk, u8 pkey, > > unsigned long init_val) > > { > > u64 new_amr_bits = 0x0ul; > > diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h > > index 5292e6dfe2a7..48efb81f6cc6 100644 > > --- a/arch/x86/include/asm/pkeys.h > > +++ b/arch/x86/include/asm/pkeys.h > > @@ -9,7 +9,7 @@ > > */ > > #define arch_max_pkey() (cpu_feature_enabled(X86_FEATURE_OSPKE) ? 16 : 1) > > > > -extern int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, > > +extern int arch_set_user_pkey_access(struct task_struct *tsk, u8 pkey, > > unsigned long init_val); > > > > static inline bool arch_pkeys_enabled(void) > > @@ -115,7 +115,7 @@ int mm_pkey_free(struct mm_struct *mm, int pkey) > > return 0; > > } > > > > -extern int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, > > +extern int arch_set_user_pkey_access(struct task_struct *tsk, u8 pkey, > > unsigned long init_val); > > > > static inline int vma_pkey(struct vm_area_struct *vma) > > diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c > > index 7c7824ae7862..db511bec57e5 100644 > > --- a/arch/x86/kernel/fpu/xstate.c > > +++ b/arch/x86/kernel/fpu/xstate.c > > @@ -1068,7 +1068,7 @@ void *get_xsave_addr(struct xregs_state *xsave, int xfeature_nr) > > * This will go out and modify PKRU register to set the access > > * rights for @pkey to @init_val. > > */ > > -int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, > > +int arch_set_user_pkey_access(struct task_struct *tsk, u8 pkey, > > unsigned long init_val) > > { > > u32 old_pkru, new_pkru_bits = 0; > > diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h > > index 86be8bf27b41..aa40ed2fb0fc 100644 > > --- a/include/linux/pkeys.h > > +++ b/include/linux/pkeys.h > > @@ -35,7 +35,7 @@ static inline int mm_pkey_free(struct mm_struct *mm, int pkey) > > return -EINVAL; > > } > > > > -static inline int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, > > +static inline int arch_set_user_pkey_access(struct task_struct *tsk, u8 pkey, > > unsigned long init_val) > > { > > return 0; > > -- > > 2.35.1