Hello, I'm nearing the point where I think the hardware-asan patch series could go in and would appreciate some feedback on what features need to be implemented before it could be put into trunk. (The RFC can be found at https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00387.html, the only change to the general approach I've made since then is to use backend hooks to determine the RTL to emit instead of introducing a new RTX called `ADDTAG`)
--- Note that hwasan will not have support for architectures other than AArch64 to start with, and any support that could be added later for architectures without TBI would be difficult. As a comparison; LLVM has support for hwasan on x86_64 "but it's not really practical because any library built without instrumentation is a big source of false positives" https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00773.html. --- We would really like to enable using HWASAN for the kernel (in KHWASAN -- https://lwn.net/Articles/748455/) when compiling with GCC, while also allowing use of hwasan for testing/debugging of userland processes (i.e. not to be run in production). A secondary benefit is that the hwasan instrumentation should provide a framework for adding stack-tagging MTE support to the compiler. The implementation is unlikely to be production-quality since development on libhwasan is only on its `platform` ABI. This libhwasan ABI requires changes to the system libc so that it calls into libhwasan on interesting events. I haven't looked into adding these changes to glibc, but expect that most people running a Linux distribution would not want to install a special glibc to use this sanitizer. The alternate libhwasan ABI is called the `interceptor` ABI. This intercepts certain functions in the system libc so that libhwasan can run its own code. The method of intercepting events has some known difficulties. Also, as one of the LLVM hwasan developers mentioned, this ABI is not being developed any more https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00773.html. --- If this aim is acceptable, then the biggest question I have is whether HWASAN could be accepted as a first stage without having the option for inline instrumentation. As it stands I've just implemented the function-call instrumentation for checking tags and tagging memory, with the idea that inline instrumentation could be added later. Similarly I'm not planning on implementing global instrumentation for this first stage and hoping that's OK with the community. Cheers, Matthew
