From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14538 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Luiz Angelo Daros de Luca Newsgroups: gmane.linux.lib.musl.general Subject: dlsym returning unresolved symbol address instead of dependency library symbol address Date: Sat, 10 Aug 2019 05:16:19 -0300 Message-ID: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007b75ea058fbee86b" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="50446"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14554-gllmg-musl=m.gmane.org@lists.openwall.com Sat Aug 10 10:57:07 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 1hwNBR-000Cyq-15 for gllmg-musl@m.gmane.org; Sat, 10 Aug 2019 10:57:05 +0200 Original-Received: (qmail 11969 invoked by uid 550); 10 Aug 2019 08:57:01 -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 9729 invoked from network); 10 Aug 2019 08:16:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=WDgtqx4UmYCyXOzDoXfSopvGX/nkt51j62ZiVPZHm9k=; b=jevsrTDpuCZIIwTa2rwyo4Ckf5qfm8rBU/g44dofWN8c2CPJvwC3HJckiRayiRB4Wl 2V48xQ8g5/52RUANjGo2/Nu6rckNpDeSWUHOitYlVx4dG2qpgNW+9fL3NimCjk/FMWxN kLHOpQUhEMX/W0JDwpZloc0/ZOxYQAP/ErVmnDnJON3Iwiw2IVfsX3djxKi7itH8l240 odo7YtuG7rzuCSSc5iCFA4LmG1+8ahoBBsnUbWh5NwVJH5uru+LBY80+eFIEawQCtsWE vxKVfCMh0s6RfqU8yRTWUO/KrP/BMo++whlwb0h34dm4EAofpxG6a2L6BNyo3p8Ybs40 ILEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WDgtqx4UmYCyXOzDoXfSopvGX/nkt51j62ZiVPZHm9k=; b=CfssDt/9CnEQuco8sG5PeE+UZgnYSLAGMC9DPDNdio/jEGPy6LkcFdkJqTwMjOnFgi JhvxRRs111EcCPjdH0uYZCh2OBeqVPUvIH92EHP5TiS85tDiBvI7VbLn2Kncq2yUbZnr ygyHPMhjPw96smvFXG7v/AuVBlTla/zKoKi/EKorWpostTPKaAaHn7deFMhiu4+fa5mC y41kblAHcC619iwCQfmseOH3zXOIKjPP0wR54+mSxyaXWQxCUtWuvRF+Y/YlJolZAiuP yoFZhva3h7eUT3qfAF7nnc8tyExkzMThAKOUNSGUO10CjX6jsw+2ohUhsYX5YEWB8P0i VhKw== X-Gm-Message-State: APjAAAXlL/IfRVzB7PKFh5XkAa1iTo4f1G4Ups99MKlVcRrSMxLBHr4S Xzsi8BwI5e2/ZtHAaWh1XXnEMoCtnm5bkGEwo9ZYeLxF X-Google-Smtp-Source: APXvYqxTfX8uXqb+2N6xUNSAF93kr30RzIuTEwrhSn9g9CIrXcidbrvjr9F8xV5etYoh2jdd4+bsmgw7hPIvlXzXZwY= X-Received: by 2002:a0c:acef:: with SMTP id n44mr22048117qvc.39.1565424990515; Sat, 10 Aug 2019 01:16:30 -0700 (PDT) Xref: news.gmane.org gmane.linux.lib.musl.general:14538 Archived-At: --0000000000007b75ea058fbee86b Content-Type: text/plain; charset="UTF-8" Hello, I'm ruby maintainer in OpenWrt 18.06 (musl 1.1.19). I got a bug report ( https://github.com/openwrt/packages/issues/9297) related to musl in mipsel 32bit. When ruby loads a module (.so), it checks if that module was built for the same ruby that is loading it. Ruby loads libruby at startup, which exports ruby_xmalloc sym. So, the check consists on loading the module, searching for ruby_xmalloc in the module context and comparing with global ruby_xmalloc address. If they do not match, the module is using a different libruby. Something like this: handle = (void*)dlopen(file, RTLD_LAZY|RTLD_GLOBAL) void *ex = dlsym(handle, EXTERNAL_PREFIX"ruby_xmalloc"); if (ex && ex != ruby_xmalloc) { // module is incompatible! } The first time a module is loaded, it simply works as expected. I debugged and musl is working nicely. At do_dlsym(struct dso *p, const char *s, void *ra), it correctly fails to find the symbol with: sym = sysv_lookup(s, h, p) and correctly find it with: sysv_lookup(s, h, p->deps[0]) Now, when the second module is loaded, it find "ruby_xmalloc" already with: sym = sysv_lookup(s, h, p) However, sym now points to the address of the undefined symbol in the second library (sym->st_shndx is NULL) instead of searching for it in dependencies. It seems that do_dlsym() only checks for undefined symbol (sym->shndx==NULL) when DL_FDPIC is 1 and DL_FDPIC is 0 in my case. Does it make any sense to return an undefined symbol from dlsym()? Or does it make sense to return an undefined symbol from sysv_lookup()? Or is there any other arch specific issue that happened before, when library was loaded? I created a simple patch that skips a symbol if it is undefined. https://raw.githubusercontent.com/luizluca/openwrt/b9674d528513c7c93205fa000fed7c0d3c6bb2e7/toolchain/musl/patches/020-dlsym_donot_return_address_from_undef_sym.patch It fixes the issue and it did not break my system(it still boots). However, I didn't test it with multiples archs nor I runned an extensive test. I'm not subscribed. Please, CC me. Regards, --- Luiz Angelo Daros de Luca luizluca@gmail.com --0000000000007b75ea058fbee86b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I'm ruby maintainer in OpenW= rt 18.06 (musl 1.1.19). I got a bug report (https://github.com/openwrt/packages/issues/929= 7) related to musl in mipsel 32bit.

