From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/15094 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: d.dorau@avm.de Newsgroups: gmane.linux.lib.musl.general Subject: Issue with musl and valgrind Date: Mon, 6 Jan 2020 12:01:34 +0100 Message-ID: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 003C91B0C12584E7_=" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="101480"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-15110-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 06 12:01:51 2020 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 1ioQ8t-000QHZ-02 for gllmg-musl@m.gmane.org; Mon, 06 Jan 2020 12:01:51 +0100 Original-Received: (qmail 3203 invoked by uid 550); 6 Jan 2020 11:01:47 -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 3169 invoked from network); 6 Jan 2020 11:01:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=avm.de; s=mail; t=1578308495; bh=KySGQ9wKS2WXyTv1mltOa6f1W7jSpEwQyks7os+NErc=; h=To:Subject:From:Date:From; b=c8kXPTYQfoeueDmpVugP/aB4ZcwnihvPz0kkgUfh2k0kAv75cmFxFsv/nlTpCgObP ymvZeDbUlnD/2BbOxxJpBEMiBmabUuA2grxRAVrAvkW+SU6bb49KuAolvccQ0OhDDV g+JPqkBPdZCxGR13qLGHuO2v5Ydxt9Pu+rq2r36g= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=avm.de; s=mail; t=1578308495; bh=KySGQ9wKS2WXyTv1mltOa6f1W7jSpEwQyks7os+NErc=; h=To:Subject:From:Date:From; b=c8kXPTYQfoeueDmpVugP/aB4ZcwnihvPz0kkgUfh2k0kAv75cmFxFsv/nlTpCgObP ymvZeDbUlnD/2BbOxxJpBEMiBmabUuA2grxRAVrAvkW+SU6bb49KuAolvccQ0OhDDV g+JPqkBPdZCxGR13qLGHuO2v5Ydxt9Pu+rq2r36g= X-KeepSent: 11E7837C:B1724FC1-C12584E7:0035C6F0; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1 October 14, 2013 X-MIMETrack: Serialize by Router on ANIS1/AVM(Release 10.0.1FP3|August 09, 2019) at 06.01.2020 12:01:35, Serialize complete at 06.01.2020 12:01:35 X-purgate-ID: 149429::1578308495-000004DE-420F017E/0/0 X-purgate-type: clean X-purgate-size: 9452 X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate: clean X-Filtered-With: renattach 1.2.4 X-RenAttach-Info: mode=badlist action=rename count=0 Xref: news.gmane.org gmane.linux.lib.musl.general:15094 Archived-At: Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 003C91B0C12584E7_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hello and a happy new year! I'm looking for some help/advice regarding the use of valgrind with musl. In my attempts to use valgrind with musl I ran into a reproducible crash.=20 I found others experienced this earlier as well, but with no apparent solution: https://forum.archive.openwrt.org/viewtopic.php?id=3D70169 =3D=3D3915=3D=3D Invalid read of size 4 =3D=3D3915=3D=3D at 0x48C3154: free (in=20 /usr/lib/valgrind/vgpreload=5Fmemcheck-mips32-linux.so) =3D=3D3915=3D=3D by 0x4088C04: ??? (in /lib/libc.so) =3D=3D3915=3D=3D Address is not stack'd, malloc'd or (recently) free'd I did some debugging and came to a plausible reason, and with a quick hack I could get it to run. My findings are that when musl loads vgpreload=5Fmemcheck-mips32-linux.so, malloc/free are replaced by the implementation provided from valgrind, as=20 expected. The free() call that leads to the crash originates from musl's=20 dynlink.c:782 in map=5Flibrary(). The crash in valgrind's vgpreload=5Fmemcheck-mips32-linux.so is located in = coregrind/m=5Freplacemalloc/vg=5Freplace=5Fmalloc.c:184 as part of the macr= o=20 DO=5FINIT static int init=5Fdone; #define DO=5FINIT if (UNLIKELY(!init=5Fdone)) init() [...] #define FREE(soname, fnname, vg=5Freplacement) \ \ void VG=5FREPLACE=5FFUNCTION=5FEZU(10050,soname,fnname) (void *p); \ void VG=5FREPLACE=5FFUNCTION=5FEZU(10050,soname,fnname) (void *p) \ { \ DO=5FINIT; \ MALLOC=5FTRACE(#fnname "(%p)\n", p ); \ if (p =3D=3D NULL) \ return; \ (void)VALGRIND=5FNON=5FSIMD=5FCALL1( info.tl=5F##vg=5Freplacement, p = ); \ } that is called in the free function provided by valgrind. Calculating back the crash address 0x1e0d8 from the example above leads to = the address of the variable "init=5Fdone" of the valgrind code in the ELF file = itself! My interpretation is that although the relocation of the new free function = has apprently been done, the variables (and maybe other called functions) used = *inside* the valgrind library have not been relocated yet, so that their addresses=20 still point to the bare address in the ELF file. (I hope the explanation makes=20 sense.) I could avoid the crash by patching musl so that dynlink.c always calls=20 musl's own malloc/free function (by renaming and an additional wrapper for the=20 exported symbols). Since I don't have in-depth knowledge about the inner workings of musl's=20 shared library loader, I'm now looking for advice on how to solve this issue. At first glance the fact that functions inside the loaded library are=20 called before all relocations are done looks problematic to me.=20 Assuming this would be solved, wouldn't it be desirable to ensure that=20 malloc/free calls inside musl won't be replaced by external libraries so that we don't = get stale allocations left from the old allocator? Best regards, Daniel -- AVM Audiovisuelles Marketing und Computersysteme GmbH Alt-Moabit 95, 10559 Berlin HRB 23075 AG Charlottenburg Gesch=E4ftsf=FChrer: Johannes Nill =20 --=_alternative 003C91B0C12584E7_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hello and a happy new year!

