Used uptr for __sanitizer_kernel_sigset_t.sig to avoid byte order issues on big endian systems
Reviewd by bruening.
Differential: D24332
llvm-svn: 283438
The VM layout is not stable between iOS version releases, so switch to dynamic shadow offset.
Differential Revision: https://reviews.llvm.org/D25218
llvm-svn: 283375
The VM layout is not stable between iOS version releases, so switch to dynamic shadow offset.
Differential Revision: https://reviews.llvm.org/D25218
llvm-svn: 283240
Summary:
Handles early allocation from dlsym by allocating memory from a local
static buffer.
Reviewers: bruening
Subscribers: kubabrecka
Differential Revision: https://reviews.llvm.org/D25193
llvm-svn: 283139
Summary:
s/CHECK_LT/CHECK_LE/ in the secondary allocator, as under certain circumstances
Ptr + Size can be equal to MapEnd. This edge case was not found by the current
tests, so those were extended to be able to catch that.
Reviewers: kcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25101
llvm-svn: 282913
Summary:
The check-asan-dynamic tests were broken on win10 because the interception
library was not able to hook on some functions.
credits: thanks sebastian marchand to help debugging this on win10.
Reviewers: rnk
Subscribers: chrisha, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D25120
llvm-svn: 282904
Summary:
This patch is adding support for dynamic shadow allocation.
This is a merge and re-commit of the following patches.
```
[compiler-rt] Fix Asan build on Android
https://reviews.llvm.org/D24768
[compiler-rt] Add support for the dynamic shadow allocation
https://reviews.llvm.org/D23363
```
This patch needed to re-land at the same time:
```
[asan] Support dynamic shadow address instrumentation
https://reviews.llvm.org/D23354
```
Reviewers: rnk, zaks.anna
Subscribers: tberghammer, danalbert, kubabrecka, dberris, chrisha, llvm-commits
Differential Revision: https://reviews.llvm.org/D25104
llvm-svn: 282882
Summary:
The MSVC compiler is generating multiple instance of the exception handler
when compiling on win64 with /MD.
see: https://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx
Two tests were failing when running:
```
ninja check-asan-dynamic.
```
The tests were failing because only the first occurence of the function was patched.
The function `__C_specific_handler` is defined in `ntdll` and `vcruntime140`.
After this patch, there is still two remaining tests failing.
```
********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 87.81s
********************
Failing Tests (2):
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memchr.cc
AddressSanitizer-x86_64-windows-dynamic :: TestCases/Windows/dll_intercept_memcpy_indirect.cc
Expected Passes : 342
Passes With Retry : 2
Expected Failures : 16
Unsupported Tests : 152
Unexpected Failures: 2
```
Reviewers: rnk, vitalybuka
Subscribers: vitalybuka, llvm-commits, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D24983
llvm-svn: 282614
This patch extends __sanitizer_finish_switch_fiber method to optionally return previous stack base and size.
This solves the problem of coroutines/fibers library not knowing the original stack context from which the library is used. It's incorrect to assume that such context is always the default stack of current thread (e.g. one such library may be used from a fiber/coroutine created by another library). Bulding a separate stack tracking mechanism would not only duplicate AsanThread, but also require each coroutines/fibers library to integrate with it.
Author: Andrii Grynenko (andriigrynenko)
Reviewed in: https://reviews.llvm.org/D24628
llvm-svn: 282582
This is a follow up to r282152.
A more extensive testing on real apps revealed a subtle bug in r282152.
The revision made shadow mapping non-linear even within a single
user region. But there are lots of code in runtime that processes
memory ranges and assumes that mapping is linear. For example,
region memory access handling simply increments shadow address
to advance to the next shadow cell group. Similarly, DontNeedShadowFor,
java memory mover, search of heap memory block header, etc
make similar assumptions.
To trigger the bug user range would need to cross 0x008000000000 boundary.
This was observed for a module data section.
Make shadow mapping linear within a single user range again.
Add a startup CHECK for linearity.
llvm-svn: 282405
Don't xor user address with kAppMemXor in meta mapping.
The only purpose of kAppMemXor is to raise shadow for ~0 user addresses,
so that they don't map to ~0 (which would cause overlap between
user memory and shadow).
For meta mapping we explicitly add kMetaShadowBeg offset,
so we don't need to additionally raise meta shadow.
llvm-svn: 282403
It's wrong to pass to MsanReallocate a pointer that MSan allocator doesn't own.
Use nullptr instead of ptr to prevent possible (still unlikely) failure.
llvm-svn: 282390
This reverts commit r282294. It breaks a Linux bot:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/12180
It looks like the test checks that __llvm_profile_set_filename() alters the raw
profile filename in both the dylib and the main program. Now that
lprofCurFilename is hidden, this can't work, and we get two profiles (one for
the call to "main" and one for "func").
Back this change out so that we don't affect external users.
llvm-svn: 282304
On Darwin, -lm, -pthread and others are implied. -pthread currently produces a warning (compiler option unused).
Differential Revision: https://reviews.llvm.org/D24698
llvm-svn: 282260
Summary:
Window compiler is stricter for attributes location. This patch fixes a compilation error.
```
D:\src\llvm\llvm\projects\compiler-rt\lib\lsan\lsan_thread.cc(39): error C2144: syntax error: 'int' should be preceded by ';'
```
Reviewers: rnk, majnemer
Subscribers: majnemer, llvm-commits, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D24810
llvm-svn: 282254
In ShadowToMem we call MemToShadow potentially for incorrect addresses.
So DCHECK(IsAppMem(p)) can fire in debug mode.
Fix this by swapping range and MemToShadow checks.
llvm-svn: 282157
4.1+ Linux kernels map pie binaries at 0x55:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90
Currently tsan does not support app memory at 0x55 (https://github.com/google/sanitizers/issues/503).
Older kernels also map pie binaries at 0x55 when ASLR is disables (most notably under gdb).
This change extends tsan mapping for linux/x86_64 to cover 0x554-0x568 app range and fixes both 4.1+ kernels and gdb.
This required to slightly shrink low and high app ranges and move heap. The mapping become even more non-linear, since now we xor lower bits. Now even a continuous app range maps to split, intermixed shadow ranges. This breaks ShadowToMemImpl as it assumes linear mapping at least within a continuous app range (however it turned out to be already broken at least on arm64/42-bit vma as uncovered by r281970). So also change ShadowToMemImpl to hopefully a more robust implementation that does not assume a linear mapping.
llvm-svn: 282152
For mips assember '#' is the start of comment. We get assembler error messages if # is used in the struct names. Therefore using '$' which works for all architectures.
Differential: D24335
Reviewed by: zhaoqin
llvm-svn: 282142
Summary:
Finish work on PR30351 (last one, after D24551, D24552, and D24554 land)
Also replace the old ReportData structure/variable with the current_error_ static
member of the ScopedInErrorReport class.
This has the following side-effects:
- Move ASAN_ON_ERROR(); call to the start of the destructor, instead
of in StartReporting().
- We only generate the error structure after the
ScopedInErrorReport constructor finishes, so we can't call
ASAN_ON_ERROR() during the constructor. I think this makes more
sense, since we end up never running two of the ASAN_ON_ERROR()
callback. This also works the same way as error reporting, since
we end up having a lock around it. Otherwise we could end up
with the ASAN_ON_ERROR() call for error 1, then the
ASAN_ON_ERROR() call for error 2, and then lock the mutex for
reporting error 1.
- The __asan_get_report_* functions will be able to, in the future,
provide information about other errors that aren't a "generic
error". But we might want to rethink that API, since it's too
restricted. Ideally we teach lldb about the current_error_ member of
ScopedInErrorReport.
Reviewers: vitalybuka, kcc, eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D24555
llvm-svn: 282107
Reid Kleckner