On 9/20/19 7:11 PM, Matthew Malcomson wrote: > Hello, Hi.
Next time, please send the email to the HWASAN email thread. > > 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. I'll reply to the original cover letter email about what will help me to do a proper patch review easier. > (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. Yes, I agree with you that we should aim only on aarch64 in 2 modes: TBI and MTE. > > > --- > 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. Can you please provide a link about what special one needs in glibc to support HWASAN? > > 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. Yes, that is really not needed now and can be added incrementally. > 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. Which is also fine for me. Martin > > Cheers, > Matthew >
