summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/hwasan/hwasan_allocator.h
Commit message (Collapse)AuthorAgeFilesLines
* [hwasan] Remove system allocator fallback.Evgeniy Stepanov2019-10-181-6/+0
| | | | | | | | | | | | | | | | Summary: This has been an experiment with late malloc interposition, made possible by a non-standard feature of the Android dynamic loader. Reviewers: pcc, mmalcomson Subscribers: srhines, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69199 llvm-svn: 375296
* [sanitizer][NFC] Set LargeMmapAllocator type from PrimaryAllocatorVitaly Buka2019-05-011-2/+1
| | | | | | | | | | | | | | They need to have same AddressSpaceView and MapUnmapCallback. Reviewers: eugenis Subscribers: kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61168 llvm-svn: 359719
* [sanitizer][NFC] Get type of AllocatorCache from CombinedAllocatorVitaly Buka2019-05-011-3/+2
| | | | | | | | | | | | | | Reviewers: eugenis, cryptoad, kcc Reviewed By: kcc Subscribers: kcc, kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61155 llvm-svn: 359715
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* hwasan: Use system allocator to realloc and free untagged pointers in ↵Peter Collingbourne2019-01-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | interceptor mode. The Android dynamic loader has a non-standard feature that allows libraries such as the hwasan runtime to interpose symbols even after the symbol already has a value. The new value of the symbol is used to relocate libraries loaded after the interposing library, but existing libraries keep the old value. This behaviour is activated by the DF_1_GLOBAL flag in DT_FLAGS_1, which is set by passing -z global to the linker, which is what we already do to link the hwasan runtime. What this means in practice is that if we have .so files that depend on interceptor-mode hwasan without the main executable depending on it, some of the libraries in the process will be using the hwasan allocator and some will be using the system allocator, and these allocators need to interact somehow. For example, if an instrumented library calls a function such as strdup that allocates memory on behalf of the caller, the instrumented library can reasonably expect to be able to call free to deallocate the memory. We can handle that relatively easily with hwasan by using tag 0 to represent allocations from the system allocator. If hwasan's realloc or free functions are passed a pointer with tag 0, the system allocator is called. One limitation is that this scheme doesn't work in reverse: if an instrumented library allocates memory, it must free the memory itself and cannot pass ownership to a system library. In a future change, we may want to expose an API for calling the system allocator so that instrumented libraries can safely transfer ownership of memory to system libraries. Differential Revision: https://reviews.llvm.org/D55986 llvm-svn: 350427
* [hwasan] Switch to 64 allocator with a dense size class map.Evgeniy Stepanov2019-01-031-11/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Replace the 32-bit allocator with a 64-bit one with a non-constant base address, and reduce both the number of size classes and the maximum size of per-thread caches. As measured on [1], this reduces average weighted memory overhead (MaxRSS) from 26% to 12% over stock android allocator. These numbers include overhead from code instrumentation and hwasan shadow (i.e. not a pure allocator benchmark). This switch also enables release-to-OS functionality, which is not implemented in the 32-bit allocator. I have not seen any effect from that on the benchmark. [1] https://android.googlesource.com/platform/system/extras/+/master/memory_replay/ Reviewers: vitalybuka, kcc Subscribers: kubamracek, cryptoad, llvm-commits Differential Revision: https://reviews.llvm.org/D56239 llvm-svn: 350370
* Introduce `AddressSpaceView` template parameter to `SizeClassAllocator32`, ↵Dan Liew2018-12-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `FlatByteMap`, and `TwoLevelByteMap`. Summary: This is a follow up patch to r346956 for the `SizeClassAllocator32` allocator. This patch makes `AddressSpaceView` a template parameter both to the `ByteMap` implementations (but makes `LocalAddressSpaceView` the default), some `AP32` implementations and is used in `SizeClassAllocator32`. The actual changes to `ByteMap` implementations and `SizeClassAllocator32` are very simple. However the patch is large because it requires changing all the `AP32` definitions, and users of those definitions. For ASan and LSan we make `AP32` and `ByteMap` templateds type that take a single `AddressSpaceView` argument. This has been done because we will instantiate the allocator with a type that isn't `LocalAddressSpaceView` in the future patches. For the allocators used in the other sanitizers (i.e. HWAsan, MSan, Scudo, and TSan) use of `LocalAddressSpaceView` is hard coded because we do not intend to instantiate the allocators with any other type. In the cases where untemplated types have become templated on a single `AddressSpaceView` parameter (e.g. `PrimaryAllocator`) their name has been changed to have a `ASVT` suffix (Address Space View Type) to indicate they are templated. The only exception to this are the `AP32` types due to the desire to keep the type name as short as possible. In order to check that template is instantiated in the correct a way a `static_assert(...)` has been added that checks that the `AddressSpaceView` type used by `Params::ByteMap::AddressSpaceView` matches the `Params::AddressSpaceView`. This uses the new `sanitizer_type_traits.h` header. rdar://problem/45284065 Reviewers: kcc, dvyukov, vitalybuka, cryptoad, eugenis, kubamracek, george.karpenkov Subscribers: mgorny, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D54904 llvm-svn: 349138
* [hwasan] optionally right-align heap allocationsKostya Serebryany2018-11-161-1/+2
| | | | | | | | | | | | | | | | | Summary: ... so that we can find intra-granule buffer overflows. The default is still to always align left. It remains to be seen wether we can enable this mode at scale. Reviewers: eugenis Reviewed By: eugenis Subscribers: jfb, dvyukov, kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D53789 llvm-svn: 347082
* [hwasan] when reporting a bug, print some very basic information about the ↵Kostya Serebryany2018-10-101-0/+2
| | | | | | heap chunk (in addition to the more detailed info that we may fail to show) llvm-svn: 344193
* [hwasan] Export memory stats through /proc/$PID/maps.Evgeniy Stepanov2018-09-081-1/+1
| | | | | | | Adds a line to /proc/$PID/maps with more or less up-to-date memory stats of the process. llvm-svn: 341735
* [hwasan] introduce __hwasan_print_memory_usageKostya Serebryany2018-09-061-0/+1
| | | | llvm-svn: 341592
* [hwasan] when verbose_threads==1, print the memory usage per threadKostya Serebryany2018-09-051-0/+2
| | | | llvm-svn: 341507
* [hwasan] simplify the code, NFCKostya Serebryany2018-09-051-7/+1
| | | | llvm-svn: 341501
* [hwasan] move code around to remove an opaque class definition ↵Kostya Serebryany2018-08-311-4/+46
| | | | | | (HwasanThreadLocalMallocStorage) that had incorrect size and used 10x more than needed RAM (500K instead of 50K per thread) llvm-svn: 341170
* [hwasan] simplify the code, NFCKostya Serebryany2018-08-311-1/+0
| | | | llvm-svn: 341166
* [hwasan] use thread-local ring buffers to properly report heap-use-after-freeKostya Serebryany2018-08-301-1/+1
| | | | llvm-svn: 341133
* [hwasan] formatting change, NFCKostya Serebryany2018-08-291-1/+1
| | | | llvm-svn: 340980
* Add a thread-local ring buffer of heap allocationsKostya Serebryany2018-08-291-0/+12
| | | | | | | | | | | | | | | | | | Summary: We need this in order to properly report heap-use-after-free, since we don't have a quarantine. This is a first part of the code, more like a proof of concept. But I'd like to commit at as is and proceed with refactoring, adding a ThreadRegistry, and extending the functionality. Reviewers: eugenis Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D51394 llvm-svn: 340971
* [hwasan] remove stale data fieldKostya Serebryany2018-08-221-1/+0
| | | | llvm-svn: 340442
* Hardware-assisted AddressSanitizer (compiler-rt)Evgeniy Stepanov2017-12-091-0/+55
Summary: Runtime library for HWASan, initial commit. Does not randomize tags yet, does not handle stack or globals. Reviewers: kcc, pcc, alekseyshl Subscribers: srhines, kubamracek, dberris, mgorny, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D40935 llvm-svn: 320231
OpenPOWER on IntegriCloud