[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 16 Apr 2018 06:19:24 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: tcmalloc compatibility
On Sun, Apr 15, 2018 at 01:52:10PM +0200, ardi wrote:
> On Tue, Apr 10, 2018 at 11:17 PM, Szabolcs Nagy <nsz@...t70.net> wrote:
> >
> > then the wrappers with dlsym(RTLD_NEXT,sym) would not work.
> > (malloc checkers, valgrind, sanitizers etc all do it)
>
> I've been using ElectricFence, as my only memory debugger since 1996
> or so; mostly with the libc of commercial Unices, but also with glibc
> in Linux, and with the OSX libc. I never considered I could run into
> the issues commented in this thread, and in fact I never faced these
> issues and it always worked as expected (however, I must admit I only
> use multithreading for accelerating clearly isolated math-intensive
> loops that don't call malloc-related functions from inside the loop).
>
> Said this, when I'm linking with ElectricFence, my brain has the "hack
> mode flag" ON (I mean, I always had the feeling that I'm working with
> a temporary hack that can fail whenever my link line contains -lefence
> , and I'm aware that things can go wrong --I didn't consider thread
> safety, but anyway I know ElectricFence can fail if the OS syscalls
> that allocate protected memory at buffer ends change their behaviour
> in newer versions, or if there's some OS/CPU-dependent subtlety with
> alignment, etc...)
>
> I've not tried to use ElectricFence with musl yet... but reading this,
> can I suppose it won't work? Is there any "hack mode ON" procedure
> (yet easy) that would allow to use ElectricFence (assuming
> non-threaded code, which is always my case).
>
> I agree with your commitment to correctness, and I'm not asking for a
> safe and guaranteed implementation of function interposition, just
> that sometimes I need to break my binaries to make them crash hard as
> soon as pointer accesses a byte it shouldn't access.
>
> Cheers,
>
> ardi
So long as you refrain from using dynamic linking (because of the memory
donation) and calloc() and memalign() (and posix_memalign()) are unused
or overloaded, you should be fine. Both of these functions use the
internal bookkeeping of musl's malloc. calloc() uses it to figure out if
a chunk was mmapped (in which case no initialization is necessary), and
memalign() uses it to construct a second chunk header to cause the
returned pointer to be aligned.
Most of the questioning here arose from that first part. Those are the
two big problems, actually, we need an interface to donate memory to the
malloc implementation, and the malloc implementation needs to provide
all of the hairier functions like memalign(). And we currently have no
way of enforcing either of these.
Ciao,
Markus
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.
