[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180315121228.GW4418@port70.net>
Date: Thu, 15 Mar 2018 13:12:29 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Cc: Bracken Dawson <abdawson@...il.com>
Subject: Re: Program with constructor function segfaults frequently
with musl
* Bracken Dawson <abdawson@...il.com> [2018-03-15 11:28:56 +0000]:
> Sadly my use case is to set a given mnt namespace before go becomes
> multi-threaded, which happens before the go main() function, so I do depend
> on reading argv in the constructor, I mean I could use a file or something
> else, but would rather not.
>
> I guess this is just something I can get away with today in glibc that musl
> will never support.
>
i don't think it is guaranteed that the process is single threaded by
the time your ctor is called (another ctor that runs earlier can easily
create other threads)
so either you have full control over the runtime, in which case you
should be able to do whatever you want before things become multithread
without any hacks, or you have no control over the runtime, which happens
when you use a high level language like go, but then you should not make
any assumptions what happens under the hood since (c)go runtime may
change and break your assumptions in the future.
i think a better solution is e.g. having a simple executable written
in c that does whatever you want and execs the real go binary after
setting things up the right way.
> Thanks for looking though.
>
> :wq
>
> On 15 March 2018 at 11:17, Szabolcs Nagy <nsz@...t70.net> wrote:
>
> > * Szabolcs Nagy <nsz@...t70.net> [2018-03-15 12:01:44 +0100]:
> > > * Bracken Dawson <abdawson@...il.com> [2018-03-15 10:38:31 +0000]:
> > > > I have been having trouble getting a cgo program to run with musl, it
> > has
> > > > been segfaulting frequently and with 'No stack' when run under gdb.
> > > >
> > > > I have managed to reproduce such a failure in pure c with a very small
> > > > example:
> > > >
> > > > ```
> > > > #include <stdio.h>
> > > > #include <stdlib.h>
> > > > #include <getopt.h>
> > > >
> > > > __attribute__((constructor)) void enter_namespace(int argc, char
> > *argv[]) {
> > >
> > > the arguments passed to ctors are not part of the elf abi
> > > http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#init_fini
> >
> > ah this does not explain the type signature, the right link is
> > http://www.sco.com/developers/gabi/latest/ch4.sheader.html#init_array
> >
> > > (and it cannot really work for dynamically loaded libraries anyway:
> > > the application can arbitrarily clobber argv by that time)
> > >
> > > glibc passes these arguments as an extension (the semantics
> > > for dlopened libraries is unclear), which happens to work
> > > since the calling convention of functions with no arguments
> > > allows this on all supported targets.
> > >
> > > (note that there are security hardenning solutions that check
> > > the call site function signature against the callee and abort on
> > > mismatch and such extension would not work with that)
> > >
> > > is this cgo that tries to capture argv in a ctor or some other
> > > c library? (in either case you should first try to solve it
> > > portably without depending on the glibc extension)
> >
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.
