Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Jul 2015 16:20:27 -0400
From: Rich Felker <>
Subject: Re: Commit 01d4274 breaks Clang's LeakSanitizer when used
 with musl

On Thu, Jul 02, 2015 at 10:57:58PM +0300, Alexander Monakov wrote:
> > for glibc calloc they have some ugly workaround, maybe similar hack
> > is needed for free in musl, but none of this is future proof so
> > they will just keep piling hacks..
> Re: hacks, I think it doesn't have to be like that.  There should be a
> reasonable mechanism to wrap library functions in the context of dynamic
> linking; static linking is slightly ahead in that game if you count ld
> --wrap=symbol functionality.
> For dynamic linking it should be doable with a new type of ELF tag and a bit
> of support from the dynamic linker.  Would you be interested?
> (at the moment I don't have an answer why lsan started failing like that; and
> even if, hypothetically, there would be a good library wrapping mechanism,
> sanitizers would likely need other support from libc, like dynamic tls layout
> discovery for memory sanitizer; I hope it can be resolved to everyone's
> satisfaction eventually, improving sanitizers usability, rather than ignoring
> it and perpetually calling sanitizers a pile of hacks)

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?


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.