summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/ubsan
Commit message (Collapse)AuthorAgeFilesLines
* 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
* OpenBSD UBsan support / ubsan partKamil Rytarowski2018-03-021-1/+2
| | | | | | | | | | | | | | | | Summary: UBsan, enable OpenBSD platform Patch by: David CARLIER Reviewers: krytarowski, kettenis, visa, vitalybuka Reviewed By: vitalybuka Subscribers: kubamracek, fedor.sergeev, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D43894 llvm-svn: 326543
* Recognize all NetBSD architectures in UBSanKamil Rytarowski2018-02-171-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Use uniform accessors for Program Pointer, Stack Pointer and Frame Pointer. Remove CPU check in UBSan supported platforms and rely only on the OS type. This adds NetBSD support in GetPcSpBp() for: - ARM - ARM64 - HPPA - PowerPC/PowerPC64 - SPARC/SPARC64 - MIPS - DEC Alpha AXP - DEC VAX - M68K and M68010 - SH3 - IA64 - OR1K - RISCV Sponsored by <The NetBSD Foundation> Reviewers: joerg, vitalybuka, ro Reviewed By: vitalybuka Subscribers: aemerson, jyknight, sdardis, kubamracek, arichardson, llvm-commits, kristof.beyls, fedor.sergeev, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D43021 llvm-svn: 325431
* [ubsan] Add preinit initializer for ubsanFrancis Ricci2018-01-233-2/+48
| | | | | | | | | | | | | | | | | | | | Summary: Now that ubsan does function interception (for signals), we need to ensure that ubsan is initialized before any library constructors are called. Otherwise, if a constructor calls sigaction, ubsan will intercept in an unitialized state, which will cause a crash. This patch is a partial revert of r317757, which removed preinit arrays for ubsan. Reviewers: vitalybuka, eugenis, pcc Subscribers: kubamracek, mgorny, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D42389 llvm-svn: 323249
* [ubsan] Disable signal handling on Android.Evgeniy Stepanov2018-01-221-4/+19
| | | | | | | | | | | | Summary: See rationale in the comments. Reviewers: vitalybuka Subscribers: srhines, llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D42329 llvm-svn: 323142
* -fsanitize=vptr warnings on bad static types in dynamic_cast and typeidStephan Bergmann2017-12-281-1/+2
| | | | | | | | | | | | | | | | ...when such an operation is done on an object during con-/destruction. (This adds a test case to compiler-rt/test/ubsan/TestCases/TypeCheck/vptr.cpp that, unlike the existing test cases there, wants to detect multiple UBSan warnings in one go. Therefore, that file had to be changed from globally using -fno-sanitize-recover to individually using halt_on_error only where appropriate.) This is the compiler-rt part of a patch covering both cfe and compiler-rt. Differential Revision: https://reviews.llvm.org/D40295 llvm-svn: 321518
* [ubsan] Diagnose noreturn functions which return (compiler-rt)Vedant Kumar2017-12-211-1/+1
| | | | | | | | This is paired with the clang change: https://reviews.llvm.org/D40698 Differential Revision: https://reviews.llvm.org/D40700 llvm-svn: 321232
* Revert r320977 "No -fsanitize=function warning when calling noexcept ↵Stephan Bergmann2017-12-182-50/+9
| | | | | | | | | | | | | function through non-noexcept pointer in C++17" At least <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android/ builds/6013/steps/annotate/logs/stdio> complains about __ubsan::__ubsan_handle_function_type_mismatch_abort (compiler-rt lib/ubsan/ubsan_handlers.cc) returning now despite being declared 'noreturn', so looks like a different approach is needed for the function_type_mismatch check to be called also in cases that may ultimately succeed. llvm-svn: 320981
* No -fsanitize=function warning when calling noexcept function through ↵Stephan Bergmann2017-12-182-9/+50
| | | | | | | | | | | | | | | | | | | | | | | non-noexcept pointer in C++17 As discussed in the mail thread <https://groups.google.com/a/isocpp.org/forum/ #!topic/std-discussion/T64_dW3WKUk> "Calling noexcept function throug non- noexcept pointer is undefined behavior?", such a call should not be UB. However, Clang currently warns about it. There is no cheap check whether two function type_infos only differ in noexcept,so pass those two type_infos as additional data to the function_type_mismatch handler (with the optimization of passing a null "static callee type" info when that is already noexcept, so the additional check can be avoided anyway). For the Itanium ABI (which appears to be the only one that happens to be used on platforms that support -fsanitize=function, and which appears to only record noexcept information for pointer-to-function type_infos, not for function type_infos themselves), we then need to check the mangled names for occurrence of "Do" representing "noexcept". This is the compiler-rt part of a patch covering both cfe and compiler-rt. Differential Revision: https://reviews.llvm.org/D40720 llvm-svn: 320977
* [Sanitizers] Basic sanitizer Solaris support (PR 33274)Kamil Rytarowski2017-12-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is the first mostly working version of the Sanitizer port to 32-bit Solaris/x86. It is currently based on Solaris 11.4 Beta. This part was initially developed inside libsanitizer in the GCC tree and should apply to both. Subsequent parts will address changes to clang, the compiler-rt build system and testsuite. I'm not yet sure what the right patch granularity is: if it's profitable to split the patch up, I'd like to get guidance on how to do so. Most of the changes are probably straightforward with a few exceptions: * The Solaris syscall interface isn't stable, undocumented and can change within an OS release. The stable interface is the libc interface, which I'm using here, if possible using the internal _-prefixed names. * While the patch primarily target 32-bit x86, I've left a few sparc changes in. They cannot currently be used with clang due to a backend limitation, but have worked fine inside the gcc tree. * Some functions (e.g. largefile versions of functions like open64) only exist in 32-bit Solaris, so I've introduced a separate SANITIZER_SOLARIS32 to check for that. The patch (with the subsequent ones to be submitted shortly) was tested on i386-pc-solaris2.11. Only a few failures remain, some of them analyzed, some still TBD: AddressSanitizer-i386-sunos :: TestCases/Posix/concurrent_overflow.cc AddressSanitizer-i386-sunos :: TestCases/init-order-atexit.cc AddressSanitizer-i386-sunos :: TestCases/log-path_test.cc AddressSanitizer-i386-sunos :: TestCases/malloc-no-intercept.c AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/concurrent_overflow.cc AddressSanitizer-i386-sunos-dynamic :: TestCases/Posix/start-deactivated.cc AddressSanitizer-i386-sunos-dynamic :: TestCases/default_options.cc AddressSanitizer-i386-sunos-dynamic :: TestCases/init-order-atexit.cc AddressSanitizer-i386-sunos-dynamic :: TestCases/log-path_test.cc AddressSanitizer-i386-sunos-dynamic :: TestCases/malloc-no-intercept.c SanitizerCommon-Unit :: ./Sanitizer-i386-Test/MemoryMappingLayout.DumpListOfModules SanitizerCommon-Unit :: ./Sanitizer-i386-Test/SanitizerCommon.PthreadDestructorIterations Maybe this is good enough the get the ball rolling. Reviewers: kcc, alekseyshl Reviewed By: alekseyshl Subscribers: srhines, jyknight, kubamracek, krytarowski, fedor.sergeev, llvm-commits, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D40898 llvm-svn: 320740
* [sanitizers] Rename GetStackTraceWithPcBpAndContextVitaly Buka2017-11-093-11/+8
| | | | | | Name does not need to enumerate arguments. llvm-svn: 317774
* ubsan: Allow programs to use setenv to configure ubsan_standalone.Peter Collingbourne2017-11-093-40/+4
| | | | | | | | | | | | | | | | | | | | | | Previously ubsan_standalone used the GetEnv function to read the environment variables UBSAN_OPTIONS and UBSAN_SYMBOLIZER_PATH. The problem with GetEnv is that it does not respect changes to the environment variables made using the libc setenv function, which prevents clients from setting environment variables to configure ubsan before loading ubsan-instrumented libraries. The reason why we have GetEnv is that some runtimes need to read environment variables while they initialize using .preinit_array, and getenv does not work while .preinit_array functions are being called. However, it is unnecessary for ubsan_standalone to initialize that early. So this change switches ubsan_standalone to using getenv and removes the .preinit_array entry. The static version of the runtime still ends up being initialized using a C++ constructor that exists to support the shared runtime. Differential Revision: https://reviews.llvm.org/D39827 llvm-svn: 317757
OpenPOWER on IntegriCloud