From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9070 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: string word-at-a-time and atomic.h FAQ on twitter Date: Fri, 8 Jan 2016 17:05:35 -0500 Message-ID: <20160108220535.GO238@brightrain.aerifal.cx> References: <20160105164640.GL23362@port70.net> <20160105175040.GA238@brightrain.aerifal.cx> <5690315B.5010206@openwall.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1452290767 21212 80.91.229.3 (8 Jan 2016 22:06:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Jan 2016 22:06:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9083-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 08 23:05:55 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aHfAP-00067Q-3s for gllmg-musl@m.gmane.org; Fri, 08 Jan 2016 23:05:53 +0100 Original-Received: (qmail 29840 invoked by uid 550); 8 Jan 2016 22:05:50 -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 29812 invoked from network); 8 Jan 2016 22:05:49 -0000 Content-Disposition: inline In-Reply-To: <5690315B.5010206@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9070 Archived-At: On Sat, Jan 09, 2016 at 12:59:55AM +0300, Alexander Cherepanov wrote: > On 2016-01-05 20:50, Rich Felker wrote: > >So we could just consider trying to drop the OOB > >accesses. Do we have a list of affected functions? That might be nice > >to include. > > I think it would be nice to have a full list of intentional UB. For > example, this: > > http://git.musl-libc.org/cgit/musl/tree/src/stdio/vsnprintf.c#n33 > > if (n > (char *)0+SIZE_MAX-s-1) n = (char *)0+SIZE_MAX-s-1; > > If I understand the code correctly, fixing it will require changes > to the FILE structure. Are there such plans? Fixing it requires not just changes to the structure, but abandoning compatibility with buffer reads and writes via the glibc ABI (used by glibc getc_unlocked and putc_unlocked macros). This is not as bad as it sounds; if we just abandoned use of the glibc-offset-defined fields and made them always null pointers, then legacy glibc code would always see no buffer available and make a function call instead. I'm not clear on whether this might break code using the gnulib junk that pokes at glibc FILE internals, though, or whether such code works now, nor am I clear whether we even care. > >>this takes care of oob access, but the bytes outside the passed > >>object might change concurrently i.e. strlen might introduce a > >>data race: again this is a problem on the abstract c language > >>level that may be solved e.g. by making all accesses to those > >>bytes relaxed atomic, but user code is not under libc control. > >>in practice the code works if HASZERO reads the word once so it > >>does arithmetics with a consistent value (because the memory > >>model of the underlying machine does not treat such race > >>undefined and it does not propagate unspecified value bits nor > >>has trap representations). > > > >Indeed, this seems like less of a practical concern. > > HASZERO reads the word twice so this should be a problem for > unoptimized code on big-endian platforms. The number of abstract-machine reads is irrelevant unless we use volatile here. A good compiler will always reduce it to one read, and a bad compiler is always free to turn it into multiple reads. Rich