I'm looking for some help/advice re= garding the use of valgrind with musl.
In my attempts to use valgrind with musl I ran into a reproducible crash. I found others
experienced this earlier as well, b= ut with no apparent solution:

= https://forum.archive.openwrt.org/viewt= opic.php?id=3D70169

=3D=3D3915=3D=3D Invalid read of si= ze 4
=3D=3D3915=3D=3D    at 0x48C3154: free (in /usr/lib/valgrind/vgpr= eload=5Fmemcheck-mips32-linux.so)
=3D=3D3915=3D=3D    by 0x4088C04: ??? (in /lib/libc.so)
=3D=3D3915=3D=3D  Address  is not stack'd, malloc'd or (recently)= free'd

I did some debugging and came to a plausible reason, and with a quick
hack I could get it to run.

My findings are that when musl loads vgpreload=5Fmemcheck-mips32-linux.so,
malloc/free are replaced by the imp= lementation provided from valgrind, as expected.

The free() call that leads to the c= rash originates from musl's dynlink.c:782 in
map=5Flibrary().

The crash in valgrind's vgpreload= =5Fmemcheck-mips32-linux.so is located in
coregrind/m=5Freplacemalloc/vg=5Fre= place=5Fmalloc.c:184 as part of the macro DO=5FINIT


static int init=5Fdone;
#define DO=5FINIT if (UNLIKELY(!ini= t=5Fdone)) init()
[...]
#define FREE(soname, fnname, vg=5Fr= eplacement) \
   \
   void VG=5FREPLACE=5FFU= NCTION=5FEZU(10050,soname,fnname) (void *p); \
   void VG=5FREPLACE=5FFU= NCTION=5FEZU(10050,soname,fnname) (void *p)  \
   { \
      DO=5FINIT; \
      MALLOC=5FTRACE= (#fnname "(%p)\n", p ); \
      if (p =3D=3D N= ULL)  \
         r= eturn; \
      (void)VALGRIND= =5FNON=5FSIMD=5FCALL1( info.tl=5F##vg=5Freplacement, p ); \
   }

that is called in the free function provided by valgrind.

Calculating back the crash address 0x1e0d8 from the example above leads to the
address of the variable "init= =5Fdone" of the valgrind code in the ELF file itself!

My interpretation is that although the relocation of the new free function has
apprently been done, the variables (and maybe other called functions) used *inside*
the valgrind library have not been relocated yet, so that their addresses still
point to the bare address in the ELF file. (I hope the explanation makes sense.)

I could avoid the crash by patching musl so that dynlink.c always calls musl's
own malloc/free function (by renami= ng and an additional wrapper for the exported
symbols).

Since I don't have in-depth knowled= ge about the inner workings of musl's shared
library loader, I'm now looking for advice on how to solve this issue.

At first glance the fact that funct= ions inside the loaded library are called before
all relocations are done looks prob= lematic to me.
Assuming this would be solved, woul= dn't it be desirable to ensure that malloc/free
calls inside musl won't be replaced by external libraries so that we don't get
stale allocations left from the old allocator?


Best regards,
Daniel





--
AVM Audiovisuelles Marketing und Computersysteme GmbH
Alt-Moabit 95, 10559 Berlin
HRB 23075 AG Charlottenburg
Gesch=E4ftsf=FChrer: Johannes Nill
 --=_alternative 003C91B0C12584E7_=--