[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 30 Apr 2013 18:34:23 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Word-sized reads access memory past the bound of objects
* Rich Felker <dalias@...ifal.cx> [2013-04-30 11:40:45 -0400]:
> On Tue, Apr 30, 2013 at 05:11:14PM +0200, Jonas Wagner wrote:
> > - Are there other types of "soft" undefined behavior that MUSL exploits?
>
> I don't think so. The closest things I can think of:
>
> - UTF-8 code depends on sign-extending right-shift. This could be
> easily fixed if it can be verified that the standard trick to work
> around it generates the same (or equally efficient) code. Note this
> is implementation-defined, not undefined.
>
there are similar cases in src/math
(implementation defined signed int arithmetics)
although those are not intentional and are planned
to be cleaned up (they came from fdlibm of freebsd)
> - Floating point conversion to/from strings depends on IEEE arithmetic
> properties and on long double being an IEEE conforming type. (x87
> ld80 is fine, so is IEEE quad, but IBM double-double will not work,
> and systems that typically use IBM double-double should instead have
> their compiler configured for 64-bit long double instead.)
>
> - calloc assumes its own implementation of malloc. Compilers and
> analysis tools which assume negative offsets from the pointer
> returned by malloc are invalid will falsely detect problems and/or
> miscompile calloc.c. This issue affected old versions of clang.
>
> - The dynamic linker also makes some assumptions about the
> implementation of malloc and passes pointers not obtained by malloc
> to free, as part of its mechanism to reclaim wasted slack space in
> shared libraries due to page alignment.
>
> - POSIX timers with SIGEV_THREAD perform a longjmp out of a
> cancellation handler to intercept cancellation/exit so the same
> physical thread can be kept to handle the next timer expiration. For
> an application to do this would be UB (at the POSIX level, not the C
> level) but since they're both part of the same implementation they
> can assume things about each other.
>
> That's all that comes to mind right now. Thanks for bringing up this
> question, because it's something that should be documented in case
> people want to reuse parts of musl in contexts where some of the
> assumptions may no longer be valid.
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.
