This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH 0/X] Introduce HWASAN sanitizer to GCC


Hello,

This patch series adds the LLVM hardware address sanitizer (HWASAN) to
GCC.  The document describing HWASAN can be found here
http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html.

This address sanitizer only works for AArch64 at the moment.  It
requires the "top byte ignore" feature where the top byte of a pointer
does not affect dereferences.  This is checked for by a backend hook so
that if other architectures have this feature HWASAN can be used for
them.

We require a linux kernel with the relaxed ABI to allow tagged pointers
in system calls.  This is in the linux mainline, I have been testing
this feature on 5.4.0-rc2.

HWASAN works by storing a tag in the top bits of every pointer and a tag in
a shadow memory region corresponding to each area of memory pointed at.
On every memory access through a pointer the tag in the pointer is
checked against the tag in shadow memory corresponding to the memory the
pointer is accessing.  If the pointer tag and memory tag 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 tagging 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 for the stack, and
hence I have a "dummy" patch demonstrating the approach envisaged for
this.


Some points that I know need some discussion are:

1) Should we set the existing inbuilt __SANITIZER_ADDRESS__ macro, or a
   new __SANITIZER_HWADDRESS__ macro?
   (extra information in patch 13).
2) How should we account for exceptions?
   (see demo patch number 17).


Outline of patch series is:

  1 - Change type used in `build_personality_function`.
      Bug I noticed -- fix not actually needed for patch series.
  2 - Fix off-by-one allocation mistake.
      Bug that hwasan found, not needed for the patch series.
  2 - Introduce libhwasan to GCC tree
      Take from LLVM at same revision as rest of libsanitizer.
  3 - libhwasan initialisation include kernel syscall ABI relaxation
      Backport from LLVM
  4 - libhwasan add longjmp & setjmp interceptors
      Backport from LLVM
  5 - Remove system allocator fallback
      Backport from LLVM
  6 - Add hwasan_exceptions.cpp file
      Backport from LLVM
  7 - Add missing SANITIZER_INTERFACE_ATTRIBUTE on __hwasan_personality_wrapper
      Backport from LLVM
  8 - Expose __hwasan_tag_mismatch_stub
      Backport from LLVM
  9 - Remove lazy thread initialisation
      Backport from LLVM
  10 - Tie the hwasan library into our build system
  11 - Only build libhwasan when targeting AArch64
  12 - Add option to bootstrap using HWASAN
       Write a bootstrap-*.mk file similar to bootstrap-asan.mk
  13 - Add hwasan flags and argument parsing
  14 - Introduce stack variable handling for HWASAN
       Ensuring the "shadow stack" is tagged and each pointer to a stack
       variable has a tag in it.
  15 - Add hwasan pass and associated gimple changes
       Introduce checks that tags match on access, also tag variables
       around the blocks they're defined for.
  16 - Add tests
  17 - Add hwasan Exception handling
       This is a temporary patch -- it does not work due to a mismatch
       with libhwasan.  I am hoping for a discussion on what to do here.
       Since our main aim is to implement this sanitizer for the kernel,
       not handling C++ exceptions is not a blocker.
  18 - Add in MTE stubs
       Demonstration patch to show how MTE might be added on top of
       this.  Is not to go into trunk.


Testing done:
Full bootstrap and regtest on x86_64 (no difference -- hwasan not used).

Full bootstrap and regtest on AArch64 sanitizing with hwasan and running
on recent kernel.
Regressions all accounted for:
  1) tests under plugin/
     testism where hwasan library is not linked in.
     (same appears to happen for asan)
  2) branch-protection-attr.c
     New bug found by hwasan, fix in this patch series.
  3) pr88597.c 
     timeout, can run manually and everything works (but is very slow)
  4) aarch64/long_branch_1.c
     timeout, as above.
  5) gfortran/class_61.f90
     bug already caught by ASAN and reported upstream
     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661
  6) gfortran/dec_type_print_2.f03
     bug already caught by ASAN and reported upstream
     https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86657
  7) gfortran/minlocval_3.f90
     timeout, can run manually and passes (but is very slow)


Entire patch series attached to cover letter.

Attachment: all-patches.tar.gz
Description: all-patches.tar.gz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]