From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 4c06403d for ; Fri, 12 Apr 2019 16:12:27 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id F151C95084; Sat, 13 Apr 2019 02:12:25 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 604AE95075; Sat, 13 Apr 2019 02:11:53 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id E1BD495075; Sat, 13 Apr 2019 02:11:50 +1000 (AEST) Received: from zimbra.anteil.com (zimbra.anteil.com [67.110.179.138]) by minnie.tuhs.org (Postfix) with ESMTP id 09F2E95074 for ; Sat, 13 Apr 2019 02:11:50 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.anteil.com (Postfix) with ESMTP id 6D680100AA; Fri, 12 Apr 2019 12:11:49 -0400 (EDT) Received: from zimbra.anteil.com ([127.0.0.1]) by localhost (zimbra.anteil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 831FFIWQ11xL; Fri, 12 Apr 2019 12:11:47 -0400 (EDT) Received: from zimbra.anteil.com (zimbra.anteil.com [192.168.1.22]) by zimbra.anteil.com (Postfix) with ESMTP id 8E62010072; Fri, 12 Apr 2019 12:11:47 -0400 (EDT) Date: Fri, 12 Apr 2019 11:11:47 -0500 (EST) From: Jim Capp To: Richard Salz Message-ID: <32714704.14145.1555085507471.JavaMail.root@zimbraanteil> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_14144_29184140.1555085507471" X-Originating-IP: [192.168.200.43] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - SAF3 (Linux)/6.0.7_GA_2473.UBUNTU8) Subject: Re: [TUHS] "Fork considered harmful" X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: tuhs@tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" ------=_Part_14144_29184140.1555085507471 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I think the problem with fork() is that it's elegance invites people to use it outside its sweet spot. I always thought (perhaps wrongly) that fork() didn't have to copy all the memory, just the stack and user areas, and that VM page table entries were cloned to share the code segment. fork() is beautiful for what it is and what it does. Being able to create a mirror image of the current process, and to be able to share all the I/O and signal states is cool, if that's what you want. I think the author of the micro$oft article is complaining that fork() shares too much, and therefore to use it is a security risk. If you don't want to share all that stuff, maybe you shouldn't be using fork(), or, you should fork() early, sharing EXACTLY what you want to share and nothing more, and then differentiate with exec(). C is elegant. C can also be dangerous if you don't use it wisely. I think the author should take a lesson from "The Kings Toaster". http://www.ee.ryerson.ca:8080/~elf/hack/ktoast.html Cheers, Jim From: "Richard Salz" To: tuhs@tuhs.org Sent: Wednesday, April 10, 2019 7:06:23 PM Subject: [TUHS] "Fork considered harmful" Any view on this? https://www.microsoft.com/en-us/research/publication/a-fork-in-the-road/ ------=_Part_14144_29184140.1555085507471 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= >I think the problem with fork() is that i= t's elegance invites people to use it outside its sweet spot.

I always thought (perhaps wrongly) that fork() didn't have to copy all the= memory, just the stack and user areas, and that VM page table entries were= cloned to share the code segment.

fork() is beautiful for what it is and what it does.&= nbsp; Being able to create a mirror image of the current process, and to be= able to share all the I/O and signal states is cool, if that's what you wa= nt.  I think the author of the m= icro$oft article is complaining that fork() shares too much, and therefore = to use it is a security risk. 

If you don't want to share = all that stuff, maybe you shouldn't be using fork(), or, you should fork() = early, sharing EXACTLY what you want to share and nothing more, and then di= fferentiate with exec().

C is elegant.  C can also be dangerous if you don't use it wisely= .

I think the author should take a lesson from "The Kings Toas= ter".

=09http://www.ee.ryerson.ca:8080/~elf/hack/ktoa= st.html

Cheers,

Jim




From: "Richard Sal= z" <rich.salz@gmail.com>
To: tuhs@tuhs.org
Sent: Wednesday, April 10, 2019 7:06:23 PM
Subject: [TUH= S] "Fork considered harmful"

------=_Part_14144_29184140.1555085507471--