Re: mm: NULL ptr deref handling mmaping of special mappings

Cyrill Gorcunov
2014-05-17T06:16:00Z

On Fri, May 16, 2014 at 03:40:48PM -0700, Andy Lutomirski wrote:
> >>
> >> There are other ways how to find where additional pages are laying but it
> >> would be great if there a straightforward interface for that (ie some mark
> >> in /proc/pid/maps output).
> >
> > I'll try to write a patch in time for 3.15.
> >
>
> 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.

Yeah, thanks a lot, Andy, this is more than enough.

> 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.

Ouch. Thanks for the note, I'll read new code with more attention and
report the effect it did over criu (prob. on next week).