[llvm-dev] Extra questions about HWASAN

[Matthew Malcomson via llvm-dev]

Hello again,

I have been thinking more about the GCC implementation of hwasan and
found a few more questions that I would really appreciate help with.

---
I've noticed a match-all condition in the compiler inline
instrumentation, but can't see where it's used in the libhwasan function
call checks.  Is that a planned behaviour or am I just missing the part
in the code where this happens?

 From reading the git history I'm guessing it's not in the library since
the feature was introduced for the kernel specifically and the kernel
doesn't use the library ... or is that wild speculation on my part?

---
Would it be OK to add `report_load{size}` functions to the library?  I
notice that LLVM emits an inline-assembler `brk` into the IR for the
inline tag-mismatch report.

I'm a little uncomfortable putting architecture specific assembly code
into the mid-end of GCC (even though the entire HWASAN is AArch64
specific in GCC) and would like to put some "just report" functions into
libhwasan (in the same manner that libasan has
`__asan_report_(load|store){1,2,4,8,16,_n}{,_noabort}` functions).

Would that be OK?  It's a simple patch that I already have locally.  I
guess tag-mismatch reporting would then contain an extra function in the
stack report?

---
As I understand it, when the mainline kernel gets patched to accept
tagged pointers in syscalls, the relaxed ABI will be behind a `prctl`
call rather than being generically turned on.  I guess this means that
Android will eventually have the same requirement?

If/when that happens, would the initial call to `prctl` be put in
libhwasan, or would something like that be done in Bionic?  (n.b. this
call needs to be done for every program since the setting doesn't
propagate across fork).  I have a patch that adds the relevant `prctl`
call to what `__hwasan_init` does in libhwasan.  I do this because I'm
using a glibc unmodified for hwasan.

---
I've noticed code around maintaining a thread-specific ring-buffer of
the stack frames that have been used (recording the PC and SP) -- it
looks like this is in order to give better messages on tag-mismatch, is
that correct?

---
Would the addition of `longjmp` and `setjmp` to the "interceptor ABI"
build of libhwasan be OK?  I understand that LLVM pretty much only use
that ABI for testing, but I'm working without a glibc that supports the
"platform ABI".

Thanks,
Matthew