| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[sanitizer] Switch StackStore to 8 MiB blocks Larger blocks are more convenient for compressions. Blocks are allocated with MmapNoReserveOrDie to save some memory. Also it's 15% faster on StackDepotBenchmarkSuite Depends on D114464. Reviewed By: morehouse Differential Revision: https://reviews.llvm.org/D114488 | 4 年前 | |
[HWASan] Use page aliasing on x86_64. Userspace page aliasing allows us to use middle pointer bits for tags without untagging them before syscalls or accesses. This should enable easier experimentation with HWASan on x86_64 platforms. Currently stack, global, and secondary heap tagging are unsupported. Only primary heap allocations get tagged. Note that aliasing mode will not work properly in the presence of fork(), since heap memory will be shared between the parent and child processes. This mode is non-ideal; we expect Intel LAM to enable full HWASan support on x86_64 in the future. Reviewed By: vitalybuka, eugenis Differential Revision: https://reviews.llvm.org/D98875 | 5 年前 | |
compiler-rt: Rename .cc file in test/hwasan to .cpp Like r367463, but for test/hwasan. llvm-svn: 367849 | 6 年前 | |
[HWASan] Use page aliasing on x86_64. Userspace page aliasing allows us to use middle pointer bits for tags without untagging them before syscalls or accesses. This should enable easier experimentation with HWASan on x86_64 platforms. Currently stack, global, and secondary heap tagging are unsupported. Only primary heap allocations get tagged. Note that aliasing mode will not work properly in the presence of fork(), since heap memory will be shared between the parent and child processes. This mode is non-ideal; we expect Intel LAM to enable full HWASan support on x86_64 in the future. Reviewed By: vitalybuka, eugenis Differential Revision: https://reviews.llvm.org/D98875 | 5 年前 | |
[sanitizers] include build ids in stacks on linux. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D114294 | 4 年前 | |
Require lld for hwasan tests. 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. llvm-svn: 368111 | 6 年前 | |
compiler-rt: Rename .cc file in test/hwasan to .cpp Like r367463, but for test/hwasan. llvm-svn: 367849 | 6 年前 | |
[HWASan] Leave pointer tagged when calling memmove. Fixes a false positive that occurs when a user-implemented memmove is instrumented by HWASan. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D118180 | 4 年前 | |
[hwasan] Add __hwasan_add_frame_record to the hwasan interface Hwasan includes instructions in the prologue that mix the PC and SP and store it into the stack ring buffer stored at __hwasan_tls. This is a thread_local global exposed from the hwasan runtime. However, if TLS-mechanisms or the hwasan runtime haven't been setup yet, it will be invalid to access __hwasan_tls. This is the case for Fuchsia where we instrument libc, so some functions that are instrumented but can run before hwasan initialization will incorrectly access this global. Additionally, libc cannot have any TLS variables, so we cannot weakly define __hwasan_tls until the runtime is loaded. A way we can work around this is by moving the instructions into a hwasan function that does the store into the ring buffer and creating a weak definition of that function locally in libc. This way __hwasan_tls will not actually be referenced. This is not our long-term solution, but this will allow us to roll out hwasan in the meantime. This patch includes: - A new llvm flag for choosing to emit a libcall rather than instructions in the prologue (off by default) - The libcall for storing into the ringbuffer (__hwasan_add_frame_record) Differential Revision: https://reviews.llvm.org/D128387 | 3 年前 | |
[hwasan] Fix test with TCO eliminating free frame. This broke https://lab.llvm.org/buildbot/#/builders/37/builds/6016/steps/10/logs/stdio Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D107864 | 4 年前 | |
[AArch64][NFC] require aarch64 support for hwasan test This was breaking builds where the target is not enabled. Reviewed By: danielkiss, eugenis Differential Revision: https://reviews.llvm.org/D85412 | 5 年前 | |
Add no_sanitize('hwaddress') (and 'memtag', but that's a no-op). Currently, __attribute__((no_sanitize('hwaddress'))) is not possible. Add this piece of plumbing, and now that we properly support copying attributes between an old and a new global variable, add a regression test for the GlobalOpt bug that previously lost the attribute. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D127544 | 3 年前 | |
Add no_sanitize('hwaddress') (and 'memtag', but that's a no-op). Currently, __attribute__((no_sanitize('hwaddress'))) is not possible. Add this piece of plumbing, and now that we properly support copying attributes between an old and a new global variable, add a regression test for the GlobalOpt bug that previously lost the attribute. Reviewed By: aaron.ballman Differential Revision: https://reviews.llvm.org/D127544 | 3 年前 | |
[HWASan] Apply TagMaskByte to every global tag. Previously we only applied it to the first one, which could allow subsequent global tags to exceed the valid number of bits. Reviewed By: hctim Differential Revision: https://reviews.llvm.org/D112853 | 4 年前 | |
compiler-rt: Rename .cc file in test/hwasan to .cpp Like r367463, but for test/hwasan. llvm-svn: 367849 | 6 年前 | |
[hwasan] print exact mismatch offset for short granules. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D104463 | 4 年前 | |
[HWASan] Print short tags in tag mismatch description. I recently spent some extra time debugging a false positive because I didn't realize the "real" tag was in the short granule. Adding the short tag here makes it more obvious that we could be dealing with a short granule. Reviewed By: hctim, eugenis Differential Revision: https://reviews.llvm.org/D112949 | 4 年前 | |
[HWASan] Print short tags in __hwasan_print_shadow. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D112959 | 4 年前 | |
[HWASan] deflake hwasan_symbolize test Also enable on X86_64. The directory would change during the test execution. This should not necessarily prevent us from indexing a directory (a user might potentially do that if they specify a parent directory of the actual symbols directory, and change unrelated files). Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D125143 | 4 年前 | |
[hwasan] Reset current thread pointer on thread exit. Summary: This is necessary to handle calls to free() after __hwasan_thread_exit, which is possible in glibc. Also, add a null check to GetCurrentThread, otherwise the logic in GetThreadByBufferAddress turns it into a non-null value. This means that all of the checks for GetCurrentThread() != nullptr do not have any effect at all right now! Reviewers: pcc, hctim Subscribers: #sanitizers, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D79608 | 6 年前 | |
[HWASan] Intercept setjmp/longjmp on x86_64. Reviewed By: xiangzhangllvm Differential Revision: https://reviews.llvm.org/D109790 | 4 年前 | |
Revert "[hwasan] More realistic setjmp test." Breaks https://lab.llvm.org/buildbot/#/builders/sanitizer-x86_64-linux-qemu This reverts commit 5511bfdb671505c1e7968ab8ef6032414bba3852. | 4 年前 | |
[HWASan] Disable LTO test on aarch64. It fails for non-Android aarch64 bots as well. | 4 年前 | |
[hwasan] Fix allocator alignment. Summary: Fix hwasan allocator not respecting the requested alignment when it is higher than a page, but still within primary (i.e. [2048, 65536]). Reviewers: pcc, hctim, cryptoad Subscribers: #sanitizers, llvm-commits Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D79656 | 6 年前 | |
[hwasan] Fix new[] with zero size. Fixes "allocator is out of memory trying to allocate 0x0 bytes" by always allocating at least one byte. llvm-svn: 341229 | 7 年前 | |
Runtime flags for malloc bisection. Reviewers: kcc, pcc Subscribers: kubamracek, mgorny, jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D58162 llvm-svn: 354156 | 7 年前 | |
[HWASan] Use page aliasing on x86_64. Userspace page aliasing allows us to use middle pointer bits for tags without untagging them before syscalls or accesses. This should enable easier experimentation with HWASan on x86_64 platforms. Currently stack, global, and secondary heap tagging are unsupported. Only primary heap allocations get tagged. Note that aliasing mode will not work properly in the presence of fork(), since heap memory will be shared between the parent and child processes. This mode is non-ideal; we expect Intel LAM to enable full HWASan support on x86_64 in the future. Reviewed By: vitalybuka, eugenis Differential Revision: https://reviews.llvm.org/D98875 | 5 年前 | |
[HWASan] Use page aliasing on x86_64. Userspace page aliasing allows us to use middle pointer bits for tags without untagging them before syscalls or accesses. This should enable easier experimentation with HWASan on x86_64 platforms. Currently stack, global, and secondary heap tagging are unsupported. Only primary heap allocations get tagged. Note that aliasing mode will not work properly in the presence of fork(), since heap memory will be shared between the parent and child processes. This mode is non-ideal; we expect Intel LAM to enable full HWASan support on x86_64 in the future. Reviewed By: vitalybuka, eugenis Differential Revision: https://reviews.llvm.org/D98875 | 5 年前 | |
hwasan: Ignore loads and stores of size 0. 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 llvm-svn: 350683 | 7 年前 | |
[hwasan] print exact mismatch offset for short granules. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D104463 | 4 年前 | |
[HWASan] Properly handle musttail calls. Fixes a compile error when the clang::musttail attribute is used. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D118712 | 4 年前 | |
[NFC][hwasan] Check __GLIBCXX__ before checking _GLIBCXX_RELEASE in test _GLIBCXX_RELEASE wasn't defined before GCC 7.1. This is another follow-up to https://reviews.llvm.org/D119161 | 4 年前 | |
Set an output file name for the override-new-delete.cpp test. The android_compile.py script requires one. llvm-svn: 362764 | 6 年前 | |
[HWASan] Add __hwasan_init to .preinit_array. Fixes segfaults on x86_64 caused by instrumented code running before shadow is set up. Reviewed By: pcc Differential Revision: https://reviews.llvm.org/D118171 | 4 年前 | |
[hwasan] Re-enable print-memory-usage-android test. The problem was not in a non-rooted device, but in tagged local variable address passed to a system call, see comments in the code. llvm-svn: 341875 | 7 年前 | |
[hwasan] relax the rint-memory-usage.c test further llvm-svn: 341625 | 7 年前 | |
[hwasan] Implement print_module_map flag. Reviewers: kcc, pcc Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D57130 llvm-svn: 352150 | 7 年前 | |
[HWASan] Ensure RNG is initialized in GenerateRandomTag Fixes a CHECK-failure caused by glibc's pthread_getattr_np implementation calling realloc. Essentially, Thread::GenerateRandomTag gets called during Thread::Init and before Thread::InitRandomState: HWAddressSanitizer: CHECK failed: hwasan_thread.cpp:134 "((random_buffer_)) != (0)" (0x0, 0x0) (tid=314) #0 0x55845475a662 in __hwasan::CheckUnwind() #1 0x558454778797 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) #2 0x558454766461 in __hwasan::Thread::GenerateRandomTag(unsigned long) #3 0x55845475c58b in __hwasan::HwasanAllocate(__sanitizer::StackTrace*, unsigned long, unsigned long, bool) #4 0x55845475c80a in __hwasan::hwasan_realloc(void*, unsigned long, __sanitizer::StackTrace*) #5 0x5584547608aa in realloc #6 0x7f6f3a3d8c2c in pthread_getattr_np #7 0x5584547790dc in __sanitizer::GetThreadStackTopAndBottom(bool, unsigned long*, unsigned long*) #8 0x558454779651 in __sanitizer::GetThreadStackAndTls(bool, unsigned long*, unsigned long*, unsigned long*, unsigned long*) #9 0x558454761bca in __hwasan::Thread::InitStackAndTls(__hwasan::Thread::InitState const*) #10 0x558454761e5c in __hwasan::HwasanThreadList::CreateCurrentThread(__hwasan::Thread::InitState const*) #11 0x55845476184f in __hwasan_thread_enter #12 0x558454760def in HwasanThreadStartFunc(void*) #13 0x7f6f3a3d6fa2 in start_thread #14 0x7f6f3a15b4ce in __clone Also reverts 7a3fb71c3cbdd80666335fa8f6f071b43f0b922a, as it's now unneeded. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D113045 | 4 年前 | |
[hwasan] fix pthread_exit llvm-svn: 341594 | 7 年前 | |
[hwasan] use thread-local ring buffers to properly report heap-use-after-free llvm-svn: 341133 | 7 年前 | |
compiler-rt: Rename .cc file in test/hwasan to .cpp Like r367463, but for test/hwasan. llvm-svn: 367849 | 6 年前 | |
[HWASan] Disable stack, globals and force callbacks for x86_64. Subsequent patches will implement page-aliasing mode for x86_64, which will initially only work for the primary heap allocator. We force callback instrumentation to simplify the initial aliasing implementation. Reviewed By: vitalybuka, eugenis Differential Revision: https://reviews.llvm.org/D98069 | 5 年前 | |
[compiler-rt][hwasan] Update register-dump-read.c test Since d564cfb53c71dbbbd46b6719f5fe53d70313de45 moved __hwasan_tag_mismatch4 this test has been reporting a frame 0 of __hwasan_tag_mismatch_v2. This failure can be seen on our bots: https://lab.llvm.org/buildbot/#/builders/185/builds/170 Before the change: #0 0xaaaaba100e40 in main <...>/register-dump-read.c:21:10 After the change: #0 0xaaaab8494bec in __hwasan_tag_mismatch_v2 <...>/hwasan/hwasan_tag_mismatch_aarch64.S:147 #1 0xaaaab84b4df8 in main <..>/register-dump-read.c:14:10 Update the test to check for a main frame as either frame 0 or frame 1. | 4 年前 | |
[HWASan] Add basic stack tagging support for LAM. Adds the basic instrumentation needed for stack tagging. Currently does not support stack short granules or TLS stack histories, since a different code path is followed for the callback instrumentation we use. We may simply wait to support these two features until we switch to a custom calling convention. Patch By: xiangzhangllvm, morehouse Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D102901 | 4 年前 | |
compiler-rt: Rename .cc file in test/hwasan to .cpp Like r367463, but for test/hwasan. llvm-svn: 367849 | 6 年前 | |
[HWASan] Use page aliasing on x86_64. Userspace page aliasing allows us to use middle pointer bits for tags without untagging them before syscalls or accesses. This should enable easier experimentation with HWASan on x86_64 platforms. Currently stack, global, and secondary heap tagging are unsupported. Only primary heap allocations get tagged. Note that aliasing mode will not work properly in the presence of fork(), since heap memory will be shared between the parent and child processes. This mode is non-ideal; we expect Intel LAM to enable full HWASan support on x86_64 in the future. Reviewed By: vitalybuka, eugenis Differential Revision: https://reviews.llvm.org/D98875 | 5 年前 | |
[hwasan] Always untag short granule in shadow. Fixes a regression when the allocator is disabled, and a dirty allocation is re-used. This only occurs when the allocator is disabled, so a test-only fix, but still necessary. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D108650 | 4 年前 | |
[compiler-rt][sanitizer] Have all OOM-related error messages start with the same format This way downstream tools that read sanitizer output can differentiate between OOM errors reported by sanitizers from other sanitizer errors. Changes: - Introduce ErrorIsOOM for checking if a platform-specific error code from an "mmap" is an OOM err. - Add ReportOOMError which just prepends this error message to the start of a Report call. - Replace some Reports for OOMs with calls to ReportOOMError. - Update necessary tests. Differential Revision: https://reviews.llvm.org/D127161 | 3 年前 | |
[hwasan] Add __hwasan_add_frame_record to the hwasan interface Hwasan includes instructions in the prologue that mix the PC and SP and store it into the stack ring buffer stored at __hwasan_tls. This is a thread_local global exposed from the hwasan runtime. However, if TLS-mechanisms or the hwasan runtime haven't been setup yet, it will be invalid to access __hwasan_tls. This is the case for Fuchsia where we instrument libc, so some functions that are instrumented but can run before hwasan initialization will incorrectly access this global. Additionally, libc cannot have any TLS variables, so we cannot weakly define __hwasan_tls until the runtime is loaded. A way we can work around this is by moving the instructions into a hwasan function that does the store into the ring buffer and creating a weak definition of that function locally in libc. This way __hwasan_tls will not actually be referenced. This is not our long-term solution, but this will allow us to roll out hwasan in the meantime. This patch includes: - A new llvm flag for choosing to emit a libcall rather than instructions in the prologue (off by default) - The libcall for storing into the ringbuffer (__hwasan_add_frame_record) Differential Revision: https://reviews.llvm.org/D128387 | 3 年前 | |
[hwasan] Fix incorrect candidate matching for stack OOB. We would find an address with matching tag, only to discover in ShowCandidate that it's very far away from [stack]. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105197 | 4 年前 | |
[HWASan] Add basic stack tagging support for LAM. Adds the basic instrumentation needed for stack tagging. Currently does not support stack short granules or TLS stack histories, since a different code path is followed for the callback instrumentation we use. We may simply wait to support these two features until we switch to a custom calling convention. Patch By: xiangzhangllvm, morehouse Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D102901 | 4 年前 | |
[HWASan] Add basic stack tagging support for LAM. Adds the basic instrumentation needed for stack tagging. Currently does not support stack short granules or TLS stack histories, since a different code path is followed for the callback instrumentation we use. We may simply wait to support these two features until we switch to a custom calling convention. Patch By: xiangzhangllvm, morehouse Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D102901 | 4 年前 | |
[hwasan] Add __hwasan_add_frame_record to the hwasan interface Hwasan includes instructions in the prologue that mix the PC and SP and store it into the stack ring buffer stored at __hwasan_tls. This is a thread_local global exposed from the hwasan runtime. However, if TLS-mechanisms or the hwasan runtime haven't been setup yet, it will be invalid to access __hwasan_tls. This is the case for Fuchsia where we instrument libc, so some functions that are instrumented but can run before hwasan initialization will incorrectly access this global. Additionally, libc cannot have any TLS variables, so we cannot weakly define __hwasan_tls until the runtime is loaded. A way we can work around this is by moving the instructions into a hwasan function that does the store into the ring buffer and creating a weak definition of that function locally in libc. This way __hwasan_tls will not actually be referenced. This is not our long-term solution, but this will allow us to roll out hwasan in the meantime. This patch includes: - A new llvm flag for choosing to emit a libcall rather than instructions in the prologue (off by default) - The libcall for storing into the ringbuffer (__hwasan_add_frame_record) Differential Revision: https://reviews.llvm.org/D128387 | 3 年前 | |
[hwasan] Add __hwasan_add_frame_record to the hwasan interface Hwasan includes instructions in the prologue that mix the PC and SP and store it into the stack ring buffer stored at __hwasan_tls. This is a thread_local global exposed from the hwasan runtime. However, if TLS-mechanisms or the hwasan runtime haven't been setup yet, it will be invalid to access __hwasan_tls. This is the case for Fuchsia where we instrument libc, so some functions that are instrumented but can run before hwasan initialization will incorrectly access this global. Additionally, libc cannot have any TLS variables, so we cannot weakly define __hwasan_tls until the runtime is loaded. A way we can work around this is by moving the instructions into a hwasan function that does the store into the ring buffer and creating a weak definition of that function locally in libc. This way __hwasan_tls will not actually be referenced. This is not our long-term solution, but this will allow us to roll out hwasan in the meantime. This patch includes: - A new llvm flag for choosing to emit a libcall rather than instructions in the prologue (off by default) - The libcall for storing into the ringbuffer (__hwasan_add_frame_record) Differential Revision: https://reviews.llvm.org/D128387 | 3 年前 | |
[hwasan] Check for overflow when searching candidates. If the fault address is at the boundary of memory regions, this could cause us to segfault otherwise. Ran test with old compiler_rt to make sure it fails. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D105032 | 4 年前 | |
Fix false positive when tag_in_malloc=0,tag_in_free=1. 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 llvm-svn: 354155 | 7 年前 | |
[hwasan] Don't report short-granule shadow as overwritten. The shadow for a short granule is stored in the last byte of the granule. Currently, if there's a tail-overwrite report (a buffer-overflow-write in uninstrumented code), we report the shadow byte as a mismatch against the magic. Fix this bug by slapping the shadow into the expected value. This also makes sure that if the uninstrumented WRITE does clobber the shadow byte, it reports the shadow was actually clobbered as well. Reviewed By: eugenis, fmayer Differential Revision: https://reviews.llvm.org/D107938 | 4 年前 | |
[HWASan] Ensure RNG is initialized in GenerateRandomTag Fixes a CHECK-failure caused by glibc's pthread_getattr_np implementation calling realloc. Essentially, Thread::GenerateRandomTag gets called during Thread::Init and before Thread::InitRandomState: HWAddressSanitizer: CHECK failed: hwasan_thread.cpp:134 "((random_buffer_)) != (0)" (0x0, 0x0) (tid=314) #0 0x55845475a662 in __hwasan::CheckUnwind() #1 0x558454778797 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) #2 0x558454766461 in __hwasan::Thread::GenerateRandomTag(unsigned long) #3 0x55845475c58b in __hwasan::HwasanAllocate(__sanitizer::StackTrace*, unsigned long, unsigned long, bool) #4 0x55845475c80a in __hwasan::hwasan_realloc(void*, unsigned long, __sanitizer::StackTrace*) #5 0x5584547608aa in realloc #6 0x7f6f3a3d8c2c in pthread_getattr_np #7 0x5584547790dc in __sanitizer::GetThreadStackTopAndBottom(bool, unsigned long*, unsigned long*) #8 0x558454779651 in __sanitizer::GetThreadStackAndTls(bool, unsigned long*, unsigned long*, unsigned long*, unsigned long*) #9 0x558454761bca in __hwasan::Thread::InitStackAndTls(__hwasan::Thread::InitState const*) #10 0x558454761e5c in __hwasan::HwasanThreadList::CreateCurrentThread(__hwasan::Thread::InitState const*) #11 0x55845476184f in __hwasan_thread_enter #12 0x558454760def in HwasanThreadStartFunc(void*) #13 0x7f6f3a3d6fa2 in start_thread #14 0x7f6f3a15b4ce in __clone Also reverts 7a3fb71c3cbdd80666335fa8f6f071b43f0b922a, as it's now unneeded. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D113045 | 4 年前 | |
[hwasan] Workaround unwinder issues in try-catch test. Android links the unwinder library to every DSO. The problem is, unwinder has global state, and hwasan implementation of personality function wrapper happens to rub it the wrong way. Switch the test to static libc++ as a temporary workaround. llvm-svn: 375471 | 6 年前 | |
[hwasan] On every use-after-free print a developer note: the index of this heap object in the thread's deallocation ring buffer. Mostly useful to hwasan developers, will hopefully let us know the good size of the deallocation ring buffer llvm-svn: 342014 | 7 年前 | |
[hwasan] Display causes in order of probability. A heap or global buffer that is far away from the faulting address is unlikely to be the cause, especially if there is a potential use-after-free as well, so we want to show it after the other causes. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D104781 | 4 年前 | |
[hwasan] Fix test on x86. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D107816 | 4 年前 | |
[hwasan] Commit missed REQUIRES: stable-runtime. Differential Revision: https://reviews.llvm.org/D107268 | 4 年前 | |
[hwasan] Detect use after scope within function. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105201 | 4 年前 | |
[hwasan] Detect use after scope within function. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105201 | 4 年前 | |
[hwasan] Detect use after scope within function. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105201 | 4 年前 | |
[hwasan] Detect use after scope within function. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105201 | 4 年前 | |
[hwasan] Detect use after scope within function. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105201 | 4 年前 | |
[hwasan] Detect use after scope within function. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105201 | 4 年前 | |
[hwasan] Detect use after scope within function. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105201 | 4 年前 | |
[hwasan] Detect use after scope within function. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105201 | 4 年前 | |
[hwasan] work around lifetime issue with setjmp. setjmp can return twice, but PostDominatorTree is unaware of this. as such, it overestimates postdominance, leaving some cases (see attached compiler-rt) where memory does not get untagged on return. this causes false positives later in the program execution. this is a crude workaround to unblock use-after-scope for now, in the longer term PostDominatorTree should bemade aware of returns_twice function, as this may cause problems elsewhere. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D118647 | 4 年前 | |
[hwasan] Detect use after scope within function. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105201 | 4 年前 | |
[hwasan] Detect use after scope within function. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105201 | 4 年前 | |
[hwasan] Test use-after-scope with -fno-exceptions. Reviewed By: hctim Differential Revision: https://reviews.llvm.org/D109224 | 4 年前 | |
[hwasan] Detect use after scope within function. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D105201 | 4 年前 | |
[hwasan] Fix wild free tests on x86. | 4 年前 | |
[hwasan] do not check if freed pointer belonged to allocator. In that case it is very likely that there will be a tag mismatch anyway. We handle the case that the pointer belongs to neither of the allocators by getting a nullptr from allocator.GetBlockBegin. Reviewed By: hctim, eugenis Differential Revision: https://reviews.llvm.org/D108383 | 4 年前 | |
[hwasan] Fix wild free tests on x86. | 4 年前 | |
[hwasan] do not check if freed pointer belonged to allocator. In that case it is very likely that there will be a tag mismatch anyway. We handle the case that the pointer belongs to neither of the allocators by getting a nullptr from allocator.GetBlockBegin. Reviewed By: hctim, eugenis Differential Revision: https://reviews.llvm.org/D108383 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 5 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 6 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 |