[LLVMdev] Intercepting dlinfo in memory sanitizer

[Keno Fischer]

It's called by strtol (there's a strtol at plt in the assembly code). It seems
to be a problem just with this function.

On Fri, Apr 10, 2015 at 5:59 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com
> wrote:

> On Fri, Apr 10, 2015 at 5:22 AM, Keno Fischer
> <kfischer at college.harvard.edu> wrote:
> > 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?
>
> Strong symbol should not be a problem. What name is it called by?
> There are a number of __strtol_internal, __strtol_l and other variants
> that we intercept.
> It is a problem with all calls from that library, or just this one
> function?
>
>
> >
> > 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/20150410/90ba9d34/attachment.html>