From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756371AbaEPW42 (ORCPT ); Fri, 16 May 2014 18:56:28 -0400 Received: from terminus.zytor.com ([198.137.202.10]:60653 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752758AbaEPW41 (ORCPT ); Fri, 16 May 2014 18:56:27 -0400 Message-ID: <53769785.6060809@zytor.com> Date: Fri, 16 May 2014 15:56:05 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Andy Lutomirski , Cyrill Gorcunov CC: Andrew Morton , Sasha Levin , "linux-mm@kvack.org" , Dave Jones , LKML , Pavel Emelyanov Subject: Re: mm: NULL ptr deref handling mmaping of special mappings References: <20140514221140.GF28328@moon> <20140515084558.GI28328@moon> <20140515195320.GR28328@moon> <20140515201914.GS28328@moon> <20140515213124.GT28328@moon> <20140515215722.GU28328@moon> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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