When ruby = loads a module (.so), it checks if that module was built for the same ruby = that is loading it. Ruby loads libruby at startup, which exports ruby_xmall= oc sym. So, the check consists on loading the module, searching for ruby_xm= alloc in the module context and comparing with global ruby_xmalloc address.= If they do not match, the module is using a different libruby. Something l= ike this:

handle =3D (void*)dlopen(file, RTLD_LAZY= |RTLD_GLOBAL)
void *ex =3D dlsym(handle, EXTERNAL_PREFIX"= ;ruby_xmalloc");
if (ex && ex !=3D ruby_xmalloc) {
=C2=A0 =C2=A0// module is incompatible!
}

The first time a module is loaded, it simply works as expected.
I debugged and musl is working nicely. At do_dlsym(struct dso *p, co= nst char *s, void *ra), it correctly fails to find the symbol with:

sym =3D sysv_lookup(s, h, p)

and correctly find it with:

sysv_lookup(s, h, p-&= gt;deps[0])

Now, when the second module is loa= ded, it find "ruby_xmalloc" already with:

sym =3D sysv_lookup(s, h, p)

However, sym no= w points to the address of the undefined symbol in the second library (sym-= >st_shndx is NULL) instead of searching for it in dependencies. It seems= that do_dlsym() only checks for undefined symbol (sym->shndx=3D=3DNULL)= when=C2=A0DL_FDPIC is 1 and DL_FDPIC is 0 in my case.

=
Does it make any sense to return an undefined symbol from dlsym()?
Or does it make sense to return an undefined symbol from sysv_lookup= ()?
Or is there any other arch specific issue that happened befor= e, when library was loaded?

I created a simple pat= ch that skips a symbol if it is undefined.

It fixes the issue= and it did not break my system(it still boots). However, I didn't test= it with multiples archs nor I runned an extensive test.=C2=A0
I'm not subscribed. Please, CC me.

Regards,
---
=C2=A0 =C2=A0= =C2=A0 Luiz Angelo Daros de Luca
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 luizluca@gmail.= com
--0000000000007b75ea058fbee86b--