[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56903A8E.90802@openwall.com>
Date: Sat, 9 Jan 2016 01:39:10 +0300
From: Alexander Cherepanov <ch3root@...nwall.com>
To: musl@...ts.openwall.com
Subject: Re: string word-at-a-time and atomic.h FAQ on twitter
On 2016-01-09 01:05, Rich Felker wrote:
> 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.
Ugh.
Documenting UB in it in the mean time seems like non-controversial thing:-)
>>>> 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.
Ok, I'll reformulate: is compiling musl on a big-endian platform with
optimizations turned off officially supported?
--
Alexander Cherepanov
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.
