llvm dev - Apr 2015 - [LLVMdev] Intercepting dlinfo in memory sanitizer

Hi everyone,

I ran into a false positive with memory sanitizer due to it not
intercepting dlinfo. I tried to get started on writing such an interceptor,
but dlinfo seems like an extraordinarily difficult function to intercept.
The three considerations that I would like somebody to look at are:

1) How do we get the enum values to decide what kind of pointer dlinfo is
getting. Ideally we'd include dlfcn.h, but the interceptor file doesn't
generally include system headers. What's the right thing to do here?
2) The structures pointed to contain linked lists, etc. of dynamic linker
state. In order to avoid spurious failures, it seems like we should iterate
the linked lists and unpoison all of them, but that seems expensive. Do you
see a better solution?
3) The return values include pointers into the object files. It seems
perfectly reasonable for a user to want to read these object files based on
information from dlinfo. That probably means we should unpoison them as
well? Do we need to do something here or are these already unpoisoned by
some other mechanism (e.g. because msan realizes they are part of a loaded
object file or unposions them on load - does this happen?).

Thanks,
Keno
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150409/9f6da5cd/attachment.html>

On Thu, Apr 9, 2015 at 9:24 PM, Keno Fischer
<kfischer at college.harvard.edu> wrote:
> Hi everyone,
>
> I ran into a false positive with memory sanitizer due to it not
intercepting
> dlinfo. I tried to get started on writing such an interceptor, but dlinfo
> seems like an extraordinarily difficult function to intercept. The three
> considerations that I would like somebody to look at are:
>
> 1) How do we get the enum values to decide what kind of pointer dlinfo is
> getting. Ideally we'd include dlfcn.h, but the interceptor file
doesn't
> generally include system headers. What's the right thing to do here?
We generally redefine system constants and types in
sanitizer_platform_limits_posix.h and verify correctness with
assertions in .cc.
> 2) The structures pointed to contain linked lists, etc. of dynamic linker
> state. In order to avoid spurious failures, it seems like we should iterate
> the linked lists and unpoison all of them, but that seems expensive. Do you
> see a better solution?
Nope, sounds like that's want you need to do.
> 3) The return values include pointers into the object files. It seems
> perfectly reasonable for a user to want to read these object files based on
> information from dlinfo. That probably means we should unpoison them as
> well? Do we need to do something here or are these already unpoisoned by
> some other mechanism (e.g. because msan realizes they are part of a loaded
> object file or unposions them on load - does this happen?).
They are unpoisoned. All memory defaults to unpoisoned (shadow == 0),
and we take care of unpoisoning all memory we return to the OS.
>
> Thanks,
> Keno
>
>

Thanks! I'll try that.

In order to avoid starting a new thread, let me ask you the next question.
One of the shared libraries I load calls strtol and msan fails to intercept
it. Why would this be? The library seems to be otherwise implemented. One
of the potential culprits I saw is that strtol is marked as strong in libc.
Is there any workaround?

Keno

On Thu, Apr 9, 2015 at 3:00 PM, Evgeniy Stepanov <eugeni.stepanov at
gmail.com>
wrote:
> On Thu, Apr 9, 2015 at 9:24 PM, Keno Fischer
> <kfischer at college.harvard.edu> wrote:
> > Hi everyone,
> >
> > I ran into a false positive with memory sanitizer due to it not
> intercepting
> > dlinfo. I tried to get started on writing such an interceptor, but
dlinfo
> > seems like an extraordinarily difficult function to intercept. The
three
> > considerations that I would like somebody to look at are:
> >
> > 1) How do we get the enum values to decide what kind of pointer dlinfo
is
> > getting. Ideally we'd include dlfcn.h, but the interceptor file
doesn't
> > generally include system headers. What's the right thing to do
here?
>
> We generally redefine system constants and types in
> sanitizer_platform_limits_posix.h and verify correctness with
> assertions in .cc.
>
> > 2) The structures pointed to contain linked lists, etc. of dynamic
linker
> > state. In order to avoid spurious failures, it seems like we should
> iterate
> > the linked lists and unpoison all of them, but that seems expensive.
Do
> you
> > see a better solution?
>
> Nope, sounds like that's want you need to do.
>
> > 3) The return values include pointers into the object files. It seems
> > perfectly reasonable for a user to want to read these object files
based
> on
> > information from dlinfo. That probably means we should unpoison them
as
> > well? Do we need to do something here or are these already unpoisoned
by
> > some other mechanism (e.g. because msan realizes they are part of a
> loaded
> > object file or unposions them on load - does this happen?).
>
> They are unpoisoned. All memory defaults to unpoisoned (shadow == 0),
> and we take care of unpoisoning all memory we return to the OS.
>
> >
> > Thanks,
> > Keno
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150409/2f14e4a7/attachment.html>