From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Newsgroups: gmane.lisp.guile.devel Subject: Re: GNU Guile 3.0.9rc1 available for testing! Date: Mon, 23 Jan 2023 12:19:24 +0100 Message-ID: <877cxd33cz.fsf@gnu.org> References: <87v8l15hb2.fsf@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25467"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cc: To: Greg Troxel Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Jan 23 12:19:46 2023 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pJura-0006Oi-K5 for guile-devel@m.gmane-mx.org; Mon, 23 Jan 2023 12:19:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJurL-0007dc-K0; Mon, 23 Jan 2023 06:19:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJurH-0007cp-UK for guile-devel@gnu.org; Mon, 23 Jan 2023 06:19:28 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJurH-00015c-Dp; Mon, 23 Jan 2023 06:19:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-Reply-To:Date:References:Subject:To: From; bh=stMLufqxzwHBN0nNwg++KUtNzqFZSQ8v53OSeXBZQFw=; b=KaunNls4iRyMBFSkgeM4 mcoK2KXdxTSnhaFBX40WTiJ4MRIkjGJu34hhyZL5dB5S6RI7hX31o0syJBzeazzkrxwgHw+3s0T7g DuB5UhoRz3TNCBSDYHlH+Unu+NAXFzVCWz1lJk7nUR7Zt108Wi1jEZWU9ND9qc+XACvMqtOD+EiCR Od2zfH3a27r1SmN+uTIHp1Mcc00+XsZDvrdkuioDQQNEuo6K1PxqU753DiPcy9DE6I4BJ4yDELBUB qAUP4Crx6bofJwzfquuWkPg7SQTT3lkw7+WM9tBknriZhSTTDwGeO+dow3eshFyZkLcoE8UMZCtNk 1wS0fHh0C22Z6Q==; Original-Received: from [193.50.110.246] (helo=ribbon) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pJurG-0002FM-P0; Mon, 23 Jan 2023 06:19:26 -0500 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: Quartidi 4 =?utf-8?Q?Pluvi=C3=B4se?= an 231 de la =?utf-8?Q?R=C3=A9volution=2C?= jour du Perce-neige X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-pc-linux-gnu In-Reply-To: (Greg Troxel's message of "Sun, 22 Jan 2023 12:41:09 -0500") X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:21613 Archived-At: Greg Troxel skribis: > My second approach is using the rc tarball in pkgsrc. I had to patch > out the verify call. pkgsrc already works around PaX issues mostly, via > paxctl on things that do jit, after build and before use, and by > > --- libguile/loader.c.orig 2018-01-08 16:21:04.790894906 +0000 > +++ libguile/loader.c > @@ -484,7 +484,7 @@ map_file_contents (int fd, size_t len, i > char *data; > > #ifdef HAVE_SYS_MMAN_H > - data =3D mmap (NULL, len, PROT_READ, MAP_PRIVATE, fd, 0); > + data =3D mmap (NULL, len, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0= ); > if (data =3D=3D MAP_FAILED) > SCM_SYSERROR; > *is_read_only =3D 1; > > because (something like, am fuzzy) mprotect (at least ours) can only > reduce not add permissions. I still don't understand why this isn't a > more widespread issue. My understanding is that the expectation of being able to later mprotect that mapping to make it writable is a valid one per POSIX. Quoth : If PROT_WRITE is specified, the application shall ensure that it has opened the mapped objects in the specified address range with write permission, unless MAP_PRIVATE was specified in the original mapping, regardless of whether the file descriptors used to map the objects have since been closed. Here the original file descriptors are O_RDONLY, but the mapping is MAP_PRIVATE. I=E2=80=99m not sure how to best address that. Thoughts? Ludo=E2=80=99.