From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58EB0C433E1 for ; Thu, 30 Jul 2020 22:02:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2551C21883 for ; Thu, 30 Jul 2020 22:02:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2551C21883 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8F0698D0006; Thu, 30 Jul 2020 18:02:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A1D48D0005; Thu, 30 Jul 2020 18:02:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 792488D0006; Thu, 30 Jul 2020 18:02:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0195.hostedemail.com [216.40.44.195]) by kanga.kvack.org (Postfix) with ESMTP id 636A18D0005 for ; Thu, 30 Jul 2020 18:02:25 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 2F0563622 for ; Thu, 30 Jul 2020 22:02:25 +0000 (UTC) X-FDA: 77096116650.03.tent13_19021e226f7e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id F1C9528A4E8 for ; Thu, 30 Jul 2020 22:02:24 +0000 (UTC) X-HE-Tag: tent13_19021e226f7e X-Filterd-Recvd-Size: 7649 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Thu, 30 Jul 2020 22:02:24 +0000 (UTC) Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1k1Gcs-004a9H-FX; Thu, 30 Jul 2020 16:02:10 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1k1Gcr-000601-6f; Thu, 30 Jul 2020 16:02:10 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Steven Sistare Cc: Matthew Wilcox , Anthony Yznaga , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-arch@vger.kernel.org, mhocko@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, arnd@arndb.de, keescook@chromium.org, gerg@linux-m68k.org, ktkhai@virtuozzo.com, christian.brauner@ubuntu.com, peterz@infradead.org, esyr@redhat.com, jgg@ziepe.ca, christian@kellner.me, areber@redhat.com, cyphar@cyphar.com References: <1595869887-23307-1-git-send-email-anthony.yznaga@oracle.com> <20200730152250.GG23808@casper.infradead.org> <20200730171251.GI23808@casper.infradead.org> <63a7404c-e4f6-a82e-257b-217585b0277f@oracle.com> <20200730174956.GK23808@casper.infradead.org> Date: Thu, 30 Jul 2020 16:58:58 -0500 In-Reply-To: (Steven Sistare's message of "Thu, 30 Jul 2020 14:27:21 -0400") Message-ID: <87y2n03brx.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1k1Gcr-000601-6f;;;mid=<87y2n03brx.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX196C4Bc9XRPT8Fq7uQRPXVtTpJ1Q6VZOFs= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [RFC PATCH 0/5] madvise MADV_DOEXEC X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) X-Rspamd-Queue-Id: F1C9528A4E8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Steven Sistare writes: > On 7/30/2020 1:49 PM, Matthew Wilcox wrote: >> On Thu, Jul 30, 2020 at 01:35:51PM -0400, Steven Sistare wrote: >>> mshare + VA reservation is another possible solution. >>> >>> Or MADV_DOEXEC alone, which is ready now. I hope we can get back to reviewing that. >> >> We are. This is the part of the review process where we explore other >> solutions to the problem. >> >>>>> Also, we need to support updating legacy processes that already created anon segments. >>>>> We inject code that calls MADV_DOEXEC for such segments. >>>> >>>> Yes, I was assuming you'd inject code that called mshare(). >>> >>> OK, mshare works on existing memory and builds a new vma. >> >> Actually, reparents an existing VMA, and reuses the existing page tables. >> >>>> Actually, since you're injecting code, why do you need the kernel to >>>> be involved? You can mmap the new executable and any libraries it depends >>>> upon, set up a new stack and jump to the main() entry point, all without >>>> calling exec(). I appreciate it'd be a fair amount of code, but it'd all >>>> be in userspace and you can probably steal / reuse code from ld.so (I'm >>>> not familiar with the details of how setting up an executable is done). >>> >>> Duplicating all the work that the kernel and loader do to exec a process would >>> be error prone, require ongoing maintenance, and be redundant. Better to define >>> a small kernel extension and leave exec to the kernel. >> >> Either this is a one-off kind of thing, in which case it doesn't need >> ongoing maintenance, or it's something with broad applicability, in >> which case it can live as its own userspace project. It could even >> start off life as part of qemu and then fork into its own project. > > exec will be enhanced over time in the kernel. A separate user space implementation > would need to track that. > > Reimplementing exec in userland would be a big gross mess. Not a good solution when > we have simple and concise ways of solving the problem. The interesting work is not done in exec. The interesting work of loading an executable is done in ld.so, and ld.so lives in userspace. >> The idea of tagging an ELF executable to say "I can cope with having >> chunks of my address space provided to me by my executor" is ... odd. > > I don't disagree. But it is useful. We already pass a block of data containing > environment variables and arguments from one process to the next. Preserving > additional segments is not a big leap from there. But we randomize where that block lives. It has been found to be very useful to have randomization by default and you are arguing against that kind of randomization. Here is another suggestion. Have a very simple program that does: for (;;) { handle = dlopen("/my/real/program"); real_main = dlsym(handle, "main"); real_main(argc, argv, envp); dlclose(handle); } With whatever obvious adjustments are needed to fit your usecase. That should give the same level of functionality, be portable to all unices, and not require you to duplicate code. It belive it limits you to not upgrading libc, or librt but that is a comparatively small limitation. Given that in general the interesting work is done in userspace and that userspace has provided an interface for reusing that work already. I don't see the justification for adding anything to exec at this point. Eric