similar to: MTE -- discussion on Exception unwinding ABI

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

> > 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 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:

Hello, I'm working on implementing hwasan instrumentation in GCC, and have just started discussing my current work-in-progress on the gcc-patches mailing list. (https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00387.html -- the email that Kostya saw and added people to). I've gotten about as basic a user-space implementation as possible (using the interceptor ABI) up and running, and would

Thanks for the update, Phillips. Yes, please add me, Stephen and Ana (CCed) to Phabricator reviews. Zhaoshi From: Mitch Phillips <mitchp at google.com> Sent: Tuesday, July 14, 2020 19:10 To: Zhaoshi Zheng <zhaoshiz at quicinc.com> Cc: llvm-dev at lists.llvm.org; Stephen Long <steplong at quicinc.com> Subject: [EXT] Re: [llvm-dev] [MTE] Tagging Globals Hi Zhaoshi, Currently

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

Not at this stage -- no. On Wed, Jul 15, 2020 at 3:23 PM Zhaoshi Zheng <zhaoshiz at quicinc.com> wrote: > Mitch, > > > > I forgot to ask: do you have any timeline on sharing it through > Phabricator? > > > > Thanks, > > Zhaoshi > > > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Zhaoshi > Zheng via llvm-dev

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

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

* Mitch Phillips <mitchp at google.com> [2020-10-09 13:17:06 -0700]: > > > static int a[8]; > > static int *p = a - 5; > > ... > > p[10] = 1; > > should work (even if it's not valid in c it can be valid as > > a c extension or written in asm, so ELF should support it). > > > IMO this is exactly the kind of thing that MTE is trying

Hi Bill, >> The unwinder delegates the decision of whether to stop in a call frame to >> that call frame's language-specific personality function. Not all personality >> functions guarantee that they will stop to perform cleanups. I was talking about who decides what to do if there are only cleanups all the way up the stack (in C++ the program is terminated without

On Sep 27, 2011, at 4:58 AM, Duncan Sands wrote: > Hi Bill, > >>>> I'm looking at the docs, and while it refers to a "catch-all" clause, >>> >>> hopefully Bill will get rid of the first reference to "catch-all" since >>> that section is inaccurate. >>> >> I *think* this is now correct. Please check. :) >

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.

Thank you for the explanation, Ben! I realized I didn’t give enough context for my question: As you noted, the slow/fast unwinder can only do its work if there is enough (runtime) information. Otherwise stack printing usually does exactly what you suggested: printing the one frame corresponding to the recent pc. When I asked if “platforms are required to at least support one kind of unwinder” I

Hi, In sanitizer code we have two notions of stack unwinders: fast and slow. [1] In the context of sanitizers, stack unwinding is most often for printing error reports that include a stack trace. I am currently trying to fix an issue that is related to some platforms (Darwin) only supporting the fast unwinder, but calling code not being aware of that possibility. My mental model was that

Hi Bill, >>> I'm looking at the docs, and while it refers to a "catch-all" clause, >> >> hopefully Bill will get rid of the first reference to "catch-all" since >> that section is inaccurate. >> > I *think* this is now correct. Please check. :) I still have some niggles: The unwinder delegates the decision of whether to stop in a

Since it looks like we're going to start discussing changing the EH representation again, I think it would be a very good idea to first review the core requirements we have of the exceptions IR. Mostly, here, I'm taking the major exceptions implementations I have direct knowledge of --- zero-cost DWARF-based libUnwind with the default GCC personalities, builtin_sjlj-based libUnwind with

Hi Duncan, On Sep 27, 2011, at 7:58, Duncan Sands wrote: > Hi Bill, > >>>> I'm looking at the docs, and while it refers to a "catch-all" clause, >>> >>> hopefully Bill will get rid of the first reference to "catch-all" since >>> that section is inaccurate. >>> >> I *think* this is now correct. Please check. :)