Commit Graph

351 Commits

Author SHA1 Message Date
Roman Lebedev 6430adbe64 [UBSan] Appease linter
llvm-svn: 374316
2019-10-10 11:32:06 +00:00
Roman Lebedev 536b0ee40a [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined 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
2019-10-10 09:25:02 +00:00
Vitaly Buka d39e7e2cf1 [compiler-rt] Use GetNextInstructionPc in signal handlers
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
2019-10-02 21:20:37 +00:00
Vitaly Buka c0fa632236 Remove NOLINTs from compiler-rt
llvm-svn: 371687
2019-09-11 23:19:48 +00:00
Max Moroz 9508738cd1 [UBSan] Do not overwrite the default print_summary sanitizer option.
Summary:
This option is true by default in sanitizer common. The default
false value was added a while ago without any reasoning in
524e934112

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
2019-09-09 19:30:48 +00:00
Nico Weber 4a1a113a99 Remove a few straggler ".cc"s in compiler-rt/lib
llvm-svn: 367589
2019-08-01 17:53:25 +00:00
Nico Weber 46ba969752 compiler-rt: Rename .cc files in lib/ubsan to .cpp.
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
2019-07-31 17:51:05 +00:00
Stephan Bergmann e215996a29 Finish "Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO"
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
2019-07-16 06:23:27 +00:00
Vitaly Buka 0b1ea8cb28 Improve error message when '=' is missing in {ASAN,...}_OPTIONS.
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
2019-06-15 01:37:14 +00:00
Stephan Bergmann 2f0ef58e53 Fix for Windows
...after 5745eccef5 "Adapt -fsanitize=function to
SANITIZER_NON_UNIQUE_TYPEINFO"

llvm-svn: 359760
2019-05-02 07:05:29 +00:00
Stephan Bergmann 5745eccef5 Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO
This follows up after b7692bc3e9 "[UBSan] Fix
isDerivedFromAtOffset on iOS ARM64" fixed the RTTI comparison in
isDerivedFromAtOffset on just one platform and then
a25a2c7c9a "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
2019-05-02 06:40:33 +00:00
Martin Liska a25a2c7c9a Always compare C++ typeinfo (based on libstdc++ implementation).
Differential Revision: https://reviews.llvm.org/D58028

llvm-svn: 355488
2019-03-06 08:36:50 +00:00
Julian Lettner 9fe3b4906f [NFC][Sanitizer] Make GetStackTrace a private method of BufferedStackTrace
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
2019-03-01 22:10:49 +00:00
Julian Lettner 13c4bc5671 [NFC][Sanitizer] Add new BufferedStackTrace::Unwind API
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
2019-03-01 04:03:38 +00:00
Julian Lettner e6ec6bd8e0 Revert "[NFC][Sanitizer] Add new BufferedStackTrace::Unwind API"
This reverts commit 6112f37e75.

llvm-svn: 355171
2019-03-01 03:35:05 +00:00
Julian Lettner 6112f37e75 [NFC][Sanitizer] Add new BufferedStackTrace::Unwind API
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
2019-03-01 03:08:34 +00:00
Julian Lettner ce65261fae [NFC][Sanitizer] Weak linkage is not available on Windows
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
2019-02-28 18:42:14 +00:00
Julian Lettner a7171b2e47 [NFC][Sanitizer] Use correct WEAK annotation to make Windows work
The previous fix didn't work for Windows:
52b751088b

llvm-svn: 355052
2019-02-28 00:43:40 +00:00
Julian Lettner 52b751088b [Sanitizer] Attempt to fix linker error on ARM variants
Previous commit:
a0884da62a

llvm-svn: 355046
2019-02-27 23:47:00 +00:00
Julian Lettner a0884da62a [NFC][Sanitizer] Pull up GetStackTrace into sanitizer_common
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
2019-02-27 22:16:02 +00:00
Julian Lettner 46e1b16e36 [NFC][Sanitizer] Hard-code fast/slow unwinder at call site
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
2019-02-27 20:01:04 +00:00
Julian Lettner de7626985f [Sanitizer] Fix uses of stack->Unwind(..., fast)
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
2019-02-22 22:00:13 +00:00
Julian Lettner eb3bcc1c95 [Sanitizer] On Darwin `__sanitizer_print_stack_trace` only prints topmost frame
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
2019-02-18 18:47:49 +00:00
Jonas Hahnfeld a05d442391 [compiler-rt] Cleanup usage of C++ ABI library
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
2019-02-16 08:34:26 +00:00
Jonas Hahnfeld ea686e2845 Revert "[compiler-rt] Cleanup usage of C++ ABI library"
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
2019-02-15 18:25:26 +00:00
Jonas Hahnfeld 3cc63cfaa7 [compiler-rt] Cleanup usage of C++ ABI library
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
2019-02-15 14:30:18 +00:00
Martin Liska acc348aad0 Revert https://reviews.llvm.org/D56485.
llvm-svn: 352033
2019-01-24 08:46:06 +00:00
Martin Liska dc5c81330b Always compare C++ typeinfo (based on libstdc++ implementation).
Differential Revision: https://reviews.llvm.org/D56485.

llvm-svn: 352032
2019-01-24 08:25:36 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
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
2019-01-19 08:50:56 +00:00
Nico Weber 07d8b321b3 Make compiler-rt CMakeLists.txt formatting a bit more like LLVM's usual formatting
llvm-svn: 351363
2019-01-16 18:12:45 +00:00
Roman Lebedev a06ad18669 [compiler-rt][UBSan] Sanitization for alignment assumptions.
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
2019-01-15 09:44:27 +00:00
Vlad Tsyrklevich 86e68fda3b Revert alignment assumptions changes
Revert r351104-6, r351109, r351110, r351119, r351134, and r351153. These
changes fail on the sanitizer bots.

llvm-svn: 351159
2019-01-15 03:38:02 +00:00
Roman Lebedev fd10ac3584 [compiler-rt] Update ubsan_interface.inc with alignment assumption handlers
Somehow this escaped my local testing.
A follow-up for r351106.

llvm-svn: 351110
2019-01-14 19:35:12 +00:00
Roman Lebedev cc10d54432 [compiler-rt][UBSan] Sanitization for alignment assumptions.
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
2019-01-14 19:09:29 +00:00
Roman Lebedev 1d0c7f563c [compiler-rt][UBSan] silence_unsigned_overflow: do *NOT* ignore *fatal* 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:
* [[ 8eeffa627f/projects/llvm_libcxx/build.sh (L18-L20) | libc++ ]]
* [[ 8eeffa627f/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
2018-11-21 20:35:43 +00:00
Roman Lebedev 320e9af309 [compiler-rt][ubsan] Implicit Conversion Sanitizer - integer sign change - 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
2018-10-30 21:58:54 +00:00
Roman Lebedev d32c0d1466 [compiler-rt][ubsan] Split Implicit Integer Truncation Sanitizer into 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
2018-10-11 09:09:52 +00:00
Roman Lebedev eb4a9bc343 [compiler-rt][ubsan] Implicit Conversion Sanitizer - integer truncation - 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
2018-07-30 18:58:30 +00:00
Max Moroz 038771a25a [UBSan] Followup for silence_unsigned_overflow flag to handle negate overflows.
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
2018-07-13 22:49:06 +00:00
Dan Liew b1f95697c1 [CMake] Add compiler-rt header files to the list of sources for targets
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
2018-07-10 13:00:17 +00:00
Matt Morehouse 520748f01e [UBSan] Add silence_unsigned_overflow flag.
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
2018-06-27 18:24:46 +00:00
Vlad Tsyrklevich e745cf9bf3 CFI: Print DSO names for failed cross-DSO icalls
Reviewers: pcc

Reviewed By: pcc

Subscribers: kubamracek, delcypher, llvm-commits, kcc, #sanitizers

Differential Revision: https://reviews.llvm.org/D48583

llvm-svn: 335644
2018-06-26 18:51:04 +00:00
Peter Collingbourne e44acadf6a Implement CFI for indirect calls via a member function pointer.
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
2018-06-26 02:15:47 +00:00
Vedant Kumar c835306ac5 [ubsan] Fix __ubsan_on_report interface definition
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
2018-06-22 20:15:33 +00:00
Vedant Kumar 059d20360a [ubsan] Add support for reporting diagnostics to a monitor process
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
2018-06-22 17:21:17 +00:00
Walter Lee b134dbb3c3 [sanitizer] Trivial portion of the port to Myriad RTEMS
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
2018-05-18 00:43:54 +00:00
Petr Hosek 1608ca6d64 [CMake] Build shared version of runtimes for Fuchsia
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
2018-05-09 21:24:06 +00:00
Kostya Kortchinsky 25eae5c879 [sanitizer] Fix OSX build failure post D45457
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
2018-04-16 18:17:22 +00:00
Kostya Kortchinsky 596b8b4a22 [sanitizer] Split Symbolizer/StackTraces from core RTSanitizerCommon
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
2018-04-16 16:32:19 +00:00
Kostya Kortchinsky 988fab3f66 [sanitizer] Split coverage into separate RT in sanitizer_common
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
2018-03-22 15:04:31 +00:00