Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754480AbdGUQmv (ORCPT ); Fri, 21 Jul 2017 12:42:51 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:37502 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849AbdGUQmt (ORCPT ); Fri, 21 Jul 2017 12:42:49 -0400 Date: Fri, 21 Jul 2017 09:42:30 -0700 From: Ram Pai To: "Aneesh Kumar K.V" Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au, khandual@linux.vnet.ibm.com, bsingharora@gmail.com, dave.hansen@intel.com, hbabu@us.ibm.com, arnd@arndb.de, akpm@linux-foundation.org, corbet@lwn.net, mingo@redhat.com, mhocko@kernel.org Subject: Re: [RFC v6 27/62] powerpc: helper to validate key-access permissions of a pte Reply-To: Ram Pai References: <1500177424-13695-1-git-send-email-linuxram@us.ibm.com> <1500177424-13695-28-git-send-email-linuxram@us.ibm.com> <87mv7zpq1k.fsf@skywalker.in.ibm.com> <20170720221504.GJ5487@ram.oc3035372033.ibm.com> <87k232p9ix.fsf@skywalker.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k232p9ix.fsf@skywalker.in.ibm.com> User-Agent: Mutt/1.5.20 (2009-12-10) X-TM-AS-GCONF: 00 x-cbid: 17072116-0024-0000-0000-000002B3E105 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007400; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00890842; UDB=6.00445118; IPR=6.00671009; BA=6.00005482; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016316; XFM=3.00000015; UTC=2017-07-21 16:42:44 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072116-0025-0000-0000-000044D4A7CA Message-Id: <20170721164230.GK5487@ram.oc3035372033.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-21_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707210258 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3120 Lines: 91 On Fri, Jul 21, 2017 at 12:21:50PM +0530, Aneesh Kumar K.V wrote: > Ram Pai writes: > > > On Thu, Jul 20, 2017 at 12:12:47PM +0530, Aneesh Kumar K.V wrote: > >> Ram Pai writes: > >> > >> > helper function that checks if the read/write/execute is allowed > >> > on the pte. > >> > > >> > Signed-off-by: Ram Pai > >> > --- > >> > arch/powerpc/include/asm/book3s/64/pgtable.h | 4 +++ > >> > arch/powerpc/include/asm/pkeys.h | 12 +++++++++ > >> > arch/powerpc/mm/pkeys.c | 33 ++++++++++++++++++++++++++ > >> > 3 files changed, 49 insertions(+), 0 deletions(-) > >> > > >> > diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h > >> > index 30d7f55..0056e58 100644 > >> > --- a/arch/powerpc/include/asm/book3s/64/pgtable.h > >> > +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h > >> > @@ -472,6 +472,10 @@ static inline void write_uamor(u64 value) > >> > mtspr(SPRN_UAMOR, value); > >> > } > >> > > >> > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > >> > +extern bool arch_pte_access_permitted(u64 pte, bool write, bool execute); > >> > +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */ > >> > + > >> > #define __HAVE_ARCH_PTEP_GET_AND_CLEAR > >> > static inline pte_t ptep_get_and_clear(struct mm_struct *mm, > >> > unsigned long addr, pte_t *ptep) > >> > diff --git a/arch/powerpc/include/asm/pkeys.h b/arch/powerpc/include/asm/pkeys.h > >> > index bbb5d85..7a9aade 100644 > >> > --- a/arch/powerpc/include/asm/pkeys.h > >> > +++ b/arch/powerpc/include/asm/pkeys.h > >> > @@ -53,6 +53,18 @@ static inline u64 pte_to_hpte_pkey_bits(u64 pteflags) > >> > ((pteflags & H_PAGE_PKEY_BIT4) ? HPTE_R_KEY_BIT4 : 0x0UL)); > >> > } > >> > > >> > +static inline u16 pte_to_pkey_bits(u64 pteflags) > >> > +{ > >> > + if (!pkey_inited) > >> > + return 0x0UL; > >> > >> Do we really need that above check ? We should always find it > >> peky_inited to be set. > > > > Yes. there are cases where pkey_inited is not enabled. > > a) if the MMU is radix. > That should be be a feature check > > > b) if the PAGE size is 4k. > > That is a kernel config change > > > c) if the device tree says the feature is not available > > d) if the CPU is of a older generation. P6 and older. > > Both feature check. > > how about doing something like > > static inline u16 pte_to_pkey_bits(u64 pteflags) > { > if (!(pteflags & H_PAGE_KEY_MASK)) > return 0x0UL; This check accomplishes the same thing as the return below. When (pteflag & H_PAGE_KEY_MASK) is 0, the code below returns the same 0x0UL. > > return (((pteflags & H_PAGE_PKEY_BIT0) ? 0x10 : 0x0UL) | > ((pteflags & H_PAGE_PKEY_BIT1) ? 0x8 : 0x0UL) | > ((pteflags & H_PAGE_PKEY_BIT2) ? 0x4 : 0x0UL) | > ((pteflags & H_PAGE_PKEY_BIT3) ? 0x2 : 0x0UL) | > ((pteflags & H_PAGE_PKEY_BIT4) ? 0x1 : 0x0UL)); > } The idea behind if (!pkey_inited) return 0x0UL; was to not interpret the ptebits if we knew they were not initialized to begin with. -- Ram Pai