search for: scudo

Greetings, compiler-rt hosts a hardened usermode memory allocator, named Scudo ( https://llvm.org/docs/ScudoHardenedAllocator.html). It aims at providing additional mitigation against heap-based vulnerabilities, while maintaining good performance. It leverages sanitizer_common code, and provides allocation primitives via the usual C/C++ functions. Up until now, Scudo was mos...

...SanitizerCommon-Unit :: Sanitizer-x86_64-Test/SanitizerLinux.ThreadDescriptorSize /tmp/llvm/utils/release/rc2/llvm.src/projects/compiler-rt/lib/sanitizer_common/tests/sanitizer_linux_test.cc:230: Failure Value of: ThreadDescriptorSize() Actual: 2288 Expected: (uptr)result Which is: 2304 Scudo :: alignment.cpp Scudo :: double-free.cpp Scudo :: malloc.cpp Scudo :: memalign.cpp Scudo :: mismatch.cpp Scudo :: overflow.cpp Scudo :: preinit.cpp Scudo :: quarantine.cpp Scudo :: realloc.cpp Scudo :: sized-delete.cpp Scudo :: sizes.cpp These ^^ fail to fi...

Hi, I just tagged 3.9.1-rc2, so testing can begin. There was a bug found in -rc1 before I could send out a release announcement, so I decided to merge the fix and tag -rc2 to save some testing cycles. We can always use more testers, so if you are interested in helping, let me know. Thanks, Tom

While debugging Scudo on ChromeOS, we found that the no reserve mode immediately crashed `sshd`. We tracked it down to the sandbox-seccomp-filter. Being able to mmap with MAP_NORESERVE is useful (if not necessary) for some overcommitting allocators. During mmap calls, the flag MAP_NORESERVE is used by some allocators...

Hello, We're evaluating memory tagging (MTE) on some internal workloads. We noticed that stack variables are tagged by an instrumentation pass and heap objects are handled by the allocator (Scudo). How about global variables? We tried a simple case using -march=armv8a+memtag -fsanitize=memtag, but found no tagging: Are we missing anything or tagging globals is still in progress? int global_array[16]; int main(int argc, char **argv) { global_array[1] = 0; return global_array[argc + 1...

...aoshi Zheng via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hello, We’re evaluating memory tagging (MTE) on some internal workloads. We noticed that stack variables are tagged by an instrumentation pass and heap objects are handled by the allocator (Scudo). How about global variables? We tried a simple case using -march=armv8a+memtag -fsanitize=memtag, but found no tagging: Are we missing anything or tagging globals is still in progress? int global_array[16]; int main(int argc, char **argv) { global_array[1] = 0; return global_array[argc + 1...

Hi folks, ARM v8.5 introduces the Memory Tagging Extension (MTE), a hardware that allows for detection of memory safety bugs (buffer overflows, use-after-free, etc) with low overhead. So far, MTE support is implemented in the Scudo hardened allocator (compiler-rt/lib/scudo/standalone) for heap, and stack allocation is implemented in LLVM/Clang behind -fsanitize=memtag <https://llvm.org/docs/MemTagSanitizer.html>. As part of a holistic MTE implementation, global memory should also be properly tagged. HWASan <http://c...

...; wrote: > > > > Hi folks, > > > > > > ARM v8.5 introduces the Memory Tagging Extension (MTE), a hardware that > allows for detection of memory safety bugs (buffer overflows, > use-after-free, etc) with low overhead. So far, MTE support is implemented > in the Scudo hardened allocator (compiler-rt/lib/scudo/standalone) for > heap, and stack allocation is implemented in LLVM/Clang behind > -fsanitize=memtag. > > > > > > As part of a holistic MTE implementation, global memory should also be > properly tagged. HWASan (a software-only im...

...; >>> > Hi folks, >>> > >>> > >>> > ARM v8.5 introduces the Memory Tagging Extension (MTE), a hardware that allows for detection of memory safety bugs (buffer overflows, use-after-free, etc) with low overhead. So far, MTE support is implemented in the Scudo hardened allocator (compiler-rt/lib/scudo/standalone) for heap, and stack allocation is implemented in LLVM/Clang behind -fsanitize=memtag. >>> > >>> > >>> > As part of a holistic MTE implementation, global memory should also be properly tagged. HWASan (a softwar...

Asan and the Debug CRT take different approaches, but the problems they cover largely overlap. Both help with detection of errors like buffer overrun, double free, use after free, etc. Asan generally gives you more immediate feedback on those, but you pay a higher price in performance. Debug CRT lets you do some trade off between the performance hit and how soon it detects problems. Asan

...vm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hello, > > > > We’re evaluating memory tagging (MTE) on some internal workloads. > > > > We noticed that stack variables are tagged by an instrumentation pass and > heap objects are handled by the allocator (Scudo). > > > > How about global variables? We tried a simple case using > -march=armv8a+memtag -fsanitize=memtag, but found no tagging: > > > > Are we missing anything or tagging globals is still in progress? > > > > *int global_array[16];* > > > > *int...

...> [2020-09-17 > 15:05:18 -0700]: > > ARM v8.5 introduces the Memory Tagging Extension (MTE), a hardware that > > allows for detection of memory safety bugs (buffer overflows, > > use-after-free, etc) with low overhead. So far, MTE support is > implemented > > in the Scudo hardened allocator (compiler-rt/lib/scudo/standalone) for > > heap, and stack allocation is implemented in LLVM/Clang behind > > -fsanitize=memtag <https://llvm.org/docs/MemTagSanitizer.html>. > > > > As part of a holistic MTE implementation, global memory should also...

All, The LLVM project has had many years of success with the Google Summer of Code project and we would really like to continue our participation. However, without the support of more community members, we fear that we may not be selected as an organization this year. They are already reviewing projects and to improve our chances of participation we need more projects and mentors listed on the

Trying to run a self host "ninja check-clang" with ASan enabled I hit a /lot/ of errors like this (strangely I hit none of these in check-llvm, only in check-clang): Any ideas? ==10525==ERROR: AddressSanitizer failed to deallocate 0x10800 (67584) bytes at address 0x631000014800 ==10525==AddressSanitizer CHECK failed:

...L=OFF //Generate dSYM files and strip executables and libraries (Darwin // Only) COMPILER_RT_EXTERNALIZE_DEBUGINFO:BOOL=OFF //Generate and build compiler-rt unit tests. COMPILER_RT_INCLUDE_TESTS:BOOL=ON //sanitizers to build if supported on the target (all;asan;dfsan;msan;tsan;safestack;cfi;esan;scudo) COMPILER_RT_SANITIZERS_TO_BUILD:STRING=asan;dfsan;msan;tsan;safestack;cfi;esan;scudo //Enable to build Debian packages CPACK_BINARY_DEB:BOOL=OFF //Enable to build IFW packages CPACK_BINARY_IFW:BOOL=OFF //Enable to build NSIS packages CPACK_BINARY_NSIS:BOOL=OFF //Enable to build RPM packages CP...

Sorry for the delay in writing this up and sending it out, but I wanted to recap the discussion from the roundtable on October 23rd. The roundtable ran for almost two hours and we discussed at most of the main points in my RFC. Thank you everyone who participated and contributed to the discussion! TL;DR: We should move to CMake 3.15 (RFC incoming). We should make `all` really `all`. We should