Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 3 Jul 2015 01:11:31 +0300 (MSK)
From: Alexander Monakov <>
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


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.