summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/ubsan
Commit message (Collapse)AuthorAgeFilesLines
* [UBSan] Appease linterRoman Lebedev2019-10-101-2/+4
| | | | llvm-svn: 374316
* [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined ↵Roman Lebedev2019-10-102-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behaviour Summary: Quote from http://eel.is/c++draft/expr.add#4: ``` 4 When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P. (4.1) If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value. (4.2) Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]), the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the expression P - J points to the (possibly-hypothetical) array element i−j of x if 0≤i−j≤n. (4.3) Otherwise, the behavior is undefined. ``` Therefore, as per the standard, applying non-zero offset to `nullptr` (or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined, i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.) To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer is undefined, although Clang front-end pessimizes the code by not lowering that info, so this UB is "harmless". Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`) LLVM middle-end uses those guarantees for transformations. If the source contains such UB's, said code may now be miscompiled. Such miscompilations were already observed: * https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html * https://github.com/google/filament/pull/1566 Surprisingly, UBSan does not catch those issues ... until now. This diff teaches UBSan about these UB's. `getelementpointer inbounds` is a pretty frequent instruction, so this does have a measurable impact on performance; I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%), and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark: (all measurements done with LLVM ToT, the sanitizer never fired.) * no sanitization vs. existing check: average `+21.62%` slowdown * existing check vs. check after this patch: average `22.04%` slowdown * no sanitization vs. this patch: average `48.42%` slowdown Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers Reviewed By: rsmith Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D67122 llvm-svn: 374293
* [compiler-rt] Use GetNextInstructionPc in signal handlersVitaly Buka2019-10-021-2/+3
| | | | | | | | | | | | | | | | | | Summary: All other stack trace callers assume that PC contains return address. HWAsan already use GetNextInstructionPc in similar code. PR43339 Reviewers: eugenis, kcc, jfb Subscribers: dexonsmith, dberris, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68313 llvm-svn: 373529
* Remove NOLINTs from compiler-rtVitaly Buka2019-09-111-1/+1
| | | | llvm-svn: 371687
* [UBSan] Do not overwrite the default print_summary sanitizer option.Max Moroz2019-09-091-1/+0
| | | | | | | | | | | | | | | | | | | | | Summary: This option is true by default in sanitizer common. The default false value was added a while ago without any reasoning in https://github.com/llvm-mirror/compiler-rt/commit/524e934112a593ac081bf2b05aa0d60a67987f05 so, presumably it's safe to remove for consistency. Reviewers: hctim, samsonov, morehouse, kcc, vitalybuka Reviewed By: hctim, samsonov, vitalybuka Subscribers: delcypher, #sanitizers, llvm-commits, kcc Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D67193 llvm-svn: 371442
* Remove a few straggler ".cc"s in compiler-rt/libNico Weber2019-08-011-1/+1
| | | | llvm-svn: 367589
* compiler-rt: Rename .cc files in lib/ubsan to .cpp.Nico Weber2019-07-3118-37/+36
| | | | | | | | | | | See https://reviews.llvm.org/D58620 for discussion, and for the commands I ran. In addition I also ran for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done and manually updated references to renamed files found by that. llvm-svn: 367452
* Finish "Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO"Stephan Bergmann2019-07-163-17/+17
| | | | | | | | | | | | | | | | | | | | | i.e., recent 5745eccef54ddd3caca278d1d292a88b2281528b: * Bump the function_type_mismatch handler version, as its signature has changed. * The function_type_mismatch handler can return successfully now, so SanitizerKind::Function must be AlwaysRecoverable (like for SanitizerKind::Vptr). * But the minimal runtime would still unconditionally treat a call to the function_type_mismatch handler as failure, so disallow -fsanitize=function in combination with -fsanitize-minimal-runtime (like it was already done for -fsanitize=vptr). * Add tests. Differential Revision: https://reviews.llvm.org/D61479 llvm-svn: 366186
* Improve error message when '=' is missing in {ASAN,...}_OPTIONS.Vitaly Buka2019-06-151-1/+1
| | | | | | | | | | | | | | | | | | Summary: It's handling isses as described here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832 Patch by Martin Liška. Reviewers: kcc, vitalybuka Reviewed By: vitalybuka Subscribers: cryptoad, kubamracek Differential Revision: https://reviews.llvm.org/D59876 llvm-svn: 363480
* Fix for WindowsStephan Bergmann2019-05-021-2/+1
| | | | | | | ...after 5745eccef54ddd3caca278d1d292a88b2281528b "Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO" llvm-svn: 359760
* Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFOStephan Bergmann2019-05-027-48/+79
| | | | | | | | | | | | | | | | | | | | | | | | This follows up after b7692bc3e9ad2691fc07261904b88fb15f30696b "[UBSan] Fix isDerivedFromAtOffset on iOS ARM64" fixed the RTTI comparison in isDerivedFromAtOffset on just one platform and then a25a2c7c9a7e1e328a5bd8274d2d86b1fadc4692 "Always compare C++ typeinfo (based on libstdc++ implementation)" extended that fix to more platforms. But there is another RTTI comparison for -fsanitize=function generated in clang's CodeGenFunction::EmitCall as just a pointer comparison. For SANITIZER_NON_UNIQUE_TYPEINFO platforms this needs to be extended to also do string comparison. For that, __ubsan_handle_function_type_mismatch[_abort] takes the two std::type_info pointers as additional parameters now, checks them internally for potential equivalence, and returns without reporting failure if they turn out to be equivalent after all. (NORETURN needed to be dropped from the _abort variant for that.) Also these functions depend on ABI-specific RTTI now, so needed to be moved from plain UBSAN_SOURCES (ubsan_handlers.h/cc) to UBSAN_CXXABI_SOURCES (ubsan_handlers_cxx.h/cc), but as -fsanitize=function is only supported in C++ mode that's not a problem. Differential Revision: https://reviews.llvm.org/D60760 llvm-svn: 359759
* Always compare C++ typeinfo (based on libstdc++ implementation).Martin Liska2019-03-061-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D58028 llvm-svn: 355488
* [NFC][Sanitizer] Make GetStackTrace a private method of BufferedStackTraceJulian Lettner2019-03-011-5/+5
| | | | | | | | | | GetStackTrace is a implementation detail of BufferedStackTrace. Make it a private method. Reviewed By: vitalybuka Differential-Revision: https://reviews.llvm.org/D58753 llvm-svn: 355232
* [NFC][Sanitizer] Add new BufferedStackTrace::Unwind APIJulian Lettner2019-03-011-11/+13
| | | | | | | | | | | | | | | | | | | | | Retrying without replacing call sites in sanitizer_common (which might not have a symbol definition). Add new Unwind API. This is the final envisioned API with the correct abstraction level. It hides/slow fast unwinder selection from the caller and doesn't take any arguments that would leak that abstraction (i.e., arguments like stack_top/stack_bottom). GetStackTrace will become an implementation detail (private method) of the BufferedStackTrace class. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58741 > llvm-svn: 355168 llvm-svn: 355172
* Revert "[NFC][Sanitizer] Add new BufferedStackTrace::Unwind API"Julian Lettner2019-03-011-13/+11
| | | | | | This reverts commit 6112f37e758ebf2405955e091a745f5003c1f562. llvm-svn: 355171
* [NFC][Sanitizer] Add new BufferedStackTrace::Unwind APIJulian Lettner2019-03-011-11/+13
| | | | | | | | | | | | | | | | Add new Unwind API. This is the final envisioned API with the correct abstraction level. It hides/slow fast unwinder selection from the caller and doesn't take any arguments that would leak that abstraction (i.e., arguments like stack_top/stack_bottom). GetStackTrace will become an implementation detail (private method) of the BufferedStackTrace class. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58741 llvm-svn: 355168
* [NFC][Sanitizer] Weak linkage is not available on WindowsJulian Lettner2019-02-282-7/+14
| | | | | | | | | | | The concept of weak linkage is not available on Windows. The available workarounds in LLVM/sanitizer runtimes have their own problems. Define a separte symbol ubsan_GetStackTrace to work around the issue now. At lest this way it is painfully obvious that we still have to do more cleanup. Follow-up to revision: https://reviews.llvm.org/D58651 llvm-svn: 355113
* [NFC][Sanitizer] Use correct WEAK annotation to make Windows workJulian Lettner2019-02-281-1/+1
| | | | | | | The previous fix didn't work for Windows: https://github.com/llvm/llvm-project/commit/52b751088b11547e0f4ef0589ebbe5e57752c68c llvm-svn: 355052
* [Sanitizer] Attempt to fix linker error on ARM variantsJulian Lettner2019-02-272-11/+14
| | | | | | | Previous commit: https://github.com/llvm/llvm-project/commit/a0884da62a471f08c65a03e337aea23203a43eb8 llvm-svn: 355046
* [NFC][Sanitizer] Pull up GetStackTrace into sanitizer_commonJulian Lettner2019-02-273-14/+11
| | | | | | | | | | | | | | | | | | | | We already independently declare GetStackTrace in all (except TSan) sanitizer runtime headers. Lets move it to sanitizer_stacktrace.h to have one canonical way to fill in a BufferedStackFrame. Also enables us to use it in sanitizer_common itself. This patch defines GetStackTrace for TSan and moves the function from ubsan_diag.cc to ubsan_diag_standalone.cc to avoid duplicate symbols for the UBSan-ASan runtime. Other than that this patch just moves the code out of headers and into the correct namespace. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58651 llvm-svn: 355039
* [NFC][Sanitizer] Hard-code fast/slow unwinder at call siteJulian Lettner2019-02-272-7/+10
| | | | | | | | | | | | | Also assert that the caller always gets what it requested. This purely mechanical change simplifies future refactorings and eventual removal of BufferedStackTrace::Unwind. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58557 llvm-svn: 355022
* [Sanitizer] Fix uses of stack->Unwind(..., fast)Julian Lettner2019-02-221-1/+1
| | | | | | | | | | | Apply StackTrace::WillUseFastUnwind(fast) in a few more places missed by my previous patch (https://reviews.llvm.org/D58156). Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58550 llvm-svn: 354695
* [Sanitizer] On Darwin `__sanitizer_print_stack_trace` only prints topmost frameJulian Lettner2019-02-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In compiler-rt we have the notion of a `fast` and a `slow` stack unwinder. Darwin currently only supports the fast unwinder. From reading the code, my understanding is that `BufferedStackTrace::Unwind` can be called with `bp=0, stack_top=0, stack_bottom=0, request_fast_unwind=false`. If `request_fast_unwind=true`, then we alos need to supply bp, stack_top, and stack_bottom. However, `BufferedStackTrace::Unwind` uses `StackTrace::WillUseFastUnwind` which will adapt `request_fast_unwind` if the requested unwinder is not supported. On Darwin, the result is that we don't pass actual values for bp, stack_top, and stack_bottom, but end up using the fast unwinder. The tests then fail because we only print the topmost stack frame. This patch adds a check to `WillUseFastUnwind` at the point of usage to avoid the mismatch between `request_fast_unwind` and what `Unwind` actually does. I am also interested in cleaning up the `request_fast_unwind` machinery so this patch just the simplest thing possible so I can enable the tests. Reviewers: vitalybuka, vsk Differential Revision: https://reviews.llvm.org/D58156 llvm-svn: 354282
* [compiler-rt] Cleanup usage of C++ ABI libraryJonas Hahnfeld2019-02-161-1/+1
| | | | | | | | | | | | | Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking unit tests. This needs to be a full C++ library and cannot be libcxxabi. Recommit r354132 which I reverted in r354153 because it broke a sanitizer bot. This was because of the "fixes" for pthread linking, so I've removed these changes. Differential Revision: https://reviews.llvm.org/D58012 llvm-svn: 354198
* Revert "[compiler-rt] Cleanup usage of C++ ABI library"Jonas Hahnfeld2019-02-151-1/+1
| | | | | | | This reverts r354132 because it breaks sanitizer-x86_64-linux: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/19915 llvm-svn: 354153
* [compiler-rt] Cleanup usage of C++ ABI libraryJonas Hahnfeld2019-02-151-1/+1
| | | | | | | | | Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking unit tests. This needs to be a full C++ library and cannot be libcxxabi. Differential Revision: https://reviews.llvm.org/D58012 llvm-svn: 354132
* Revert https://reviews.llvm.org/D56485.Martin Liska2019-01-241-1/+1
| | | | llvm-svn: 352033
* Always compare C++ typeinfo (based on libstdc++ implementation).Martin Liska2019-01-241-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D56485. llvm-svn: 352032
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1930-120/+90
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Make compiler-rt CMakeLists.txt formatting a bit more like LLVM's usual ↵Nico Weber2019-01-161-4/+7
| | | | | | formatting llvm-svn: 351363
* [compiler-rt][UBSan] Sanitization for alignment assumptions.Roman Lebedev2019-01-154-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the compiler-rt part. The clang part is D54589. This is a second commit, the original one was r351106, which was mass-reverted in r351159 because 2 compiler-rt tests were failing. Now, i have fundamentally changed the testing approach: i malloc a few bytes, intentionally mis-align the pointer (increment it by one), and check that. Also, i have decreased the expected alignment. This hopefully should be enough to pacify all the bots. If not, i guess i might just drop the two 'bad' tests. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351178
* Revert alignment assumptions changesVlad Tsyrklevich2019-01-154-70/+0
| | | | | | | Revert r351104-6, r351109, r351110, r351119, r351134, and r351153. These changes fail on the sanitizer bots. llvm-svn: 351159
* [compiler-rt] Update ubsan_interface.inc with alignment assumption handlersRoman Lebedev2019-01-141-0/+2
| | | | | | | Somehow this escaped my local testing. A follow-up for r351106. llvm-svn: 351110
* [compiler-rt][UBSan] Sanitization for alignment assumptions.Roman Lebedev2019-01-143-0/+68
| | | | | | | | | | | | | | | | | | Summary: This is the compiler-rt part. The clang part is D54589. Reviewers: filcab, vsk, #sanitizers, vitalybuka, rsmith, morehouse Reviewed By: morehouse Subscribers: rjmccall, krytarowski, rsmith, kcc, srhines, kubamracek, dberris, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54590 llvm-svn: 351106
* [compiler-rt][UBSan] silence_unsigned_overflow: do *NOT* ignore *fatal* ↵Roman Lebedev2018-11-212-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | unsigned overflows Summary: D48660 / rL335762 added a `silence_unsigned_overflow` env flag for [[ https://github.com/google/oss-fuzz/pull/1717 | oss-fuzz needs ]], that allows to silence the reports from unsigned overflows. It makes sense, it is there because `-fsanitize=integer` sanitizer is not enabled on oss-fuzz, so this allows to still use it as an interestingness signal, without getting the actual reports. However there is a slight problem here. All types of unsigned overflows are ignored. Even if `-fno-sanitize-recover=unsigned` was used (which means the program will die after the report) there will still be no report, the program will just silently die. At the moment there are just two projects on oss-fuzz that care: * [[ https://github.com/google/oss-fuzz/blob/8eeffa627f937040aaf8ba1b7d93f43f77d74fb9/projects/llvm_libcxx/build.sh#L18-L20 | libc++ ]] * [[ https://github.com/google/oss-fuzz/blob/8eeffa627f937040aaf8ba1b7d93f43f77d74fb9/projects/librawspeed/build.sh | RawSpeed ]] (me) I suppose this could be overridden there ^, but i really don't think this is intended behavior in any case.. Reviewers: kcc, Dor1s, #sanitizers, filcab, vsk, kubamracek Reviewed By: Dor1s Subscribers: dberris, mclow.lists, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D54771 llvm-svn: 347415
* [compiler-rt][ubsan] Implicit Conversion Sanitizer - integer sign change - ↵Roman Lebedev2018-10-303-0/+14
| | | | | | | | | | | | | | | | | | | | | | compiler-rt part Summary: This is a compiler-rt part. The clang part is D50250. See [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], https://github.com/google/sanitizers/issues/940. Reviewers: vsk, filcab, #sanitizers Reviewed By: filcab, #sanitizers Subscribers: mclow.lists, srhines, kubamracek, dberris, rjmccall, rsmith, llvm-commits, regehr Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D50251 llvm-svn: 345659
* [compiler-rt][ubsan] Split Implicit Integer Truncation Sanitizer into ↵Roman Lebedev2018-10-113-10/+33
| | | | | | | | | | | | | | | | unsigned and signed checks Summary: This is compiler-rt part. clang part is D50901. Reviewers: rsmith, vsk, filcab, Sanitizers Reviewed by: filcab Differential Revision: https://reviews.llvm.org/D50902 llvm-svn: 344231
* [compiler-rt][ubsan] Implicit Conversion Sanitizer - integer truncation - ↵Roman Lebedev2018-07-305-1/+65
| | | | | | | | | | | | | | | | | | | | | | compiler-rt part Summary: This is a compiler-rt part. The clang part is D48958. See [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], https://github.com/google/sanitizers/issues/940. Reviewers: #sanitizers, samsonov, vsk, rsmith, pcc, eugenis, kcc, filcab Reviewed By: #sanitizers, vsk, filcab Subscribers: llvm-commits, eugenis, filcab, kubamracek, dberris, #sanitizers, regehr Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D48959 llvm-svn: 338287
* [UBSan] Followup for silence_unsigned_overflow flag to handle negate overflows.Max Moroz2018-07-131-0/+3
| | | | | | | | | | | | | | | | | | | | Summary: That flag has been introduced in https://reviews.llvm.org/D48660 for suppressing UIO error messages in an efficient way. The main motivation is to be able to use UIO checks in builds used for fuzzing as it might provide an interesting signal to a fuzzing engine such as libFuzzer. See https://github.com/google/oss-fuzz/issues/910 for more information. Reviewers: morehouse, kcc Reviewed By: morehouse Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D49324 llvm-svn: 337068
* [CMake] Add compiler-rt header files to the list of sources for targetsDan Liew2018-07-101-8/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when building with an IDE so that header files show up in the UI. This massively improves the development workflow in IDEs. To implement this a new function `compiler_rt_process_sources(...)` has been added that adds header files to the list of sources when the generator is an IDE. For non-IDE generators (e.g. Ninja/Makefile) no changes are made to the list of source files. The function can be passed a list of headers via the `ADDITIONAL_HEADERS` argument. For each runtime library a list of explicit header files has been added and passed via `ADDITIONAL_HEADERS`. For `tsan` and `sanitizer_common` a list of headers was already present but it was stale and has been updated to reflect the current state of the source tree. The original version of this patch used file globbing (`*.{h,inc,def}`) to find the headers but the approach was changed due to this being a CMake anti-pattern (if the list of headers changes CMake won't automatically re-generate if globbing is used). The LLVM repo contains a similar function named `llvm_process_sources()` but we don't use it here for several reasons: * It depends on the `LLVM_ENABLE_OPTION` cache variable which is not set in standalone compiler-rt builds. * We would have to `include(LLVMProcessSources)` which I'd like to avoid because it would include a bunch of stuff we don't need. Differential Revision: https://reviews.llvm.org/D48422 llvm-svn: 336663
* [UBSan] Add silence_unsigned_overflow flag.Matt Morehouse2018-06-272-0/+7
| | | | | | | | | | | | | | | | | | | | Summary: Setting UBSAN_OPTIONS=silence_unsigned_overflow=1 will silence all UIO reports. This feature, combined with -fsanitize-recover=unsigned-integer-overflow, is useful for providing fuzzing signal without the excessive log output. Helps with https://github.com/google/oss-fuzz/issues/910. Reviewers: kcc, vsk Reviewed By: vsk Subscribers: vsk, kubamracek, Dor1s, llvm-commits Differential Revision: https://reviews.llvm.org/D48660 llvm-svn: 335762
* CFI: Print DSO names for failed cross-DSO icallsVlad Tsyrklevich2018-06-262-8/+32
| | | | | | | | | | | | Reviewers: pcc Reviewed By: pcc Subscribers: kubamracek, delcypher, llvm-commits, kcc, #sanitizers Differential Revision: https://reviews.llvm.org/D48583 llvm-svn: 335644
* Implement CFI for indirect calls via a member function pointer.Peter Collingbourne2018-06-263-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similarly to CFI on virtual and indirect calls, this implementation tries to use program type information to make the checks as precise as possible. The basic way that it works is as follows, where `C` is the name of the class being defined or the target of a call and the function type is assumed to be `void()`. For virtual calls: - Attach type metadata to the addresses of function pointers in vtables (not the functions themselves) of type `void (B::*)()` for each `B` that is a recursive dynamic base class of `C`, including `C` itself. This type metadata has an annotation that the type is for virtual calls (to distinguish it from the non-virtual case). - At the call site, check that the computed address of the function pointer in the vtable has type `void (C::*)()`. For non-virtual calls: - Attach type metadata to each non-virtual member function whose address can be taken with a member function pointer. The type of a function in class `C` of type `void()` is each of the types `void (B::*)()` where `B` is a most-base class of `C`. A most-base class of `C` is defined as a recursive base class of `C`, including `C` itself, that does not have any bases. - At the call site, check that the function pointer has one of the types `void (B::*)()` where `B` is a most-base class of `C`. Differential Revision: https://reviews.llvm.org/D47567 llvm-svn: 335569
* [ubsan] Fix __ubsan_on_report interface definitionVedant Kumar2018-06-222-1/+2
| | | | | | | | | | | | | | | | Speculative fix for the interface definition of __ubsan_on_report for the Windows bots: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/30528 lib\ubsan\ubsan_interface.inc(55): error C2065: '__ubsan_on_report': undeclared identifier INTERCEPT_SANITIZER_WEAK_FUNCTION was the wrong macro to use to begin with because __ubsan_on_report isn't weak. Reading through that macro, it's still not clear to me why there is an undefined reference, though, because it appears to define a dummy __ubsan_on_report shim. llvm-svn: 335383
* [ubsan] Add support for reporting diagnostics to a monitor processVedant Kumar2018-06-228-59/+209
| | | | | | | | | | | | | | | | | | Add support to the ubsan runtime for reporting diagnostics to a monitor process (e.g a debugger). The Xcode IDE uses this by setting a breakpoint on __ubsan_on_report and collecting diagnostic information via __ubsan_get_current_report_data, which it then surfaces to users in the editor UI. Testing for this functionality already exists in upstream lldb, here: lldb/packages/Python/lldbsuite/test/functionalities/ubsan Apart from that, this is `ninja check-{a,ub}san` clean. Differential Revision: https://reviews.llvm.org/D48446 llvm-svn: 335371
* [sanitizer] Trivial portion of the port to Myriad RTEMSWalter Lee2018-05-181-1/+1
| | | | | | | | | | | | | | | | | | | | | This commit contains the trivial portion of the port of ASan to Myriad RTEMS. - Whitelist platform in sanitizer_platform.h, ubsan_platform.h - Turn off general interception - Use memset for FastPoisonShadow - Define interception wrappers - Set errno symbol correctly - Enable ASAN_LOW_MEMORY - Enable preinit array - Disable slow unwinding - Use fuchsia offline symbolizer - Disable common code for: InitializeShadowMemory, CreateMainThread, AsanThread::ThreadStart, StartReportDeadlySignal, MaybeReportNonExecRegion. Differential Revision: https://reviews.llvm.org/D46454 llvm-svn: 332681
* [CMake] Build shared version of runtimes for FuchsiaPetr Hosek2018-05-091-1/+1
| | | | | | | | | Fuchsia is no longer treated as UNIX which means we need to explicitly enable building of shared versions of runtimes. Differential Revision: https://reviews.llvm.org/D46609 llvm-svn: 331922
* [sanitizer] Fix OSX build failure post D45457Kostya Kortchinsky2018-04-161-1/+1
| | | | | | | | | | | | Summary: It looks like OSX's UBSan needs a "NoHooks" version of `RTSanitizerCommonSymbolizer` to work build properly. Subscribers: kubamracek, mgorny, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D45696 llvm-svn: 330146
* [sanitizer] Split Symbolizer/StackTraces from core RTSanitizerCommonKostya Kortchinsky2018-04-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Host symbolizer & stacktraces related code in their own RT: `RTSanitizerCommonSymbolizer`, which is "libcdep" by nature. Symbolizer & stacktraces specific code that used to live in common files is moved to a new file `sanitizer_symbolizer_report.cc` as is. The purpose of this is the enforce a separation between code that relies on symbolization and code that doesn't. This saves the inclusion of spurious code due to the interface functions with default visibility, and the extra data associated. The following sanitizers makefiles were modified & tested locally: - dfsan: doesn't require the new symbolizer RT - esan: requires it - hwasan: requires it - lsan: requires it - msan: requires it - safestack: doesn't require it - xray: doesn't require it - tsan: requires it - ubsan: requires it - ubsan_minimal: doesn't require it - scudo: requires it (but not for Fuchsia that has a minimal runtime) This was tested locally on Linux, Android, Fuchsia. Reviewers: alekseyshl, eugenis, dberris, kubamracek, vitalybuka, dvyukov, mcgrathr Reviewed By: alekseyshl, vitalybuka Subscribers: srhines, kubamracek, mgorny, krytarowski, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D45457 llvm-svn: 330131
* [sanitizer] Split coverage into separate RT in sanitizer_commonKostya Kortchinsky2018-03-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: `sanitizer_common`'s coverage support is fairly well separated, and libcdep by default. Several sanitizers don't make use of coverage, and as far as I can tell do no benefit from the extra dependencies pulled in by the coverage public interface functions. The following sanitizers call `InitializeCoverage` explicitely: MSan, ASan, LSan, HWAsan, UBSan. On top of this, any sanitizer bundling RTUBSan should add the coverage RT as well: ASan, Scudo, UBSan, CFI (diag), TSan, MSan, HWAsan. So in the end the following have no need: DFSan, ESan, CFI, SafeStack (nolibc anyway), XRay, and the upcoming Scudo minimal runtime. I tested this with all the sanitizers check-* with gcc & clang, and in standalone on Linux & Android, and there was no issue. I couldn't test this on Mac, Fuchsia, BSDs, & Windows for lack of an environment, so adding a bunch of people for additional scrunity. I couldn't test HWAsan either. Reviewers: eugenis, vitalybuka, alekseyshl, flowerhack, kubamracek, dberris, rnk, krytarowski Reviewed By: vitalybuka, alekseyshl, flowerhack, dberris Subscribers: mgorny, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D44701 llvm-svn: 328204
OpenPOWER on IntegriCloud