| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Testing and asan leak detection are disabled by default.
Reviewers: kubamracek, kcc
Subscribers: srhines, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D31307
llvm-svn: 299669
|
|
|
|
| |
llvm-svn: 299632
|
|
|
|
| |
llvm-svn: 299631
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch addresses two issues:
* It turned out that suspended thread may have dtls->dtv_size == kDestroyedThread (-1)
and LSan wrongly assumes that DTV is available. This leads to SEGV when LSan tries to
iterate through DTV that is invalid.
* In some rare cases GetRegistersAndSP can fail with errno 3 (ESRCH). In this case LSan
assumes that the whole stack of a given thread is available. This is wrong because ESRCH
can indicate that suspended thread was destroyed and its stack was unmapped. This patch
properly handles ESRCH from GetRegistersAndSP in order to avoid invalid accesses to already
unpapped threads stack.
Differential Revision: https://reviews.llvm.org/D30818
llvm-svn: 299630
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is already assumed by the test suite, and by
asan_flags.cc.
Reviewers: m.ostapenko, vitalybuka, kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D31462
llvm-svn: 299082
|
|
|
|
|
|
|
|
| |
{M, T, E}San have fread and fwrite interceptors, let's move them to sanitizer_common to enable ASan checks as well.
Differential Revision: https://reviews.llvm.org/D31456
llvm-svn: 299061
|
|
|
|
|
|
| |
(https://reviews.llvm.org/D31332, patch by Martin Liška)
llvm-svn: 299036
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now that __thread is no longer used for lsan on darwin, i386 builds
can be enabled.
Reviewers: kcc, kubamracek
Subscribers: danalbert, srhines, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29995
llvm-svn: 298946
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several problems with the current annotations (AnnotateRWLockCreate and friends):
- they don't fully support deadlock detection (we need a hook _before_ mutex lock)
- they don't support insertion of random artificial delays to perturb execution (again we need a hook _before_ mutex lock)
- they don't support setting extended mutex attributes like read/write reentrancy (only "linker init" was bolted on)
- they don't support setting mutex attributes if a mutex don't have a "constructor" (e.g. static, Java, Go mutexes)
- they don't ignore synchronization inside of lock/unlock operations which leads to slowdown and false negatives
The new annotations solve of the above problems. See tsan_interface.h for the interface specification and comments.
Reviewed in https://reviews.llvm.org/D31093
llvm-svn: 298809
|
|
|
|
| |
llvm-svn: 298684
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change addresses https://github.com/google/sanitizers/issues/766. I
tested the change with make check-asan and the newly added test case.
Reviewers: ygribov, kcc, alekseyshl
Subscribers: kubamracek, llvm-commits
Patch by mrigger
Differential Revision: https://reviews.llvm.org/D30384
llvm-svn: 298650
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
sysconf(_SC_PAGESIZE) is called very early during sanitizer init and
any instrumented code (sysconf() wrapper/interceptor will likely be
instrumented) calling back to sanitizer before init is done will
most surely crash.
2nd attempt, now with glibc version checks (D31092 was reverted).
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D31221
llvm-svn: 298613
|
|
|
|
|
|
|
|
| |
Bot can't find <sys/auxv.h>
This reverts commit r298305.
llvm-svn: 298343
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
sysconf(_SC_PAGESIZE) is called very early, during sanitizer init and
any instrumented code (a wrapper/interceptor will likely be instrumented)
calling back to sanitizer before init is done will most surely crash.
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D31092
llvm-svn: 298305
|
|
|
|
|
|
|
| |
This broke GreenDragon:
http://lab.llvm.org:8080/green/job/clang-stage1-configure-RA_check/29210/
llvm-svn: 298029
|
|
|
|
|
|
|
|
|
| |
This fixes many sanitizer problems with -m32. It is really intended
for gcc but patches to the sanitizers make their way through llvm
first.
ref: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00855.html
llvm-svn: 297995
|
|
|
|
| |
llvm-svn: 297924
|
|
|
|
| |
llvm-svn: 297923
|
|
|
|
|
|
| |
redundant weak definition.
llvm-svn: 297914
|
|
|
|
|
|
|
|
| |
check for the existence of RTLD_DEEPBIND, since this constant is only
supported for glibc >= 2.3.4. This fixes builds for FreeBSD and other
platforms that do not have RTLD_DEEPBIND.
llvm-svn: 297763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
not the other.
Summary: This is useful in some platforms where one of these signals is special.
Reviewers: kubamracek, kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D30783
llvm-svn: 297665
|
|
|
|
| |
llvm-svn: 297383
|
|
|
|
|
|
|
|
|
|
|
|
| |
RTLD_DEEPBIND flag
People keep hitting on spurious failures in malloc/free routines when using sanitizers
with shared libraries dlopened with RTLD_DEEPBIND (see https://github.com/google/sanitizers/issues/611 for details).
Let's check for this flag and bail out with warning message instead of failing in random places.
Differential Revision: https://reviews.llvm.org/D30504
llvm-svn: 297370
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two possible return values for strerror_r:
On OS X, the return value is always `int`.
On Linux, the return value can be either `char *` or `int`, depending
on the value of:
`(_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && ! _GNU_SOURCE`
Because OS X interceptors require a matching function signature,
split out the two cases into separate interceptors, using the above
information to determine the correct signature for a given build.
llvm-svn: 297315
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If symbolizer was instrumented with sanitizer and crash, it may
try to call itself again causing infinite recursion of crashing processes.
Reviewers: eugenis
Subscribers: kubamracek, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D30222
llvm-svn: 295771
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The DLL thunks are stubs added to an instrumented DLL to redirect ASAN API calls
to the real ones in the main executable. These thunks must contain dummy
code before __asan_init got called. Unfortunately, MSVC linker is doing ICF and is
merging functions with the same body.
In our case, this two ASAN thunks were incorrectly merged:
```
asan_interface.inc:16
INTERFACE_FUNCTION(__asan_before_dynamic_init)
```
```
sanitizer_common_interface.inc:16
INTERFACE_FUNCTION(__sanitizer_verify_contiguous_container)
```
The same thunk got patched twice. After the second patching, calls to
`__asan_before_dynamic_init` are redirected to `__sanitizer_verify_contiguous_container`
and trigger a DCHECK on incorrect operands/
The problem was caused by the macro that is only using __LINE__ to prevent
collapsing code.
```
#define INTERCEPT_SANITIZER_FUNCTION(name)
extern "C" __declspec(noinline) void name() {
volatile int prevent_icf = (__LINE__ << 8); (void)prevent_icf;
```
The current patch is adding __COUNTER__ which is safer than __LINE__.
Also, to precent ICF (guarantee that code is different), we are using a unique attribute:
- the name of the function
Reviewers: rnk
Reviewed By: rnk
Subscribers: llvm-commits, kubamracek, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D30219
llvm-svn: 295761
|
|
|
|
|
|
| |
can be accessed after the static destroyed.
llvm-svn: 295348
|
|
|
|
| |
llvm-svn: 295299
|
|
|
|
|
|
| |
It's needed if libcxx is build without disabling threads.
llvm-svn: 295296
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis
Subscribers: llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D30013
llvm-svn: 295272
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Coverage is using large arrays which requires large allocations.
These allocations are flaky and often failing on win64.
We are using the 32-bits size until this gets a better fix.
Reviewers: rnk
Reviewed By: rnk
Subscribers: llvm-commits, kubamracek, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D29945
llvm-svn: 295086
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Fixes build issues when compiling lsan for darwin.
Reviewers: kubamracek, kcc, rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29785
llvm-svn: 294984
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch provides stubs for all of the lsan platform-specific
functions which need to be implemented for darwin. Currently
all of these functions are stubs, for the purpose of fixing
compilation.
Reviewers: kcc, glider, kubamracek
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D29784
llvm-svn: 294983
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27405
llvm-svn: 294880
|
|
|
|
|
|
| |
This is part of https://reviews.llvm.org/D27405
llvm-svn: 294812
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Since struct rtentry is an internal kernel-only structure on FreeBSD,
and SIOCADDRT and SIOCDELRT are not supported anyway, stop including
socketvar.h and attempting to get at the definition of struct rtentry,
and move the line with struct_rtentry_sz to the SANIZER_LINUX block.
Reviewers: kcc, kutuzov.viktor.84, emaste
Reviewed By: kcc, emaste
Subscribers: emaste, llvm-commits, kubamracek
Differential Revision: https://reviews.llvm.org/D29832
llvm-svn: 294806
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch adds whitelist for RHEL6 and RHEL7 kernels that are known to have the CVE fixed.
Reviewers: koriakin, kcc
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29825
llvm-svn: 294799
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
GET_CALLER_PC doesn't work properly on 31-bit s390, as pointers are 31-bit, the MSB bit can be set when the return address is copied into integer.
This causes e.g. errors like:
#0 0xfdadb129 (<unknown module>)
#1 0x7da5e1d1 in __asan::GetStackTraceWithPcBpAndContext(__sanitizer::BufferedStackTrace*, unsigned long, unsigned long, unsigned long, void*, bool) ../../../../../libsanitizer/asan/asan_stack.h:50
#2 0x7da5e1d1 in __asan::ErrorGeneric::Print() ../../../../../libsanitizer/asan/asan_errors.cc:482
#3 0x7db178d5 in __asan::ErrorDescription::Print() ../../../../../libsanitizer/asan/asan_errors.h:360
#4 0x7db178d5 in __asan::ScopedInErrorReport::~ScopedInErrorReport() ../../../../../libsanitizer/asan/asan_report.cc:167
#5 0x7db178d5 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) ../../../../../libsanitizer/asan/asan_report.cc:397
#6 0x7dadb14f in __interceptor_memcmp ../../../../../libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:626
#7 0x400cf5 in main /home/jakub/gcc/gcc/testsuite/c-c++-common/asan/memcmp-1.c:14
#8 0x7d807215 in __libc_start_main (/lib/libc.so.6+0x1a215)
#9 0x4007ed (/home/jakub/gcc/obj/gcc/testsuite/memcmp-1.exe+0x4007ed)
The actual return PC inside __interceptor_memcmp was 0x7dadb129 rather than 0xfdadb129.
Reviewers: koriakin, kcc
Reviewed By: kcc
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29824
llvm-svn: 294793
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Symbol __tls_get_addr_internal is a GLIBC_PRIVATE private symbol on s390{,x}, the glibc folks aren't very happy about asan using it.
Additionally, only recent glibc versions have it, older versions just have __tls_get_offset and nothing else.
The patch doesn't drop the __tls_get_addr_internal interception altogether, but changes it so that it calls real __tls_get_offset function instead (and much more importantly,
that __tls_get_offset interception calls the real __tls_get_offset function).
This way it should work also on glibc 2.18 and earlier. See http://gcc.gnu.org/PR79341 for further details.
Reviewers: kcc, koriakin
Reviewed By: kcc, koriakin
Subscribers: kubamracek, mehdi_amini
Tags: #sanitizers
Differential Revision: https://reviews.llvm.org/D29735
llvm-svn: 294790
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch unifies the behavior of BlockingMutex on linux and mac,
resolving problems that can arise when BlockingMutex is used in
code shared by the two platforms but has different behavior depending
on the platform.
No longer requires that the calling thread own the mutex for
CheckLocked calls to pass.
Reviewers: dvyukov, kubamracek
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29728
llvm-svn: 294614
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building for Windows, we would check if we were using MSVC rather
than WIN32. This resulted in needed targets not being defined by
sanitizer_common. Fix the conditional.
When registering the objects libraries for ASAN, we would multiply
register for all targets as we were creating them inside a loop over all
architectures. Only define the target per architecture.
llvm-svn: 294510
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: lib/sanitizer_common/sanitizer_win_defs.h defineds WINAPI, which is also defined by standard Windows headers. Redefining it causes warnings during compilation. This change causes us to only define WINAPI if it is not already defined, which avoids the warnings.
Reviewers: rnk, zturner, mpividori
Reviewed By: rnk, mpividori
Subscribers: kubamracek
Differential Revision: https://reviews.llvm.org/D29683
llvm-svn: 294497
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for weak hooks on Windows, as we do on Linux and Darwin.
As we use the macro: `SANITIZER_INTERFACE_WEAK_DEF()` it was not necessary to
modify the header file: `sanitizer_common_interceptors.h`.
After this diff, many tests were fixed for libFuzzer.
Differential Revision: https://reviews.llvm.org/D29562
llvm-svn: 294409
|
|
|
|
|
|
| |
std::random_shuffle is being deprecated in C++17; NFC
llvm-svn: 294370
|
|
|
|
|
|
|
|
| |
Or bogus filename like "b'foo'" would be generated.
This is part of https://reviews.llvm.org/D27405
llvm-svn: 294307
|
|
|
|
|
|
|
|
| |
Py3 emits float with '/'.
This is part of https://reviews.llvm.org/D27405
llvm-svn: 294306
|
|
|
|
|
|
|
|
|
| |
This patch tries to fixes sanitizer linkage errors on Darwin 10.6 originally reporded
in GCC's pr78663 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663).
Differential Revision: https://reviews.llvm.org/D29287
llvm-svn: 293992
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, the symbols "___stop___sancov_guards" and "___start___sancov_guards"
are not defined automatically. So, we need to take a different approach.
We define 3 sections: ".SCOV$A", ".SCOV$M" and ".SCOV$Z".
Section ".SCOV$A" will only hold a variable ___start___sancov_guard.
Section ".SCOV$M" will hold the main data.
Section ".SCOV$Z" will only hold a variable ___stop___sancov_guards.
When linking, they will be merged sorted by the characters after the $, so we
can use the pointers of the variables ___[start|stop]___sancov_guard to know the
actual range of addresses of that section.
___[start|stop]___sancov_guard should be defined only once per module. On
Windows, we have 2 different cases:
+ When considering a shared runtime:
All the modules, main executable and dlls, are linked to an auxiliary static
library dynamic_runtime_thunk.lib. Because of that, we include the delimiters
in `SancovDynamicRuntimeThunk`.
+ When considering a static runtime:
The main executable in linked to the static runtime library.
All the dlls are linked to an auxiliary static library dll_thunk.
Because of that, we include the delimiter to both `SancovDllThunk` and
`SANITIZER_LIBCDEP_SOURCES` (which is included in the static runtime lib).
Differential Revision: https://reviews.llvm.org/D28435
llvm-svn: 293959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29459
llvm-svn: 293956
|