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>