summaryrefslogtreecommitdiff
path: root/lib/asan/asan_globals.cc
AgeCommit message (Collapse)Author
2017-09-28[asan] Unpoison global metadata on dlclose.Benjamin Kramer
dlclose itself might touch it, so better return it to the state it was before. I don't know how to create a test for this as it would require chaning dlclose itself. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314415 91177308-0d34-0410-b5e6-96231b3b80d8
2017-09-27ASan allocates a global data initialization array at the tail end of eachDmitry Mikulin
compunit's .data section. This vector is not poisoned. Because of this the first symbol of the following section has no left red zone. As a result, ASan cannot detect underflow for such symbols. Poison ASan allocated metadata, it should not be accessible to user code. This fix does not eliminate the problem with missing left red zones but it reduces the set of vulnerable symbols from first symbols in each input data section to first symbols in the output section of the binary. Differential Revision: https://reviews.llvm.org/D38056 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@314365 91177308-0d34-0410-b5e6-96231b3b80d8
2017-04-27[asan] Fix dead stripping of globals on Linux (compiler-rt).Evgeniy Stepanov
Third attempt. See the description of the corresponding commit in LLVM for more details. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@301588 91177308-0d34-0410-b5e6-96231b3b80d8
2017-04-10Revert "[asan] Fix dead stripping of globals on Linux (compiler-rt)."Evgeniy Stepanov
This reverts r299698, which caused a big increase in object file size. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@299881 91177308-0d34-0410-b5e6-96231b3b80d8
2017-04-06[asan] Fix dead stripping of globals on Linux (compiler-rt).Evgeniy Stepanov
This is a re-land of r298173, r298169, r298159. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@299698 91177308-0d34-0410-b5e6-96231b3b80d8
2017-03-20Revert r298174, r298173, r298169, r298159.Evgeniy Stepanov
Revert "Fix sanitizer tests with LLVM_TOOL_LLD_BUILD=OFF." Revert "[asan] Remove gc-sections test with bfd." Revert "[asan] Disable globals-gc test with ld.bfd." Revert "[asan] Fix dead stripping of globals on Linux (compiler-rt)" OOM in gold linker. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@298287 91177308-0d34-0410-b5e6-96231b3b80d8
2017-03-17[asan] Fix dead stripping of globals on Linux (compiler-rt)Evgeniy Stepanov
Runtime support for the new instrumentation of globals based on !associated, and a bunch of tests. Differential Revision: https://reviews.llvm.org/D30120 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@298159 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-23[asan/win] Skip incremental linker padding during unregistrationReid Kleckner
Should fix issues that came up while testing Win64 ASan. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@287791 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-23[asan/win] Fix incremental linking vs. global registrationReid Kleckner
The MSVC incremental linker pads every global out to 256 bytes in case it changes size after an incremental link. So, skip over null entries in the DSO-wide asan globals array. This only works if the global padding size is divisible by the size of the asan global object, so add some defensive CHECKs. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@287780 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-17[asan] Create a .ASAN$G(A-Z) section for global registrationReid Kleckner
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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@287246 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-05asan: allow __asan_{before,after}_dynamic_init without registered globalsDmitry Vyukov
When optimizing, GCC optimizes away aggressively unused static globals. The __asan_before_dynamic_init/__asan_after_dynamic_init calls are placed in static constructor earlier while the registration of the globals is done later in the compilation process. If all the globals with dynamic initialization are optimized away from some particular TU in between those two, libasan can fail on an assertion that dynamic_init_globals is empty. While I'm going to commit a GCC change which will remove the __asan_before_dynamic_init/__asan_after_dynamic_init in many cases when this happens (basically if the optimizers can prove there are no memory references in between the two calls), there are still testcases where such pair of calls is left, e.g. for struct S { S () { asm volatile ("" : : : "memory"); } }; static S c; int main () { return 0; } with -O2 -fsanitize=address and ASAN_OPTIONS=check_initialization_order=true this still fails the assertion. Trying to avoid this problem on the compiler side would decrease code quality I'm afraid, whether it is making sure for -fsanitize=address we keep around at least one dynamically initialized global if the __asan_before_dynamic_init/__asan_after_dynamic_init pair has been emitted, or adding some artificial global which would be used as the condition for those calls etc. So, can the assertion be instead just removed, this really shouldn't slow down the calls measurably (for __asan_before_dynamic_init it is even cheaper) and the assertion doesn't check something worthwhile anyway (it is sufficient if there is a single dynamically initialized global in any other TU to make it happy). Details in http://gcc.gnu.org/PR77396 Author: Jakub Jelinek git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@280657 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-17Split DescribeAddressIfGlobal between a function that gets all the ↵Filipe Cabecinhas
information, and one that prints it. Summary: Replacement for part of D23518 This deals with global variable addresses. (This commit is written on top of D23605, but can be applied by itself) Reviewers: kcc, samsonov Subscribers: kubabrecka, llvm-commits Differential Revision: https://reviews.llvm.org/D23607 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@278959 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-28[asan] Add runtime support for __asan_(un)register_image_globalsRyan Govostes
This change introduces routines that register and unregister all instrumented globals in a loaded executable image. These routines are only implemented on Darwin, where globals metadata is expected to be placed in the __DATA,__asan_globals section. Review: http://reviews.llvm.org/D16841 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@264644 91177308-0d34-0410-b5e6-96231b3b80d8
2016-03-22Test commit to verify repository access and fix a typo.Derek Bruening
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@264112 91177308-0d34-0410-b5e6-96231b3b80d8
2016-02-08[asan] Introduce new approach for ODR violation detection based on odr ↵Maxim Ostapenko
indicator symbols. This is a compiler-rt part of this http://reviews.llvm.org/D15642 patch. Here, we add a new approach for ODR violation detection. Instead of using __asan_region_is_poisoned(g->beg, g->size_with_redzone) on global address (that would return false now due to using private alias), we can use new globally visible indicator symbol to perform the check. Differential Revision: http://reviews.llvm.org/D15644 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@260076 91177308-0d34-0410-b5e6-96231b3b80d8
2016-02-06[asan] properly report an un-aligned global variable instead of just crashingKostya Serebryany
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@259979 91177308-0d34-0410-b5e6-96231b3b80d8
2015-10-01[compiler-rt] Apply modernize-use-nullptr fixes in sanitizersVedant Kumar
- Trim spaces. - Use nullptr in place of 0 for pointer variables. - Use '!p' in place of 'p == 0' for null pointer checks. - Add blank lines to separate function definitions. - Add 'extern "C"' or 'namespace foo' comments after the appropriate closing brackets This is a continuation of work from 409b7b82. The focus here is on the various sanitizers (not sanitizer_common, as before). Patch by Eugene Zelenko! Differential Revision: http://reviews.llvm.org/D13225 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@248966 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-22[ASan] Print global registration site in init-order-checker reports.Alexey Samsonov
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@235540 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-22[ASan] Refactor functions searching/describing globals. NFC.Alexey Samsonov
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@235539 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-02[ASan/Win] Work around PR22545: call LLVM global_dtors in the MD atexit()Timur Iskhodzhanov
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@231000 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-25[asan] add suppressions for odr violationsKostya Serebryany
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@230409 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-23[asan] when registering globals, use the same unwinder as we use for malloc, ↵Kostya Serebryany
instead of the one used for FATAL crash (which may be too slow) git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@230256 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-20[ASan/Win] Work around PR22545 - unregister globals when using the MD runtimeTimur Iskhodzhanov
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@230018 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-11[ASan] Print out a diagnostic when a global is unregisteredTimur Iskhodzhanov
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@228838 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-17[ASan] Introduce SetCanPoisonMemory() function.Alexey Samsonov
SetCanPoisonMemory()/CanPoisonMemory() functions are now used instead of "poison_heap" flag to determine if ASan is allowed to poison the shadow memory. This allows to hot-patch this value in runtime (e.g. during ASan activation) without introducing a data race. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@224395 91177308-0d34-0410-b5e6-96231b3b80d8
2014-10-26Change StackDepot interface to use StackTrace more extensivelyAlexey Samsonov
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@220637 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-26[compiler-rt] recommit of r218481: ASan debugging API for report info ↵Kuba Brecka
extraction and locating addresses Reviewed at http://reviews.llvm.org/D4527 Fixed a test case failure on 32-bit Linux, I did right shift on intptr_t, instead it should have been uintptr_t. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@218538 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-26[compiler-rt] revert r218481 due to test failure on sanitizer-x86_64-linux Kuba Brecka
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@218501 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-25[compiler-rt] ASan debugging API for report info extraction and locating ↵Kuba Brecka
addresses Reviewed at http://reviews.llvm.org/D4527 This patch is part of an effort to implement a more generic debugging API, as proposed in http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074656.html, with first part reviewed at http://reviews.llvm.org/D4466. Now adding several new APIs: __asan_report_present, __asan_get_report_{pc,bp,sp,address,type,size,description}, __asan_locate_address. These return whether an asan report happened yet, the PC, BP, SP, address, access type (read/write), access size and bug description (e.g. "heap-use-after-free"), __asan_locate_address takes a pointer and tries to locate it, i.e. say whether it is a heap pointer, a global or a stack, or whether it's a pointer into the shadow memory. If global or stack, tries to also return the variable name, address and size. If heap, tries to return the chunk address and size. Generally these should serve as an alternative to "asan_describe_address", which only returns all the data in text form. Having an API to get these data could allow having debugging scripts/extensions that could show additional information about a variable/expression/pointer. Test cases in test/asan/TestCases/debug_locate.cc and test/asan/TestCasea/debug_report.cc. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@218481 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-02[ASan] Use metadata to pass source-level information from Clang to ASan.Alexey Samsonov
Instead of creating global variables for source locations and global names, just create metadata nodes and strings. They will be transformed into actual globals in the instrumentation pass (if necessary). This approach is more flexible: 1) we don't have to ensure that our custom globals survive all the optimizations 2) if globals are discarded for some reason, we will simply ignore metadata for them and won't have to erase corresponding globals 3) metadata for source locations can be reused for other purposes: e.g. we may attach source location metadata to alloca instructions and provide better descriptions for stack variables in ASan error reports. No functionality change. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@214604 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-20[asan] when reporting an ODR violation, also print the stack traces where ↵Kostya Serebryany
the globals have been registered (thus show the name of shared library or exe to which the global belongs). The reports become a bit too verbose but I do not see any *simple* way to make them more compact. This should be especially helpful when the ODR happens because the same .cc file is used twice in the project in differend DSOs git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@211343 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-28[asan] split detect_odr_violation into two: =2 detects all ODR violations, ↵Kostya Serebryany
=1 detects only those where the variable sizes are different. BTW, the detector seems to be working well and finding nice bugs. Early adopters are welcome. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@207415 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-25[asan] implement an experimental detector of ODR violations. Not tested yet ↵Kostya Serebryany
outside of a tiny test, may need tuning. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@207210 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-24Introduce an operator new for LowLevelAllocator, and convert most users to it.Peter Collingbourne
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@193308 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-14[Sanitizer] Rename InternalVector to InternalMmapVectorAlexey Samsonov
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@183972 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-24Disable init-order checking before destructors are run.Alexey Samsonov
We don't want to report initialization-order bugs when a destructor of a global variable accesses dynamically initialized global from another (not necessarily initialized) module. We do this by intercepting __cxa_atexit and registrering our own callback that unpoisons shadow for all dynamically initialized global variables. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@182637 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-19[ASan] Make init-order checker allow access to already initialized globals.Alexey Samsonov
This change adds ASan runtime option "strict-init-order" (off by default) that makes init-order checker bark if global initializer accesses any global from different translation unit (even if the latter is already initialized). strict init-order checking doesn't play well with, e.g. LLVM registration machineries, and causes issue https://code.google.com/p/address-sanitizer/issues/detail?id=178. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@179843 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-28Make all the ALWAYS_INLINE users Windows-friendly; also, avoid ALWAYS_INLINE ↵Timur Iskhodzhanov
INLINE combinations git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@178266 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-28[ASan] Speed-up initialization-order checking: create and use fast versions ↵Alexey Samsonov
of PoisonShadow functions, store copies of __asan_global descriptors in a vector instead of list of pointers. This gives 3x speedup on both benchmarks and real binaries with lots of globals. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@178239 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-26[ASan] Change the ABI of __asan_before_dynamic_init function: now it takes ↵Alexey Samsonov
pointer to private string with module name. This string serves as a unique module ID in ASan runtime. compiler-rt part git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@178014 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-25[ASan] mark local function as staticAlexey Samsonov
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@177862 91177308-0d34-0410-b5e6-96231b3b80d8
2013-02-05[asan] Fix nonsensical reports of partial right OOB.Evgeniy Stepanov
In case of partial right OOB, ASan was reporting X is located 0 bytes to the right of [A, B) where X was actually inside [A, B). With this change, ASan will report B as the error address in such case. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@174373 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-31[ASan] Split ASan interface header into private and public parts. Add a test ↵Alexey Samsonov
that makes sure users can include interface header git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@174058 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-23[asan] simplify the code that poisons global redzones, add some more testsKostya Serebryany
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@173251 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-18[asan] kill some dead codeKostya Serebryany
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@172815 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-14asan/tsan: move blocking mutex from asan to sanitizer_commonDmitry Vyukov
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@172380 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-29Relocate the external headers provided by ASan and the common sanitizerChandler Carruth
library. These headers are intended to be available to user code when built with AddressSanitizer (or one of the other sanitizer's in the future) to interface with the runtime library. As such, they form stable external C interfaces, and the headers shouldn't be located within the implementation. I've pulled them out into what seem like fairly obvious locations and names, but I'm wide open to further bikeshedding of these names and locations. I've updated the code and the build system to cope with the new locations, both CMake and Makefile. Please let me know if this breaks anyone's build. The eventual goal is to install these headers along side the Clang builtin headers when we build the ASan runtime and install it. My current thinking is to locate them at: <prefix>/lib/clang/X.Y/include/sanitizer/common_interface_defs.h <prefix>/lib/clang/X.Y/include/sanitizer/asan_interface.h <prefix>/lib/clang/X.Y/include/sanitizer/... But maybe others have different suggestions? Fixing the style of the #include between these headers at least unblocks experimentation with installing them as they now should work when installed in these locations. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@162822 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-27[Sanitizer] Use low-level allocator in flag parsing to avoid calling ↵Alexey Samsonov
malloc() before ASan/TSan initialization is done git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@162673 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-21[asan] run-time part of the initialization order checker. Patch by Reid ↵Kostya Serebryany
Watson with some bits from kcc. The sub-pass is off by default for now. On simple tests it works fine. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@162278 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-09[ASan] move code that describes globals to asan_report.ccAlexey Samsonov
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@161572 91177308-0d34-0410-b5e6-96231b3b80d8