From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10olkn2028.outbound.protection.outlook.com [40.92.40.28]) by sourceware.org (Postfix) with ESMTPS id 432863858C2C; Tue, 24 Aug 2021 21:58:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 432863858C2C ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lFMp6wGIRUrsM7ti6XRo4EKKHdavLT6VtEmmE3Xu4aNz5DKB4NgYmGZI7mcqoJgmsQnR8Fpu197ChlK7p2Y9L0bWtGM2RrvnDZrbI3uxBF159bmkYPxuKnD8bhnkI9ervTFQrj6Zaz1pr3S86HElyiU3xy5O/CdTN3NjOoZlbO4qP6rqAiQdLfiHV/OltIwPHuB1TF1XYfSZPl5WE/MqZYJql5a7lXvpcXOy/9j4KhAtDeavUcg4y3h51shAkywJde2L1BvUr1SrfkeNt9rw+VrZVg7sZHqSuQSA19f7Kd+oTrb4oRsNHg443FlsgwEX1xhbvEdvarCjGF49n3ZlWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iACWOLS+R4JhdEHbaQMFEzqu2bzHv25Wtw4wFz7aHMQ=; b=gCcyya9fZrSTnfm3fyXCyCKHSBkbZAWbvq/LCZ55VBU2A8/N2JfmUMWUAdEInTDVR2Sihx7wdvKjmQ5KQMZALc3KR+N3KHu5l84xcQcFwqEk/fp0MMaxE2bFQVROnr8ekcq9GxqmAulKveuK9Yw++2Uwi4ryzEdydRfYswMbp1wTnbbODsgdVAWQJOBnQ0ICxM7H2qgZGmwSQ2UjdWD9FTLTe053t0XeV0S41LW1LeB6QurGLzhDTSfjqSEJnSwtaX6KPVWyqHD21ttlvy2rIBnW29z/JJIWNas7a3WTokxrAznJyc+Ue5yREbKmo58my9RNsjD3SNH3rGslYKJ9vQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from MWHPR1401MB1951.namprd14.prod.outlook.com (2603:10b6:301:51::14) by MWHPR14MB1279.namprd14.prod.outlook.com (2603:10b6:300:8c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17; Tue, 24 Aug 2021 21:58:22 +0000 Received: from MWHPR1401MB1951.namprd14.prod.outlook.com ([fe80::adc0:8922:4de7:e7b7]) by MWHPR1401MB1951.namprd14.prod.outlook.com ([fe80::adc0:8922:4de7:e7b7%9]) with mapi id 15.20.4436.025; Tue, 24 Aug 2021 21:58:22 +0000 From: Jay K To: "Kaz Kylheku (libffi)" <382-725-6798@kylheku.com>, DJ Delorie CC: "libffi-discuss@sourceware.org" , Libffi-discuss Subject: Re: is fork() supported? Thread-Topic: is fork() supported? Thread-Index: AQHXiWtrnWK1bzfmykWVm1UIt/hNSatkkfAAgAAC1IeAHoCBgIAAApNngAAFzACAACjogIAAC9S2 Date: Tue, 24 Aug 2021 21:58:22 +0000 Message-ID: References: <09e0d2b62f62482b2fa1c29120a43078@mail.kylheku.com> In-Reply-To: <09e0d2b62f62482b2fa1c29120a43078@mail.kylheku.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [dC07e45SPpGKsD2c09ReZDTMdiHJuoPtEPVvhH4kivZQMLzBt2DIPyACCE4eyLMi] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 889c9dbb-bf82-4d50-7045-08d9674a4ac1 x-ms-traffictypediagnostic: MWHPR14MB1279: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3kCYF/b0R1uemFeO9apkcEecFVk/skeIijPK88M8xq47SjLgFcRf6TjEK3118fjXSp7moO2uGHVhEOXA2JwLfRNjDHUZ6Y/MygJ9bOUwDf7irBYA00I+Li8WT5rcUHL9iyI+qfjy13iitxYWa19GHYhRjAzzl7h2eg8hShu1O+niaiEheYgz2ImNqu0TLfqdriuY74pn63rbHcqTImGZXkGWEshhoWzHA+5lGL7d56OZTliICfH3X8tE0CzX0836fk2eAD1FezCRY0TYx5umErLurbQ+y/pnTS1PxWnU+mXb/3v4PIkXAm8OF7pDohj5ZVss1pmkSEiC37hBBNqtMlNsQQ1k6VVtwaRIUaPEQjBQlIahA5nQTtm33gYr4gGBjW977KtY/cgaQ+1GWuMPk5CtVAEJK+zWnxslKoeFjj8DzpnNXWQJU9hP8iQBHOj8 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: hld0KcpxaZptZAUqbUTZ30lT7NiToCMzVdzD1L13H6Kn5zSrEFQYKF71xBuw53xTcVQIvNYWjw7F7cQN8wkr3uVR/wTC5ujg9mSByuLnjFlKZfK5s/ReBqzNPImpFPeeQ9awMcbIjmsoQrCyE853YVj+DvuukKGUdt6X3zB9cmy5gFAqJBpSkMmTsOCEljYXb8Cm8sbtzh+YCj1KHkS3yQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-32894.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR1401MB1951.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 889c9dbb-bf82-4d50-7045-08d9674a4ac1 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2021 21:58:22.8787 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1279 X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00, DKIM_INVALID, DKIM_SIGNED, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_PASS, TXREP, T_SPF_HELO_TEMPERROR autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:58:31 -0000 I have used the multi-mmap of static code in another project. Can libffi not always do that? > The problem case is when libffi can't mmap a chunk of write+exec memory, Why does it need to, given the multi-mmap of static trampoline approach? > 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 = write. People speak of "arbitrary codegen" (ACG) or unspecififically "JIT", and "something else", I have never seen a name for, "non-arbitrary codegen"?, the scenario where there is static code, and it can be mapped multiple time= s. In ACG, the two mapping approach is used by some systems. The writable address may be "difficult" for an attacker to find. It ups the arms race, some. I cannot quantify that. The writing might also be done from another process (in Windows this is "easy", at the API level, given an adequately factored JIT.. I realize the double whammy here, of both likely different addresses and address spaces, on existing code). The executing process might even be prohibited from having the writable ali= as, which is surely a very nice escalation. But, all that aside, given the recent work in libffi, the follow-up to "trampfd", why is a writable mapping every needed? I believe MacOSX also has this as an extension like this, in that instead o= f giving an fd to map, you can give an address, to another function, I cannot find the name. This can be used, I guess, to avoid remapping the e= ntire .so. Thank you, - Jay ________________________________ From: Kaz Kylheku (libffi) <382-725-6798@kylheku.com> Sent: Tuesday, August 24, 2021 9:12 PM To: DJ Delorie Cc: Jay K ; libffi-discuss@sourceware.org ; Libffi-discuss Subject: Re: is fork() supported? 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. > > Ha! Yeah, not about djgpp, which I think "just works" ;-) > >> 3 So libffi no longer has read/write/execute memory, or turns >> read/write into execute, correct? > > The problem case is when libffi can't mmap a chunk of write+exec > 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 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 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.