<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 15, 2016 at 12:42 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>----- Original Message -----<br>
> From: "Evgenii Stepanov" <<a href="mailto:eugenis@google.com" target="_blank">eugenis@google.com</a>><br>
> To: "Eric Fiselier" <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>><br>
> Cc: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>>, "Jonathan Roelofs" <<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>>, "clang developer list"<br>
> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>, "Chandler Carruth" <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>, "Kostya Serebryany" <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>><br>
</span><span>> Sent: Monday, August 15, 2016 12:46:39 AM<br>
> Subject: Re: [cfe-dev] Making MSAN Easier to Use: Providing a Sanitized Libc++<br>
><br>
</span><span>> Eric,<br>
><br>
> thanks for bringing this up! This is indeed one of the biggest issues<br>
> for sanitizer adoption right now.<br>
><br>
> I think that the same-soname approach is correct, mainly because the<br>
> sanitized library is just a version of the same library.<br>
<br>
</span>Given that, for the case of msan at least, some of the symbols have, effectively, additional semantic requirements, it seems appropriate to use a different name somewhere (i.e. the library name, symbol names).<br>
<span><br>
> Loading both<br>
> versions in one process would usually be an error.<br>
<br>
</span>While it would be undesirable to have multiple versions of libc++ in a single process, this generally works regardless. Most of the global state is in libcxxabi (or whatever ABI library is being used), and while having multiple versions of std::cout (etc.) can certainly be observable, it seems rare for this to come up in practice.<br>
<span><br>
> RPATH does not work because if only affects immediate dependencies.<br>
> The following would refer to two different versions of libc++:<br>
> Executable (with asan) -> library A (without asan) -> libc++<br>
>         |<br>
>          -> libc++<br>
> I think even in this case, if the two libc++'s have the same soname,<br>
> only one will be loaded. Linux does breadth-first search, so it<br>
> should<br>
> end up with the direct dependency of the main executable, which is<br>
> good.<br>
<br>
</span>Yes, I believe that Linux's loader does the right thing in this case. If you have the executable without asan, and the library with asan, then we should devise a scheme that does not silently break.<br>
<span><br>
><br>
> Another problem is what happens when the program is installed/copied<br>
> somewhere, and the toolchain build directory is gone. We would need<br>
> help from the dynamic loader.<br>
<br>
</span>This, IMHO, is a key problem with the rpath approach.<br></blockquote><div><br></div><div>I don't think this will be an issue. Assuming the user has a system libc++ installed then the program</div><div>should simply fall back to that unsanitized version since it won't be able to find the rpath. I don't</div><div>see anything more we could do.</div><div><br></div><div><div>One way to support this case would be to provide additional static versions of libc++, since</div><div>statically linked executable's don't depend on the toolchain build directory. </div></div><div><br></div><div>Did you have other fallback behavior in mind?</div><div>How does Compiler-rt handle this problem with shared sanitizer runtimes?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span><br>
> We have something like this set up on Android for ASan, see<br>
> <a href="https://source.android.com/devices/tech/debug/asan.html#sanitize_target" rel="noreferrer" target="_blank">https://source.android.com/dev<wbr>ices/tech/debug/asan.html#sani<wbr>tize_target</a><br>
> The dynamic loader adds directories to the default library search<br>
> path<br>
> when it loads an instrumented executable. The directory with the ASan<br>
> libraries is added at the start of the list. I think this is similar<br>
> to how multilib works.<br>
><br>
> On Android we use the linker name itself (PT_INTERP field) to<br>
> identify<br>
> ASan executables. It would probably be better to use a .note section<br>
> or even something else.<br>
><br>
<br>
</span>Interesting. I don't understand what you're proposing here, however.<br>
<span><font color="#888888"><br>
 -Hal<br>
