From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751449AbbCTQJR (ORCPT ); Fri, 20 Mar 2015 12:09:17 -0400 Received: from mail-lb0-f170.google.com ([209.85.217.170]:32965 "EHLO mail-lb0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750916AbbCTQJN (ORCPT ); Fri, 20 Mar 2015 12:09:13 -0400 Date: Fri, 20 Mar 2015 19:09:10 +0300 From: Cyrill Gorcunov To: Kees Cook Cc: Davidlohr Bueso , Oleg Nesterov , Andrew Morton , Al Viro , koct9i@gmail.com, Linux-MM , LKML Subject: Re: [PATCH -next v2 0/4] mm: replace mmap_sem for mm->exe_file serialization Message-ID: <20150320160910.GA27066@moon> References: <1426372766-3029-1-git-send-email-dave@stgolabs.net> <20150315142137.GA21741@redhat.com> <1426431270.28068.92.camel@stgolabs.net> <20150315152652.GA24590@redhat.com> <1426434125.28068.100.camel@stgolabs.net> <20150315170521.GA2278@moon> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 16, 2015 at 03:08:40PM -0700, Kees Cook wrote: > > > >> Ok I think I am finally seeing where you are going. And I like it *a > >> lot* because it allows us to basically replace mmap_sem with rcu > >> (MMF_EXE_FILE_CHANGED being the only user that requires a lock!!), but > >> am afraid it might not be possible. I mean currently we have no rule wrt > >> to users that don't deal with prctl. > >> > >> Forbidding multiple exe_file changes to be generic would certainly > >> change address space semantics, probably for the better (tighter around > >> security), but changed nonetheless so users would have a right to > >> complain, no? So if we can get away with removing MMF_EXE_FILE_CHANGED > >> I'm all for it. Andrew? > > I can't figure out why MMF_EXE_FILE_CHANGED is used to stop a second > change. But it does seem useful to mark a process as "hey, we know for > sure this the exe_file changed on this process" from an accounting > perspective. Sure, except it start being more stopper for further development so ripping it off would help ;) > > And I'd agree about the malware: it would never use this interface, so > there's no security benefit I can see. Maybe I haven't had enough > coffee, though. :) Yes, same here, would never use it either.