summaryrefslogtreecommitdiff
path: root/test/hwasan
Commit message (Collapse)AuthorAgeFilesLines
* [hwasan] Fix test failure in r369721.Evgeniy Stepanov2019-08-261-3/+6
| | | | | | | | | Try harder to emulate "old runtime" in the test. To get the old behavior with the new runtime library, we need both disable personality function wrapping and enable landing pad instrumentation. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@369977 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Untag unwound stack frames by wrapping personality functions.Peter Collingbourne2019-08-232-3/+13
| | | | | | | | | | | | | | | | | | | | | | | One problem with untagging memory in landing pads is that it only works correctly if the function that catches the exception is instrumented. If the function is uninstrumented, we have no opportunity to untag the memory. To address this, replace landing pad instrumentation with personality function wrapping. Each function with an instrumented stack has its personality function replaced with a wrapper provided by the runtime. Functions that did not have a personality function to begin with also get wrappers if they may be unwound past. As the unwinder calls personality functions during stack unwinding, the original personality function is called and the function's stack frame is untagged by the wrapper if the personality function instructs the unwinder to keep unwinding. If unwinding stops at a landing pad, the function is still responsible for untagging its stack frame if it resumes unwinding. The old landing pad mechanism is preserved for compatibility with old runtimes. Differential Revision: https://reviews.llvm.org/D66377 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@369721 91177308-0d34-0410-b5e6-96231b3b80d8
* Add LLD as a requirement for hwasan tests because of change in r368111.Douglas Yung2019-08-081-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368242 91177308-0d34-0410-b5e6-96231b3b80d8
* [HWASan] Use LLD for check-hwasan.Mitch Phillips2019-08-071-1/+1
| | | | | | | | HWASan+globals build fix in rL368111 unfortunately didn't fix the problem when clang_cflags specified -fuse-ld=ld.gold. Change the order to force lld in an attempt to fix the Android sanitizer bot. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368218 91177308-0d34-0410-b5e6-96231b3b80d8
* Require lld for hwasan tests.Peter Collingbourne2019-08-063-2/+5
| | | | | | | | We're using relocations that are unsupported by the version of gold on the bot, so force the use of lld. One of the tests is already using lld, so this should be safe. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368111 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Instrument globals.Peter Collingbourne2019-08-062-1/+23
| | | | | | | | | | | | | | | | | | Globals are instrumented by adding a pointer tag to their symbol values and emitting metadata into a special section that allows the runtime to tag their memory when the library is loaded. Due to order of initialization issues explained in more detail in the comments, shadow initialization cannot happen during regular global initialization. Instead, the location of the global section is marked using an ELF note, and we require libc support for calling a function provided by the HWASAN runtime when libraries are loaded and unloaded. Based on ideas discussed with @evgeny777 in D56672. Differential Revision: https://reviews.llvm.org/D65770 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368102 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Untag global variable addresses in tests.Peter Collingbourne2019-08-0514-42/+99
| | | | | | | | | | | | Once we start instrumenting globals, all addresses including those of string literals that we pass to the operating system will start being tagged. Since we can't rely on the operating system to be able to cope with these addresses, we need to untag them before passing them to the operating system. This change introduces a macro that does so and uses it everywhere it is needed. Differential Revision: https://reviews.llvm.org/D65768 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@367938 91177308-0d34-0410-b5e6-96231b3b80d8
* More follow-up to r367851Nico Weber2019-08-053-3/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@367856 91177308-0d34-0410-b5e6-96231b3b80d8
* compiler-rt: Rename cc files in test/hwasan/TestCases subdirectories as wellNico Weber2019-08-054-0/+0
| | | | | | | Should've been part of r367849. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@367851 91177308-0d34-0410-b5e6-96231b3b80d8
* compiler-rt: Rename .cc file in test/hwasan to .cppNico Weber2019-08-0513-6/+6
| | | | | | | Like r367463, but for test/hwasan. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@367849 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Use C++ driver for cfi.cc test.Peter Collingbourne2019-07-171-1/+1
| | | | | | | | | | | | | | It turns out that this test was only passing by accident. It was relying on the optimizer to remove the only reference to A's vtable by realizing that the CFI check will always fail. The vtable contains a reference to RTTI in libc++, which will be unresolved because the C driver won't link against it. This was found by my prototype implementation of HWASAN for globals, which happens to end up preserving the reference. Differential Revision: https://reviews.llvm.org/D64890 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@366389 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Improve precision of checks using short granule tags.Peter Collingbourne2019-07-094-64/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A short granule is a granule of size between 1 and `TG-1` bytes. The size of a short granule is stored at the location in shadow memory where the granule's tag is normally stored, while the granule's actual tag is stored in the last byte of the granule. This means that in order to verify that a pointer tag matches a memory tag, HWASAN must check for two possibilities: * the pointer tag is equal to the memory tag in shadow memory, or * the shadow memory tag is actually a short granule size, the value being loaded is in bounds of the granule and the pointer tag is equal to the last byte of the granule. Pointer tags between 1 to `TG-1` are possible and are as likely as any other tag. This means that these tags in memory have two interpretations: the full tag interpretation (where the pointer tag is between 1 and `TG-1` and the last byte of the granule is ordinary data) and the short tag interpretation (where the pointer tag is stored in the granule). When HWASAN detects an error near a memory tag between 1 and `TG-1`, it will show both the memory tag and the last byte of the granule. Currently, it is up to the user to disambiguate the two possibilities. Because this functionality obsoletes the right aligned heap feature of the HWASAN memory allocator (and because we can no longer easily test it), the feature is removed. Also update the documentation to cover both short granule tags and outlined checks. Differential Revision: https://reviews.llvm.org/D63908 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@365551 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Teach the runtime to identify the local variable being accessed in ↵Peter Collingbourne2019-06-273-13/+53
| | | | | | | | | | | | | | UAR reports. Each function's PC is recorded in the ring buffer. From there we can access the function's local variables and reconstruct the tag of each one with the help of the information printed by llvm-symbolizer's new FRAME command. We can then find the variable that was likely being accessed by matching the pointer's tag against the reconstructed tag. Differential Revision: https://reviews.llvm.org/D63469 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@364607 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Rename lit.*.cfg.* -> lit.*.cfg.py.*Reid Kleckner2019-06-275-3/+3
| | | | | | | | | | | | | These lit configuration files are really Python source code. Using the .py file extension helps editors and tools use the correct language mode. LLVM and Clang already use this convention for lit configuration, this change simply applies it to all of compiler-rt. Reviewers: vitalybuka, dberris Differential Revision: https://reviews.llvm.org/D63658 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@364591 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Use bits [3..11) of the ring buffer entry address as the base stack tag.Peter Collingbourne2019-06-173-13/+16
| | | | | | | | | | | | | | This saves roughly 32 bytes of instructions per function with stack objects and causes us to preserve enough information that we can recover the original tags of all stack variables. Now that stack tags are deterministic, we no longer need to pass -hwasan-generate-tags-with-calls during check-hwasan. This also means that the new stack tag generation mechanism is exercised by check-hwasan. Differential Revision: https://reviews.llvm.org/D63360 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363636 91177308-0d34-0410-b5e6-96231b3b80d8
* Set an output file name for the override-new-delete.cpp test.Peter Collingbourne2019-06-071-1/+1
| | | | | | The android_compile.py script requires one. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@362764 91177308-0d34-0410-b5e6-96231b3b80d8
* [HWASAN] Make new/delete weakEugene Leviant2019-06-041-0/+23
| | | | | | | | | | This allows instrumenting programs which have their own versions of new and delete operators. Differential revision: https://reviews.llvm.org/D62794 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@362478 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Limit try-catch tests to aarch64.Evgeniy Stepanov2019-05-171-0/+3
| | | | | | | HWASan C++ tests do not do well on x86_64. Fixes https://bugs.llvm.org/show_bug.cgi?id=41923 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@361063 91177308-0d34-0410-b5e6-96231b3b80d8
* HWASan exception support.Evgeniy Stepanov2019-05-161-0/+60
| | | | | | | | | | | | | | | | | | Summary: Adds a call to __hwasan_handle_vfork(SP) at each landingpad entry. Reusing __hwasan_handle_vfork instead of introducing a new runtime call in order to be ABI-compatible with old runtime library. Reviewers: pcc Subscribers: kubamracek, hiraditya, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61968 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@360959 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Implement reallocarray.Evgeniy Stepanov2019-05-013-8/+25
| | | | | | | | | | | | | | | | Summary: It's a cross of calloc and realloc. Sanitizers implement calloc-like check for size overflow. Reviewers: vitalybuka, kcc Subscribers: kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61108 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359708 91177308-0d34-0410-b5e6-96231b3b80d8
* Removed regiser dump checks from FP unit test.Mitch Phillips2019-04-191-41/+14
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@358770 91177308-0d34-0410-b5e6-96231b3b80d8
* [HWASan] Added no-FP unit test for register dump.Mitch Phillips2019-04-191-12/+12
| | | | | | | | | | | | | | Summary: Unit test for D60798. Reviewers: eugenis Subscribers: kubamracek, #sanitizers, llvm-commits, pcc Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D60806 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@358769 91177308-0d34-0410-b5e6-96231b3b80d8
* Updated test case.Mitch Phillips2019-04-191-7/+19
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@358768 91177308-0d34-0410-b5e6-96231b3b80d8
* Added no-FP unit test for register dump.Mitch Phillips2019-04-191-0/+43
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@358767 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Enable -hwasan-allow-ifunc by default.Peter Collingbourne2019-04-091-2/+1
| | | | | | | | | It's been on in Android for a while without causing problems, so it's time to make it the default and remove the flag. Differential Revision: https://reviews.llvm.org/D60355 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@357960 91177308-0d34-0410-b5e6-96231b3b80d8
* [HWASan] Save + print registers when tag mismatch occurs in AArch64.Mitch Phillips2019-03-081-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change change the instrumentation to allow users to view the registers at the point at which tag mismatch occured. Most of the heavy lifting is done in the runtime library, where we save the registers to the stack and emit unwind information. This allows us to reduce the overhead, as very little additional work needs to be done in each __hwasan_check instance. In this implementation, the fast path of __hwasan_check is unmodified. There are an additional 4 instructions (16B) emitted in the slow path in every __hwasan_check instance. This may increase binary size somewhat, but as most of the work is done in the runtime library, it's manageable. The failure trace now contains a list of registers at the point of which the failure occured, in a format similar to that of Android's tombstones. It currently has the following format: Registers where the failure occurred (pc 0x0055555561b4): x0 0000000000000014 x1 0000007ffffff6c0 x2 1100007ffffff6d0 x3 12000056ffffe025 x4 0000007fff800000 x5 0000000000000014 x6 0000007fff800000 x7 0000000000000001 x8 12000056ffffe020 x9 0200007700000000 x10 0200007700000000 x11 0000000000000000 x12 0000007fffffdde0 x13 0000000000000000 x14 02b65b01f7a97490 x15 0000000000000000 x16 0000007fb77376b8 x17 0000000000000012 x18 0000007fb7ed6000 x19 0000005555556078 x20 0000007ffffff768 x21 0000007ffffff778 x22 0000000000000001 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007ffffff6f0 x30 00000055555561b4 ... and prints after the dump of memory tags around the buggy address. Every register is saved exactly as it was at the point where the tag mismatch occurs, with the exception of x16/x17. These registers are used in the tag mismatch calculation as scratch registers during __hwasan_check, and cannot be saved without affecting the fast path. As these registers are designated as scratch registers for linking, there should be no important information in them that could aid in debugging. Reviewers: pcc, eugenis Reviewed By: pcc, eugenis Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, hiraditya, jdoerfert, llvm-commits, #sanitizers Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58857 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355738 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan, asan] Intercept vfork.Evgeniy Stepanov2019-02-271-0/+32
| | | | | | | | | | | | | | | Summary: Intercept vfork on arm, aarch64, i386 and x86_64. Reviewers: pcc, vitalybuka Subscribers: kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58533 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355030 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Fix tests after .cc->.cpp renaming.Evgeniy Stepanov2019-02-271-2/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355028 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[asan] Fix vfork handling.", +1Evgeniy Stepanov2019-02-211-32/+0
| | | | | | Revert r354625, r354627 - multiple build failures. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354629 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan,asan] Intercept vfork.Evgeniy Stepanov2019-02-211-0/+32
| | | | | | | | | | | | | | Summary: AArch64 only for now. Reviewers: vitalybuka, pcc Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, jdoerfert, #sanitizers, llvm-commits, kcc Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58313 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354625 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix unsymbolized stack history printing.Evgeniy Stepanov2019-02-151-0/+5
| | | | | | | | | | | | | | | | | | | | | Summary: When symbols are unavailable, the current code prints sp: ... pc: ... (null) (null) instead of module name + offset. Change the output to include module name and offset, and also to match the regular sanitizer stack trace format so that it is recognized by symbolize.py out of the box. Reviewers: kcc, pcc Subscribers: kubamracek, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58267 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354157 91177308-0d34-0410-b5e6-96231b3b80d8
* Runtime flags for malloc bisection.Evgeniy Stepanov2019-02-151-0/+26
| | | | | | | | | | | | Reviewers: kcc, pcc Subscribers: kubamracek, mgorny, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58162 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354156 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix false positive when tag_in_malloc=0,tag_in_free=1.Evgeniy Stepanov2019-02-151-0/+51
| | | | | | | | | | | | | | | | Summary: With tag_in_free=1, malloc() can not assume that the memory is untagged, and needs to retag is to 0. Reviewers: pcc, kcc Subscribers: kubamracek, jfb, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58158 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354155 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Decorate /proc/self/maps better.Evgeniy Stepanov2019-02-061-0/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Refactor the way /proc/self/maps entries are annotated to support most (all?) posix platforms, with a special implementation for Android. Extend the set of decorated Mmap* calls. Replace shm_open with internal_open("/dev/shm/%s"). Shm_open is problematic because it calls libc open() which may be intercepted. Generic implementation has limits (max number of files under /dev/shm is 64K on my machine), which can be conceivably reached when sanitizing multiple programs at once. Android implemenation is essentially free, and enabled by default. The test in sanitizer_common is copied to hwasan and not reused directly because hwasan fails way too many common tests at the moment. Reviewers: pcc, vitalybuka Subscribers: srhines, kubamracek, jfb, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D57720 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@353255 91177308-0d34-0410-b5e6-96231b3b80d8
* gn build: Upgrade to NDK r19.Peter Collingbourne2019-02-051-1/+3
| | | | | | | | | | NDK r19 includes a sysroot that can be used directly by the compiler without creating a standalone toolchain, so we just need a handful of flags to point Clang there. Differential Revision: https://reviews.llvm.org/D57733 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@353139 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Implement print_module_map flag.Evgeniy Stepanov2019-01-251-0/+32
| | | | | | | | | | Reviewers: kcc, pcc Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D57130 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@352150 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Read shadow address from ifunc if we don't need a frame record.Peter Collingbourne2019-01-231-1/+2
| | | | | | | | | | | | | This saves a cbz+cold call in the interceptor ABI, as well as a realign in both ABIs, trading off a dcache entry against some branch predictor entries and some code size. Unfortunately the functionality is hidden behind a flag because ifunc is known to be broken on static binaries on Android. Differential Revision: https://reviews.llvm.org/D57084 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@351989 91177308-0d34-0410-b5e6-96231b3b80d8
* [HWASAN] Improve tag mismatch diagnosticsEugene Leviant2019-01-211-5/+7
| | | | | | | | | | Reports correct size and tags when either size is not power of two or offset to bad granule is not zero. Differential revision: https://reviews.llvm.org/D56603 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@351730 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Madvise away unused shadow.Evgeniy Stepanov2019-01-191-0/+70
| | | | | | | | | | | | | | | | | | Summary: Whenever a large shadow region is tagged to zero, madvise(DONT_NEED) as much of it as possible. This reduces shadow RSS on Android by 45% or so, and total memory use by 2-4%, probably even more on long running multithreaded programs. CPU time seems to be in the noise. Reviewers: kcc, pcc Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D56757 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@351620 91177308-0d34-0410-b5e6-96231b3b80d8
* compiler-rt/test: Add a couple of convenience features for Android.Peter Collingbourne2019-01-152-0/+4
| | | | | | | | | | | | | | | | Add a ANDROID_SERIAL_FOR_TESTING CMake variable. This lets you run the tests with multiple devices attached without having to set ANDROID_SERIAL. Add a mechanism for pushing files to the device. Currently most sanitizers require llvm-symbolizer and the sanitizer runtime to be pushed to the device. This lets the sanitizer make this happen automatically before running the tests by specifying the paths in the lit.site.cfg file. Differential Revision: https://reviews.llvm.org/D56712 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@351260 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Ignore loads and stores of size 0.Peter Collingbourne2019-01-091-0/+10
| | | | | | | | | | | | | | | | | | Now that memory intrinsics are instrumented, it's more likely that CheckAddressSized will be called with size 0. (It was possible before with IR like: %val = load [0 x i8], [0 x i8]* %ptr but I don't think clang will generate IR like that and the optimizer would normally remove it by the time it got anywhere near our pass anyway). The right thing to do in both cases is to disable the addressing checks (since the underlying memory intrinsic is a no-op), so that's what we do. Differential Revision: https://reviews.llvm.org/D56465 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@350683 91177308-0d34-0410-b5e6-96231b3b80d8
* Disable system-allocator-fallback.cc test on Android O and earlier.Peter Collingbourne2019-01-041-0/+4
| | | | | | | The dynamic loader on Android O appears to have a bug where it crashes when dlopening DF_1_GLOBAL libraries. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@350444 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Use system allocator to realloc and free untagged pointers in ↵Peter Collingbourne2019-01-042-1/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@350427 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Switch to 64 allocator with a dense size class map.Evgeniy Stepanov2019-01-032-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@350370 91177308-0d34-0410-b5e6-96231b3b80d8
* [HWASAN] Add support for memory intrinsicsEugene Leviant2018-12-201-0/+37
| | | | | | | | | | This is patch complements D55117 implementing __hwasan_mem* functions in runtime Differential revision: https://reviews.llvm.org/D55554 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@349730 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix typo in test cases as well.Peter Collingbourne2018-12-153-8/+8
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@349255 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Link ubsan_cxx to shared runtime library.Evgeniy Stepanov2018-12-121-0/+18
| | | | | | | | | | | | Summary: This is needed for C++-specific ubsan and cfi error reporting to work. Reviewers: kcc, vitalybuka Subscribers: srhines, kubamracek, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D55589 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@348986 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] make the heap-buffer-overflow.c test more robust and re-enable it. ↵Kostya Serebryany2018-11-171-3/+3
| | | | | | With malloc_align_right the relative offsets of heap chunks are less predictable to simply don't test for them. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@347118 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] implement free_checks_tail_magic=1Kostya Serebryany2018-11-171-0/+28
| | | | | | | | | | | | | | | | | | | | | | | Summary: With free_checks_tail_magic=1 (default) HWASAN writes magic bytes to the tail of every heap allocation (last bytes of the last granule, if the last granule is not fully used) and checks these bytes on free(). This feature will detect buffer overwires within the last granule at the time of free(). This is an alternative to malloc_align_right=[1289] that should have fewer compatibility issues. It is also weaker since it doesn't detect read overflows and reports bugs at free() instead of at access. Reviewers: eugenis Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D54656 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@347116 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] use reads instead of writes in a testKostya Serebryany2018-11-161-1/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@347107 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status