From: tycho@docker.com (Tycho Andersen)
To: linux-arm-kernel@lists.infradead.org
Subject: [kernel-hardening] [PATCH v6 10/11] mm: add a user_virt_to_phys symbol
Date: Mon, 18 Sep 2017 14:56:09 -0600 [thread overview]
Message-ID: <20170918205609.hntcd3nfaq2gjj64@docker> (raw)
In-Reply-To: <20170914183401.GC1711@remoulade>
Hi Mark,
On Thu, Sep 14, 2017 at 07:34:02PM +0100, Mark Rutland wrote:
> 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 at lists.infradead.org
> > CC: x86 at kernel.org
> > Signed-off-by: Tycho Andersen <tycho@docker.com>
> > Tested-by: Marco Benatto <marco.antonio.780@gmail.com>
> > ---
> > 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?
Yes, it should be. Since we're moving this back into the lkdtm test
code I think it's less important, since nothing should be modifying
the tables while the thread is doing the lookup, but I'll add it in
the next version.
> > +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...
I think so since we don't support section mappings right now, so
p*d_sect will always be false.
> > +{
> > + 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.
Sure, I'll rearrange this.
> > +
> > + 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.
I wasn't aware of these; we could define a similar set of functions
for x86 and then make it not arch-specific.
I wonder if we could also use follow_page_pte(), since we know that
the page is always present (given that it's been allocated).
Unfortunately follow_page_pte() is not exported.
Tycho
prev parent reply other threads:[~2017-09-18 20:56 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170907173609.22696-1-tycho@docker.com>
2017-09-07 17:36 ` [PATCH v6 05/11] arm64/mm: Add support for XPFO Tycho Andersen
2017-09-08 7:53 ` Christoph Hellwig
2017-09-08 17:24 ` Tycho Andersen
2017-09-14 10:41 ` Julien Grall
2017-09-14 11:29 ` Juergen Gross
2017-09-14 18:22 ` [kernel-hardening] " Mark Rutland
2017-09-18 21:27 ` Tycho Andersen
2017-09-07 17:36 ` [PATCH v6 07/11] arm64/mm, xpfo: temporarily map dcache regions Tycho Andersen
2017-09-14 18:25 ` Mark Rutland
2017-09-18 21:29 ` Tycho Andersen
2017-09-07 17:36 ` [PATCH v6 08/11] arm64/mm: Add support for XPFO to swiotlb Tycho Andersen
2017-09-07 17:36 ` [PATCH v6 09/11] arm64/mm: disable section/contiguous mappings if XPFO is enabled Tycho Andersen
2017-09-09 15:38 ` Laura Abbott
2017-09-07 17:36 ` [PATCH v6 10/11] mm: add a user_virt_to_phys symbol Tycho Andersen
2017-09-08 7:55 ` Christoph Hellwig
2017-09-08 15:44 ` Kees Cook
2017-09-11 7:36 ` Christoph Hellwig
2017-09-14 18:34 ` [kernel-hardening] " Mark Rutland
2017-09-18 20:56 ` Tycho Andersen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170918205609.hntcd3nfaq2gjj64@docker \
--to=tycho@docker.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).