From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) by sourceware.org (Postfix) with ESMTPS id 95A0A3858401; Tue, 24 Aug 2021 21:12:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 95A0A3858401 Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id IYZym7kqm4bInIdiKmNRgY; Tue, 24 Aug 2021 21:12:08 +0000 Received: from kylheku.com ([70.79.163.252]) by cmsmtp with ESMTPA id IdiJmFRHiM8olIdiJmO2Wf; Tue, 24 Aug 2021 21:12:08 +0000 X-Authority-Analysis: v=2.4 cv=Ua6U9IeN c=1 sm=1 tr=0 ts=612560a8 a=95A0EdhkF1LMGt25d7h1IQ==:117 a=95A0EdhkF1LMGt25d7h1IQ==:17 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=MhDmnRu9jo8A:10 a=5KLPUuaC_9wA:10 a=69EAbJreAAAA:8 a=gODAn30l9iGWjPbJfI8A:9 a=QEXdDO2ut3YA:10 Received: from www-data by kylheku.com with local (Exim 4.72) (envelope-from <382-725-6798@kylheku.com>) id 1mIdiJ-00089H-4A; Tue, 24 Aug 2021 14:12:07 -0700 To: DJ Delorie Subject: Re: is fork() =?UTF-8?Q?supported=3F?= X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Aug 2021 14:12:07 -0700 From: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com> Cc: Jay K , libffi-discuss@sourceware.org, Libffi-discuss In-Reply-To: References: Message-ID: <09e0d2b62f62482b2fa1c29120a43078@mail.kylheku.com> X-Sender: 382-725-6798@kylheku.com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4xfJ9ee8jNQONZ0TwzIW1u+Kg1ixDQtB2rvwSztNvJcEzIAy3FMuOTw2SfuVhu0FUCHyz4FFnatYkgMRfkMEzMktBpG/MBPLom2rr3p3DJJqFVq5B9x9DD DgrboT9PYkMmCeLZxm62vTyLgWtfGAk63ztReQPdeIuOXb1SP/3DiE4fkvn6M6SvSuSaMmreHeFGW4OpAqPAJz7za1FYwikdc+h53Z3q+zfblJU+f1ZLi7Fz r4MyJYE6Fq/FmX5A+MbGxU3hI5Z44VDMEkgNmM0ZwUD88REDrbEEdz2Rndp00hUc+A7x+73htGKgx/B5pUNnHSFncn0CNR65e5xPpjVI/Z4= X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, FROM_STARTS_WITH_NUMS, HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libffi-discuss@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libffi-discuss mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 21:12:13 -0000 On 2021-08-24 11:45, DJ Delorie via Libffi-discuss wrote: > Jay K writes: >> 1 Sorry, I assumed mail from DJ was about djgpp, and that context was >> lacking in libffi. My mistake. >=20 > Ha! Yeah, not about djgpp, which I think "just works" ;-) >=20 >> 3 So libffi no longer has read/write/execute memory, or turns >> read/write into execute, correct? >=20 > The problem case is when libffi can't mmap a chunk of write+exec=20 > memory, > and resorts to writing to a file and mapping the file read+exec, which > happens in Linux with certain selinux security profiles. Isn't there some way way set up two anonymous, virtual regions such that they alias to the same frames? One can be read+exec, and the other=20 write. I could easily write code in the kernel to take some user space pages of the calling process and make them also appear somewhere else in the address space. I don't see anything like that in the Linux mmap among any of the flags and whatnot. It would be a useful extension. Imagine a MAP_ALIAS flag, which requires the void *addr argument to be present. addr, normally used with MAP_FIXED, in this case would specify the virtual address of the target range to be aliased by the returned mapping. Being able to obtain a writable alias of executable space is a security risk though: the risk that an attacker can inject a mmap call to create an writable alias of executable space. Some new PROT_* bit could help mitigate: the read+exec mapping would=20 have this bit to indicate that such aliasing of it is permitted. Mappings like shared libs and executables would not have this bit, only libffi's closure buffer. (Attackers who can call mmap to obtain a writable mapping could arguably perpetrate the same workaround as libffi: write to a file and then read+exec map it. So why worry about this too much.) Summary: /* new flags + kernel support */ #define MAP_ALIAS ... #define PROT_ALIAS_OK ... void *closures =3D mmap(NULL, len, PROT_READ | PROT_EXEC | PROT_ALIAS_OK, MAP_ANONYMOUS | MAP_PRIVATE, -1, 0); void *write_closures =3D mmap(closures, len, PROT_WRITE, MAP_ALIAS | MAP_PRIVATE, -1, 0); Write closures through write_closures pointer, execute via closures pointer. The kernel code for MAP_ALIAS has to ensure that fork observes this linkage. That is tricky. The child process gets its own copy of this memory, and the two aliased views of it. The views cannot just be subject to independent COW because their aliasing relationship will break. One more detail: mprotect should disallow PROT_ALIAS_OK. Only the original mmap must be able to specify PROT_ALIAS_OK, which is then a mapping's immutable flag.