Re: [Patch 0/X] [WIP][RFC][libsanitizer] Introduce HWASAN to GCC

[Martin Liška <mliska at suse dot cz>]

On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> Hello,
> 
> This patch series is a WORK-IN-PROGRESS towards porting the LLVM hardware
> address sanitizer (HWASAN) in GCC.  The document describing HWASAN can be found
> here http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html.

Hello.

I'm happy that you are working on the functionality for GCC and I can provide
my knowledge that I have with ASAN. I briefly read the patch series and I have
multiple questions (and observations):

1) Is the ambition of the patchset to be a software emulation of MTE that can
   work targets that do not support MTE? Is it something what clang
   names hwasan-abi=interceptor?

2) Do you have a real aarch64 hardware that has MTE support? Would it be possible
   for the future to give such a machine to GCC Compile Farm for testing purpose?

3) I like the idea of sharing of internal functions like ASAN_CHECK/HWASAN_CHECK.
   We should benefit from that in the future.

4) Am I correct that due to escape of "tagged" pointers, one needs to have an entire
DSO (dynamic shared object) built with hwasan enabled? Otherwise, a dereference of
a tagged pointer will lead to a segfault (except TBI feature on aarch64)?

5) Is there a documentation/definition of how shadow memory for memory tagging looks like?
Is it similar to ASAN, where one can get to tag with:
u8 memory_tag = *((PTR >> TG) + SHADOW_OFFSET) & 0xf?

6) Note that thing like memtag_tag_size, memtag_granule_size define an ABI of libsanitizer

> 
> The current patch series is far from complete, but I'm posting the current state
> to provide something to discuss at the Cauldron next week.
> 
> In its current state, this sanitizer only works on AArch64 with a custom kernel
> to allow tagged pointers in system calls.  This is discussed in the below link
> https://source.android.com/devices/tech/debug/hwasan -- the custom kernel allows
> tagged pointers in syscalls.

Can you be please more specific. Is the MTE in upstream linux kernel? If so,
starting from which version?

> I have also not yet put tests into the DejaGNU framework, but instead have a
> simple test file from which the tests will eventually come.  That test file is
> attached to this email despite not being in the patch series.
> 
> Something close to this patch series bootstraps and passes most regression
> tests when ~--with-build-config=bootstrap-hwasan~ is used.  The regressions it
> doesn't pass are all the other sanitizer tests and all linker plugin tests.
> The linker plugin tests fail due to a configuration problem where the library
> path is not correctly set.
> (I say "something close to this patch series" because I recently made a change
> that breaks bootstrap but I believe is the best approach once I've fixed it,
> hence for an RFC I'm leaving it in).
> 
> HWASAN works by storing a tag in the top bits of every pointer and a colour in
> a shadow memory region corresponding to every area of memory.  On every memory
> access through a pointer the tag in the pointer is checked against the colour in
> shadow memory corresponding to the memory the pointer is accessing.  If the tag
> and colour do not match then a fault is signalled.
> 
> The instrumentation required for this sanitizer has a large overlap with the
> instrumentation required for implementing MTE (which has similar functionality
> but checks are automatically done in the hardware and instructions for colouring
> shadow memory and for managing tags are provided by the architecture).
> https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/arm-a-profile-architecture-2018-developments-armv85a
> 
> We hope to use the HWASAN framework to implement MTE tagging on the stack, and
> hence I have a "dummy" patch demonstrating the approach envisaged for this.

What's the situation with heap allocated memory and global variables?

> 
> Though there is still much to implement here, the general approach should be
> clear.  Any feedback is welcomed, but I have three main points that I'm
> particularly hoping for external opinions.
> 
> 1) The current approach stores a tag on the RTL representing a given variable,
>    in order to implement HWASAN for x86_64 the tag needs to be removed before
>    every memory access but not on things like function calls.
>    Is there any obvious way to handle removing the tag in these places?
>    Maybe something with legitimize_address?

Not being a target expect, but I bet you'll need to store the tag with a RTL
representation of a stack variable.

Thanks,
Martin

> 2) The first draft presented here introduces a new RTL expression called
>    ADDTAG.  I now believe that a hook would be neater here but haven't yet
>    looked into it.  Do people agree?
>    (addtag is introduced in the patch titled "Put tags into each stack variable
>    pointer", but the reason it's introduced is so the backend can define how
>    this gets implemented with a ~define_expand~ and that's only needed for the
>    MTE handling as introduced in "Add in MTE stubs")
> 3) This patch series has not yet had much thought go towards it around command
>    line arguments.  I personally quite like the idea of having
>    ~-fsanitize=hwaddress~ turn on "checking memory tags against shadow memory
>    colour", and MTE being just a hardware acceleration of this ability.
>    I suspect this idea wouldn't be liked by all and would like to hear some
>    opinions.
> 
> Thanks,
> Matthew
>