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.