summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/scudo
Commit message (Collapse)AuthorAgeFilesLines
...
* [sanitizer] Do not use the alignment-rounded-up size when using the secondaryKostya Kortchinsky2016-12-082-5/+8
| | | | | | | | | | | | | | | | | | Summary: The combined allocator rounds up the requested size with regard to the alignment, which makes sense when being serviced by the primary as it comes with alignment guarantees, but not with the secondary. For the rare case of large alignments, it wastes memory, and entices unnecessarily large fields for the Scudo header. With this patch, we pass the non-alignement-rounded-up size to the secondary, and adapt the Scudo code for this change. Reviewers: alekseyshl, kcc Subscribers: llvm-commits, kubabrecka Differential Revision: https://reviews.llvm.org/D27428 llvm-svn: 289088
* Don't include system header inside namespaceStephan Bergmann2016-12-021-16/+16
| | | | | | | ...causes build failure at least with GCC 6.2.1, as smmintrin.h indirectly includes cstdlib, which then runs into problems. llvm-svn: 288486
* [scudo] 32-bit and hardware agnostic supportKostya Kortchinsky2016-11-3011-204/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This update introduces i386 support for the Scudo Hardened Allocator, and offers software alternatives for functions that used to require hardware specific instruction sets. This should make porting to new architectures easier. Among the changes: - The chunk header has been changed to accomodate the size limitations encountered on 32-bit architectures. We now fit everything in 64-bit. This was achieved by storing the amount of unused bytes in an allocation rather than the size itself, as one can be deduced from the other with the help of the GetActuallyAllocatedSize function. As it turns out, this header can be used for both 64 and 32 bit, and as such we dropped the requirement for the 128-bit compare and exchange instruction support (cmpxchg16b). - Add 32-bit support for the checksum and the PRNG functions: if the SSE 4.2 instruction set is supported, use the 32-bit CRC32 instruction, and in the XorShift128, use a 32-bit based state instead of 64-bit. - Add software support for CRC32: if SSE 4.2 is not supported, fallback on a software implementation. - Modify tests that were not 32-bit compliant, and expand them to cover more allocation and alignment sizes. The random shuffle test has been deactivated for linux-i386 & linux-i686 as the 32-bit sanitizer allocator doesn't currently randomize chunks. Reviewers: alekseyshl, kcc Subscribers: filcab, llvm-commits, tberghammer, danalbert, srhines, mgorny, modocache Differential Revision: https://reviews.llvm.org/D26358 llvm-svn: 288255
* Return memory to OS right after free (not in the async thread).Evgeniy Stepanov2016-11-292-1/+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
* [scudo] Lay the foundation for 32-bit supportKostya Kortchinsky2016-10-263-85/+142
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In order to support 32-bit platforms, we have to make some adjustments in multiple locations, one of them being the Scudo chunk header. For it to fit on 64 bits (as a reminder, on x64 it's 128 bits), I had to crunch the space taken by some of the fields. In order to keep the offset field small, the secondary allocator was changed to accomodate aligned allocations for larger alignments, hence making the offset constant for chunks serviced by it. The resulting header candidate has been added, and further modifications to allow 32-bit support will follow. Another notable change is the addition of MaybeStartBackgroudThread() to allow release of the memory to the OS. Reviewers: kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D25688 llvm-svn: 285209
* [scudo] Fix an edge case in the secondary allocatorKostya Kortchinsky2016-09-303-6/+6
| | | | | | | | | | | | | | | 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
* Don't use internal symbolizer if we are in process of reporting Out-of-Memory.Vitaly Buka2016-09-292-7/+13
| | | | | | Reviewed by eugenis offline, as reviews.llvm.org is down. llvm-svn: 282805
* [scudo] Fix a bug in the new Secondary AllocatorKostya Kortchinsky2016-09-201-2/+3
| | | | | | | | | | | | | | | | | | | Summary: GetActuallyAllocatedSize() was not accounting for the last page of the mapping being a guard page, and was returning the wrong number of actually allocated bytes, which in turn would mess up with the realloc logic. Current tests didn't find this as the size exercised was only serviced by the Primary. Correct the issue by subtracting PageSize, and update the realloc test to exercise paths in both the Primary and the Secondary. Reviewers: kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24787 llvm-svn: 282030
* [scudo] Modify Scudo to use its own Secondary AllocatorKostya Kortchinsky2016-09-192-2/+141
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The Sanitizer Secondary Allocator was not entirely ideal was Scudo for several reasons: decent amount of unneeded code, redundant checks already performed by the front end, unneeded data structures, difficulty to properly protect the secondary chunks header. Given that the second allocator is pretty straight forward, Scudo will use its own, trimming all the unneeded code off of the Sanitizer one. A significant difference in terms of security is that now each secondary chunk is preceded and followed by a guard page, thus mitigating overflows into and from the chunk. A test was added as well to illustrate the overflow & underflow situations into the guard pages. Reviewers: kcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D24737 llvm-svn: 281938
* [CMake] Connect Compiler-RT targets to LLVM Runtimes directoryChris Bieneman2016-08-261-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch builds on LLVM r279776. In this patch I've done some cleanup and abstracted three common steps runtime components have in their CMakeLists files, and added a fourth. The three steps I abstract are: (1) Add a top-level target (i.e asan, msan, ...) (2) Set the target properties for sorting files in IDE generators (3) Make the compiler-rt target depend on the top-level target The new step is to check if a command named "runtime_register_component" is defined, and to call it with the component name. The runtime_register_component command is defined in llvm/runtimes/CMakeLists.txt, and presently just adds the component to a list of sub-components, which later gets used to generate target mappings. With this patch a new workflow for runtimes builds is supported. The new workflow when building runtimes from the LLVM runtimes directory is: > cmake [...] > ninja runtimes-configure > ninja asan The "runtimes-configure" target builds all the dependencies for configuring the runtimes projects, and runs CMake on the runtimes projects. Running the runtimes CMake generates a list of targets to bind into the top-level CMake so subsequent build invocations will have access to some of Compiler-RT's targets through the top-level build. Note: This patch does exclude some top-level targets from compiler-rt libraries because they either don't install files (sanitizer_common), or don't have a cooresponding `check` target (stats). llvm-svn: 279863
* [sanitizer] enable random shuffling the memory chunks inside the allocator, ↵Kostya Serebryany2016-08-261-0/+2
| | | | | | under a flag. Set this flag for the scudo allocator, add a test. llvm-svn: 279793
* [sanitizer] change SizeClassAllocator64 to accept just one template ↵Kostya Serebryany2016-08-251-5/+9
| | | | | | parameter instead of 5. First, this will make the mangled names shorter. Second, this will make adding more parameters simpler. llvm-svn: 279771
* [scudo] add NORETURN to the declaration of dieWithMessage; this should fix a ↵Kostya Serebryany2016-08-021-1/+1
| | | | | | warning in lib/scudo/scudo_termination.cpp llvm-svn: 277546
* [sanitizer] Implement a __asan_default_options() equivalent for ScudoKostya Serebryany2016-08-024-16/+29
| | | | | | | | | | | | | | Summary: Currently, the Scudo Hardened Allocator only gets its flags via the SCUDO_OPTIONS environment variable. With this patch, we offer the opportunity for programs to define their own options via __scudo_default_options() which behaves like __asan_default_options() (weak symbol). A relevant test has been added as well, and the documentation updated accordingly. I also used this patch as an opportunity to rename a few variables to comply with the LLVM naming scheme, and replaced a use of Report with dieWithMessage for consistency (and to avoid a callback). Reviewers: llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D23018 llvm-svn: 277536
* [compiler-rt] Fix VisualStudio virtual folders layoutEtienne Bergeron2016-07-111-0/+1
| | | | | | | | | | | | | | | | | | | | Summary: This patch is a refactoring of the way cmake 'targets' are grouped. It won't affect non-UI cmake-generators. Clang/LLVM are using a structured way to group targets which ease navigation through Visual Studio UI. The Compiler-RT projects differ from the way Clang/LLVM are grouping targets. This patch doesn't contain behavior changes. Reviewers: kubabrecka, rnk Subscribers: wang0109, llvm-commits, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21952 llvm-svn: 275111
* [sanitizer] Initial implementation of a Hardened AllocatorKostya Serebryany2016-06-0711-0/+1256
Summary: This is an initial implementation of a Hardened Allocator based on Sanitizer Common's CombinedAllocator. It aims at mitigating heap based vulnerabilities by adding several features to the base allocator, while staying relatively fast. The following were implemented: - additional consistency checks on the allocation function parameters and on the heap chunks; - use of checksum protected chunk header, to detect corruption; - randomness to the allocator base; - delayed freelist (quarantine), to mitigate use after free and overall determinism. Additional mitigations are in the works. Reviewers: eugenis, aizatsky, pcc, krasin, vitalybuka, glider, dvyukov, kcc Subscribers: kubabrecka, filcab, llvm-commits Differential Revision: http://reviews.llvm.org/D20084 llvm-svn: 271968
OpenPOWER on IntegriCloud