Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180410211724.GJ4418@port70.net>
Date: Tue, 10 Apr 2018 23:17:24 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Florian Weimer <fw@...eb.enyo.de>
Subject: Re: tcmalloc compatibility

* Rich Felker <dalias@...c.org> [2018-04-10 16:44:11 -0400]:
> On Tue, Apr 10, 2018 at 10:33:55PM +0200, Szabolcs Nagy wrote:
> > - glibc dlsym calls calloc (bites anybody who tries to wrap
> > calloc in the usual way)
> 
> Yes. While I think it's unreasonable that glibc calls calloc from
> dlsym, I also think it's unreasonable to be calling dlsym from a
> malloc replacement. I don't think I would include dlsym or other
> heavy, AS-unsafe functions in an allowed-list for musl.

then the wrappers with dlsym(RTLD_NEXT,sym) would not work.
(malloc checkers, valgrind, sanitizers etc all do it)

in glibc there is __libc_calloc so you can get the address
without dlsym, but in general you cannot wrap libc functions
for instrumentation if dlsym is disallowed.

i guess one could run dlsym early to initialize global
pointers but then the interceptor still has to handle the
case when it gets called before the appropriate dlsym is done,
so users need to know what dlsym might call and how to do the
initialization early enough.

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.