[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160108220535.GO238@brightrain.aerifal.cx>
Date: Fri, 8 Jan 2016 17:05:35 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: string word-at-a-time and atomic.h FAQ on twitter
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
