Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751612AbdINSeG (ORCPT ); Thu, 14 Sep 2017 14:34:06 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:39302 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751316AbdINSeF (ORCPT ); Thu, 14 Sep 2017 14:34:05 -0400 Date: Thu, 14 Sep 2017 19:34:02 +0100 From: Mark Rutland To: Tycho Andersen Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-hardening@lists.openwall.com, Marco Benatto , Juerg Haefliger , linux-arm-kernel@lists.infradead.org, x86@kernel.org Subject: Re: [kernel-hardening] [PATCH v6 10/11] mm: add a user_virt_to_phys symbol Message-ID: <20170914183401.GC1711@remoulade> References: <20170907173609.22696-1-tycho@docker.com> <20170907173609.22696-11-tycho@docker.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170907173609.22696-11-tycho@docker.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2459 Lines: 83 On Thu, Sep 07, 2017 at 11:36:08AM -0600, Tycho Andersen wrote: > We need someting like this for testing XPFO. Since it's architecture > specific, putting it in the test code is slightly awkward, so let's make it > an arch-specific symbol and export it for use in LKDTM. > > v6: * add a definition of user_virt_to_phys in the !CONFIG_XPFO case > > CC: linux-arm-kernel@lists.infradead.org > CC: x86@kernel.org > Signed-off-by: Tycho Andersen > Tested-by: Marco Benatto > --- > arch/arm64/mm/xpfo.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++ > arch/x86/mm/xpfo.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++ > include/linux/xpfo.h | 5 +++++ > 3 files changed, 113 insertions(+) > > diff --git a/arch/arm64/mm/xpfo.c b/arch/arm64/mm/xpfo.c > index 342a9ccb93c1..94a667d94e15 100644 > --- a/arch/arm64/mm/xpfo.c > +++ b/arch/arm64/mm/xpfo.c > @@ -74,3 +74,54 @@ void xpfo_dma_map_unmap_area(bool map, const void *addr, size_t size, > > xpfo_temp_unmap(addr, size, mapping, sizeof(mapping[0]) * num_pages); > } > + > +/* Convert a user space virtual address to a physical address. > + * Shamelessly copied from slow_virt_to_phys() and lookup_address() in > + * arch/x86/mm/pageattr.c > + */ When can this be called? What prevents concurrent modification of the user page tables? i.e. must mmap_sem be held? > +phys_addr_t user_virt_to_phys(unsigned long addr) Does this really need to be architecture specific? Core mm code manages to walk user page tables just fine... > +{ > + phys_addr_t phys_addr; > + unsigned long offset; > + pgd_t *pgd; > + p4d_t *p4d; > + pud_t *pud; > + pmd_t *pmd; > + pte_t *pte; > + > + pgd = pgd_offset(current->mm, addr); > + if (pgd_none(*pgd)) > + return 0; Can we please separate the address and return value? e.g. pass the PA by reference and return an error code. AFAIK, zero is a valid PA, and even if the tables exist, they might point there in the presence of an error. > + > + p4d = p4d_offset(pgd, addr); > + if (p4d_none(*p4d)) > + return 0; > + > + pud = pud_offset(p4d, addr); > + if (pud_none(*pud)) > + return 0; > + > + if (pud_sect(*pud) || !pud_present(*pud)) { > + phys_addr = (unsigned long)pud_pfn(*pud) << PAGE_SHIFT; Was there some problem with: phys_addr = pmd_page_paddr(*pud); ... and similar for the other levels? ... I'd rather introduce new helpers than more open-coded calculations. Thanks, Mark.