From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by kanga.kvack.org (Postfix) with ESMTP id 2881F6B0035 for ; Fri, 16 May 2014 19:10:06 -0400 (EDT) Received: by mail-vc0-f170.google.com with SMTP id lf12so7099801vcb.29 for ; Fri, 16 May 2014 16:10:05 -0700 (PDT) Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by mx.google.com with ESMTPS id sj10si1999526vcb.15.2014.05.16.16.10.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 May 2014 16:10:05 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id if17so6947685vcb.36 for ; Fri, 16 May 2014 16:10:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <53769785.6060809@zytor.com> References: <20140514221140.GF28328@moon> <20140515084558.GI28328@moon> <20140515195320.GR28328@moon> <20140515201914.GS28328@moon> <20140515213124.GT28328@moon> <20140515215722.GU28328@moon> <53769785.6060809@zytor.com> Date: Fri, 16 May 2014 16:10:05 -0700 Message-ID: Subject: Re: mm: NULL ptr deref handling mmaping of special mappings From: Andy Lutomirski Content-Type: multipart/alternative; boundary=089e0111c00298e0c404f98c8373 Sender: owner-linux-mm@kvack.org List-ID: To: "H. Peter Anvin" Cc: linux-mm@kvack.org, Cyrill Gorcunov , Pavel Emelyanov , LKML , Sasha Levin , Andrew Morton , Dave Jones --089e0111c00298e0c404f98c8373 Content-Type: text/plain; charset=UTF-8 On May 16, 2014 4:56 PM, "H. Peter Anvin" 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 > > --089e0111c00298e0c404f98c8373 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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=3Dvdso/cleanups
> >
> > On 64-bit userspace, it results in:
> >
> > 7fffa1dfd000-7fffa1dfe000 r-xp 00000000 00:00 0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[v= dso]
> > 7fffa1dfe000-7fffa1e00000 r--p 00000000 00:00 0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[v= var]
> > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
> > =C2=A0 [vsyscall]
> >
> > On 32-bit userspace, it results in:
> >
> > f7748000-f7749000 r-xp 00000000 00:00 0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[vdso]
> > f7749000-f774b000 r--p 00000000 00:00 0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[vvar]
> > ffd94000-ffdb5000 rw-p 00000000 00:00 0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0[stack]
> >
> > Is this good for CRIU? =C2=A0Another approach would be to name bo= th of
> > these things "vdso", since they are sort of both the vd= so, but that
> > might be a bit confusing -- [vvar] is not static text the way tha= t
> > [vdso] is.
> >
> > If I backport this for 3.15 (which might be nasty -- I would argu= e
> > that the code change is actually a cleanup, but it's fairly > > intrusive), then [vvar] will be *before* [vdso], not after it. = =C2=A0I'd be
> > very hesitant to name both of them "[vdso]" in that cas= e, since there
> > is probably code that assumes that the beginning of "[vdso]&= quot; is a DSO.
> >
> > Note that it is *not* safe to blindly read from "[vvar]"= ;. =C2=A0On some
> > configurations you *will* get SIGBUS if you try to read from some= of
> > the vvar pages. =C2=A0(That's what started this whole thread.= ) =C2=A0Some pages
> > in "[vvar]" may have strange caching modes, so SIGBUS m= ight 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?=C2=A0 We can't ha= ndle 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.=C2=A0 Also, 32-bit code will cr= ash and burn if the vdso moves -- sysexit and sigreturn will die horrible d= eaths, I think.=C2=A0=C2=A0 None of these issues are new to 3.15.

--Andy

>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 -hpa
>
>

--089e0111c00298e0c404f98c8373-- -- 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: email@kvack.org