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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, 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 58F2DC4338F for ; Sat, 31 Jul 2021 22:11:50 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 3199260EBC for ; Sat, 31 Jul 2021 22:11:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3199260EBC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=johnericson.me Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.openwall.com Received: (qmail 32521 invoked by uid 550); 31 Jul 2021 22:11:39 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 32481 invoked from network); 31 Jul 2021 22:11:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=johnericson.me; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=XC4nL5KQf9oBgzHqGFiPmKgib/D5 J47Vg0BnLI9enIY=; b=bL5ExbfEWWsqoJ4XcjUD5FLVUNVKdOD//nkUMuLJAdk/ 7XMtKanesTRex1WPM12qElqehi9cB4bXz8ar1PgqPLMpge9BiG2xZlbmOorClzaU /3/KMYa+ZPzIjAt5aY0lDgip16rxJh+7QnvVKtxgu0dN6Pn/ik5xSE8BjL/+euHq IfcoucY8vq42cNtQyKBXCP6/XmNRmYNNks5ZUlYNJhvlXdh3V2hcPeLlrFP7np7o BhlmdchkFNAtSh1enXBFRGOzNTgYOZ3PApCw/Xg3eoEra6atk/ATLFiFdk7iXvO5 dxwnBo8Y3PtkRLrhary0S1PHEUZRJVDa2IT3rZnEoA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=XC4nL5 KQf9oBgzHqGFiPmKgib/D5J47Vg0BnLI9enIY=; b=ZpFBnchhxcYppH1ibhu2eI 4uuMM2TZ2K8Li7ANanIM1juGtCKfZXdIzDcSlVrwZb+BI+mNHWnMfweDFI/P2k8f povw0hnM6AHAKWrCbaZC4+WJOt+NKfvAy6njL90Zl3WMyqDzN08d5j8gPx31fPmI qGJ24vRKlVR+fdxIIr1zYo1roWB3HLQjwmv78Q+E3Md+To3i7MVpQH9I0/i7zjxw uFAsw1krT8XKKXzP8GNG8Q071D3BXDByiu1WVy7DhTlSc74kc46y46vjfN4ul6wD WYe0BRY6AWYYJGeZOIZ35YFKEswjuHQtDrbv/EPLN50XtZP6XzV3A45j6zNHXrSA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheekgddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedflfhohhhn ucfgrhhitghsohhnfdcuoehmrghilhesjhhohhhnvghrihgtshhonhdrmhgvqeenucggtf frrghtthgvrhhnpeeggeejheeikefhtdduledvffehkeettdelieeghffhhfeifffhvddt keekffffheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmrghilhesjhhohhhnvghrihgtshhonhdrmhgv X-ME-Proxy: X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-545-g7a4eea542e-fm-20210727.001-g7a4eea54 Mime-Version: 1.0 Message-Id: <1468d75c-57ae-42aa-85ce-2bee8d403763@www.fastmail.com> In-Reply-To: References: <20210729142415.qovpzky537zkg3dp@wittgenstein> Date: Sat, 31 Jul 2021 15:11:03 -0700 From: "John Ericson" To: "Al Viro" , "Christian Brauner" Cc: LKML , "David Laight" , "Andy Lutomirski" , "Jason A. Donenfeld" , "Kernel Hardening" , "Jann Horn" , "Christian Brauner" Subject: Re: Leveraging pidfs for process creation without fork Content-Type: multipart/alternative; boundary=aa95bf7a7742405481c723fb8e5473fb --aa95bf7a7742405481c723fb8e5473fb Content-Type: text/plain Do you mind pointing out one of those examples? I'm new to this, but if they follow a pattern I should be able to find the other examples based off it. I'm certainly curious to take a look :). I hope these issues aren't to deep. Ideally there's a nice decoupling so the creating process is just manipulating "inert" data structures for the embryo that scheduler doesn't even need see, and then after the embryonic process is submitted, when the context switches to it for the first time that's a completely normal process without special cases. The place complexity is hardest to avoid I think would be cleaning up the yet-unborn embryonic processes orphaned by exitted parent(s), because that will have to handle all the semi-initialized states those could be in (as opposed to real processes). John On Thu, Jul 29, 2021, at 6:41 PM, Al Viro wrote: > On Thu, Jul 29, 2021 at 04:24:15PM +0200, Christian Brauner wrote: > > On Wed, Jul 28, 2021 at 12:37:57PM -0400, John Cotton Ericson wrote: > > > Hi, > > > > > > I was excited to learn about about pidfds the other day, precisely in hopes > > > that it would open the door to such a "sane process creation API". I > > > searched the LKML, found this thread, and now hope to rekindle the > > > discussion; my apologies if there has been more discussion since that I > > > > Yeah, I haven't forgotten this discussion. A proposal is on my todo list > > for this year. So far I've scheduled some time to work on this in the > > fall. > > Keep in mind that quite a few places in kernel/exit.c very much rely upon the > lack of anything outside of thread group adding threads into it. Same for > fs/exec.c. > --aa95bf7a7742405481c723fb8e5473fb Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Do you min= d pointing out one of those examples? I'm new to this, but if they follo= w a pattern I should be able to find the other examples based off it. I'= m certainly curious to take a look :).

I ho= pe these issues aren't to deep. Ideally there's a nice decoupling so the= creating process is just manipulating "inert" data structures for the e= mbryo that scheduler doesn't even need see, and then after the embryonic= process is submitted, when the context switches to it for the first tim= e that's a completely normal process without special cases.

The place complexity is hardest to avoid I think would = be cleaning up the yet-unborn embryonic processes orphaned by exitted pa= rent(s), because that will have to handle all the semi-initialized state= s those could be in (as opposed to real processes).

John

On Thu, Jul 29, 2021, at 6:41= PM, Al Viro wrote:
On Thu, Jul 29, 2021 at 04:24:15PM +0200, Christian Brauner wrot= e:
> On Wed, Jul 28, 2021 at 12:37:57PM -0400, John Cot= ton Ericson wrote:
> > Hi,
> >&n= bsp;
> > I was excited to learn about about pidfds t= he other day, precisely in hopes
> > that it would o= pen the door to such a "sane process creation API". I
>= > searched the LKML, found this thread, and now hope to rekindle the=
> > discussion; my apologies if there has been more= discussion since that I
> 
> Yea= h, I haven't forgotten this discussion. A proposal is on my todo list
> for this year. So far I've scheduled some time to work = on this in the
> fall.

Kee= p in mind that quite a few places in kernel/exit.c very much rely upon t= he
lack of anything outside of thread group adding threads= into it.  Same for
fs/exec.c.

--aa95bf7a7742405481c723fb8e5473fb--