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.

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

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