From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12717 Path: news.gmane.org!.POSTED!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: tcmalloc compatibility Date: Mon, 16 Apr 2018 06:19:24 +0200 Message-ID: <20180416041924.GA23767@voyager> References: <0ea267bf-ea3a-9810-be1a-50e71b6cfce1@denis.im> <20180410143359.GF3094@brightrain.aerifal.cx> <878t9vlzh1.fsf@mid.deneb.enyo.de> <20180410203354.GI4418@port70.net> <20180410204411.GK3094@brightrain.aerifal.cx> <20180410211724.GJ4418@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1523852255 10241 195.159.176.226 (16 Apr 2018 04:17:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 16 Apr 2018 04:17:35 +0000 (UTC) User-Agent: Mutt/1.9.4 (2018-02-28) To: musl@lists.openwall.com Original-X-From: musl-return-12733-gllmg-musl=m.gmane.org@lists.openwall.com Mon Apr 16 06:17:31 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1f7va7-0002ZF-1Q for gllmg-musl@m.gmane.org; Mon, 16 Apr 2018 06:17:31 +0200 Original-Received: (qmail 19645 invoked by uid 550); 16 Apr 2018 04:19:37 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 19588 invoked from network); 16 Apr 2018 04:19:36 -0000 Content-Disposition: inline In-Reply-To: X-Provags-ID: V03:K1:+AiT8nW9WuWG/45m5QzAgWL7jec6gbyZ0yGLUy2VT7Y5X4yg6/t bsT2P1rxg21goh6cC91iECVc6cddFisWxpVIm5fkFcimGNKsJCzB2+yX9XoacOCkNVfxIj3 5OSE8KgKbVw3GyVNaZrYD+sJQ7UmykWjTR7q7Z78kWdofPNFomai1nfvgTr0lO/oPLEsml7 RZ83T+nZ8Scqi8qARTJAA== X-UI-Out-Filterresults: notjunk:1;V01:K0:3oNWswsGK90=:dlMLEde0sQ7Rr8ZFQgyBLw 6+uirMjhDnc3t2FzDSmYaGPEUU7MQwLXKfcw8r1wboJyAEwMt4DtmvNZm/GxCZjgAdLmqcwb9 jlu6n/4Mr+R9x46w/uhJgxCsVs+Z66Qde20J6OZ2ovtXA1IS7Nc746TGNthrr+fY3MXpnY5uS xhV9oGYwhC2pG2tnby5WQJVAH7859s+JMwSjUPk5BpKA9iDFrJqhObtVfHacTRCi3rplUQ3gG 0Vy9Wvkn+JwviYBUSA0323RCfBot0RuWuUX855eBszP+ryPGpEY48JsrISiytDT4n1mGUtEfZ 9q3JoC9AVl5j4wA2tDd0wcT6b4DFDM7spADW6nfocQEX0gu4bRzcLhoOjZyPQ4uQb1k24PX70 /sMYx0OYp5fMvi4MbPDgnPGbrpclqGu+g+j3PAZLbl52vP4tR1SIkLeYtJLEUUoybKaE01/fK fsxCPE39wYiW6mLklj6kcGLYK1N9tXYNwwG1jzTvwnY5gBSjhS6FP2jgmGlyOyiKWENZmCUM8 sCVdTXCGFKbOEfup9AUpePJOvOskGWiyvl9+/l7dytUPi898CBcXa+wdeCiQVZnzM/RXtUVDZ ak0EG4NpeTTlLvUjbkBNTAshWb/pr5HbL7xLG1iMFsqQSVtQrU6rh4mxnZL1vxEwF54a1BdQG Z0HVEUeDYlKi79p+xLxiP7i9J8aNncvVuJwPKOTQntKouSekaxpHTxhpyXjDRe4Nd1d4wg6N7 w3pKD8C0krwQKPRJMTvPvZI65iGj9/x/F4HM2E+a7UomCx64m+Hk6rVo0qxZ0dHWWMcR3ZcZ Xref: news.gmane.org gmane.linux.lib.musl.general:12717 Archived-At: On Sun, Apr 15, 2018 at 01:52:10PM +0200, ardi wrote: > On Tue, Apr 10, 2018 at 11:17 PM, Szabolcs Nagy 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