</font></span><div><div><br>
><br>
> On Sun, Aug 14, 2016 at 7:14 PM, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:<br>
> >>  As a practical matter, I can't set $PLATFORM and/or $LIB in my<br>
> >>  rpath and<br>
> >> have ld.so do the right thing in this context.<br>
> ><br>
> > Can't Clang compile the sanitized executable with a special RPATH<br>
> > pointing<br>
> > to the correct libc++ folder?<br>
> ><br>
> >> Moreover, it is really a property of how you compiled, so I think<br>
> >> using an<br>
> >> alternate library name is natural.<br>
> ><br>
> > Using an alternatively library names will likely cause problems if<br>
> > a<br>
> > non-sanitized libc++ is also present, since both libraries<br>
> > provide the exact same symbols it's possible that symbols in the<br>
> > non-sanitized libc++ will replace the sanitized versions.<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On Sun, Aug 14, 2016 at 7:31 PM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>><br>
> > wrote:<br>
> >><br>
> >> ----- Original Message -----<br>
> >> > From: "Jonathan Roelofs via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
> >> > To: "Eric Fiselier" <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>>, "clang developer list"<br>
> >> > <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>, "Chandler Carruth"<br>
> >> > <<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>>, "Kostya Serebryany" <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>>,<br>
> >> > "Evgenii<br>
> >> > Stepanov" <<a href="mailto:eugenis@google.com" target="_blank">eugenis@google.com</a>><br>
> >> > Sent: Sunday, August 14, 2016 7:07:00 PM<br>
> >> > Subject: Re: [cfe-dev] Making MSAN Easier to Use: Providing a<br>
> >> > Sanitized<br>
> >> > Libc++<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > On 8/14/16 4:05 PM, Eric Fiselier via cfe-dev wrote:<br>
> >> > > Sanitizers such as MSAN require the entire program to be<br>
> >> > > instrumented,<br>
> >> > > anything less leads to plenty of false positives.<br>
> >> > > Unfortunately<br>
> >> > > this can<br>
> >> > > be difficult to achieve, especially for the C and C++ standard<br>
> >> > > libraries. To work around this the sanitizers provide<br>
> >> > > interceptors<br>
> >> > > for<br>
> >> > > common C functions, but the same solution doesn't work as well<br>
> >> > > for<br>
> >> > > the<br>
> >> > > C++ STL. Instead users are forced to manually build and link a<br>
> >> > > custom<br>
> >> > > sanitized libc++. This is a huge PITA and I would like to<br>
> >> > > improve<br>
> >> > > the<br>
> >> > > situation, not just for MSAN but all sanitizers. I'm working<br>
> >> > > on a<br>
> >> > > proposal to change this. The basis of my proposal is:<br>
> >> > ><br>
> >> > > Clang should install/provide multiple sanitized versions of<br>
> >> > > Libc++<br>
> >> > > and a<br>
> >> > > mechanism to easily link them, as if they were a Compiler-RT<br>
> >> > > runtime.<br>
> >> > ><br>
> >> > > The goal of this proposal is:<br>
> >> > ><br>
> >> > > (1) Greatly reduce the number of false positives caused by<br>
> >> > > using an<br>
> >> > > un-sanitized STL.<br>
> >> > > (2) Allow sanitizers to catch user bugs that occur within the<br>
> >> > > STL<br>
> >> > > library, not just its headers.<br>
> >> > ><br>
> >> > > The basic steps I would like to take to achieve this are:<br>
> >> > ><br>
> >> > > (1) Teach the compiler-rt CMake how to build and install each<br>
> >> > > sanitized<br>
> >> > > libc++ version along side its other runtimes.<br>
> >> > > (2) Add options to the Clang driver to support linking/using<br>
> >> > > these<br>
> >> > > libraries.<br>
> >> > ><br>
> >> > > I think this proposal is likely to be contentious, so I would<br>
> >> > > like<br>
> >> > > to<br>
> >> > > focus on the details it. Once I have some feedback on these<br>
> >> > > details<br>
> >> > > I'll<br>
> >> > > put together a formal proposal, including a plan for<br>
> >> > > implementing<br>
> >> > > it.<br>
> >> > > The details I would like input on are:<br>
> >> > ><br>
> >> > > (A) What kind and how many sanitized versions of libc++ should<br>
> >> > > we<br>
> >> > > provide?<br>
> >> > ><br>
> >> > > ------------------------------<wbr>------------------------------<wbr>------------------------------<wbr>---------------------<br>
> >> > ><br>
> >> > > I think the minimum set would be Address (which includes<br>
> >> > > Leak),<br>
> >> > > Memory<br>
> >> > > (With origin tracking?), Thread, and Undefined.<br>
> >> > > Once we get into combinations of sanitizers things get more<br>
> >> > > complicated.<br>
> >> > > What other sanitizer combinations should we provide?<br>
> >> > ><br>
> >> > > (B) How should we handle UBSAN?<br>
> >> > > ------------------------------<wbr>---------------------<br>
> >> > ><br>
> >> > > UBSAN is really just a collection of sanitizers and providing<br>
> >> > > sanitized<br>
> >> > > versions of libc++ for every possible configuration is out of<br>
> >> > > the<br>
> >> > > question.<br>
> >> > > Instead we should figure out what subset of UBSAN checks we<br>
> >> > > want to<br>
> >> > > enable in sanitized libc++ versions. I suspect we want to<br>
> >> > > disable<br>
> >> > > the<br>
> >> > > following checks.<br>
> >> > ><br>
> >> > > * -fsanitize=vptr<br>
> >> > > * -fsanitize=function<br>
> >> > > * -fsanitize=float-divide-by-zer<wbr>o<br>
> >> > ><br>
> >> > > Additionally UBSAN can be combined with every other sanitizer<br>
> >> > > group<br>
> >> > > (ie<br>
> >> > > Address, Memory, Thread).<br>
> >> > > Do we want to provide a combination of UBSAN on/off for every<br>
> >> > > group, or<br>
> >> > > can we simply provide an over-sanitized version with UBSAN on?<br>
> >> > ><br>
> >> > > (C) How should the Clang driver expose the sanitized libraries<br>
> >> > > to<br>
> >> > > the users?<br>
> >> > ><br>
> >> > > ------------------------------<wbr>------------------------------<wbr>------------------------------<wbr>-------------------<br>
> >> > ><br>
> >> > > I would like to propose the driver option '-fsanitize-stdlib'<br>
> >> > > and<br>
> >> > > '-fsanitize-stdlib=<sanitizer><wbr>'.<br>
> >> > > The first version deduces the best sanitized version to use,<br>
> >> > > the<br>
> >> > > second<br>
> >> > > allows it to be explicitly specified.<br>
> >> > ><br>
> >> > > A couple of other options are:<br>
> >> > ><br>
> >> > > * -fsanitize=foo:  Implicitly turn on a sanitized STL. Clang<br>
> >> > > deduces<br>
> >> > > which version.<br>
> >> > > * -stdlib=libc++-<sanitizer>: Explicitly turn on and choose a<br>
> >> > > sanitized STL.<br>
> >> > ><br>
> >> > > (D) Should sanitized libc++ versions override libc++.so?<br>
> >> > ><br>
> >> > > ------------------------------<wbr>------------------------------<wbr>------------------------------<wbr>-<br>
> >> > ><br>
> >> > > For example, what happens when a program links to both a<br>
> >> > > sanitized<br>
> >> > > and<br>
> >> > > non-sanitized libc++ version?<br>
> >> > > Does the sanitized version replace the non-sanitized version,<br>
> >> > > or<br>
> >> > > should<br>
> >> > > both versions be loaded into the program?<br>
> >> > ><br>
> >> > > Essentially I'm asking if the sanitized versions of libc++<br>
> >> > > should<br>
> >> > > have<br>
> >> > > the "soname" libc++ so they can<br>
> >> > > replace non-sanitized version, or if they should have a<br>
> >> > > different<br>
> >> > > "soname" so the linker treats them as a separate library.<br>
> >> > ><br>
> >> > > I haven't looked into the consequences of either approach in<br>
> >> > > depth,<br>
> >> > > but<br>
> >> > > any input is appreciated.<br>
> >> ><br>
> >> > In a sense, these are /just/ multilibs, so my inclination would<br>
> >> > be to<br>
> >> > make all the soname's the same, and just stick them in<br>
> >> > appropriately<br>
> >> > named subfolders relative to their normal location.<br>
> >><br>
> >> I'm not sure that's true; there's no property of the environment<br>
> >> that<br>
> >> determines which library path you need. As a practical matter, I<br>
> >> can't set<br>
> >> $PLATFORM and/or $LIB in my rpath and have ld.so do the right<br>
> >> thing in this<br>
> >> context. Moreover, it is really a property of how you compiled, so<br>
> >> I think<br>
> >> using an alternate library name is natural.<br>
> >><br>
> >>  -Hal<br>
> >><br>
> >> ><br>
> >> ><br>
> >> > Jon<br>
> >> ><br>
> >> > ><br>
> >> > > Conclusion<br>
> >> > > -----------------<br>
> >> > ><br>
> >> > > I hope my proposal and questions have made sense. Any and all<br>
> >> > > input<br>
> >> > > is<br>
> >> > > appreciated.<br>
> >> > > Please let me know if anything needs clarification.<br>
> >> > ><br>
> >> > > /Eric<br>
> >> > ><br>
> >> > ><br>
> >> > ><br>
> >> > ><br>
> >> > ><br>
> >> > ><br>
> >> > > ______________________________<wbr>_________________<br>
> >> > > cfe-dev mailing list<br>
> >> > > <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> >> > > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
> >> > ><br>
> >> ><br>
> >> > --<br>
> >> > Jon Roelofs<br>
> >> > <a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a><br>
> >> > CodeSourcery / Mentor Embedded<br>
> >> > ______________________________<wbr>_________________<br>
> >> > cfe-dev mailing list<br>
> >> > <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> >> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
> >> ><br>
> >><br>
> >> --<br>
> >> Hal Finkel<br>
> >> Assistant Computational Scientist<br>
> >> Leadership Computing Facility<br>
> >> Argonne National Laboratory<br>
> ><br>
> ><br>
><br>
<br>
--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</div></div></blockquote></div><br></div></div>