Date: Fri, 3 Jul 2015 01:11:31 +0300 (MSK) From: Alexander Monakov <amonakov@...ras.ru> To: musl@...ts.openwall.com Subject: Re: Commit 01d4274 breaks Clang's LeakSanitizer when used with musl > The problem is that we're still lacking any viable proposal for how > this should work. Some constraints I think belong on a proposal for it > to be viable include: > > - It should not place new constraints on the implementation in terms > of requiring it to track information that would otherwise not be > required and that may be costly, or to use particular internal > representations of data/state, even when there's presently only one > dominant representation in use. Any complex ot costly representation > tracking should happen in the sanitizer layer, not libc. > > - It should be free of initialization order issues and thread-safety > issues. This may mean that the sanitizer implementation has to use > something like call_once all over the place. > > - It should work correctly with both static and dynamic linking, and > should not depend on particulars of libc's dynamic linking -- in > particular it should not depend on intra-libc allocator calls going > through a PLT or via a symbolic GOT entry. > > Can you think of any others? Perhaps this one? - Natural composability, or nesting: a mechanism that allows sanitizers to observe or interpose on some libc activity should naturally allow multiple such interposers to co-exist. For a write up on requirements from a sanitizer author's perspective, see https://sourceware.org/glibc/wiki/ThreadPropertiesAPI Alexander
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.