When using ASan and UBSan together, the common sanitizer tool name is
set to "AddressSanitizer". That means that when a UBSan diagnostic is
printed out, it looks like this:
SUMMARY: AddressSanitizer: ...
This can confuse users. Fix it so that we always use the correct tool
name when printing out UBSan diagnostics.
Differential Revision: https://reviews.llvm.org/D32066
llvm-svn: 300358
Add 'nullability_arg' and 'nullability_return' diagnostic handlers, and
also add a TypeCheckKind for null assignments to _Nonnull. With this in
place, we can update clang to use the nicer handlers for nullability
diagnostics.
The alternative to this approach is to update the existing 'nonnull_arg'
and 'nonnull_return' handlers to accept a boolean parameter. However,
versioning the existing handlers would cause code size bloat, and the
complexity cost of introducing new handlers into the runtime is low.
I will add tests for this, and all of -fsanitize=nullability, into
check-ubsan once the clang side of the changes is in.
llvm-svn: 297748
In Windows, when sanitizers are implemented as a shared library (DLL), users can
redefine and export a new definition for weak functions, in the main executable,
for example:
extern "C" __declspec(dllexport)
void __sanitizer_cov_trace_pc_guard(u32* guard) {
// Different implementation provided by the client.
}
However, other dlls, will continue using the default implementation imported
from the sanitizer dll. This is different in linux, where all the shared
libraries will consider the strong definition.
With the implementation in this diff, when the dll is initialized, it will check
if the main executable exports the definition for some weak function (for
example __sanitizer_cov_trace_pc_guard). If it finds that function, then it will
override the function in the dll with that pointer. So, all the dlls with
instrumentation that import __sanitizer_cov_trace_pc_guard__dll() from asan dll,
will be using the function provided by the main executable.
In other words, when the main executable exports a strong definition for a weak
function, we ensure all the dlls use that implementation instead of the default
weak implementation.
The behavior is similar to linux. Now, every user that want to override a weak
function, only has to define and export it. The same for Linux and Windows, and
it will work fine. So, there is no difference on the user's side.
All the sanitizers will include a file sanitizer_win_weak_interception.cc that
register sanitizer's weak functions to be intercepted in the binary section WEAK
When the sanitizer dll is initialized, it will execute weak_intercept_init()
which will consider all the CB registered in the section WEAK. So, for all the
weak functions registered, we will check if a strong definition is provided in
the main executable.
All the files sanitizer_win_weak_interception.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we include [asan|ubsan|sanitizer_coverage]_win_weak_interception.cc and
sanitizer_win_weak_interception.cc in asan dll, so when it is initialized, it
will consider all the weak functions from asan, ubsan and sanitizer coverage.
After this diff, sanitizer coverage is fixed for MD on Windows. In particular
libFuzzer can provide custom implementation for all sanitizer coverage's weak
functions, and they will be considered by asan dll.
Differential Revision: https://reviews.llvm.org/D29168
llvm-svn: 293958
In Windows, when the sanitizer is implemented as a shared library (DLL), we need
an auxiliary static library dynamic_runtime_thunk that will be linked to the
main executable and dlls.
In the sanitizer DLL, we are exposing weak functions with WIN_WEAK_EXPORT_DEF(),
which exports the default implementation with __dll suffix. For example: for
sanitizer coverage, the default implementation of __sanitizer_cov_trace_cmp is
exported as: __sanitizer_cov_trace_cmp__dll.
In the dynamic_runtime_thunk static library, we include weak aliases to the
imported implementation from the dll, using the macro WIN_WEAK_IMPORT_DEF().
By default, all users's programs that include calls to weak functions like
__sanitizer_cov_trace_cmp, will be redirected to the implementation in the dll,
when linking to dynamic_runtime_thunk.
After this diff, we are able to compile code with sanitizer coverage
instrumentation on Windows. When the instrumented object files are linked with
clang-rt_asan_dynamic_runtime_thunk-arch.lib all the weak symbols will be
resolved to the implementation imported from asan dll.
All the files sanitizer_dynamic_runtime_thunk.cc are independent, so we do not
need to include a specific list of sanitizers.
Now, we compile: [asan|ubsan|sanitizer_coverage]_win_dynamic_runtime_thunk.cc
and sanitizer_win_dynamic_runtime_thunk.cc to generate
asan_dynamic_runtime_thunk.lib, because we include asan, ubsan and sanitizer
coverage in the address sanitizer library.
Differential Revision: https://reviews.llvm.org/D29158
llvm-svn: 293953
In this diff, I update current implementation of the interception in dll_thunks
to consider the special case of weak functions.
First we check if the client has redefined the function in the main executable
(for example: __sanitizer_cov_trace_pc_guard). It we can't find it, then we look
for the default implementation (__sanitizer_cov_trace_pc_guard__dll). The
default implementation is always available because the static runtime is linked
to the main executable.
Differential Revision: https://reviews.llvm.org/D29155
llvm-svn: 293952
When the sanitizer is implemented as a static library and is included in the
main executable, we need an auxiliary static library dll_thunk that will be
linked to the dlls that have instrumentation, so they can refer to the runtime
in the main executable. Basically, it uses interception to get a pointer the
function in the main executable and override its function with that pointer.
Before this diff, all of the implementation for dll_thunks was included in asan.
In this diff I split it into different sanitizers, so we can use other
sanitizers regardless of whether we include asan or not.
All the sanitizers include a file sanitizer_win_dll_thunk.cc that register
functions to be intercepted in the binary section: DLLTH
When the dll including dll_thunk is initialized, it will execute
__dll_thunk_init() implemented in: sanitizer_common/sanitizer_win_dll_thunk.cc,
which will consider all the CB registered in the section DLLTH. So, all the
functions registered will be intercepted, and redirected to the implementation
in the main executable.
All the files "sanitizer_win_dll_thunk.cc" are independent, so we don't need to
include a specific list of sanitizers. Now, we compile: asan_win_dll_thunk.cc
ubsan_win_dll_thunk.cc, sanitizer_coverage_win_dll_thunk.cc and
sanitizer_win_dll_thunk.cc, to generate asan_dll_thunk, because we include asan,
ubsan and sanitizer coverage in the address sanitizer library.
Differential Revision: https://reviews.llvm.org/D29154
llvm-svn: 293951
Add a new auxiliary file to each sanitizer: sanitizer_interface.inc, listing all
the functions exported, with the macros: INTERFACE_FUNCTION() and
INTERFACE_WEAK_FUNCTION().
So, when we need to define or repeat a procedure for each function in the
sanitizer's interface, we can define the macros and include that header.
In particular, these files are needed for Windows, in the nexts commits.
Also, this files could replace the existing files: weak_symbols.txt for Apple.
Instead of reading weak_symbols.txt to get the list of weak symbols, we could
read the file sanitizer_interface.inc and consider all the symbols included with
the macro INTERFACE_WEAK_FUNCTION(Name).
In this commit, I only include these files to the sanitizers that work on
Windows. We could do the same for the rest of the sanitizers when needed.
I updated tests for: Linux, Darwin and Windows. If a new function is exported
but is not present in the interface list, the tests
"interface_symbols_[darwin|windows|linux].c" fail.
Also, I remove the comments: "/* OPTIONAL */" which are not required any more,
because we use the macro: INTERFACE_WEAK_FUNCTION() for weak functions.
Differential Revision: https://reviews.llvm.org/D29148
llvm-svn: 293682
In this diff, I define a general macro for defining weak functions
with a default implementation: "SANITIZER_INTERFACE_WEAK_DEF()".
This way, we simplify the implementation for different platforms.
For example, we cannot define weak functions on Windows, but we can
use linker pragmas to create an alias to a default implementation.
All of these implementation details are hidden in the new macro.
Also, as I modify the name for exported weak symbols on Windows, I
needed to temporarily disable "dll_host" test for asan, which checks
the list of functions included in asan_win_dll_thunk.
Differential Revision: https://reviews.llvm.org/D28596
llvm-svn: 293419
This patch adds some useful macros for dealing with pragma directives on
Windows. Also, I add appropriate documentation for future users.
Differential Revision: https://reviews.llvm.org/D28525
llvm-svn: 292650
Summary:
The build system was inconsistent in its naming conventions for
link flags. This patch changes all uses of LINKFLAGS to LINK_FLAGS,
for consistency with cmake's LINK_FLAGS property.
This patch should make it easier to search the source code for
uses of link flags, as well as providing the benefit of improved
style and consistency.
Reviewers: compnerd, beanz
Subscribers: kubabrecka, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28506
llvm-svn: 291539
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291417
Summary:
By default, darwin requires a definition for weak interface functions at
link time. Adding the '-U' link flag with each weak function allows these
weak interface functions to be used without definitions, which mirrors
behavior on linux and windows.
Reviewers: compnerd, eugenis
Subscribers: kubabrecka, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D28203
llvm-svn: 291314
This patch starts passing architecture information about a module to llvm-symbolizer and into text reports. This fixes the longstanding x86_64/x86_64h mismatch issue on Darwin.
Differential Revision: https://reviews.llvm.org/D27390
llvm-svn: 291287
Summary: This is the compiler-rt side of D28242.
Reviewers: kcc, vitalybuka, pgousseau, gbedwell
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D28244
llvm-svn: 291237
The definitions in sanitizer_common may conflict with definitions from system headers because:
The runtime includes the system headers after the project headers (as per LLVM coding guidelines).
lib/sanitizer_common/sanitizer_internal_defs.h pollutes the namespace of everything defined after it, which is all/most of the sanitizer .h and .cc files and the included system headers with: using namespace __sanitizer; // NOLINT
This patch solves the problem by introducing the namespace only within the sanitizer namespaces as proposed by Dmitry.
Differential Revision: https://reviews.llvm.org/D21947
llvm-svn: 281657
This patch builds on LLVM r279776.
In this patch I've done some cleanup and abstracted three common steps runtime components have in their CMakeLists files, and added a fourth.
The three steps I abstract are:
(1) Add a top-level target (i.e asan, msan, ...)
(2) Set the target properties for sorting files in IDE generators
(3) Make the compiler-rt target depend on the top-level target
The new step is to check if a command named "runtime_register_component" is defined, and to call it with the component name.
The runtime_register_component command is defined in llvm/runtimes/CMakeLists.txt, and presently just adds the component to a list of sub-components, which later gets used to generate target mappings.
With this patch a new workflow for runtimes builds is supported. The new workflow when building runtimes from the LLVM runtimes directory is:
> cmake [...]
> ninja runtimes-configure
> ninja asan
The "runtimes-configure" target builds all the dependencies for configuring the runtimes projects, and runs CMake on the runtimes projects. Running the runtimes CMake generates a list of targets to bind into the top-level CMake so subsequent build invocations will have access to some of Compiler-RT's targets through the top-level build.
Note: This patch does exclude some top-level targets from compiler-rt libraries because they either don't install files (sanitizer_common), or don't have a cooresponding `check` target (stats).
llvm-svn: 279863
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 279816
Summary:
On apple targets, when SANITIZER_CAN_USE_CXXABI is false,
the ubsan cxxabi sources aren't built, since they're unused.
Do this on non-apple targets as well.
This fixes errors when linking sanitizers if c++ abi is
unavailable.
Reviewers: pcc, kubabrecka, beanz
Subscribers: rnk, llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23638
llvm-svn: 279467
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 278848
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 278772
Summary: This will allow for the sanitizers to be used when c++ abi is unavailable.
Reviewers: samsonov, beanz, pcc, rnk
Subscribers: llvm-commits, kubabrecka, compnerd, dberris
Differential Revision: https://reviews.llvm.org/D23376
llvm-svn: 278764
Summary:
This patch is a refactoring of the way cmake 'targets' are grouped.
It won't affect non-UI cmake-generators.
Clang/LLVM are using a structured way to group targets which ease
navigation through Visual Studio UI. The Compiler-RT projects
differ from the way Clang/LLVM are grouping targets.
This patch doesn't contain behavior changes.
Reviewers: kubabrecka, rnk
Subscribers: wang0109, llvm-commits, kubabrecka, chrisha
Differential Revision: http://reviews.llvm.org/D21952
llvm-svn: 275111
Summary:
This CL adds a weak check for a Vtable prefix: for a well-formed
Vtable, we require the prefix to be within [-1<<20; 1<<20].
Practically, this solves most of the known cases when UBSan segfaults
without providing any useful diagnostics.
Reviewers: pcc
Subscribers: kubabrecka
Differential Revision: http://reviews.llvm.org/D19750
llvm-svn: 271560
sanitizer_common is now in good enough shape on s390x to support UBSan
- all tests passing. Let's enable it.
Differential Revision: http://reviews.llvm.org/D19157
llvm-svn: 266483
Summary:
Introducing InitializeCommonFlags accross all sanitizers to simplify
common flags management.
Setting coverage=1 when html_cov_report is requested.
Differential Revision: http://reviews.llvm.org/D18273
llvm-svn: 263820
That change did:
-#if defined(__BIG_ENDIAN__)
+#if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
If __BYTE_ORDER__ and __ORDER_BIG_ENDIAN__ aren't defined, like
they are with MSVC, this condition is true (0 == 0).
Fixes PR26919.
llvm-svn: 263324
Summary:
Use InternalScopedString more extensively. This reduces the number of
write() syscalls, and reduces the chance that UBSan output will be
mixed with program output.
Reviewers: vitalybuka
Subscribers: kcc, llvm-commits
Differential Revision: http://reviews.llvm.org/D18068
llvm-svn: 263176
Summary:
__BIG_ENDIAN__ and __LITTLE_ENDIAN__ are not supported by gcc, which
eg. for ubsan Value::getFloatValue will silently fall through to
the little endian branch, breaking display of float values by ubsan.
Use __BYTE_ORDER__ == __ORDER_BIG/LITTLE_ENDIAN__ as the condition
instead, which is supported by both clang and gcc.
Noticed while porting ubsan to s390x.
Patch by Marcin Kościelnicki!
Differential Revision: http://reviews.llvm.org/D17660
llvm-svn: 263077
Summary:
iOS on ARM64 doesn't unique RTTI.
Ref: clang's iOS64CXXABI::shouldRTTIBeUnique()
Due to this, pointer-equality will not necessarily work in this
architecture, across dylib boundaries.
dynamic_cast<>() will (as expected) still work, since Apple ships with
one prepared for this, but we can't rely on the type names being
pointer-equal.
I've limited the expensive strcmp check to the specific architecture
which needs it.
Example which triggers this bug:
lib.h:
struct X {
virtual ~X() {}
};
X *libCall();
lib.mm:
X *libCall() {
return new X;
}
prog.mm:
int main() {
X *px = libCall();
delete px;
}
Expected output: Nothing
Actual output:
<unknown>: runtime error: member call on address 0x00017001ef50 which does not point to an object of type 'X'
0x00017001ef50: note: object is of type 'X'
00 00 00 00 60 00 0f 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
vptr for ‘X’
Reviewers: kubabrecka, samsonov, eugenis, rsmith
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D11502
llvm-svn: 262147
Avoid crashing when printing diagnostics for vtable-related CFI
errors. In diagnostic mode, the frontend does an additional check of
the vtable pointer against the set of all known vtable addresses and
lets the runtime handler know if it is safe to inspect the vtable.
http://reviews.llvm.org/D16824
llvm-svn: 259717
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I am the punishment of God... If [autoconf] had not committed great sins, God would not have sent a punishment like me upon [it]."
-Genghis Khan
Reviewers: chandlerc, grosbach, bob.wilson, zaks.anna, kubabrecka, samsonov, echristo
Subscribers: iains, llvm-commits
Differential Revision: http://reviews.llvm.org/D16473
llvm-svn: 258863
* add __cfi_slowpath_diag with a 3rd parameter which is a pointer to
the diagnostic info for the ubsan handlers.
*__cfi_check gets a 3rd parameter as well.
* unify vcall/cast/etc and icall diagnostic info format, and merge
the handlers to have a single entry point (actually two points due
to abort/noabort variants).
* tests
Note that this comes with a tiny overhead in the non-diag mode:
cfi_slowpath must pass 0 as the 3rd argument to cfi_check.
llvm-svn: 258744
Summary:
Add the ability to suppress UBSan reports for files/functions/modules
at runtime. The user can now pass UBSAN_OPTIONS=suppressions=supp.txt
with the contents of the form:
signed-integer-overflow:file-with-known-overflow.cpp
alignment:function_doing_unaligned_access
vptr:shared_object_with_vptr_failures.so
Suppression categories match the arguments passed to -fsanitize=
flag (although, see below). There is no overhead if suppressions are
not provided. Otherwise there is extra overhead for symbolization.
Limitations:
1) sometimes suppressions need debug info / symbol table to function
properly (although sometimes frontend generates enough info to
do the match).
2) it's only possible to suppress recoverable UB kinds - if you've
built the code with -fno-sanitize-recover=undefined, suppressions
will not work.
3) categories are fine-grained check kinds, not groups like "undefined"
or "integer", so you can't write "undefined:file_with_ub.cc".
Reviewers: rsmith, kcc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15363
llvm-svn: 256018
Nico Weber