From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14165 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: sva sva Newsgroups: gmane.linux.lib.musl.general Subject: Re: How to get base address of heap arenas Date: Thu, 30 May 2019 13:52:39 -0400 Message-ID: References: <20190530132723.GT16415@port70.net> <20190530140153.GN23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000002028f058a1e918e" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="9697"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14181-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 30 19:53:05 2019 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.89) (envelope-from ) id 1hWPEf-0002Mu-6J for gllmg-musl@m.gmane.org; Thu, 30 May 2019 19:53:05 +0200 Original-Received: (qmail 32721 invoked by uid 550); 30 May 2019 17:53:03 -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 32692 invoked from network); 30 May 2019 17:53:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5uijZSHNF91T3nYbrdlPDl3BnGVMfn2yiHrmrGTuz1M=; b=d45tAqKj0nQ4iKPA7iTJsAvrvx9YFuRYucGGLdkAsGqXTuyd4TP2i8qvkcEZfzj4vJ 7DqNJvWfnng5OncbN2Dy+Je9iqS674xUsFt+/ZWrCEvm19Or7ALoJinlfOeo3sD4j961 0EN3nXYKlLjeEDi6FalgwnljTuHqJTEDuVjBxSTlJJpfCBnc6eP4TxCNvxCqiA+O1xn+ 8kMTDIJNmX2UJKJ8i5ZiAGPA67Dni4H8LuvbvyHs3PZx9IyUI2QL3dpLKC5h0ZOT1gLM /w2OPH/dFXBsSSh3K5eKb63pXWP0XylRRGK2ROE85iExLZVWGKnyIeXqE9Yax2HwgcQq 06Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=5uijZSHNF91T3nYbrdlPDl3BnGVMfn2yiHrmrGTuz1M=; b=lbRff1AcYj0r5K1tzkdtB1Nr+23USMMu2cLkRz6DUKZtGvhai825KQc5LLB7Sn/fln MTbXJyrS64piWLr0QVkAjFzPcsY9X/9y8hL80+TK8M8WUhnnrLzUXzFKYNVBG60/C7lg UktmiIs/P15mWFTTfm7DHBfRhgkctd4MlPQoA4KkU/NQTtobeFx3D9RhfF7TWy8dpYrh w3MWhj8G+P/8nHaH5E3Shv/jI0pRj9EYuODj/g9cNu/+GNTyGbMPNggmlOfFGcNgXKj3 S+PEaBur54s2BxoqNtc5fkPFFW/fy9/ZKygt0ehfwgqsjHHXo759sAK+7BXlYBqK/4SI FR6Q== X-Gm-Message-State: APjAAAW7WYMcFmP4zU25Zb3L/uRywW3CPzLiyIaUPlfXHSHN7D4H0LRc Km3itERnWHbVsi320oV+XrMvJAI4iyBgnH8mSaPKpQ== X-Google-Smtp-Source: APXvYqxI/rbfiYuD6HQ/12uLFe3mSUEObkG3fkU/UTT7OBikNdEgmKVFZCyyLZ1MDdbvewSJwE6I10Bnd4G845BA2P4= X-Received: by 2002:a5d:97d2:: with SMTP id k18mr3759489ios.130.1559238770032; Thu, 30 May 2019 10:52:50 -0700 (PDT) In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:14165 Archived-At: --00000000000002028f058a1e918e Content-Type: text/plain; charset="UTF-8" Correction: I currently only follow the first malloc back to the top chunk and would NOT like to follow every malloc due to the obvious performance impact. This, however, fails when there are multiple non contiguous heap regions. On Thu, May 30, 2019 at 1:49 PM sva sva wrote: > Indeed your replies verified my understanding. > > Here's what I want to do: > I have a C library that does malloc interposition and adds signatures to > header and footer of chunks by allocating extra bytes before and after it. > It also does a number of other things. Then I have some C code which is > supposed to walk the entire heap to that particular process and spit out > all the heap signatures making sure there are no scribbled ones. > > What I am doing right now is that whenever I get a malloc/calloc/etc., > which is of course overloaded, I follow the returned pointer all the way > back to reach the top chunk (prev size = 0). This would fail when I get > chunks in different memory regions that are not contiguous. So I need to > somehow keep track of the contiguous heap areas and get the top chunk for > all of those to start my heap walk. Last thing I want to do is to patch > musl's libc. > > Thanks > > Vahid > > On Thu, May 30, 2019 at 10:02 AM Rich Felker wrote: > >> On Thu, May 30, 2019 at 03:27:24PM +0200, Szabolcs Nagy wrote: >> > * sva sva [2019-05-30 08:59:46 -0400]: >> > > I am writing a heap walk program in C and would like to know if there >> is >> > > anything like the concept of arenas in musl. Basically, I need to >> have a >> > > pointer to the base address of all my allocated heaps. Unfortunately >> > > inspecting the musl code I found none. >> > >> > there is no such concept as "heap arena" visible to user >> > code, so almost surely you don't "need a pointer to the >> > base address" of it. >> > >> > try to describe what exactly you want to do (not in terms >> > of libc internals, but in terms that make sense for user >> > code) >> > >> > (do you want to get all memory mappings? -> try /proc/self/maps) >> > (do you want to track malloc behaviour? -> try malloc interposition) >> > (etc) >> >> To further clarify, the current allocator implementation has no global >> view of "the heap". It sees only free chunks and the headers or >> footers of the immediately adjacent-in-address-space allocated chunks. >> It's likely that the future replacement will have global tracking that >> further helps ensure integrity against heap corruption attacks, but it >> won't be a public API or something necessarily stable between >> versions. If you want a debugging malloc, you need to interpose one; >> for the past few releases, musl has supported malloc interposition. >> >> Rich >> > --00000000000002028f058a1e918e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correction: I currently only follow the first malloc back = to the top chunk and would NOT like to follow every malloc due to the obvio= us performance impact. This, however, fails when there are multiple non con= tiguous heap regions.

