VVitaly Buka[NFC] Clang-format D129645
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[HWASan symbolize] Write error to stderr. | 4 年前 | |
Revert "sanitizers: increase .clang-format columns to 100" This reverts commit 5d1df6d220f1d6f726d9643848679d781750db64. There is a strong objection to this change: https://reviews.llvm.org/D106436#2905618 Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D106847 | 4 年前 | |
[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] 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 年前 | |
[NFC][sanitizer] Remove unnececary HOOK macros | 4 年前 | |
Hardware-assisted AddressSanitizer (compiler-rt) 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 | 8 年前 | |
[sanitizer] Switch dlsym hack to internal_allocator Since glibc 2.34, dlsym does 1. malloc 1 2. malloc 2 3. free pointer from malloc 1 4. free pointer from malloc 2 These sequence was not handled by trivial dlsym hack. This fixes https://bugs.llvm.org/show_bug.cgi?id=52278 Reviewed By: eugenis, morehouse Differential Revision: https://reviews.llvm.org/D112588 | 4 年前 | |
[NFC][sanitizer] Consolidate malloc hook invocations | 4 年前 | |
[compiler-rt][hwasan] Add GetShadowOffset function Similar to SHADOW_OFFSET on asan, we can use this for hwasan so platforms that use a constant value for the start of shadow memory can just use the constant rather than access a global. Differential Revision: https://reviews.llvm.org/D104275 | 4 年前 | |
[HWASan] Refactor in preparation for x86 aliasing mode. NFC Reviewed By: vitalybuka, eugenis Differential Revision: https://reviews.llvm.org/D98373 | 5 年前 | |
[compiler-rt][hwasan][Fuchsia] Do not emit FindDynamicShadowStart for Fuchsia This function is unused because fuchsia does not support a dynamic shadow. Differential Revision: https://reviews.llvm.org/D105735 | 4 年前 | |
hwasan: Add __hwasan_init_static() function. 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 llvm-svn: 352816 | 7 年前 | |
[hwasan] Replace _Unwind_Word with uintptr_t GCC introduced __attribute__((mode(unwind_word))) to work around Cell Broadband Engine SPU (which was removed from GCC in 2019-09), which is irrelevant to hwasan. _Unwind_GetGR/_Unwind_GetCFA from llvm-project/libunwind don't use unwind_word. Using _Unwind_Word can lead to build failures if libunwind's unwind.h is preferred over unwind.h in the Clang resource directory (e.g. built with GCC). | 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 年前 | |
[NFC] Remove tab from the source | 5 年前 | |
[hwasan][fuchsia] Fix features bitmask checking Update the address tagging bitmask check to just see if ZX_ARM64_FEATURE_ADDRESS_TAGGING_TBI is enabled rather than checking if it's the only thing that's enabled. Differential Revision: https://reviews.llvm.org/D129318 | 3 年前 | |
[HWASan] Add sizeof(global) in report even if symbols missing. Summary: Refactor the current global header iteration to be callback-based, and add a feature that reports the size of the global variable during reporting. This allows binaries without symbols to still report the size of the global variable, which is always available in the HWASan globals PT_NOTE metadata. Reviewers: eugenis, pcc Reviewed By: pcc Subscribers: mgorny, llvm-commits, #sanitizers Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D80599 | 5 年前 | |
[HWASan] Add sizeof(global) in report even if symbols missing. Summary: Refactor the current global header iteration to be callback-based, and add a feature that reports the size of the global variable during reporting. This allows binaries without symbols to still report the size of the global variable, which is always available in the HWASan globals PT_NOTE metadata. Reviewers: eugenis, pcc Reviewed By: pcc Subscribers: mgorny, llvm-commits, #sanitizers Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D80599 | 5 年前 | |
[clang] accept -fsanitize-ignorelist= in addition to -fsanitize-blacklist= Use that for internal names (including the default ignorelists of the sanitizers). Differential Revision: https://reviews.llvm.org/D101832 | 5 年前 | |
[sanitizer] DEFINE_REAL_PTHREAD_FUNCTIONS for hwasan, lsan, msan It should be NFC, as they already intercept pthread_create. This will let us to fix BackgroundThread for these sanitizerts. In in followup patches I will fix MaybeStartBackgroudThread for them and corresponding tests. Reviewed By: kstoimenov Differential Revision: https://reviews.llvm.org/D114935 | 4 年前 | |
[compiler-rt][aarch64] Add PAC-RET/BTI property to hwasan_interceptors_vfork.S D100143 added similar annotations but missed this file. Differential Revision: https://reviews.llvm.org/D100354 | 5 年前 | |
[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 年前 | |
[NFC] Clang-format D129645 | 3 年前 | |
[compiler-rt] [hwasan] Replace INLINE with inline Fixes the build after landing D87562. | 5 年前 | |
[compiler-rt][hwasan] Refactor kAliasRegionStart usage This moves logic for setting kAliasRegionStart into hwasan_allocator.cpp so other platforms that do not support aliasing mode will not need to define kAliasRegionStart. Differential Revision: https://reviews.llvm.org/D105725 | 4 年前 | |
[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] Use hwasan_memalign for aligned new. Aligned new does not require size to be a multiple of alignment, so memalign is the correct choice instead of aligned_alloc. Fixes false reports for unaligned sizes. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D119161 | 4 年前 | |
[NFC][compiler-rt][hwasan] Move TagMemoryAligned into hwasan_linux.cpp Based on comments in D91466, we can make the current implementation linux-speciic. The fuchsia implementation will just be a call to __sanitizer_fill_shadow. Differential Revision: https://reviews.llvm.org/D105663 | 4 年前 | |
Update the file headers across all of the LLVM projects in the monorepo 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 | 7 年前 | |
[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 年前 | |
Enable -Wformat-pedantic and fix fallout. Differential Revision: https://reviews.llvm.org/D113172 | 4 年前 | |
hwasan: Improve precision of checks using short granule tags. 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 llvm-svn: 365551 | 6 年前 | |
[HWASan] Use a single .weak binding in asm. Specifying .global and .weak causes a compiler warning: warning: __sigsetjmp changed binding to STB_WEAK Specifying only .weak should have the same effect without causing a warning. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D110178 | 4 年前 | |
Reland [sanitizer] Support Intel CET 1. Include <cet.h> in sanitizer_common/sanitizer_asm.h, if it exists, to mark Intel CET support when Intel CET is enabled. 2. Define _CET_ENDBR as empty if it isn't defined. 3. Add _CET_ENDBR to function entries in assembly codes so that ENDBR instruction will be generated when Intel CET is enabled. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D111185 | 4 年前 | |
[compiler-rt][aarch64] Add PAC-RET/BTI support to HWASAN. Support for -mbranch-protection. Reviewed By: eugenis Differential Revision: https://reviews.llvm.org/D100143 | 5 年前 | |
[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] 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 年前 | |
[NFC] test commit, fix namespace ending comment. | 4 年前 | |
[NFC][compiler-rt][hwasan] Re-use ring buffer size calculation Users can call HwasanThreadList::GetRingBufferSize rather than RingBufferSize to prevent having to do the calculation in RingBufferSize. This will be useful for Fuchsia where we plan to initialize the stack ring buffer separately from the rest of thread initialization. Differential Revision: https://reviews.llvm.org/D104823 | 4 年前 | |
[HWASan] Intercept setjmp/longjmp on x86_64. Reviewed By: xiangzhangllvm Differential Revision: https://reviews.llvm.org/D109790 | 4 年前 |