similar to: Requesting clarification of some HWASAN behaviours.

Hi, On Fri, Sep 20, 2019 at 6:48 AM Matthew Malcomson <Matthew.Malcomson at arm.com> wrote: > > Hello again, > > I have been thinking more about the GCC implementation of hwasan and > found a few more questions that I would really appreciate help with. > > --- > I've noticed a match-all condition in the compiler inline > instrumentation, but can't see

Hi everyone, I believe the ABI for exception unwinding on a stack tagged with MTE needs to be clarified -- hopefully we can start the discussion here? (Please feel free to add people to the thread that you think would be interested). I'll outline some possible approaches that I think seem good below, I know Evgenii and Peter have done a lot of investigation in this area for HWASAN, so

After updating from trunk today, I am seeing this failure in hwasan: FAIL: HWAddressSanitizer-x86_64 :: TestCases/sizes.cpp (19011 of 49508) ******************** TEST 'HWAddressSanitizer-x86_64 :: TestCases/sizes.cpp' FAILED ******************** <snip> Command Output (stderr): -- + : 'RUN: at line 1' + /build/./bin/clang --driver-mode=g++ -fsanitize=hwaddress -mllvm

This commit has added __hwasan_memset to compiler-rt: commit 749bd83b08b7239f5d18c4e3095183919c68eb30 Author: Eugene Leviant <eleviant at accesssoftek.com> Date: Thu Dec 20 09:10:03 2018 +0000 [HWASAN] Add support for memory intrinsics This is patch complements D55117 implementing __hwasan_mem* functions in runtime Differential revision: https://reviews.llvm.org/D55554

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

Hi David, Does the tagging of these hidden symbols only protect against RW > primitives without a similar ldg? If I knew the address of the hidden > symbol I could presumably use the same sequence, but I think I'm > stretching what memory tagging is supposed to protect against. I might be missing your point here - but don't forget that the local globals are always PC-relative

> I might be missing your point here - but don't forget that the local globals are always PC-relative direct loads/stores. I did forget! Thanks for clarifying, now I understand. On Fri, 18 Sep 2020 at 20:51, Evgenii Stepanov <eugenis at google.com> wrote: > > > > On Fri, Sep 18, 2020 at 12:18 PM Mitch Phillips via llvm-dev <llvm-dev at lists.llvm.org> wrote:

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1

On Wed, Jul 8, 2020 at 6:30 PM Kostya Serebryany <kcc at google.com> wrote: > > > On Wed, Jun 24, 2020 at 4:58 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> Hi all, >> >> I've included an RFC for a heap profiler design I've been working on in >> conjunction with David Li. Please send any questions or feedback. For >>

> > note: these bits are not really reserved for os or processor > specific use in ELF. in practice they are processor specific > so it will be STO_AARCH64_TAGGED. > Correct. note2: undefined symbol references will need correct marking > too if objects may get copy relocated into the main exe and > linkers should check if definitions match references. Yep - at this point I

Hi all, I've included an RFC for a heap profiler design I've been working on in conjunction with David Li. Please send any questions or feedback. For sanitizer folks, one area of feedback is on refactoring some of the *ASAN shadow setup code (see the Shadow Memory section). Thanks, Teresa RFC: Sanitizer-based Heap Profiler Summary This document provides an overview of an LLVM

Hi, Teresa, This looks really useful. It seems like this general infrastructure could be useful for diagnosing places where we have a lot of false sharing too. This could be between cores, sockets, or devices. Looking forward, especially with HMM and support under Linux for transparent unified memory between CPUs and accelerators, I anticipate we'll end up looking for places where some

On Sat, Jul 4, 2020 at 11:28 PM Wenlei He <wenlei at fb.com> wrote: > This sounds very useful. We’ve improved and used memoro > <https://www.youtube.com/watch?v=fm47XsATelI> for memory profiling and > analysis, and we are also looking for ways to leverage memory profile for > PGO/FDO. I think having a common profiling infrastructure for analysis > tooling as well as

Hello again, I had hoped that rc4 would be the last one, but I wanted to pick up one more fix, so here we go. Release Candidate 5 was just tagged as llvmorg-10.0.0-rc5 on the release branch at 35627038123. Source code and docs are available at https://prereleases.llvm.org/10.0.0/#rc5 and https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc5 If nothing new comes up, I plan to tag

On Fri, May 4, 2018 at 7:09 PM Walter Lee <waltl at google.com> wrote: > On Fri, May 4, 2018 at 6:21 PM Kostya Serebryany <kcc at google.com> wrote: > > > On RAM... > > > You chose the 32-byte shadow granularity to reduce the RAM overhead, > > but I am afraid this will actually increase it due to extra alignment > requirements, > > especially if an

On RAM... You chose the 32-byte shadow granularity to reduce the RAM overhead, but I am afraid this will actually increase it due to extra alignment requirements, especially if an average allocation on your typical application is small. The pointers are 32-bit, right? Given how RAM-constrained your environment is, maybe you should consider something more like HWASAN instead of ASAN.

On Fri, May 4, 2018 at 6:21 PM Kostya Serebryany <kcc at google.com> wrote: > On RAM... > You chose the 32-byte shadow granularity to reduce the RAM overhead, > but I am afraid this will actually increase it due to extra alignment requirements, > especially if an average allocation on your typical application is small. Good point. I will run our test suite with 8-byte shadow

I ran our test suite with grain of 8 and 32, and more tests were able to avoid running out of memory with grain of 32 than 8. The ones that run out of memory on 8 but not 32 all failed trying to allocate a large region from the heap (350M). I haven't had any tests that run out of memory for other reasons. Given that, I will check in the current selected granularity of 32. I will try grain

On 3/15/23 18:25, Eric Blake wrote: > On Wed, Mar 15, 2023 at 12:01:57PM +0100, Laszlo Ersek wrote: >> Don't try to test async-signal-safety, only that >> NBD_INTERNAL_FORK_SAFE_ASSERT() works similarly to assert(): >> >> - it prints diagnostics to stderr, >> >> - it calls abort(). >> >> Some unfortunate gymnastics are necessary to avoid

I believe a good amount of them (if not most of them) have already been ported! Off the top of my head, I remember that asan, tsan, msan, hwasan, the kernel santizers, and sancov have been ported. I don't think ubsan has been ported yet though. You can also check if other passes you need run under the new PM by checking PassRegistry.def. On Fri, Aug 2, 2019, 14:20 Jordan Rupprecht