On Thu, May 30, 2019 at 1:49 PM sva sva <azharivs@gmail.com> wrote:
=
Ind= eed your replies verified my understanding.

He= re's what I want to do:
I have a C library that does malloc i= nterposition and adds signatures to header and footer of chunks by allocati= ng extra bytes before and after it. It also does a number of other things. = Then I have some C code which is supposed to walk the entire heap to that p= articular process and spit out all the heap signatures making sure there ar= e no scribbled ones.

What I am doing right now is = that whenever I get a malloc/calloc/etc., which is of course overloaded, I = follow the returned pointer all the way back to reach the top chunk (prev s= ize =3D 0). This would fail when I get chunks in different memory regions t= hat are not contiguous. So I need to somehow keep track of the contiguous h= eap areas and get the top chunk for all of those to start my heap walk. Las= t thing I want to do is to patch musl's libc.

= Thanks

Vahid

On Thu, May 30, 2019 at= 10:02 AM Rich Felker <dalias@libc.org> wrote:
On Thu, May 30, 2019 at 03:27:24PM +0200, Szabolcs Nagy = wrote:
> * sva sva <= azharivs@gmail.com> [2019-05-30 08:59:46 -0400]:
> > I am writing a heap walk program in C and would like to know if t= here is
> > anything like the concept of arenas in musl. Basically, I need to= have a
> > pointer to the base address of all my allocated heaps. Unfortunat= ely
> > inspecting the musl code I found none.
>
> there is no such concept as "heap arena" visible to user
> code, so almost surely you don't "need a pointer to the
> base address" of it.
>
> try to describe what exactly you want to do (not in terms
> of libc internals, but in terms that make sense for user
> code)
>
> (do you want to get all memory mappings? -> try /proc/self/maps) > (do you want to track malloc behaviour? -> try malloc interposition= )
> (etc)

To further clarify, the current allocator implementation has no global
view of "the heap". It sees only free chunks and the headers or footers of the immediately adjacent-in-address-space allocated chunks.
It's likely that the future replacement will have global tracking that<= br> further helps ensure integrity against heap corruption attacks, but it
won't be a public API or something necessarily stable between
versions. If you want a debugging malloc, you need to interpose one;
for the past few releases, musl has supported malloc interposition.

Rich
--00000000000002028f058a1e918e--