[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190124110931.GU21289@port70.net>
Date: Thu, 24 Jan 2019 12:09:32 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Symbol versioning approximation trips on compat symbols
* Rich Felker <dalias@...c.org> [2019-01-23 20:43:40 -0500]:
> On Mon, Jan 21, 2019 at 06:57:53PM +0100, Florian Weimer wrote:
> > On what appears to be current Alpine Linux (musl-1.1.19-r10), the
> > following reproducer
> >
> > ######################################################################
> > cat > symver.c <<EOF
> > void
> > compat_function (void)
> > {
> > }
> > __asm__ (".symver compat_function,compat_function@...VER");
> >
> > void
> > call_compat_function (void)
> > {
> > return compat_function ();
> > }
> > EOF
> >
> > echo "SYMVER { };" > symver.map
> >
> > cat > main.c <<EOF
> > extern void call_compat_function (void);
> >
> > int
> > main (void)
> > {
> > call_compat_function ();
> > }
> > EOF
> >
> > gcc -fpic -shared -o symver.so -Wl,--version-script=symver.map symver.c
> > gcc -Wl,--rpath=. -o main main.c symver.so
> > ######################################################################
> >
> > fails with:
> >
> > $ ./main
> > Error relocating ./symver.so: compat_function: symbol not found
> >
> > The problem is the compatibility symbol (one @ instead of @@). The
> > dynamic linker is supposed to ignore the difference between the two, the
> > default vs non-default version only matters to the link editor when
> > processing an undefined symbol without a symbol version.
> >
> > In my case, I do not need symbol interposition and therefore can work
> > around this, but I wonder if there is some sort of approved compile-time
> > or link-time check to detect this issue. Unfortunately, the Alpine
> > Linux toolchain (and part of the system) is built *with* symbol
> > versioning support, so this does not appear to be straightforward.
> >
> > The actual application does not need to make the symbol interposable, so
> > I can use a hidden alias within the DSO for PLT avoidance (and more
> > configure checks to disable all this on targets which do not support
> > *that*).
>
> The same issue came up before with libgcc defining and referencing a
> non-default-version symbol for some weird compatibility hack. I don't
> remember the details but Szabolcs Nagy was involved in investigating
> and might. In any case, the root cause is that musl's dynamic linker
> does not support symbol versioning; for the sake of being able to load
> libraries that were build with versioning, it always resolves a symbol
> to the "latest"/default version, the same as ld would do at link time.
> Normally this is the right thing as long as you don't actually have
> things that were linked against an old incompatible version, but it
> also breaks explicit linking to a particular version as in your
> example above.
the libgcc_s.so.1 issue on x86 was an extern object symbol (used by
function-multi-versioning ifuncs) that is initialized by a ctor.
but it turned out to be broken (ifunc resolvers may run before
relocations for the extern object are processed), so the symbol
was removed (moved to libgcc.a), but a compat symbol (@) was
kept around and the ctor of libgcc_s.so.1 still references it.
so musl cannot load libgcc_s.so.1 since there is no default
version (@@) of the symbol. (in a musl based gcc this is fixed:
there is no ifunc support or compat issue anyway
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01125.html
you would expect that it's enough to build gcc for
--disable-gnu-indirect-function or --disable-symvers
but even with those the compat symbol is there...)
i wonder what is the use-case for using a compat symbol without
introducing a new default version for the symbol in general?
>
> The right fix is probably to add support for symbol version matching
> in the dynamic linker. Unfortunately this involves some extra logic in
> the extreme hot paths, so it's hard to make the cost unobservably low,
> and last I checked some members of the community were opposed to it on
> ideological grounds. If there's a good need for it (and I think just
> avoiding silent breakage of third-party libs using versioning and
> intending for it to work is a fairly good one already), support can be
> added, but doing it without negative impact is a pretty big task.
>
> Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
