summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/sanitizer_common
Commit message (Collapse)AuthorAgeFilesLines
...
* [mips][compiler-rt] Fix build breakage.Simon Dardis2017-06-212-4/+2
| | | | | | | Change some reinterpret_casts to c-style casts due to template instantiation restrictions and build breakage due to missing paranthesises. llvm-svn: 305899
* Revert "[compiler-rt] Don't reset non-default user handler if ↵Vitaly Buka2017-06-211-19/+1
| | | | | | | | | | | | | | | | | allow_user_segv_handler is true." Summary: On Android we still need to reset preinstalled handlers and allow use handlers later. This reverts commit r304039. Reviewers: eugenis Subscribers: kubamracek, dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D34434 llvm-svn: 305871
* [Sanitizers] Move cached allocator_may_return_null flag to sanitizer_allocatorAlex Shlyapnikov2017-06-207-87/+96
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Move cached allocator_may_return_null flag to sanitizer_allocator.cc and provide API to consolidate and unify the behavior of all specific allocators. Make all sanitizers using CombinedAllocator to follow AllocatorReturnNullOrDieOnOOM() rules to behave the same way when OOM happens. When OOM happens, turn allocator_out_of_memory flag on regardless of allocator_may_return_null flag value (it used to not to be set when allocator_may_return_null == true). release_to_os_interval_ms and rss_limit_exceeded will likely be moved to sanitizer_allocator.cc too (later). Reviewers: eugenis Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D34310 llvm-svn: 305858
* [scudo] Enabling MIPS support for ScudoSagar Thakur2017-06-192-6/+81
| | | | | | | | | Adding MIPS 32-bit and 64-bit support for Scudo. Reviewed by cryptoad, sdardis. Differential: D31803 llvm-svn: 305682
* [Sanitizer] Remove CombinedAllocator::Allocate's 'cleared' parameterAlex Shlyapnikov2017-06-162-9/+3
| | | | | | | | | | | | | | Summary: CombinedAllocator::Allocate cleared parameter is not used anywhere and seem to be obsolete. Reviewers: eugenis Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D34289 llvm-svn: 305590
* [Sanitizers] Secondary allocator respects allocator_may_return_null=1.Alex Shlyapnikov2017-06-164-2/+34
| | | | | | | | | | | | | | | | | | 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
* [asan] Fix typo in doc string.Vitaly Buka2017-06-151-1/+1
| | | | llvm-svn: 305436
* [asan] Return allow_user_segv_handler=0 to fix compatibility issues.Vitaly Buka2017-06-153-5/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: After r303941 it was not possible to setup ASAN_OPTIONS to have the same behavior for pre r303941 and post r303941 builds. Pre r303941 Asan does not accept handle_sigbus=2. Post r303941 Asan does not accept allow_user_segv_handler. This fix ignores allow_user_segv_handler=1, but for allow_user_segv_handler=0 it will upgrade flags like handle_sigbus=1 to handle_sigbus=2. So user can set ASAN_OPTIONS=allow_user_segv_handler=0 and have same behavior on old and new clang builds (except range from r303941 to this revision). In future users which need to prevent third party handlers should switch to handle_sigbus=2 and remove allow_user_segv_handler as soon as suport of older builds is not needed. Related bugs: https://github.com/google/oss-fuzz/issues/675 https://bugs.chromium.org/p/chromium/issues/detail?id=731130 Reviewers: eugenis Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D34227 llvm-svn: 305433
* [sanitizer] Reverting D34152Kostya Kortchinsky2017-06-145-112/+20
| | | | | | | | | | | | | | | | | 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-145-20/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ASan] Move rss_limit_is_exceeded_ flag to ASan.Alex Shlyapnikov2017-06-131-14/+5
| | | | | | | | | | | | | | Summary: Move the OOM decision based on RSS limits out of generic allocator to ASan allocator, where it makes more sense at the moment. Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D34180 llvm-svn: 305342
* [sanitize] Remove stack size limits from secondary threads.Evgeniy Stepanov2017-06-131-1/+0
| | | | | | | | If pthread_attr_getstack tell us the stack is 2G, why would we doubt that? Differential Revision: https://reviews.llvm.org/D34169 llvm-svn: 305330
* [sanitizer] Fix symbolizer build after r304864.Evgeniy Stepanov2017-06-071-1/+2
| | | | | | | r304864 moved code into a new BinaryFormat library. Update the symbolizer build script. llvm-svn: 304930
* [tsan]: Fix GNU version of strerror_r interceptorVitaly Buka2017-06-071-1/+4
| | | | | | | | | | GNU version of strerror_r returns a result pointer that doesn't match the input buffer. The result pointer is in fact a pointer to some internal storage. TSAN was recording a write to this location, which was incorrect. Fixed https://github.com/google/sanitizers/issues/696 llvm-svn: 304858
* Revert "[sanitizer-coverage] test for -fsanitize-coverage=inline-8bit-counters"Renato Golin2017-06-052-9/+10
| | | | | | | | | | | | | Revert "Mark sancov test as unsupported on Darwin" Revert "[LSan] Detect dynamic loader by its base address." This reverts commit r304633. This reverts commit r304673. This reverts commit r304632. Those commit have broken LOTS of ARM/AArch64 bots for two days. llvm-svn: 304699
* Adjust sanitizers for FreeBSD 64-bit inode updateDimitry Andric2017-06-032-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Very recently, FreeBSD 12 has been updated to use 64-bit inode numbers: <https://svnweb.freebsd.org/changeset/base/318737>. This entails many user-visible changes, but for the sanitizers the modifications are limited in scope: * The `stat` and `lstat` syscalls were removed, and should be replaced with calls to `fstatat`. * The `getdents` syscall was removed, and should be replaced with calls to `getdirentries`. * The layout of `struct dirent` was changed to accomodate 64-bit inode numbers, and a new `d_off` field was added. * The system header <sys/_types.h> now contains a macro `__INO64` to determine whether the system uses 64-bit inode numbers. I tested these changes on both FreeBSD 12.0-CURRENT (after r318959, which adds the `__INO64` macro), and FreeBSD 11.0-STABLE (which still uses 32-bit inode numbers). Reviewers: emaste, kcc, vitalybuka, kubamracek Reviewed By: vitalybuka Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D33600 llvm-svn: 304658
* [LSan] Detect dynamic loader by its base address.Alex Shlyapnikov2017-06-032-10/+9
| | | | | | | | | | | | | | | Summary: Whenever possible (Linux + glibc 2.16+), detect dynamic loader module by its base address, not by the module name matching. The current name matching approach fails on some configurations. Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D33859 llvm-svn: 304633
* [asan] fix one more case where stack-use-after-return is not ↵Kostya Serebryany2017-06-021-1/+1
| | | | | | async-signal-safe (during thread startup). beef-up the test to give it a chance to catch regressions. Also relax the lint to make C++11 more usable. llvm-svn: 304598
* [sanitizer-coverage] nuke more stale codeKostya Serebryany2017-06-022-13/+3
| | | | llvm-svn: 304508
* [sanitizer-coverage] nuke more stale codeKostya Serebryany2017-06-026-620/+25
| | | | llvm-svn: 304504
* [sanitizer-coverage] nuke more stale codeKostya Serebryany2017-06-024-137/+0
| | | | llvm-svn: 304503
* [sanitizer-coverage] nuke more stale codeKostya Serebryany2017-06-012-5/+0
| | | | llvm-svn: 304500
* [asan] Add strndup/__strndup interceptors.Pierre Gousseau2017-06-014-0/+65
| | | | | | | | Recommit of r302781 with Vitaly Buka's fix for non zero terminated strings. Differential Revision: https://reviews.llvm.org/D31457 llvm-svn: 304399
* [sanitizer-coverage] remove stale code (old coverage); compiler-rt part Kostya Serebryany2017-05-314-49/+9
| | | | llvm-svn: 304318
* [sanitizer] Add "isapla" to symbolizer's global symbols whitelist.Alex Shlyapnikov2017-05-301-0/+1
| | | | | | | | | | | | Summary: D33637 introduced isalpha, whitelist need to reflect that. Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D33687 llvm-svn: 304234
* [compiler-rt] Don't reset non-default user handler if ↵Vitaly Buka2017-05-261-1/+19
| | | | | | | | | | | | allow_user_segv_handler is true. Reviewers: eugenis, kcc Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D32457 llvm-svn: 304039
* [compiler-rt] Replace allow_user_segv_handler=0 with kHandleSignalExclusiveVitaly Buka2017-05-259-17/+24
| | | | | | | | | | | | | | 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
* [compiler-rt] Make print_module_map description consistent with the rest.Vitaly Buka2017-05-251-2/+2
| | | | | | | | | | Reviewers: eugenis Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D33160 llvm-svn: 303892
* Implement tls scanning for darwin LSanFrancis Ricci2017-05-251-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This required for any users who call exit() after creating thread-specific data, as tls destructors are only called when pthread_exit() or pthread_cancel() are used. This should also match tls behavior on linux. Getting the base address of the tls section is straightforward, as it's stored as a section offset in %gs. The size is a bit trickier to work out, as there doesn't appear to be any official documentation or source code referring to it. The size used in this patch was determined by taking the difference between the base address and the address of the subsequent memory region returned by vm_region_recurse_64, which was 1024 * sizeof(uptr) on all threads except the main thread, where it was larger. Since the section must be the same size on all of the threads, 1024 * sizeof(uptr) seemed to be a reasonable size to use, barring a more programtic way to get the size. 1024 seems like a reasonable number, given that PTHREAD_KEYS_MAX is 512 on darwin, so pthread keys will fit inside the region while leaving space for other tls data. A larger size would overflow the memory region returned by vm_region_recurse_64, and a smaller size wouldn't leave room for all the pthread keys. In addition, the stress test added here passes, which means that we are scanning at least the full set of possible pthread keys, and probably the full tls section. Reviewers: alekseyshl, kubamracek Subscribers: krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D33215 llvm-svn: 303887
* [sanitizer] Revert rL303879 as it breaks WindowsKostya Kortchinsky2017-05-251-53/+8
| | | | | | | | | | | | | | | | Summary: Apparently Windows's `UnmapOrDie` doesn't support partial unmapping. Which makes the new region allocation technique not Windows compliant. Reviewers: alekseyshl, dvyukov Reviewed By: alekseyshl Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D33554 llvm-svn: 303883
* [sanitizer] Change the 32-bit Primary AllocateRegion to reduce fragmentationKostya Kortchinsky2017-05-251-10/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, AllocateRegion has a tendency to fragment memory: it allocates `2*kRegionSize`, and if the memory is aligned, will unmap `kRegionSize` bytes, thus creating a hole, which can't itself be reused for another region. This is exacerbated by the fact that if 2 regions get allocated one after another without any `mmap` in between, the second will be aligned due to mappings generally being contiguous. An idea, suggested by @alekseyshl, to prevent such a behavior is to have a stash of regions: if the `2*kRegionSize` allocation is properly aligned, split it in two, and stash the second part to be returned next time a region is requested. At this point, I thought about a couple of ways to implement this: - either an `IntrusiveList` of regions candidates, storing `next` at the begining of the region; - a small array of regions candidates existing in the Primary. While the second option is more constrained in terms of size, it offers several advantages: - security wise, a pointer in a region candidate could be overflowed into, and abused when popping an element; - we do not dirty the first page of the region by storing something in it; - unless several threads request regions simultaneously from different size classes, the stash rarely goes above 1 entry. I am not certain about the Windows impact of this change, as `sanitizer_win.cc` has its own version of MmapAlignedOrDie, maybe someone could chime in on this. MmapAlignedOrDie is effectively unused after this change and could be removed at a later point. I didn't notice any sizeable performance gain, even though we are saving a few `mmap`/`munmap` syscalls. Reviewers: alekseyshl, kcc, dvyukov Reviewed By: alekseyshl Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D33454 llvm-svn: 303879
* [sanitizer] Pair atomic acquire with release in BlockingMutex::UnlockAlex Shlyapnikov2017-05-251-1/+1
| | | | | | | | | | | | | | | Summary: Dmitry, seeking your expertise. I believe, the proper way to implement Lock/Unlock here would be to use acquire/release semantics. Am I missing something? Reviewers: dvyukov Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D33521 llvm-svn: 303869
* [compiler-rt] Change default of allow_user_segv_handler to trueVitaly Buka2017-05-251-1/+1
| | | | | | | | | | Reviewers: eugenis Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D32443 llvm-svn: 303842
* Revert "[compiler-rt] Change default of allow_user_segv_handler to true"Vitaly Buka2017-05-241-1/+1
| | | | | | | | Breaks sanitizer-x86_64-linux-fuzzer bot. This reverts commit r303729. llvm-svn: 303795
* [sanitizer] [SystemZ] Update CVE-2016-2143 check for Ubuntu 16.04Ulrich Weigand2017-05-241-0/+7
| | | | | | | The Ubuntu 16.04 kernel contains a backport of the CVE check starting with version 4.4.0-13. Update FixedCVE_2016_2143. llvm-svn: 303757
* [compiler-rt] Change default of allow_user_segv_handler to trueVitaly Buka2017-05-241-1/+1
| | | | | | | | | | Reviewers: eugenis Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D32443 llvm-svn: 303729
* Revert "[compiler-rt] Change default of allow_user_segv_handler to true"Vitaly Buka2017-05-201-1/+1
| | | | | | | | Failed libFuzzer tests on Windows. This reverts commit r303476. llvm-svn: 303481
* [compiler-rt] Change default of allow_user_segv_handler to trueVitaly Buka2017-05-201-1/+1
| | | | | | | | | | Reviewers: eugenis Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D32443 llvm-svn: 303476
* [compiler-rt] Switch handle_<signal> flags from bool to enum.Vitaly Buka2017-05-194-14/+61
| | | | | | | | | | | | Summary: We are going to make it tri-state and remove allow_user_segv_handler. Reviewers: eugenis, alekseys, kcc Subscribers: kubamracek, dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D33159 llvm-svn: 303464
* [compiler-rt] Add negative test for boolean flags.Vitaly Buka2017-05-191-0/+8
| | | | | | | | | | Reviewers: eugenis, alekseyshl Subscribers: kubamracek, dberris, llvm-commits Differential Revision: https://reviews.llvm.org/D33344 llvm-svn: 303462
* Use write instead of read permissions to check for global sections on macFrancis Ricci2017-05-196-11/+11
| | | | | | | | | | | | | | | 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
* [compiler-rt] Replace ifs with switch statement in IsHandledDeadlySignalVitaly Buka2017-05-182-19/+27
| | | | | | | | | | Reviewers: eugenis Subscribers: kubamracek, llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D33158 llvm-svn: 303392
* [compiler-rt][cmake] Build unit tests conditionally with ↵Simon Dardis2017-05-181-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | _FILE_OFFSET_BITS=64 and _LARGEFILE_SOURCE The sanitizer library unit tests for libc can get a different definition of 'struct stat' to what the sanitizer library is built with for certain targets. For MIPS the size element of 'struct stat' is after a macro guarded explicit padding element. This patch resolves any possible inconsistency by adding the same _FILE_OFFSET_BITS=64 and _LARGE_SOURCE with the same conditions as the sanitizer library to the build flags for the unit tests. This resolves a recurring build failure on the MIPS buildbots due to 'struct stat' defintion differences. Reviewers: slthakur Differential Revision: https://reviews.llvm.org/D33131 llvm-svn: 303350
* Revert r302781 and subsequent attempts to disable part of it.Daniel Jasper2017-05-184-68/+0
| | | | | | | The Msan unit tests are still broken and by this point, I think we should start over. llvm-svn: 303339
* temporary disable stndup interceptor, due to r302781 being buggyKostya Serebryany2017-05-182-3/+5
| | | | llvm-svn: 303324
* Revert "Implement tls scanning for darwin LSan"Francis Ricci2017-05-171-23/+2
| | | | | | This reverts r303262, due to TSan buildbot breakages. llvm-svn: 303266
* Implement tls scanning for darwin LSanFrancis Ricci2017-05-171-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This required for any users who call exit() after creating thread-specific data, as tls destructors are only called when pthread_exit() or pthread_cancel() are used. This should also match tls behavior on linux. Getting the base address of the tls section is straightforward, as it's stored as a section offset in %gs. The size is a bit trickier to work out, as there doesn't appear to be any official documentation or source code referring to it. The size used in this patch was determined by taking the difference between the base address and the address of the subsequent memory region returned by vm_region_recurse_64, which was 1024 * sizeof(uptr) on all threads except the main thread, where it was larger. Since the section must be the same size on all of the threads, 1024 * sizeof(uptr) seemed to be a reasonable size to use, barring a more programtic way to get the size. 1024 seems like a reasonable number, given that PTHREAD_KEYS_MAX is 512 on darwin, so pthread keys will fit inside the region while leaving space for other tls data. A larger size would overflow the memory region returned by vm_region_recurse_64, and a smaller size wouldn't leave room for all the pthread keys. In addition, the stress test added here passes, which means that we are scanning at least the full set of possible pthread keys, and probably the full tls section. Reviewers: alekseyshl, kubamracek Subscribers: krytarowski, llvm-commits Differential Revision: https://reviews.llvm.org/D33215 llvm-svn: 303262
* [asan] make asan under sandboxes more robustKostya Serebryany2017-05-151-2/+2
| | | | llvm-svn: 303132
* [sanitizer] Change SizeClassAllocator32 to accept just one templateKostya Kortchinsky2017-05-153-31/+56
| | | | | | | | | | | | | | | | | | | | | Summary: With rL279771, SizeClassAllocator64 was changed to accept only one template instead of 5, for the following reasons: "First, this will make the mangled names shorter. Second, this will make adding more parameters simpler". This patch mirrors that work for SizeClassAllocator32. This is in preparation for introducing the randomization of chunks in the 32-bit SizeClassAllocator in a later patch. Reviewers: kcc, alekseyshl, dvyukov Reviewed By: alekseyshl Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D33141 llvm-svn: 303071
* Add dyld to sanitizer procmaps on darwinFrancis Ricci2017-05-122-7/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Sanitizer procmaps uses dyld apis to iterate over the list of images in the process. This is much more performan than manually recursing over all of the memory regions in the process, however, dyld does not report itself in the list of images. In order to prevent reporting leaks from dyld globals and to symbolize dyld functions in stack traces, this patch special-cases dyld and ensures that it is added to the list of modules. This is accomplished by recursing through the memory map of the process until a dyld Mach header is found. While this recursion is expensive, it is run before the full set of images has been loaded in the process, so only a few calls are required. The result is cached so that it never needs to be searched for when the full process memory map exists, as this would be incredibly slow, on the order of minutes for leak sanitizer with only 25 or so libraries loaded. Reviewers: alekseyshl, kubamracek Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D32968 llvm-svn: 302899
OpenPOWER on IntegriCloud