| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Like r367463, but for asan.
llvm-svn: 367558
|
|
|
|
|
|
|
|
|
| |
- Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap
- Adds unit tests for the new interceptors and expands HeapAlloc
tests to demonstrate new functionality.
Reviewed as D62927
llvm-svn: 365422
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Causes build failure on clang-ppc64be-linux-lnt:
compiler-rt/lib/asan/asan_malloc_win.cc:23:2: error: #error "Missing arch or unsupported platform for Windows."
#error "Missing arch or unsupported platform for Windows."
^~~~~
compiler-rt/lib/asan/asan_malloc_win.cc:25:10: fatal error: heapapi.h: No such file or directory
#include <heapapi.h>
^~~~~~~~~~~
compilation terminated.
[39/1151] Building CXX object projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_debugging.cc.o
[40/1151] Building CXX object projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o
FAILED: projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o
/usr/bin/c++ -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/compiler-rt/lib/asan -Icompiler-rt/lib/asan -Iinclude -I/home/buildbots/ppc64be-clang-lnt-test/clang-ppc64be-lnt/llvm/include -Icompiler-rt/lib/asan/.. -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -std=c++11 -Wno-unused-parameter -O2 -UNDEBUG -m64 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fvisibility=hidden -fno-lto -O3 -g -Wno-variadic-macros -Wno-non-virtual-dtor -fno-rtti -MD -MT projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o -MF projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o.d -o projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o -c compiler-rt/lib/asan/asan_malloc_win.cc
compiler-rt/lib/asan/asan_malloc_win.cc:23:2: error: #error "Missing arch or unsupported platform for Windows."
#error "Missing arch or unsupported platform for Windows."
^~~~~
compiler-rt/lib/asan/asan_malloc_win.cc:25:10: fatal error: heapapi.h: No such file or directory
#include <heapapi.h>
^~~~~~~~~~~
llvm-svn: 365384
|
|
|
|
|
|
|
|
|
| |
- Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap
- Adds unit tests for the new interceptors and expands HeapAlloc
tests to demonstrate new functionality.
Reviewed as D62927
llvm-svn: 365381
|
|
|
|
|
|
|
|
|
| |
We have windows.h in asan_win.cc, so we can just use the correct
prototypes for these EH-related interceptors without worrying.
Also fix an unused variable warning while I'm here.
llvm-svn: 359500
|
|
|
|
| |
llvm-svn: 359339
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a second attempt at r342652 using a TLS callback instead of an
interceptor.
In long-running builds we've seen some ASan complaints during thread creation
that we suspect are due to leftover poisoning from previous threads whose
stacks occupied that memory. This patch adds a callback that unpoisons the
stack memory when a thread exits.
Differential Revision: https://reviews.llvm.org/D58641
llvm-svn: 354836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`dlopen()`.
Summary:
The purpose of this option is provide a way for the ASan dylib
to be loaded via `dlopen()` without triggering most initialization
steps (e.g. shadow memory set up) that normally occur when the
ASan dylib is loaded.
This new functionality is exposed by
- A `SANITIZER_SUPPORTS_INIT_FOR_DLOPEN` macro which indicates if the
feature is supported. This only true for Darwin currently.
- A `HandleDlopenInit()` function which should return true if the library
is being loaded via `dlopen()` and
`SANITIZER_SUPPORTS_INIT_FOR_DLOPEN` is supported. Platforms that
support this may perform any initialization they wish inside this
function.
Although disabling initialization is something that could potentially
apply to other sanitizers it appears to be unnecessary for other
sanitizers so this patch only makes the change for ASan.
rdar://problem/45284065
Reviewers: kubamracek, george.karpenkov, kcc, eugenis, krytarowski
Subscribers: #sanitizers, llvm-commits
Differential Revision: https://reviews.llvm.org/D54469
llvm-svn: 348078
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts r343606 again. The NtTerminateThread interceptor is causing
problems in NaCl:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/CrWinAsan/1839
I reproduced the problem locally and tried my best to debug them, but
it's beyond me.
llvm-svn: 347933
|
|
|
|
|
|
|
|
|
| |
This change was reverted because it caused some nacl tests in chromium
to fail. I attempted to reproduce those problems locally, but I was
unable to. Let's reland this and let Chromium's test infrastructure
discover any problems.
llvm-svn: 346560
|
|
|
|
|
|
| |
This still seems to be causing pnacl + asan to crash.
llvm-svn: 343876
|
|
|
|
|
|
|
|
| |
In long-running builds we've seen some ASan complaints during thread creation that we suspect are due to leftover poisoning from previous threads whose stacks occupied that memory. This patch adds a hook that unpoisons the stack just before the NtTerminateThread syscall.
Differential Revision: https://reviews.llvm.org/D52091
llvm-svn: 343606
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seems to cause the thread's exit code to be clobbered, breaking
Chromium tests.
Also revert follow-up r342654.
> In long-running builds we've seen some ASan complaints during thread creation that we suspect are due to leftover poisoning from previous threads whose stacks occupied that memory. This patch adds a hook that unpoisons the stack just before the NtTerminateThread syscall.
>
> Differential Revision: https://reviews.llvm.org/D52091
llvm-svn: 343322
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D52505
llvm-svn: 343123
|
|
|
|
|
|
|
|
| |
In long-running builds we've seen some ASan complaints during thread creation that we suspect are due to leftover poisoning from previous threads whose stacks occupied that memory. This patch adds a hook that unpoisons the stack just before the NtTerminateThread syscall.
Differential Revision: https://reviews.llvm.org/D52091
llvm-svn: 342652
|
|
|
|
|
|
|
|
| |
We don't use the result of the query, and all tests pass if I remove it.
During startup, ASan spends a fair amount of time in this handler, and
the query is much more expensive than the call to commit the memory.
llvm-svn: 333595
|
|
|
|
|
|
| |
argument.
llvm-svn: 326111
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: eugenis, alekseyshl
Subscribers: kubamracek, dberris
Differential Revision: https://reviews.llvm.org/D37827
llvm-svn: 313223
|
|
|
|
| |
llvm-svn: 313177
|
|
|
|
|
|
|
|
|
|
| |
On iOS/AArch64, the address space is very limited and has a dynamic maximum address based on the configuration of the device. We're already using a dynamic shadow, and we find a large-enough "gap" in the VM where we place the shadow memory. In some cases and some device configuration, we might not be able to find a large-enough gap: E.g. if the main executable is linked against a large number of libraries that are not part of the system, these libraries can fragment the address space, and this happens before ASan starts initializing.
This patch has a solution, where we have a "backup plan" when we cannot find a large-enough gap: We will restrict the address space (via MmapFixedNoAccess) to a limit, for which the shadow limit will fit.
Differential Revision: https://reviews.llvm.org/D35098
llvm-svn: 307865
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This flags is not covered by tests on Windows and looks like it's implemented
incorrectly. Switching its default breaks some tests.
Taking into account that related handle_segv flag is not supported on Windows
it's safer to remove it until we commit to support it.
Reviewers: eugenis, zturner, rnk
Subscribers: kubamracek, llvm-commits
Differential Revision: https://reviews.llvm.org/D33471
llvm-svn: 303728
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: On windows 10, the ucrt DLL is performing allocations before the function hooking and there are multiple allocations not handled by Asan. When a free occur at the end of the process, asan is reporting desallocations not malloc-ed.
Reviewers: rnk, kcc
Reviewed By: rnk, kcc
Subscribers: kcc, llvm-commits, kubamracek, chrisha, dberris
Differential Revision: https://reviews.llvm.org/D25946
llvm-svn: 295730
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this diff I update the code for asan on Windows, so we can intercept
SetUnhandledExceptionFilter and catch some exceptions depending on the result of
IsHandledDeadlyException() (which depends on asan flags).
This way we have the same behavior on Windows and Posix systems.
On Posix, we intercept signal and sigaction, so user's code can only register
signal handlers for signals that are not handled by asan.
After this diff, the same happens on Windows, user's code can only register
exception handlers for exceptions that are not handled by asan.
Differential Revision: https://reviews.llvm.org/D29463
llvm-svn: 293957
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29459
llvm-svn: 293956
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29458
llvm-svn: 293955
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29457
llvm-svn: 293954
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 291089
|
|
|
|
| |
llvm-svn: 291077
|
|
|
|
| |
llvm-svn: 291076
|
|
|
|
| |
llvm-svn: 291071
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The expectation is that new instrumented code will add global variable
metadata to the .ASAN$GL section, and we will use this new code to
iterate over it.
This technique seems to break when using incremental linking, which
seems to align every global to a 256 byte boundary. Presumably this is
so that it can incrementally cope with global changing size. Clang
already passes -incremental:no as a linker flag when you invoke it to do
the link step.
The two tests added for this feature will fail until the LLVM
instrumentation change in D26770 lands, so they are marked XFAIL for
now.
Reviewers: pcc, kcc, mehdi_amini, kubabrecka
Subscribers: llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D26771
llvm-svn: 287246
|
|
|
|
|
|
|
|
|
|
|
| |
Users often have their own unhandled exception filters installed. ASan
already goes to great lengths to install its own filter, but our core
wars with Chrome crashpad have escalated to the point that its time to
declare a truce. By exposing this hook, they can call us directly when
they want ASan crash reporting without worrying about who initializes
when.
llvm-svn: 287040
|
|
|
|
| |
llvm-svn: 286346
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
User applications may register hooks in the .CRT$XL* callback list,
which is called very early by the loader. This is very common in
Chromium:
https://cs.chromium.org/search/?q=CRT.XL&sq=package:chromium&type=cs
This has flown under the radar for a long time because the loader
appears to catch exceptions originating from these callbacks. It's a
real problem when you're debugging an asan application, though, since it
makes the program crash early.
The solution is to add our own callback to this list, and sort it very
early in the list like we do elsewhere. Also add a test with such an
instrumented callback, and test that it gets called with asan.
Reviewers: etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D26404
llvm-svn: 286290
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Don't list __sanitizer_print_memory profile as an INTERFACE_FUNCTION. It
is not exported by ASan; it is exported by user code.
Move the weak definition from asan_win.cc to sanitizer_win.cc to fix the
ubsan tests.
llvm-svn: 281619
|
|
|
|
| |
llvm-svn: 281558
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Keep reifying other errors.
Reviewers: kcc, samsonov
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23873
llvm-svn: 280930
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We are going to use store instructions to poison some allocas.
Runtime flag will require branching in instrumented code on every lifetime
intrinsic. We'd like to avoid that.
Reviewers: eugenis
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23967
llvm-svn: 279981
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Go back to intercepting kernel32!RaiseException, and only go for
ntdll!RtlRaiseException if that fails. Fixes throw_and_catch.cc test.
Work around an issue in LLVM's win64 epilogues. We end up with an
epilogue that looks like this, and it drives the Win64 unwinder crazy
until stack overflow:
call ill_cc!__asan_handle_no_return
xor eax,eax
add rsp,40h // epilogue starts
pop rbp // CSR
ud2 // Trap here
ret // Ret?
nop word ptr [rax+rax]
sub rsp,28h // Next function
Will file a PR soon.
llvm-svn: 277874
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
RtlRaiseException
Our Report implementation calls OutputDebugString, which calls
RtlRaiseException, which can re-enter back into the ASan runtime and
cause a hang.
Don't treat this special debugger-only exception code as a noreturn
event, since the stack won't really unwind all the way.
llvm-svn: 277763
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Respect the handle_sigill common flag and handle_segv flags while we're
at it.
We still handle signals/exceptions differently on Unix and Windows. The
installation process is tricky on Windows, and difficult to push down
into sanitizer_common without concerning it with the different
static/dynamic CRT models on Windows.
Reviewers: kcc, etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23098
llvm-svn: 277621
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On my install of Windows 10, RaiseException is a tail call to
kernelbase!RaiseException. Obviously, we fail to intercept that.
Instead, try hooking at the ntdll!RtlRaiseException layer. It is
unlikely that this layer will contain control flow.
Intercepting at this level requires adding a decoding for
'LEA ESP, [ESP + 0xXXXXXXXX]', which is a really obscure way to write
'SUB ESP, 0xXXXXXXXX' that avoids clobbering EFLAGS.
Reviewers: etienneb
Subscribers: llvm-commits, kubabrecka
Differential Revision: https://reviews.llvm.org/D23046
llvm-svn: 277518
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
On Windows 10, this gets called after TLS has been torn down from NTDLL,
and we crash attempting to return fake_tsd. This interceptor isn't
needed after r242948 anyway, so let's remove it. The ASan runtime can
now tolerate unregistered threads calling __asan_handle_no_return.
Reviewers: vitalybuka, etienneb
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D23044
llvm-svn: 277478
|
|
|
|
| |
llvm-svn: 277345
|
|
|
|
|
|
| |
Also remove the needless static that was using them.
llvm-svn: 276327
|
|
|
|
|
|
|
|
|
|
| |
Make kStderrFd a macro to avoid dynamic initialization of the
report_file global. This actually causes a crash at runtime, because
ASan initializes before static initializers run.
Remove an unused variable in asan_win.cc.
llvm-svn: 276314
|