From: Luiz Angelo Daros de Luca <luizluca@gmail.com>
To: musl@lists.openwall.com
Subject: dlsym returning unresolved symbol address instead of dependency library symbol address
Date: Sat, 10 Aug 2019 05:16:19 -0300 [thread overview]
Message-ID: <CAJq09z7pQ6wmkozqWEuKjY2WiZAWeD6m=GNn18BmJeRXzyKyaQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3110 bytes --]
next reply other threads:[~2019-08-10 8:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-10 8:16 Luiz Angelo Daros de Luca [this message]
2019-08-10 10:11 ` Szabolcs Nagy
2019-08-10 12:35 ` Szabolcs Nagy
2019-08-10 16:42 ` Rich Felker
2019-08-10 17:27 ` Szabolcs Nagy
2019-08-13 7:10 ` Luiz Angelo Daros de Luca
2019-08-13 8:50 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJq09z7pQ6wmkozqWEuKjY2WiZAWeD6m=GNn18BmJeRXzyKyaQ@mail.gmail.com' \
--to=luizluca@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).