summaryrefslogtreecommitdiff
path: root/lib/hwasan
Commit message (Collapse)AuthorAgeFilesLines
* hwasan: Compatibility fixes for short granules.Peter Collingbourne2019-09-271-2/+48
| | | | | | | | | | | | | | | | | | | | | | | | | We can't use short granules with stack instrumentation when targeting older API levels because the rest of the system won't understand the short granule tags stored in shadow memory. Moreover, we need to be able to let old binaries (which won't understand short granule tags) run on a new system that supports short granule tags. Such binaries will call the __hwasan_tag_mismatch function when their outlined checks fail. We can compensate for the binary's lack of support for short granules by implementing the short granule part of the check in the __hwasan_tag_mismatch function. Unfortunately we can't do anything about inline checks, but I don't believe that we can generate these by default on aarch64, nor did we do so when the ABI was fixed. A new function, __hwasan_tag_mismatch_v2, is introduced that lets code targeting the new runtime avoid redoing the short granule check. Because tag mismatches are rare this isn't important from a performance perspective; the main benefit is that it introduces a symbol dependency that prevents binaries targeting the new runtime from running on older (i.e. incompatible) runtimes. Differential Revision: https://reviews.llvm.org/D68059 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373035 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Better lint output for .inc filesVitaly Buka2019-09-121-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@371702 91177308-0d34-0410-b5e6-96231b3b80d8
* Remove NOLINTs from compiler-rtVitaly Buka2019-09-111-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@371687 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Align n_namesz and n_descsz to 4 when reading notes.Peter Collingbourne2019-08-231-2/+2
| | | | | | | | | | There is no requirement for the producer of a note to include the note alignment in these fields. As a result we can end up missing the HWASAN note if one of the other notes in the binary has the alignment missing. Differential Revision: https://reviews.llvm.org/D66692 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@369826 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Untag unwound stack frames by wrapping personality functions.Peter Collingbourne2019-08-232-0/+65
| | | | | | | | | | | | | | | | | | | | | | | 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
* hwasan: Add a code model check for tagged globals.Peter Collingbourne2019-08-081-4/+34
| | | | | | | | | | See D65364 for the code model requirements for tagged globals. Because of the relocations used these requirements cannot be checked at link time so they must be checked at runtime. Differential Revision: https://reviews.llvm.org/D65968 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@368351 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Instrument globals.Peter Collingbourne2019-08-064-20/+138
| | | | | | | | | | | | | | | | | | 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
* [Sanitizer] Linux refactor shadow huge page mode handlingDavid Carlier2019-08-051-2/+1
| | | | | | | | | | | | Disabling Transparent huge page mode refactored in one function. Reviewers: vitalybuka Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D65771 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@367925 91177308-0d34-0410-b5e6-96231b3b80d8
* compiler-rt: Call a generated c++ file in hwasan .cpp instead of .ccNico Weber2019-08-011-3/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@367572 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Improve precision of checks using short granule tags.Peter Collingbourne2019-07-095-127/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Fix an off-by-one error in PrintTagsAroundAddr.Peter Collingbourne2019-06-271-1/+1
| | | | | | | | Previously we were printing 16 rows of tags, not 17. Differential Revision: https://reviews.llvm.org/D63906 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@364609 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Teach the runtime to identify the local variable being accessed in ↵Peter Collingbourne2019-06-273-60/+78
| | | | | | | | | | | | | | 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
* hwasan: Use bits [3..11) of the ring buffer entry address as the base stack tag.Peter Collingbourne2019-06-171-0/+5
| | | | | | | | | | | | | | 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
* Improve error message when '=' is missing in {ASAN,...}_OPTIONS.Vitaly Buka2019-06-151-5/+2
| | | | | | | | | | | | | | | | | | Summary: It's handling isses as described here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832 Patch by Martin Liška. Reviewers: kcc, vitalybuka Reviewed By: vitalybuka Subscribers: cryptoad, kubamracek Differential Revision: https://reviews.llvm.org/D59876 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@363480 91177308-0d34-0410-b5e6-96231b3b80d8
* [HWASAN] Make new/delete weakEugene Leviant2019-06-041-8/+8
| | | | | | | | | | 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] Remove unused codeEugene Leviant2019-05-292-28/+0
| | | | | | | Differential revision: https://reviews.llvm.org/D62489 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@361942 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix some gcc warnings in compiler-rtNico Weber2019-05-101-2/+2
| | | | | | | | - Several "warning: extra ';' [-Wpedantic]" - One "C++ style comments are not allowed in ISO C90 [enabled by default]" in a file that uses C style comments everywhere but in one place git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@360430 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Fix HWASAN_WITH_INTERCEPTORS=OFF build on not-android.Evgeniy Stepanov2019-05-031-1/+11
| | | | | | | | | | | | | | | | | Summary: I'm not aware of any platforms where this will work, but the code should at least compile. HWASAN_WITH_INTERCEPTORS=OFF means there is magic in libc that would call __hwasan_thread_enter / __hwasan_thread_exit as appropriate. Reviewers: pcc, winksaville Subscribers: srhines, kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61337 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359914 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359719 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@359715 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Implement reallocarray.Evgeniy Stepanov2019-05-014-0/+20
| | | | | | | | | | | | | | | | 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
* [HWASan] Fixed slow DWARF unwinding.Mitch Phillips2019-04-161-3/+3
| | | | | | | | | | | | | | | | Summary: CFA was setup incorrectly, as there is an 8-byte gap at the top of the stack for SP 16-byte alignment purposes. Reviewers: eugenis Reviewed By: eugenis Subscribers: kubamracek, javed.absar, #sanitizers, llvm-commits, pcc Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D60798 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@358535 91177308-0d34-0410-b5e6-96231b3b80d8
* [HWASan] Use less Printf() calls in register dump.Mitch Phillips2019-03-141-16/+22
| | | | | | | | | | | | | | | | | | | | Summary: Explicitly print 4 registers/line in each iteration during register dump. Reduces logcat spam as we get a single logcat message per call to Printf(), even if the output isn't newline-terminated. This brings the output format in logcat closer to that of the normal textual dump. Reviewers: eugenis, pcc Reviewed By: pcc Subscribers: kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D59320 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@356166 91177308-0d34-0410-b5e6-96231b3b80d8
* [HWASan] Remove address significance from tag_mismatch.Mitch Phillips2019-03-111-6/+0
| | | | | | Actually fix the issue referenced in rL355840. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355844 91177308-0d34-0410-b5e6-96231b3b80d8
* [HWASan] Fixed minor AArch64/GCC build error.Mitch Phillips2019-03-111-0/+4
| | | | | | | Fixed buildbot clang-cmake-aarch64-lld by ensuring clang-only features are guarded by clang-only #defines. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355840 91177308-0d34-0410-b5e6-96231b3b80d8
* [HWASan] Save + print registers when tag mismatch occurs in AArch64.Mitch Phillips2019-03-086-8/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [NFC][Sanitizer] Make GetStackTrace a private method of BufferedStackTraceJulian Lettner2019-03-011-10/+8
| | | | | | | | | | | GetStackTrace is a implementation detail of BufferedStackTrace. Make it a private method. Reviewed By: vitalybuka Differential-Revision: https://reviews.llvm.org/D58753 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355232 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFC][Sanitizer] Add new BufferedStackTrace::Unwind APIJulian Lettner2019-03-012-11/+9
| | | | | | | | | | | | | | | | | | | | | Retrying without replacing call sites in sanitizer_common (which might not have a symbol definition). Add new Unwind API. This is the final envisioned API with the correct abstraction level. It hides/slow fast unwinder selection from the caller and doesn't take any arguments that would leak that abstraction (i.e., arguments like stack_top/stack_bottom). GetStackTrace will become an implementation detail (private method) of the BufferedStackTrace class. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58741 llvm-svn: 355168 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355172 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[NFC][Sanitizer] Add new BufferedStackTrace::Unwind API"Julian Lettner2019-03-012-9/+11
| | | | | | This reverts commit 6112f37e758ebf2405955e091a745f5003c1f562. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355171 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFC][Sanitizer] Add new BufferedStackTrace::Unwind APIJulian Lettner2019-03-012-11/+9
| | | | | | | | | | | | | | | | Add new Unwind API. This is the final envisioned API with the correct abstraction level. It hides/slow fast unwinder selection from the caller and doesn't take any arguments that would leak that abstraction (i.e., arguments like stack_top/stack_bottom). GetStackTrace will become an implementation detail (private method) of the BufferedStackTrace class. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58741 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355168 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Disable vfork code when building w/o interceptors.Evgeniy Stepanov2019-03-011-1/+1
| | | | | | Don't define vfork when OMPILER_RT_HWASAN_WITH_INTERCEPTORS=OFF. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355165 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Fix vfork handling with large stack limit.Evgeniy Stepanov2019-02-281-3/+1
| | | | | | | | | | | Remove the maximum stack cleanup size check. With ulimit -s unlimited main thread stack can be very large, but we don't really have a choice other than cleaning all of it. It should be reasonably fast - hwasan cleans large shadow ranges with a single madvise call. This change fixes check-hwasan after ulimit -s unlimited. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355137 91177308-0d34-0410-b5e6-96231b3b80d8
* [NFC][Sanitizer] Pull up GetStackTrace into sanitizer_commonJulian Lettner2019-02-272-23/+22
| | | | | | | | | | | | | | | | | | | | We already independently declare GetStackTrace in all (except TSan) sanitizer runtime headers. Lets move it to sanitizer_stacktrace.h to have one canonical way to fill in a BufferedStackFrame. Also enables us to use it in sanitizer_common itself. This patch defines GetStackTrace for TSan and moves the function from ubsan_diag.cc to ubsan_diag_standalone.cc to avoid duplicate symbols for the UBSan-ASan runtime. Other than that this patch just moves the code out of headers and into the correct namespace. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58651 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355039 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan, asan] Intercept vfork.Evgeniy Stepanov2019-02-276-1/+50
| | | | | | | | | | | | | | | 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
* [NFC][Sanitizer] Hard-code fast/slow unwinder at call siteJulian Lettner2019-02-271-2/+5
| | | | | | | | | | | | | Also assert that the caller always gets what it requested. This purely mechanical change simplifies future refactorings and eventual removal of BufferedStackTrace::Unwind. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58557 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@355022 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Rename source files from cc to cppNico Weber2019-02-2712-20/+21
| | | | | | | | | | | | | | | | | | | | As discussed elsewhere: LLVM uses cpp as its C++ source extension; the sanitizers should too. This updates files in hwasan. Patch generated by for f in lib/hwasan/*.cc ; do svn mv $f ${f%.cc}.cpp; done followed by for f in lib/hwasan/*.cpp ; do sed -i '' -e '1s/\.cc -/.cpp /' $f; done CMakeLists.txt updated manually. Differential Revision: https://reviews.llvm.org/D58620 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354989 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[asan] Fix vfork handling.", +1Evgeniy Stepanov2019-02-216-46/+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-216-0/+46
| | | | | | | | | | | | | | 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
* [compiler-rt] Cleanup usage of C++ ABI libraryJonas Hahnfeld2019-02-161-1/+1
| | | | | | | | | | | | | Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking unit tests. This needs to be a full C++ library and cannot be libcxxabi. Recommit r354132 which I reverted in r354153 because it broke a sanitizer bot. This was because of the "fixes" for pthread linking, so I've removed these changes. Differential Revision: https://reviews.llvm.org/D58012 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354198 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix unsymbolized stack history printing.Evgeniy Stepanov2019-02-151-2/+2
| | | | | | | | | | | | | | | | | | | | | 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-154-2/+67
| | | | | | | | | | | | 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-4/+10
| | | | | | | | | | | | | | | | 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
* Revert "[compiler-rt] Cleanup usage of C++ ABI library"Jonas Hahnfeld2019-02-151-1/+1
| | | | | | | This reverts r354132 because it breaks sanitizer-x86_64-linux: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/19915 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354153 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Cleanup usage of C++ ABI libraryJonas Hahnfeld2019-02-151-1/+1
| | | | | | | | | Add missed value "libcxxabi" and introduce SANITIZER_TEST_CXX for linking unit tests. This needs to be a full C++ library and cannot be libcxxabi. Differential Revision: https://reviews.llvm.org/D58012 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@354132 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Decorate /proc/self/maps better.Evgeniy Stepanov2019-02-061-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Mark __rela_iplt_{start,end} as weak.Peter Collingbourne2019-02-011-1/+1
| | | | | | Should fix non-lld links. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@352823 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Add __hwasan_init_static() function.Peter Collingbourne2019-01-318-19/+64
| | | | | | | | | | | This function initializes enough of the runtime to be able to run instrumented code in a statically linked executable. It replaces __hwasan_shadow_init() which wasn't doing enough initialization for instrumented code that uses either TLS or IFUNC to work. Differential Revision: https://reviews.llvm.org/D57490 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@352816 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Madvise away thread aux dataEvgeniy Stepanov2019-01-251-13/+29
| | | | | | | | | | | | | | | | | | | | Summary: Release memory pages for thread data (allocator cache, stack allocations ring buffer, etc) when a thread exits. We can not simply munmap them because this memory is custom allocated within a limited address range, and it needs to stay "reserved". This change alters thread storage layout by putting the ring buffer before Thread instead of after it. This makes it possible to find the start of the thread aux allocation given only the Thread pointer. Reviewers: kcc, pcc Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D56621 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@352151 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Implement print_module_map flag.Evgeniy Stepanov2019-01-252-7/+13
| | | | | | | | | | 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: Move memory access checks into small outlined functions on aarch64.Peter Collingbourne2019-01-231-8/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Each hwasan check requires emitting a small piece of code like this: https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#memory-accesses The problem with this is that these code blocks typically bloat code size significantly. An obvious solution is to outline these blocks of code. In fact, this has already been implemented under the -hwasan-instrument-with-calls flag. However, as currently implemented this has a number of problems: - The functions use the same calling convention as regular C functions. This means that the backend must spill all temporary registers as required by the platform's C calling convention, even though the check only needs two registers on the hot path. - The functions take the address to be checked in a fixed register, which increases register pressure. Both of these factors can diminish the code size effect and increase the performance hit of -hwasan-instrument-with-calls. The solution that this patch implements is to involve the aarch64 backend in outlining the checks. An intrinsic and pseudo-instruction are created to represent a hwasan check. The pseudo-instruction is register allocated like any other instruction, and we allow the register allocator to select almost any register for the address to check. A particular combination of (register selection, type of check) triggers the creation in the backend of a function to handle the check for specifically that pair. The resulting functions are deduplicated by the linker. The pseudo-instruction (really the function) is specified to preserve all registers except for the registers that the AAPCS specifies may be clobbered by a call. To measure the code size and performance effect of this change, I took a number of measurements using Chromium for Android on aarch64, comparing a browser with inlined checks (the baseline) against a browser with outlined checks. Code size: Size of .text decreases from 243897420 to 171619972 bytes, or a 30% decrease. Performance: Using Chromium's blink_perf.layout microbenchmarks I measured a median performance regression of 6.24%. The fact that a perf/size tradeoff is evident here suggests that we might want to make the new behaviour conditional on -Os/-Oz. But for now I've enabled it unconditionally, my reasoning being that hwasan users typically expect a relatively large perf hit, and ~6% isn't really adding much. We may want to revisit this decision in the future, though. I also tried experimenting with varying the number of registers selectable by the hwasan check pseudo-instruction (which would result in fewer variants being created), on the hypothesis that creating fewer variants of the function would expose another perf/size tradeoff by reducing icache pressure from the check functions at the cost of register pressure. Although I did observe a code size increase with fewer registers, I did not observe a strong correlation between the number of registers and the performance of the resulting browser on the microbenchmarks, so I conclude that we might as well use ~all registers to get the maximum code size improvement. My results are below: Regs | .text size | Perf hit -----+------------+--------- ~all | 171619972 | 6.24% 16 | 171765192 | 7.03% 8 | 172917788 | 5.82% 4 | 177054016 | 6.89% Differential Revision: https://reviews.llvm.org/D56954 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@351920 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status