linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Balbir Singh <bsingharora@gmail.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
	Paul Mackerras <paulus@samba.org>,
	Kees Cook <keescook@chromium.org>,
	Breno Leitao <leitao@debian.org>,
	Laura Abbott <labbott@redhat.com>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>
Subject: Re: [PATCH] powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash
Date: Fri, 19 May 2017 04:00:06 +1000	[thread overview]
Message-ID: <CAKTCnzna2SFRhwd=fHEX_XevEHr+yZ6ar3UExr_gpXusFMYpXg@mail.gmail.com> (raw)
In-Reply-To: <1495103851-14916-1-git-send-email-mpe@ellerman.id.au>

On Thu, May 18, 2017 at 8:37 PM, Michael Ellerman <mpe@ellerman.id.au> wrote:
> virt_addr_valid() is supposed to tell you if it's OK to call virt_to_page() on
> an address. What this means in practice is that it should only return true for
> addresses in the linear mapping which are backed by a valid PFN.
>
> We are failing to properly check that the address is in the linear mapping,
> because virt_to_pfn() will return a valid looking PFN for more or less any
> address. That bug is actually caused by __pa(), used in virt_to_pfn().
>
> eg: __pa(0xc000000000010000) = 0x10000  # Good
>     __pa(0xd000000000010000) = 0x10000  # Bad!
>     __pa(0x0000000000010000) = 0x10000  # Bad!
>

I fixed something similar in skiboot and KVM, I should have audited this space
as well.

> This started happening after commit bdbc29c19b26 ("powerpc: Work around gcc
> miscompilation of __pa() on 64-bit") (Aug 2013), where we changed the definition
> of __pa() to work around a GCC bug. Prior to that we subtracted PAGE_OFFSET from
> the value passed to __pa(), meaning __pa() of a 0xd or 0x0 address would give
> you something bogus back.
>
> Until we can verify if that GCC bug is no longer an issue, or come up with
> another solution, this commit does the minimal fix to make virt_addr_valid()
> work, by explicitly checking that the address is in the linear mapping region.
>
> Fixes: bdbc29c19b26 ("powerpc: Work around gcc miscompilation of __pa() on 64-bit")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
>  arch/powerpc/include/asm/page.h | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 2a32483c7b6c..8da5d4c1cab2 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -132,7 +132,19 @@ extern long long virt_phys_offset;
>  #define virt_to_pfn(kaddr)     (__pa(kaddr) >> PAGE_SHIFT)
>  #define virt_to_page(kaddr)    pfn_to_page(virt_to_pfn(kaddr))
>  #define pfn_to_kaddr(pfn)      __va((pfn) << PAGE_SHIFT)
> +
> +#ifdef CONFIG_PPC_BOOK3S_64
> +/*
> + * On hash the vmalloc and other regions alias to the kernel region when passed
> + * through __pa(), which virt_to_pfn() uses. That means virt_addr_valid() can
> + * return true for some vmalloc addresses, which is incorrect. So explicitly
> + * check that the address is in the kernel region.
> + */
> +#define virt_addr_valid(kaddr) (REGION_ID(kaddr) == KERNEL_REGION_ID && \
> +                               pfn_valid(virt_to_pfn(kaddr)))
> +#else
>  #define virt_addr_valid(kaddr) pfn_valid(virt_to_pfn(kaddr))
> +#endif
>

Looks good to me

Reviewed-by: Balbir Singh <bsingharora@gmail.com>

  parent reply	other threads:[~2017-05-18 18:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-18 10:37 [PATCH] powerpc/mm: Fix virt_addr_valid() etc. on 64-bit hash Michael Ellerman
2017-05-18 11:57 ` Paul Mackerras
2017-05-18 18:00 ` Balbir Singh [this message]
2017-05-18 19:04 ` Breno Leitao
2017-05-19  9:45 ` Michael Ellerman

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='CAKTCnzna2SFRhwd=fHEX_XevEHr+yZ6ar3UExr_gpXusFMYpXg@mail.gmail.com' \
    --to=bsingharora@gmail.com \
    --cc=keescook@chromium.org \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=labbott@redhat.com \
    --cc=leitao@debian.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.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).