From: Frantisek Hrbata <fhrbata@redhat.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Will Huck <will.huckk@gmail.com>,
hpa@zytor.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
tglx@linutronix.de, mingo@redhat.com, x86@kernel.org,
oleg@redhat.com, kamaleshb@in.ibm.com, hechjie@cn.ibm.com
Subject: Re: [PATCH] x86: add phys addr validity check for /dev/mem mmap
Date: Wed, 1 May 2013 21:04:09 +0200 [thread overview]
Message-ID: <20130501190408.GA6508@dhcp-26-164.brq.redhat.com> (raw)
In-Reply-To: <51815CA3.4090807@intel.com>
On Wed, May 01, 2013 at 11:19:15AM -0700, Dave Hansen wrote:
> On 04/27/2013 08:17 PM, Will Huck wrote:
> >> PTE bits 51 - M are reserved, where M is physical address width
> >> found 2)
> >> Note: step 2) is actually not needed, we can always set just the
> >> 51th bit
> >> (0x8000000000000)
> >
> > What's the meaning here? You trigger oops since the address is beyond
> > max address cpu supported or access to a reserved page? If the answer is
> > the latter, I'm think it's not right. For example, the kernel code/data
> > section is reserved in memory, kernel access it will trigger oops? I
> > don't think so.
>
> I think you're confusing the original problem here with how we would
> implement the solution.
>
> /dev/mem essentially lets you create ptes with as large of a value as
> you like. You just mmap() it, and the kernel will build you a pte to
> access whatever crazy offset you choose.
>
> The problem is that on _some_ systems, you won't just get a bus error,
> the kernel actually sets up some ptes which the hardware objects to (the
> reserved bits in the pte), and we'll panic when the hardware sees the
> ptes. We're trying to avoid these panics by ensuring that we never
> create these nasty ptes.
>
> Those "nasty" PTEs point to memory which can not even possibly be
> *addressed* on the CPUs where they upset the hardware. In other words,
> if we limit /dev/mem to *possible* memory on the system (which is sane
> all by itself) we will also fix this particular problem.
Hi Dave,
thank you for jumping in. This is exactly what the patch is doing. Note that the
same check is already done in ioremap. This patch just uses the same approach
and adds the same check to mmap_mem. I would like to ask what do you think about
the fix and if it looks ok to you.
Many thanks
--
Frantisek Hrbata
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2013-05-01 19:04 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 12:28 [PATCH] x86: add phys addr validity check for /dev/mem mmap Frantisek Hrbata
2013-04-02 18:02 ` Oleg Nesterov
2013-04-02 18:48 ` H. Peter Anvin
2013-04-02 19:10 ` Frantisek Hrbata
2013-04-02 20:29 ` H. Peter Anvin
2013-04-02 20:52 ` Frantisek Hrbata
2013-04-24 11:36 ` Frantisek Hrbata
2013-04-04 1:11 ` Simon Jeons
2013-04-04 1:13 ` H. Peter Anvin
2013-04-04 1:17 ` Simon Jeons
2013-04-04 1:32 ` H. Peter Anvin
2013-04-04 1:53 ` Simon Jeons
2013-04-04 2:14 ` H. Peter Anvin
2013-04-04 2:17 ` Simon Jeons
2013-04-04 5:20 ` Simon Jeons
2013-04-11 2:40 ` Simon Jeons
2013-04-11 2:48 ` H. Peter Anvin
2013-04-11 2:58 ` Simon Jeons
2013-04-03 2:46 ` Cheng Jie He
2013-04-26 5:21 ` Will Huck
2013-04-26 15:35 ` Frantisek Hrbata
2013-04-27 7:00 ` Will Huck
2013-04-27 19:13 ` Frantisek Hrbata
2013-04-28 3:17 ` Will Huck
2013-04-28 4:00 ` H. Peter Anvin
2013-04-28 8:03 ` Will Huck
2013-05-01 18:19 ` Dave Hansen
2013-05-01 19:04 ` Frantisek Hrbata [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=20130501190408.GA6508@dhcp-26-164.brq.redhat.com \
--to=fhrbata@redhat.com \
--cc=dave.hansen@intel.com \
--cc=hechjie@cn.ibm.com \
--cc=hpa@zytor.com \
--cc=kamaleshb@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=oleg@redhat.com \
--cc=tglx@linutronix.de \
--cc=will.huckk@gmail.com \
--cc=x86@kernel.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).