Re: Question on direction of GCC support for HWASAN.

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

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
>