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

[Andy Lutomirski <luto@amacapital.net>]

[-- Attachment #1: Type: text/plain, Size: 2082 bytes --]

On May 16, 2014 4:56 PM, "H. Peter Anvin" <hpa@zytor.com> wrote:
>
> 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?

(On phone, so this may bounce)

Does mremap work with remap_pfn_range?  We can't handle faults on the vvar
mapping.

I haven't tested at all, but it looks like arch_vma_name may get rather
confused if mremap happens.  Also, 32-bit code will crash and burn if the
vdso moves -- sysexit and sigreturn will die horrible deaths, I think.
None of these issues are new to 3.15.

--Andy

>
>         -hpa
>
>

[-- Attachment #2: Type: text/html, Size: 3096 bytes --]