[BUG] SB2 x86 hooking vs glibc

asked 2019-06-13 14:27:58 +0300

tortoisedoc gravatar image

updated 2019-06-20 22:00:24 +0300

I personally have encoutered this problem on x86 target. I don't know if it exists on ARM; but given the code of glibc is the same, i guess it should? Note also that this bug appears only on SB2, not on real devices.

SB2 relies heavily on hooking of glibc public api's to provide development functionalities for individual targets.

Glibc has a "dark" side to it, however - an "internal" (private) api (prefixed with __libc), which for other glibc-related reasons exist; this api provides private versions of the public api's which usually are hooked by SB2.

As the symbols of this api are private, they cant be hooked by SB2. So you have glibc working black magic behind the scenes.

An example, the sem_open function:

https://bugs.merproject.org/show_bug.cgi?id=2000

Another example is the spawn api.

And if you care to throw a read (tl;dr;), here's the story :

http://kastlunger.blogspot.com/2019/04/lets-do-time-warp-again-or-compile-llvm.html

edit retag flag offensive close delete

Comments

@James can you tag this (@sledges suggested)? thanks!

tortoisedoc ( 2019-06-14 13:11:00 +0300 )edit

pinging @lbt on this:)

sledges ( 2019-07-11 12:22:59 +0300 )edit
1

"I don't know if it exists on ARM" - could you please check that? I wouldn't be surprised if the problem only existed on x86, in which case you should have two options: 1) force sb2 to use qemu even for your x86 target or 2) do not use sb2 for x86 build of these special packages - e.g. OBS does not use sb2 for x86 builds.

martyone ( 2019-07-11 13:10:41 +0300 )edit

I recall someone complaining the bug didnt show on arm when I first brought it up on irc :). How can I enable qemu on x86?

tortoisedoc ( 2019-07-11 18:34:02 +0300 )edit

Just checked and qemu-usermode does not provide x86 versions, so unless you want to build qemu yourself with these included, option 1 is a no go.

martyone ( 2019-07-15 08:20:33 +0300 )edit