From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932388AbcGLOO2 (ORCPT ); Tue, 12 Jul 2016 10:14:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46786 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750990AbcGLOO1 (ORCPT ); Tue, 12 Jul 2016 10:14:27 -0400 Date: Tue, 12 Jul 2016 16:14:46 +0200 From: Oleg Nesterov To: Andy Lutomirski Cc: Dmitry Safonov , Michal Hocko , Vladimir Davydov , "linux-kernel@vger.kernel.org" , Dmitry Safonov <0x7f454c46@gmail.com>, "linux-mm@kvack.org" , Ingo Molnar , Cyrill Gorcunov , xemul@virtuozzo.com, Andy Lutomirski , Thomas Gleixner , "H. Peter Anvin" , X86 ML Subject: Re: [PATCHv2 3/6] x86/arch_prctl/vdso: add ARCH_MAP_VDSO_* Message-ID: <20160712141446.GB28837@redhat.com> References: <20160629105736.15017-1-dsafonov@virtuozzo.com> <20160629105736.15017-4-dsafonov@virtuozzo.com> <20160711182654.GA19160@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 12 Jul 2016 14:14:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/11, Andy Lutomirski wrote: > > On Mon, Jul 11, 2016 at 11:26 AM, Oleg Nesterov wrote: > > > > Do we really care? I mean, the kernel can't crash or something like this, > > just the old vdso mapping can faultin the "wrong" page from the new > > vdso_image, right? > > That makes me nervous. IMO a mapping should have well-defined > semantics. Perhaps. but map_vdso() will be special anyway, it also changes ->vdso. For example, if a 32-bit application calls prctl(ARCH_MAP_VDSO) from a signal handler and we unmap the old vdso mapping, it will crash later trying to call the (unmapped) restorer == kernel_rt_sigreturn. > If nothing else, could be really messy if the list of > pages were wrong. I do not see anything really wrong, but I can easily miss something. And don't get me wrong, I agree that any cleanup (say, associate vdso image with vma) makes sense. > My real concern is DoS: I doubt that __install_special_mapping gets > all the accounting right. Yes, and if it was not clear I fully agree. Even if we forget about the accounting, I feel that special mappings must not be abused by userspace. > > So it seems that we should do this by hand somehow. But in fact, what > > I actually think right now is that I am totally confused and got lost ;) > > I'm starting to wonder if we should finally suck it up and give > special mappings a non-NULL vm_file so we can track them properly. > Oleg, weren't you thinking of doing that for some other reason? Yes, uprobes. Currently we can't probe vdso page(s). Oleg.