From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14164 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:49:10 -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="000000000000912d0a058a1e84f3" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="263379"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14180-gllmg-musl=m.gmane.org@lists.openwall.com Thu May 30 19:49:40 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 1hWPBJ-0016My-4h for gllmg-musl@m.gmane.org; Thu, 30 May 2019 19:49:37 +0200 Original-Received: (qmail 29882 invoked by uid 550); 30 May 2019 17:49:34 -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 29864 invoked from network); 30 May 2019 17:49:33 -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=q5UdkmtnS+h/sB0rsz9hu/lUX6vCrv8o2zBfBhjLpKs=; b=VsvLS32t1rsclp1v2DfUnlED9Dk/Ucs6sAnBSxOZ94dMwyQpvV2QqEyPXwjXwumQjh e80J14OHOIRuEpQ5cO1HJoAeL2sghochwT6Jp69P6UVfp2vHkzBV6H7KrXhX3l72hh2W 9IKNlBQdwT3/zJxQ/tiFRUTOgFg5LNKm8ishbEtu4GVNE6KbOqmjfzM3BC9iAmNSGTfW yyU+1u6htY/8Z5em0mXjsBldPE6hPDGPaSw6YVzTX+gt8Ilg+/QR8ZC4D8AiVpfjCDeG iCnG2iwXQAM9RVABL8oAeQHa5fS8FLivafbSWqHXPVO7HR+O5bdSVNXg1zAYob9+hO4d ukvg== 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=q5UdkmtnS+h/sB0rsz9hu/lUX6vCrv8o2zBfBhjLpKs=; b=Jfd4fNdwqQGSywfeH0Fv447f1n1Xg4s+/OzU6REZBhwcG+wigOxyvGMXu2PKhgaJs/ zNqAPKSsGHh+VD+J4Vv/QWvNSeOWrh7iJ+ZRr8tYXf3w6SsqpGHzbXQjvfu46gJ3hlDh 6XHPxaifrHRdrqer8IPcHGcjJy5FwZFyccTm7nNaedSVHhw6eLB0t9dxVPE2PvqIpRfW qISSN2Bca0BGy+iQNrsr+6fFRAZhFIn9WUEBxFG5uRWAM1mc3A75FXX+gmsFiMgtB7LC odG28UZ9IEuSgIqrbQyIdgXgX7nutkvVRAhjB0FfAvGI3UPb06UhwSsSa4ucvwINm/uE rnbA== X-Gm-Message-State: APjAAAUV52gvzMDDCCu3GBaXa0GY31ot/Y8ylIzwO+tGC8x0Lqc/g0+G ROtHtruwKPr337goe4m7lIX730w6s75MCOFqaYA/Cw== X-Google-Smtp-Source: APXvYqxGzRmp8Q44TE0Hen32nIxyQq11hPqHxZciyZM3wrAPZVg+865jaflw8r2cZ1FVCibZVYi5IFA08xY3sv54e34= X-Received: by 2002:a05:6638:35e:: with SMTP id x30mr3274026jap.92.1559238561310; Thu, 30 May 2019 10:49:21 -0700 (PDT) In-Reply-To: <20190530140153.GN23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14164 Archived-At: --000000000000912d0a058a1e84f3 Content-Type: text/plain; charset="UTF-8" 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 > --000000000000912d0a058a1e84f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Indeed your replies verified my understanding.

Here's what I want to do:
I have a C l= ibrary that does malloc interposition and adds signatures to header and foo= ter 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 signat= ures 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 re= ach the top chunk (prev size =3D 0). This would fail when I get chunks in d= ifferent 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 t= o start my heap walk. Last thing I want to do is to patch musl's libc.<= /div>

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, Szabolc= s 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
--000000000000912d0a058a1e84f3--