A collection of LD_AUDIT bugs that are important for tools (with better formatting for this list)

[Mark Krentel]

Sorry, I was out one day (Tuesday) and I've missed an entire email
thread.  :-)

I agree, we don't want to intercept threads at level of clone().
clone is less portable (args vary by arch type), has variable args,
also mixed in with fork, etc.  That would be much harder and much more
buggy.

thrd_create() is simply a new C11 function that we haven't added yet.
Keep in mind that HPCToolkit goes back well before 2011.

I don't think thrd_create() per se would be a problem.  But I'm not
quite clear on the term "non-iterposable".  Does that mean LD_PRELOAD
is not going to work?  THAT would be a big problem for us.

Let me say in general that for these kinds of things, there is always
a great temptation to go behind the system's back and say, just give
me the "real" thing.  That is simply wrong, wrong, wrong.  There's a
saying in CS that "all problems can be solved by adding an extra layer
of indirection."  That's a bit extreme, but there's a lot of truth to
it.

Imagine a app that wanted to bypass virtual memory because it's doing
low-level gpu programming or whatever and it knows the physical
addresses and wants to use them directly.  Imagine the chaos that
would cause.  That's what MS Windows used to do.

Anyway, there needs to be a clean API line for these things.  If you
bypass the line, then you don't work and play well with others.  And
at some point, all we can do is say, we can't work with your app. :-(

--Mark




> On Jun 23, 2021, at 1:32 AM, Florian Weimer <fweimer@redhat.com> wrote:
> 
> * Adhemerval Zanella:
> 
>> Currently, you need to interpose both pthread_create and thrd_create.  Florian
>> has suggested we allow pthread_create to be interposable (meaning glibc will
>> issue a plt call on each usage). 
>> 
>> We can do it for clone instead, it would have the advantage to hide
>> the multiple architecture different kernel ABIs.
> 
> But the clone call is very low-level.  The start routine is not called
> with a fully configured thread, so wrapping the startup routine would be
> rather awkward.
> 
> The guts of posix_spawn are equally tricky because code is running
> without a properly configured TCB and stack.  I'm not sure if it
> possible to call an interceptable execve from posix_spawn, for instance.
> We would need to know more about interceptor requirements to see if
> there is a solution.
> 
> Thanks,
> Florian
>