From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11831 Path: news.gmane.org!.POSTED!not-for-mail From: Pascal Cuoq Newsgroups: gmane.linux.lib.musl.general Subject: musl's putenv makes assumptions about memcmp Date: Mon, 21 Aug 2017 05:50:28 +0000 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_A1F6D5AF081B4BE2A744577CBBA49E5Ctrustinsoftcom_" X-Trace: blaine.gmane.org 1503294631 9614 195.159.176.226 (21 Aug 2017 05:50:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 21 Aug 2017 05:50:31 +0000 (UTC) To: "musl@lists.openwall.com" Original-X-From: musl-return-11844-gllmg-musl=m.gmane.org@lists.openwall.com Mon Aug 21 07:50:26 2017 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1djfbL-0001eC-SZ for gllmg-musl@m.gmane.org; Mon, 21 Aug 2017 07:50:15 +0200 Original-Received: (qmail 1682 invoked by uid 550); 21 Aug 2017 05:50:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1648 invoked from network); 21 Aug 2017 05:50:18 -0000 Thread-Topic: musl's putenv makes assumptions about memcmp Thread-Index: AQHTGkFkVvaucxpu80ySc1R1scBYCg== Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [86.246.63.122] Xref: news.gmane.org gmane.linux.lib.musl.general:11831 Archived-At: --_000_A1F6D5AF081B4BE2A744577CBBA49E5Ctrustinsoftcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Quoting myself from a previous report: when I started testing parts of musl with TIS Interpreter, I made sure to u= se TIS Interpreter versions of low-level functions such as memcpy and memse= t, while testing higher-level functions. Musl's functions can provide guara= ntees beyond the standard, and it is fair game to rely on these guarantees = elsewhere in musl since musl's versions of these functions are called, but = I thought it would be interesting to know that musl provides additional gua= rantees and relies on them. An interesting new example just turned up. According to the succinct description of memcmp in the C standard, and to t= he interpretation of Glibc's developers, memcmp should only be called with = fully valid buffers, even when a sequential comparison of the two buffers w= ould not make any out-of-bounds access. Please see https://trust-in-soft.co= m/memcmp-requires-pointers-to-fully-valid-buffers/ for details. musl's implementation of putenv uses memcmp exactly like the blog post says= it shouldn't: https://git.musl-libc.org/cgit/musl/tree/src/env/putenv.c?id=3D80bf5952551c= 002cf12d96deb145629765272db0 This doesn't matter now, because the implementation of memcmp used is musl'= s, which does sequentially compare characters and does stop as early as it = knows what to return: https://git.musl-libc.org/cgit/musl/tree/src/string/m= emcmp.c?id=3D80bf5952551c002cf12d96deb145629765272db0 However this behavior of musl's memcmp should be documented and preserved i= n future versions. Otherwise introducing a memcmp optimization in musl simi= lar to Glibc's would silently break putenv, making it segfault in rare and = perhaps hard to reproduce circumstances. Alternately, it is possible to make putenv rely only on the standard behavi= or of the functions it calls. It seems to me that strncmp can be used here.= The difference in execution speed between memcmp and strncmp should not ma= tter in this context. Pascal --_000_A1F6D5AF081B4BE2A744577CBBA49E5Ctrustinsoftcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hello,

Quoting myself from a previous report:

when I started testing parts of musl w= ith TIS Interpreter, I made sure to use TIS Interpreter versions of low-lev= el functions such as memcpy and memset, while testing higher-level function= s. Musl's functions can provide guarantees beyond the standard, and it is fair game to rely on these guarantees elsew= here in musl since musl's versions of these functions are called, but I tho= ught it would be interesting to know that musl provides additional guarante= es and relies on them.

An interesting new example just turned up.

According to the succinct description of memcmp in the C st= andard, and to the interpretation of Glibc's developers, memcmp should only= be called with fully valid buffers, even when a sequential comparison of t= he two buffers would not make any out-of-bounds access. Please see https://trust= -in-soft.com/memcmp-requires-pointers-to-fully-valid-buffers/ for = details.

musl's implementation of putenv uses memcmp exactly like th= e blog post says it shouldn't:

https:/= /git.musl-libc.org/cgit/musl/tree/src/env/putenv.c?id=3D80bf5952551c002cf12= d96deb145629765272db0

This doesn't matter now, because the implementation of memc= mp used is musl's, which does sequentially compare characters and does stop= as early as it knows what to return: https://git.musl-libc.org/cgit/musl/tree/src/string/= memcmp.c?id=3D80bf5952551c002cf12d96deb145629765272db0

However this behavior of musl's memcmp should be documented= and preserved in future versions. Otherwise introducing a memcmp optimizat= ion in musl similar to Glibc's would silently break putenv, making it segfa= ult in rare and perhaps hard to reproduce circumstances.

Alternately, it is possible to make putenv rely only on the= standard behavior of the functions it calls. It seems to me that strncmp c= an be used here. The difference in execution speed between memcmp and strnc= mp should not matter in this context.

Pascal

--_000_A1F6D5AF081B4BE2A744577CBBA49E5Ctrustinsoftcom_--