[llvm-dev] Extra questions about HWASAN

[Evgenii Stepanov via llvm-dev]

Hi,

On Fri, Sep 20, 2019 at 6:48 AM Matthew Malcomson
<Matthew.Malcomson at arm.com> wrote:
>
> 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?

Yes, I think this is exactly right.

> ---
> 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?

Does __hwasan_tag_mismatch / __hwasan_tag_mismatch_stub work for you?
The first one has a non-standard ABI, but it can save register state
at the point of the fault in the user code.

> ---
> 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 agree, __hwasan_init is the right place for this.

> ---
> 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?

Yes, for stack errors. We emit the tag offset of each local variable
in DWARF debug info, and the ring buffer contains PC, SP and the base
tag for recent stack frames. The code in PrintStackAllocations
combines this info to find possible source(s) of a mismatching pointer
tag.

> ---
> 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".

Sure, patches are welcome.

> Thanks,
> Matthew