From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5259 invoked from network); 24 Jan 2021 18:48:28 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 Jan 2021 18:48:28 -0000 Received: (qmail 25831 invoked by uid 550); 24 Jan 2021 18:48:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 25813 invoked from network); 24 Jan 2021 18:48:24 -0000 Date: Sun, 24 Jan 2021 21:48:11 +0300 (MSK) From: Alexander Monakov To: musl@lists.openwall.com cc: Andrew Rogers In-Reply-To: <20210124181036.GS23432@brightrain.aerifal.cx> Message-ID: References: <20210124154026.GR23432@brightrain.aerifal.cx> <20210124181036.GS23432@brightrain.aerifal.cx> User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: Re: [musl] Potential DL_NOMMU_SUPPORT bug. > > sdcard [pseudo-]partition is usually mounted noexec, so mmap with PROT_EXEC > > should fail. > > Uhg, that makes no sense. Does it enforce that even for MAP_PRIVATE, > which should semantically be equivalent to just making anon memory > with the requested permissions and copying the file contents into it?? I think it makes sense: isn't the entire point of 'noexec' that a user who has write access only to noexec filesystems will not be able to run arbitrary binary code (assuming the already-present binaries are not cooperative, unlike musl ld.so with the above patch would be)? Enforcing noexec for MAP_PRIVATE ensures the users can not trivially side-step noexec by invoking ld.so (without extra checks on ld.so side). Alexander