<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Eric Fiselier via cfe-dev" <cfe-dev@lists.llvm.org><br><b>To: </b>"clang developer list" <cfe-dev@lists.llvm.org>, "Chandler Carruth" <chandlerc@gmail.com>, "Kostya Serebryany" <kcc@google.com>, "Evgenii Stepanov" <eugenis@google.com><br><b>Sent: </b>Sunday, August 14, 2016 5:05:57 PM<br><b>Subject: </b>[cfe-dev] Making MSAN Easier to Use: Providing a Sanitized Libc++<br><br><div id="DWT16739" dir="ltr">Sanitizers such as MSAN require the entire program to be instrumented, anything less leads to plenty of false positives. Unfortunately this can be difficult to achieve, especially for the C and C++ standard libraries. To work around this the sanitizers provide interceptors for common C functions, but the same solution doesn't work as well for the C++ STL. Instead users are forced to manually build and link a custom sanitized libc++. This is a huge PITA and I would like to improve the situation, not just for MSAN but all sanitizers.</div></blockquote>I've not thought deeply about the deployment model here, but this is certainly an important problem. Thanks for working on this. We need to figure out a way of automatically providing users with a sanitized STL in a straightforward manner. I'd prefer that they automatically get the appropriately-instrumented runtime, by default, just by providing the -fsanitize=... flag. The same issue comes up for other runtimes, such as the OpenMP runtime library.<br><br> -Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div dir="ltr"> I'm working on a proposal to change this. The basis of my proposal is:<div><div><br></div><div>Clang should install/provide multiple sanitized versions of Libc++ and a mechanism to easily link them, as if they were a Compiler-RT runtime.</div><div><br></div><div>The goal of this proposal is:</div><div><br></div><div>(1) Greatly reduce the number of false positives caused by using an un-sanitized STL.</div><div>(2) Allow sanitizers to catch user bugs that occur within the STL library, not just its headers.</div><div><br></div><div>The basic steps I would like to take to achieve this are:</div><div><br></div><div>(1) Teach the compiler-rt CMake how to build and install each sanitized libc++ version along side its other runtimes.</div><div>(2) Add options to the Clang driver to support linking/using these libraries.</div><div><br></div><div>I think this proposal is likely to be contentious, so I would like to focus on the details it. Once I have some feedback on these details I'll put together a formal proposal, including a plan for implementing it.</div><div>The details I would like input on are:</div><div><br></div><div>(A) What kind and how many sanitized versions of libc++ should we provide?</div><div>---------------------------------------------------------------------------------------------------------------</div><div><br></div><div>I think the minimum set would be Address (which includes Leak), Memory (With origin tracking?), Thread, and Undefined.</div><div>Once we get into combinations of sanitizers things get more complicated. What other sanitizer combinations should we provide?</div><div><br></div><div>(B) How should we handle UBSAN?</div><div>---------------------------------------------------</div><div><br></div><div>UBSAN is really just a collection of sanitizers and providing sanitized versions of libc++ for every possible configuration is out of the question.</div><div>Instead we should figure out what subset of UBSAN checks we want to enable in sanitized libc++ versions. I suspect we want to disable the following checks.</div><div><br></div><div>* -fsanitize=vptr</div><div>* -fsanitize=function</div><div>* -fsanitize=float-divide-by-zero</div><div><br></div><div>Additionally UBSAN can be combined with every other sanitizer group (ie Address, Memory, Thread).</div><div>Do we want to provide a combination of UBSAN on/off for every group, or can we simply provide an over-sanitized version with UBSAN on?</div><div><br></div><div>(C) How should the Clang driver expose the sanitized libraries to the users?</div><div>-------------------------------------------------------------------------------------------------------------</div><div><br></div><div>I would like to propose the driver option '-fsanitize-stdlib' and '-fsanitize-stdlib=<sanitizer>'.</div><div>The first version deduces the best sanitized version to use, the second allows it to be explicitly specified.</div><div><br></div><div>A couple of other options are:</div><div><br></div><div>* -fsanitize=foo: Implicitly turn on a sanitized STL. Clang deduces which version.</div><div>* -stdlib=libc++-<sanitizer>: Explicitly turn on and choose a sanitized STL.</div><div><br></div><div>(D) Should sanitized libc++ versions override libc++.so?</div><div>-------------------------------------------------------------------------------------------</div><div><br></div><div>For example, what happens when a program links to both a sanitized and non-sanitized libc++ version?</div><div>Does the sanitized version replace the non-sanitized version, or should both versions be loaded into the program?</div><div><br></div><div>Essentially I'm asking if the sanitized versions of libc++ should have the "soname" libc++ so they can</div><div>replace non-sanitized version, or if they should have a different "soname" so the linker treats them as a separate library.</div><div><br></div><div>I haven't looked into the consequences of either approach in depth, but any input is appreciated.</div><div><br></div><div>Conclusion</div><div>-----------------</div><div><br></div><div>I hope my proposal and questions have made sense. Any and all input is appreciated.</div><div>Please let me know if anything needs clarification.</div><div><br></div><div>/Eric</div><div><br></div><div><br></div><div><br></div><div><br></div></div></div>
<br>_______________________________________________<br>cfe-dev mailing list<br>cfe-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>