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

[Evgeniy Stepanov]

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.
>
>> 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.