summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/sanitizer_common/sanitizer_common.h
Commit message (Collapse)AuthorAgeFilesLines
...
* [compiler-rt] Move IsStackOverflow from asan into sanitizer_commonVitaly Buka2017-09-121-1/+4
| | | | | | | | | | | | Summary: Part of https://github.com/google/sanitizers/issues/637 Reviewers: eugenis, alekseyshl Subscribers: kubamracek, dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D37536 llvm-svn: 312987
* Revert "[compiler-rt] Move IsStackOverflow from asan into sanitizer_common"Vitaly Buka2017-09-121-1/+0
| | | | | | | | Windows is broken. This reverts commit r312951 llvm-svn: 312984
* [compiler-rt] Move IsStackOverflow from asan into sanitizer_commonVitaly Buka2017-09-111-0/+1
| | | | | | | | | | | | Summary: Part of https://github.com/google/sanitizers/issues/637 Reviewers: eugenis, alekseyshl Subscribers: kubamracek, dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D37536 llvm-svn: 312951
* [sanitizers] Add a blocking boolean to GetRandom prototypeKostya Kortchinsky2017-08-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: On platforms with `getrandom`, the system call defaults to blocking. This becomes an issue in the very early stage of the boot for Scudo, when the RNG source is not set-up yet: the syscall will block and we'll stall. Introduce a parameter to specify that the function should not block, defaulting to blocking as the underlying syscall does. Update Scudo to use the non-blocking version. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D36399 llvm-svn: 310839
* Only scan global sections containing data in LSan on darwinFrancis Ricci2017-07-251-3/+9
| | | | | | | | | | | | | | | | | | | | Summary: __DATA segments on Darwin contain a large number of separate sections, many of which cannot actually contain pointers, and contain const values or objc metadata. Not scanning sections which cannot contain pointers significantly improves performance. On a medium-sized (~4000 files) internal project, I saw a speedup of about 30% in standalone LSan's execution time (30% improvement in the time spent running LSan, not the total program time). Reviewers: kcc, kubamracek, alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D35432 llvm-svn: 308999
* [sanitizer_common] Move filesystem-related code out of sanitizer_common.ccVitaly Buka2017-07-221-79/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This is a pure refactoring change. It just moves code that is related to filesystem operations from sanitizer_common.{cc,h} to sanitizer_file.{cc,h}. This makes it cleaner to disable the filesystem-related code for a new port that doesn't want it. Submitted on behalf of Roland McGrath. Reviewers: kcc, eugenis, alekseyshl Reviewed By: alekseyshl Subscribers: vitalybuka, llvm-commits, kubamracek, mgorny, phosek Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D35591 llvm-svn: 308819
* Revert "[sanitizer_common] Move filesystem-related code out of ↵Vitaly Buka2017-07-201-1/+79
| | | | | | | | | | sanitizer_common.cc" Breaks Windows build. This reverts commit r308640. llvm-svn: 308648
* [sanitizer_common] Move filesystem-related code out of sanitizer_common.ccAlex Shlyapnikov2017-07-201-79/+1
| | | | | | | | | | | | | | | | | This is a pure refactoring change. It just moves code that is related to filesystem operations from sanitizer_common.{cc,h} to sanitizer_file.{cc,h}. This makes it cleaner to disable the filesystem-related code for a new port that doesn't want it. Commiting for mcgrathr. Reviewers: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D35591 llvm-svn: 308640
* Revert "Only scan global sections containing data in LSan on darwin"Francis Ricci2017-07-181-9/+3
| | | | | | This reverts commit 7e46d78d47832f03ce42adcf56417fbfd47cbaad. llvm-svn: 308394
* Only scan global sections containing data in LSan on darwinFrancis Ricci2017-07-171-3/+9
| | | | | | | | | | | | | | | | | | | | Summary: __DATA segments on Darwin contain a large number of separate sections, most of which cannot actually contain pointers, and contain const values or objc metadata. Only scanning sections which can contain pointers greatly improves performance. On a medium-sized (~4000 files) internal project, I saw a speedup of about 50% in standalone LSan's execution time (50% improvement in the time spent running LSan, not the total program time). Reviewers: kcc, kubamracek, alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D35432 llvm-svn: 308231
* [asan] For iOS/AArch64, if the dynamic shadow doesn't fit, restrict the VM spaceKuba Mracek2017-07-121-1/+2
| | | | | | | | | | 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
* [Sanitizers] 64 bit allocator respects allocator_may_return_null flagAlex Shlyapnikov2017-06-261-0/+3
| | | | | | | | | | | | | | | | Summary: Make SizeClassAllocator64 return nullptr when it encounters OOM, which allows the entire sanitizer's allocator to follow allocator_may_return_null=1 policy (LargeMmapAllocator: D34243, SizeClassAllocator64: D34433). Reviewers: eugenis Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D34540 llvm-svn: 306342
* [asan] Add support for Android debug message.Evgeniy Stepanov2017-06-231-0/+3
| | | | | | Add ASan report to the "debug message" field in Android tombstones. llvm-svn: 306184
* [Sanitizers] 32 bit allocator respects allocator_may_return_null flagAlex Shlyapnikov2017-06-221-1/+3
| | | | | | | | | | | | | | | | | | | Summary: Make SizeClassAllocator32 return nullptr when it encounters OOM, which allows the entire sanitizer's allocator to follow allocator_may_return_null=1 policy, even for small allocations (LargeMmapAllocator is already fixed by D34243). Will add a test for OOM in primary allocator later, when SizeClassAllocator64 can gracefully handle OOM too. Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D34433 llvm-svn: 305972
* [sanitizer] Add a function to gather random bytesKostya Kortchinsky2017-06-211-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: AFAICT compiler-rt doesn't have a function that would return 'good' random bytes to seed a PRNG. Currently, the `SizeClassAllocator64` uses addresses returned by `mmap` to seed its PRNG, which is not ideal, and `SizeClassAllocator32` doesn't benefit from the entropy offered by its 64-bit counterpart address space, so right now it has nothing. This function aims at solving this, allowing to implement good 32-bit chunk randomization. Scudo also has a function that does this for Cookie purposes, which would go away in a later CL once this lands. This function will try the `getrandom` syscall if available, and fallback to `/dev/urandom` if not. Unfortunately, I do not have a way to implement and test a Mac and Windows version, so those are unimplemented as of now. Note that `kRandomShuffleChunks` is only used on Linux for now. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: zturner, rnk, llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D34412 llvm-svn: 305922
* [Sanitizers] Secondary allocator respects allocator_may_return_null=1.Alex Shlyapnikov2017-06-161-0/+3
| | | | | | | | | | | | | | | | | | Summary: Context: https://github.com/google/sanitizers/issues/740. Making secondary allocator to respect allocator_may_return_null=1 flag and return nullptr when "out of memory" happens. More changes in primary allocator and operator new will follow. Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D34243 llvm-svn: 305569
* [sanitizer] Reverting D34152Kostya Kortchinsky2017-06-141-9/+1
| | | | | | | | | | | | | | | | | Summary: This broke thread_local_quarantine_pthread_join.cc on some architectures, due to the overhead of the stashed regions. Reverting while figuring out the best way to deal with it. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D34213 llvm-svn: 305404
* [sanitizer] MmapAlignedOrDie changes to reduce fragmentationKostya Kortchinsky2017-06-141-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The reasoning behind this change is explained in D33454, which unfortunately broke the Windows version (due to the platform not supporting partial unmapping of a memory region). This new approach changes `MmapAlignedOrDie` to allow for the specification of a `padding_chunk`. If non-null, and the initial allocation is aligned, this padding chunk will hold the address of the extra memory (of `alignment` bytes). This allows `AllocateRegion` to get 2 regions if the memory is aligned properly, and thus help reduce fragmentation (and saves on unmapping operations). As with the initial D33454, we use a stash in the 32-bit Primary to hold those extra regions and return them on the fast-path. The Windows version of `MmapAlignedOrDie` will always return a 0 `padding_chunk` if one was requested. Reviewers: alekseyshl, dvyukov, kcc Reviewed By: alekseyshl Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D34152 llvm-svn: 305391
* [sanitizer-coverage] nuke more stale codeKostya Serebryany2017-06-021-5/+0
| | | | llvm-svn: 304504
* [sanitizer-coverage] nuke more stale codeKostya Serebryany2017-06-021-1/+0
| | | | llvm-svn: 304503
* [compiler-rt] Replace allow_user_segv_handler=0 with kHandleSignalExclusiveVitaly Buka2017-05-251-1/+1
| | | | | | | | | | | | | | Summary: allow_user_segv_handler had confusing name did not allow to control behavior for signals separately. Reviewers: eugenis, alekseyshl, kcc Subscribers: llvm-commits, dberris, kubamracek Differential Revision: https://reviews.llvm.org/D33371 llvm-svn: 303941
* Use write instead of read permissions to check for global sections on macFrancis Ricci2017-05-191-4/+4
| | | | | | | | | | | | | | | Summary: The LINKEDIT section is very large and is read-only. Scanning this section caused LSan on darwin to be very slow. When only writable sections are scanned for global pointers, performance improved by a factor of about 25x. Reviewers: alekseyshl, kubamracek Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33322 llvm-svn: 303422
* [sanitizer] Introduce tid_t as a typedef for OS-provided thread IDsKuba Mracek2017-04-171-1/+1
| | | | | | | | We seem to assume that OS-provided thread IDs are either uptr or int, neither of which is true on Darwin. This introduces a tid_t type, which holds a OS-provided thread ID (gettid on Linux, pthread_threadid_np on Darwin, pthread_self on FreeBSD). Differential Revision: https://reviews.llvm.org/D31774 llvm-svn: 300473
* Don't read non-readable address ranges during lsan pointer scanningFrancis Ricci2017-04-171-4/+9
| | | | | | | | | | | | Summary: This specifically addresses the Mach-O zero page, which we cannot read from. Reviewers: kubamracek, samsonov, alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32044 llvm-svn: 300456
* [ubsan] Use the correct tool name in diagnosticsVedant Kumar2017-04-141-3/+7
| | | | | | | | | | | | | | | 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
* [sanitizer] Bail out with warning if user dlopens shared library with ↵Maxim Ostapenko2017-03-091-0/+2
| | | | | | | | | | | | 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
* [sanitizer] Move DescribeSignalOrException to sanitizer_common.Marcos Pividori2017-02-021-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D29459 llvm-svn: 293956
* Follow-up for r291277: Add a return to silence GCC's "control reaches end of ↵Kuba Mracek2017-01-111-0/+1
| | | | | | non-void function" warning. llvm-svn: 291639
* [sanitizer] Add a 'print_module_map' flag which prints modules with UUIDs on ↵Kuba Mracek2017-01-061-0/+30
| | | | | | | | | | Darwin This patch add a new sanitizer flag, print_module_map, which enables printing a module map when the process exits, or after each report (for TSan). The output format is very similar to what Crash Reporter produces on Darwin (e.g. the format of module UUIDs). This enables users to use the existing symbol servers to offline symbolicate and aggregate reports. Differential Revision: https://reviews.llvm.org/D27400 llvm-svn: 291277
* [sanitizer] Track which modules are instrumented in LoadedModule objectsKuba Mracek2017-01-061-2/+7
| | | | | | | | This patch adds tracking which modules are instrumented and which are not. On macOS, instrumented modules link against the ASan/TSan/... dylib, so we can just check if such a load command exists or not. Differential Revision: https://reviews.llvm.org/D28263 llvm-svn: 291268
* [sancov] __sanitizer_dump_coverage apiMike Aizatsky2016-12-121-0/+7
| | | | | | | | Subscribers: kubabrecka, mgorny Differential Revision: https://reviews.llvm.org/D26758 llvm-svn: 289498
* [sanitizer] Track architecture and UUID of modules in LoadedModuleKuba Mracek2016-12-021-1/+25
| | | | | | | | | | When we enumerate loaded modules, we only track the module name and base address, which then has several problems on macOS. Dylibs and executables often have several architecture slices and not storing which architecture/UUID is actually loaded creates problems with symbolication: A file path + offset isn't enough to correctly symbolicate, since the offset can be valid in multiple slices. This is especially common for Haswell+ X86_64 machines, where x86_64h slices are preferred, but if one is not available, a regular x86_64 is loaded instead. But the same issue exists for i386 vs. x86_64 as well. This patch adds tracking of arch and UUID for each LoadedModule. At this point, this information isn't used in reports, but this is the first step. The goal is to correctly identify which slice is loaded in symbolication, and also to output this information in reports so that we can tell which exact slices were loaded in post-mortem analysis. Differential Revision: https://reviews.llvm.org/D26632 llvm-svn: 288537
* Release memory to OS only when the requested range covers the entire pageEvgeniy Stepanov2016-11-301-1/+3
| | | | | | | | | | | | | | | | | Summary: The current code was sometimes attempting to release huge chunks of memory due to undesired RoundUp/RoundDown interaction when the requested range is fully contained within one memory page. Reviewers: eugenis Subscribers: kubabrecka, llvm-commits Patch by Aleksey Shlyapnikov. Differential Revision: https://reviews.llvm.org/D27228 llvm-svn: 288271
* Return memory to OS right after free (not in the async thread).Evgeniy Stepanov2016-11-291-6/+4
| | | | | | | | | | | | | | | | | | Summary: In order to avoid starting a separate thread to return unused memory to the system (the thread interferes with process startup on Android, Zygota waits for all threads to exit before fork, but this thread never exits), try to return it right after free. Reviewers: eugenis Subscribers: cryptoad, filcab, danalbert, kubabrecka, llvm-commits Patch by Aleksey Shlyapnikov. Differential Revision: https://reviews.llvm.org/D27003 llvm-svn: 288091
* [asan] Add a "dump_registers" flag to print out CPU registers after a SIGSEGVKuba Mracek2016-11-261-0/+2
| | | | | | | | This patch prints out all CPU registers after a SIGSEGV. These are available in the signal handler context. Only implemented for Darwin. Can be turned off with the dump_registers flag. Differential Revision: https://reviews.llvm.org/D11365 llvm-svn: 287957
* rename InternalBinarySearch to InternalLowerBoundMike Aizatsky2016-11-181-3/+3
| | | | | | | | | | | | Summary: The new name better corresponds to its logic. Reviewers: kcc Subscribers: kubabrecka Differential Revision: https://reviews.llvm.org/D26821 llvm-svn: 287377
* fixing binary search for cases when element is not in arrayMike Aizatsky2016-11-161-6/+5
| | | | | | | | Subscribers: kubabrecka Differential Revision: https://reviews.llvm.org/D26707 llvm-svn: 287078
* [compiler-rt] Add support for the dynamic shadow allocationEtienne Bergeron2016-09-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [sanitizer_common] Delete some copy/move methods in InternalScopedBufferVedant Kumar2016-09-271-8/+8
| | | | | | Differential Revision: https://reviews.llvm.org/D24811 llvm-svn: 282548
* revert 282085, 281909, they broke 32-bit dynamic ASan and the ↵Nico Weber2016-09-211-3/+0
| | | | | | sanitizer-windows bot llvm-svn: 282096
* [compiler-rt] Add support for the dynamic shadow allocationEtienne Bergeron2016-09-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch is adding the needed code to compiler-rt to support dynamic shadow. This is to support this patch: https://reviews.llvm.org/D23354 It's adding support for using a shadow placed at a dynamic address determined at runtime. The dynamic shadow is required to work on windows 64-bits. Reviewers: rnk, kcc, vitalybuka Subscribers: kubabrecka, dberris, llvm-commits, chrisha Differential Revision: https://reviews.llvm.org/D23363 llvm-svn: 281909
* [compiler-rt] Do not introduce __sanitizer namespace globallyAnna Zaks2016-09-151-5/+5
| | | | | | | | | | | | 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
* [sanitizer] replace CHECK with CHECK_XY in two places for better diagnosticsKostya Serebryany2016-09-121-2/+2
| | | | llvm-svn: 281255
* [asan] Cleanup: Move tid into ErrorBase, add const to BufferedStackTrace, be ↵Filipe Cabecinhas2016-09-121-1/+1
| | | | | | | | | | | | | | | | consistent in constructor arguments and member order. Summary: As mentioned in D24394, I'm moving tid to ErrorBase, since basically all errors need it. Also mentioned in the same review are other cleanups like adding const to BufferedStackTrace and make sure constructor orders are consistent. Reviewers: vitalybuka, kcc, eugenis Subscribers: llvm-commits, kubabrecka Differential Revision: https://reviews.llvm.org/D24455 llvm-svn: 281236
* [asan] first attempt at releasing free-d memory back to the system using ↵Kostya Serebryany2016-08-261-1/+8
| | | | | | madvise. Requires quite some tuning. llvm-svn: 279887
* [sanitizer] Stop unwinding the stack when a close-to-zero PC is foundKuba Brecka2016-06-271-1/+6
| | | | | | | | On OS X, we often get stack trace in a report that ends with a 0x0 frame. To get rid of it, let's trim the stack trace when we find a close-to-zero value, which is obviously not a valid PC. Differential Revision: http://reviews.llvm.org/D14656 llvm-svn: 273886
* [sanitizers] introduce yet another API function: ↵Kostya Serebryany2016-06-161-0/+2
| | | | | | __sanitizer_install_malloc_and_free_hooks llvm-svn: 272943
* [esan] Add handling of large stack size rlimitsDerek Bruening2016-05-281-0/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Adds detection of large stack size rlimits (over 1 TB or unlimited), which results in an mmap location that our shadow mapping does not support. We re-exec the application in this situation. Adds a test of this behavior. Adds general detection of mmap regions outside of our app regions. In the future we want to try to adaptively handle these but for now we abort. Moves the existing Linux-specific mmap code into a platform-specific file where the new rlimit code lives. Reviewers: eugenis Subscribers: vitalybuka, zhaoqin, kcc, aizatsky, llvm-commits, kubabrecka Differential Revision: http://reviews.llvm.org/D20745 llvm-svn: 271079
* [sanitizer] [SystemZ] Abort if the kernel might be vulnerable to CVE-2016-2143.Marcin Koscielnicki2016-04-271-0/+10
| | | | | | | | | | | | | | | | | | In short, CVE-2016-2143 will crash the machine if a process uses both >4TB virtual addresses and fork(). ASan, TSan, and MSan will, by necessity, map a sizable chunk of virtual address space, which is much larger than 4TB. Even worse, sanitizers will always use fork() for llvm-symbolizer when a bug is detected. Disable all three by aborting on process initialization if the running kernel version is not known to contain a fix. Unfortunately, there's no reliable way to detect the fix without crashing the kernel. So, we rely on whitelisting - I've included a list of upstream kernel versions that will work. In case someone uses a distribution kernel or applied the fix themselves, an override switch is also included. Differential Revision: http://reviews.llvm.org/D19576 llvm-svn: 267747
* [sanitizer] add a function MmapNoAccess that mmaps a protected region ↵Kostya Serebryany2016-04-231-0/+1
| | | | | | *somewhere*; use MmapNoAccess in the Allocator when SpaceBeg is not a constant. In this mode the allocator will be a bit more hardened llvm-svn: 267256
OpenPOWER on IntegriCloud