From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3yHSjP56FrzDq5x for ; Thu, 19 Oct 2017 10:20:57 +1100 (AEDT) Received: by mail-pg0-x241.google.com with SMTP id 15so838920pgc.12 for ; Wed, 18 Oct 2017 16:20:57 -0700 (PDT) Date: Thu, 19 Oct 2017 10:20:46 +1100 From: Balbir Singh To: Ram Pai Cc: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, benh@kernel.crashing.org, paulus@samba.org, khandual@linux.vnet.ibm.com, aneesh.kumar@linux.vnet.ibm.com, hbabu@us.ibm.com, mhocko@kernel.org, bauerman@linux.vnet.ibm.com, ebiederm@xmission.com Subject: Re: [PATCH 19/25] powerpc: implementation for arch_vma_access_permitted() Message-ID: <20171019102046.356de68b@MiWiFi-R3-srv> In-Reply-To: <1504910713-7094-28-git-send-email-linuxram@us.ibm.com> References: <1504910713-7094-1-git-send-email-linuxram@us.ibm.com> <1504910713-7094-28-git-send-email-linuxram@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 8 Sep 2017 15:45:07 -0700 Ram Pai wrote: > This patch provides the implementation for > arch_vma_access_permitted(). Returns true if the > requested access is allowed by pkey associated with the > vma. > > Signed-off-by: Ram Pai > --- > arch/powerpc/include/asm/mmu_context.h | 5 +++- > arch/powerpc/mm/pkeys.c | 43 ++++++++++++++++++++++++++++++++ > 2 files changed, 47 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h > index 04e9221..9a56355 100644 > --- a/arch/powerpc/include/asm/mmu_context.h > +++ b/arch/powerpc/include/asm/mmu_context.h > @@ -135,6 +135,10 @@ static inline void arch_bprm_mm_init(struct mm_struct *mm, > { > } > > +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > +bool arch_vma_access_permitted(struct vm_area_struct *vma, > + bool write, bool execute, bool foreign); > +#else /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */ > static inline bool arch_vma_access_permitted(struct vm_area_struct *vma, > bool write, bool execute, bool foreign) > { > @@ -142,7 +146,6 @@ static inline bool arch_vma_access_permitted(struct vm_area_struct *vma, > return true; > } > > -#ifndef CONFIG_PPC64_MEMORY_PROTECTION_KEYS > #define pkey_initialize() > #define pkey_mm_init(mm) > > diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c > index 24589d9..21c3b42 100644 > --- a/arch/powerpc/mm/pkeys.c > +++ b/arch/powerpc/mm/pkeys.c > @@ -320,3 +320,46 @@ bool arch_pte_access_permitted(u64 pte, bool write, bool execute) > return pkey_access_permitted(pte_to_pkey_bits(pte), > write, execute); > } > + > +/* > + * We only want to enforce protection keys on the current process > + * because we effectively have no access to AMR/IAMR for other > + * processes or any way to tell *which * AMR/IAMR in a threaded > + * process we could use. > + * > + * So do not enforce things if the VMA is not from the current > + * mm, or if we are in a kernel thread. > + */ > +static inline bool vma_is_foreign(struct vm_area_struct *vma) > +{ > + if (!current->mm) > + return true; > + /* > + * if the VMA is from another process, then AMR/IAMR has no > + * relevance and should not be enforced. > + */ > + if (current->mm != vma->vm_mm) > + return true; > + > + return false; > +} > + > +bool arch_vma_access_permitted(struct vm_area_struct *vma, > + bool write, bool execute, bool foreign) > +{ > + int pkey; > + > + if (!pkey_inited) > + return true; > + > + /* allow access if the VMA is not one from this process */ > + if (foreign || vma_is_foreign(vma)) > + return true; > + > + pkey = vma_pkey(vma); > + > + if (!pkey) > + return true; > + > + return pkey_access_permitted(pkey, write, execute); > +} Again, I think this is GUP, I don't really understand the top level use case of enforcing permissions for GUP in a thread context. Balbir Singh.