[llvm-commits] [PATCH] Have ReExec read environment from /proc/self/environ

Reid Kleckner rnk at google.com
Thu Jan 17 06:19:43 PST 2013


On Thu, Jan 17, 2013 at 4:39 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com
> wrote:

> On Thu, Jan 17, 2013 at 8:23 AM, Peter Collingbourne <peter at pcc.me.uk>
> wrote:
> >
> >
> > ================
> > Comment at: lib/sanitizer_common/sanitizer_linux.cc:204
> > @@ -203,5 +203,3 @@
> >
> > -void ReExec() {
> > -  static const int kMaxArgv = 100;
> > -  InternalScopedBuffer<char*> argv(kMaxArgv + 1);
> > -  static char *buff;
> > +static void ReadNullSepFileToArray(const char *path, char ***arr, int
> arr_size){
> > +  char *buff;
> > ----------------
> > Reid Kleckner wrote:
> >> Isn't /proc unavailable in many contexts, like chroots?  I believe
> function pointers in preinit_array receive argc, argv, and envp as
> arguments, which are forwarded straight from what the kernel put on the
> stack.  You may be able to use that instead.
> >> Isn't /proc unavailable in many contexts, like chroots?
> >
> > I'm not convinced that we care enough about these contexts that we need
> to support them.  Besides, this code already has a dependency on /proc.
>

It might be nice to have at some point.


> >> I believe function pointers in preinit_array receive argc, argv, and
> envp as arguments, which are forwarded straight from what the kernel put on
> the stack. You may be able to use that instead.
> >
> > The trouble is that (e.g.) __msan_init may be called from contexts from
> which we don't have access to these.  Perhaps one of the msan developers
> can enlighten us as to why .preinit_array isn't being used for msan.
>
> Because we are OK with high-priority module constructor, and
> .preinit_array is problematic - you can not put it in a shared
> library, for example.
>
> We need __msan_init to happen before any instrumented code is
> executed, and not necessarily as the first thing in a process. Module
> constructor + checks in all interceptors work fine for that.
>
> AFAIK, constructors have access to envp through their arguments.
>

I did some experiments with this for DynamoRIO, and
__attribute__((constructor)) may or may not get argv+envp depending on
which gcc you are using.  Some time ago they switched from .ctors to
.init_array, and .init_array gets argv+envp, but .ctors does not.

If you use _init, then that will get argv+envp too.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130117/7b071a07/attachment.html>


More information about the llvm-commits mailing list