linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Andy Lutomirski <luto@amacapital.net>,
	Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Sasha Levin <sasha.levin@oracle.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Dave Jones <davej@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Pavel Emelyanov <xemul@parallels.com>
Subject: Re: mm: NULL ptr deref handling mmaping of special mappings
Date: Fri, 16 May 2014 15:56:05 -0700	[thread overview]
Message-ID: <53769785.6060809@zytor.com> (raw)
In-Reply-To: <CALCETrU5-4sMyOW7t75PJ4RQ3WdUg=s2xhYG5uEstm_LEOV+mg@mail.gmail.com>

On 05/16/2014 03:40 PM, Andy Lutomirski wrote:
> 
> My current draft is here:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=vdso/cleanups
> 
> On 64-bit userspace, it results in:
> 
> 7fffa1dfd000-7fffa1dfe000 r-xp 00000000 00:00 0                          [vdso]
> 7fffa1dfe000-7fffa1e00000 r--p 00000000 00:00 0                          [vvar]
> ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
>   [vsyscall]
> 
> On 32-bit userspace, it results in:
> 
> f7748000-f7749000 r-xp 00000000 00:00 0                                  [vdso]
> f7749000-f774b000 r--p 00000000 00:00 0                                  [vvar]
> ffd94000-ffdb5000 rw-p 00000000 00:00 0                                  [stack]
> 
> Is this good for CRIU?  Another approach would be to name both of
> these things "vdso", since they are sort of both the vdso, but that
> might be a bit confusing -- [vvar] is not static text the way that
> [vdso] is.
> 
> If I backport this for 3.15 (which might be nasty -- I would argue
> that the code change is actually a cleanup, but it's fairly
> intrusive), then [vvar] will be *before* [vdso], not after it.  I'd be
> very hesitant to name both of them "[vdso]" in that case, since there
> is probably code that assumes that the beginning of "[vdso]" is a DSO.
> 
> Note that it is *not* safe to blindly read from "[vvar]".  On some
> configurations you *will* get SIGBUS if you try to read from some of
> the vvar pages.  (That's what started this whole thread.)  Some pages
> in "[vvar]" may have strange caching modes, so SIGBUS might not be the
> only surprising thing about poking at it.
> 

mremap() should work on these pages, right?

	-hpa



  reply	other threads:[~2014-05-16 22:56 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-14 15:55 mm: NULL ptr deref handling mmaping of special mappings Sasha Levin
2014-05-14 20:23 ` Andrew Morton
2014-05-14 20:41   ` Sasha Levin
2014-05-14 21:03     ` Andrew Morton
2014-05-14 21:11       ` Sasha Levin
2014-05-14 21:31         ` Andrew Morton
2014-05-14 21:33           ` Andy Lutomirski
2014-05-14 22:11             ` Cyrill Gorcunov
2014-05-14 22:23               ` Andy Lutomirski
2014-05-15  2:36                 ` Pavel Emelyanov
2014-05-15 19:42                   ` Andy Lutomirski
2014-05-19  8:27                     ` Pavel Emelyanov
2014-05-19  8:40                       ` Cyrill Gorcunov
2014-05-15  8:45                 ` Cyrill Gorcunov
2014-05-15 19:46                   ` Andy Lutomirski
2014-05-15 19:53                     ` Cyrill Gorcunov
2014-05-15 19:59                       ` Andy Lutomirski
2014-05-15 20:19                         ` Cyrill Gorcunov
2014-05-15 21:31                           ` Cyrill Gorcunov
2014-05-15 21:42                             ` Andy Lutomirski
2014-05-15 21:57                               ` Cyrill Gorcunov
2014-05-15 22:15                                 ` Andy Lutomirski
2014-05-16 22:40                                   ` Andy Lutomirski
2014-05-16 22:56                                     ` H. Peter Anvin [this message]
2014-05-17  6:15                                     ` Cyrill Gorcunov
2014-05-14 22:51           ` Andy Lutomirski
2014-05-14 21:26       ` Andy Lutomirski

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=53769785.6060809@zytor.com \
    --to=hpa@zytor.com \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=sasha.levin@oracle.com \
    --cc=xemul@parallels.com \
    /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).