[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 21 Nov 2018 15:46:52 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Gernot Reisinger <Gernot.Reisinger@...ino.at>
Subject: Re: Question regarding dynamic loader
* Gernot Reisinger <Gernot.Reisinger@...ino.at> [2018-11-21 14:55:19 +0100]:
> Hi,
> I recently stumbled upon an issue with preloading a shared object into a Go
> application (see related Go ticket https://github.com/golang/go/issues/28909
> ).
>
> In short - Go comes with an internal linker which will not link crt code to
> the application. The entry point will directly execute Go standard library
then calling into the c runtime later is undefined.
crt is required for the c runtime setup.
> code. As musl libc calls shared object constructors in crt code, the shared
this is not true, the crt code is a tiny stub that
calls the __libc_start_main setup code in libc.so,
where ctors are run (there are several mechanisms
to do ctors, but that's an elf thing: musl supports
both _init and initarry style initializers, former
is passed as argument to __libc_start_main the latter
requires begin/end symbols for the .initarray section,
in glibc is similar, but part of the initialization
happens in the dynamic linker and part of it in
libc_nonshared.a code which should be linked to the
application and not in libc.so. static linking is
another story but i assume you are using dynamic linking).
> objects constructors subsequently will never be invoked. Things will work
> on glibc systems / processes. it It seems to be a subtle - but in this case
> wide reaching - behavioral difference to glibc.
this is libc internal implementation detail that
callers should not try to guess or rely on.
(however it has to be abi stable within one libc
implementation because old crt1.o linked into
an executable must work with new libc.so, otoh
in glibc the abi can changed over time using
symbol versioning for backward compatibility,
and there were talks about doing exactly that
because the way it runs ctor code is a perfect
gadget for rop attacks and present in every
executable)
> I wonder if calling constructor functions from crt code is an intended musl
> libc behavior. My personal - non expert - gut feeling considers glibc
> behavior "more correct". Is there a chance that musl will change this
what made you think musl calls ctors from crt code?
> behavior?
> br
> Gernot
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.
