[llvm-dev] Requesting clarification of some HWASAN behaviours.

[Evgenii Stepanov via llvm-dev]

On Thu, Sep 12, 2019 at 9:23 AM Matthew Malcomson
<Matthew.Malcomson at arm.com> wrote:
>
> Hello,
>
> I'm working on implementing hwasan instrumentation in GCC, and have just
> started discussing my current work-in-progress on the gcc-patches
> mailing list.
> (https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00387.html -- the email
> that Kostya saw and added people to).

I must say I really like your plan to reuse parts of HWASan codegen
for MTE in that change. In LLVM, we did hwasan before we had a good
idea of what MTE ISA would look like, and they ended up mostly
independent. I'm considering eventually refactoring HWASan to use more
of MTE codegen, but it does not look like this work would be
justifiable by the performance or code size gains it might bring.

> I've gotten about as basic a user-space implementation as possible
> (using the interceptor ABI) up and running, and would appreciate it if I
> could get some clarification on some other parts of hwasan and it's use
> so I can look into those.
>
> As you may guess by my current task I'm most interested in features that
> require some compiler instrumentation.
>
> Most of the questions I have are just double checking the impression I
> have from skimming the LLVM source code, but I would very much
> appreciate any extra clarification people think would be helpful.
>
> Evgenii's recent reply on the GCC mailing list was very useful, so I
> figure there could be a lot of information I don't quite know to ask for
> that could be a great help.
> (https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00773.html)
>
> The questions I know I have are:
>
> 1) What code-generation differences are there between kernel and
>     userspace hwasan?
>     From what I can see in the llvm source code there is
>     - No C++ exceptions, globals, or module constructor & init functions
>     - Kernel has match-all of 0xFF by default.
>     - Tagging code differences due to 0xFF in kernel address top byte.
>     - Shadow memory is located in a different place.
>     Is there anything else I should know around hwasan in the kernel?

That's about all I can remember.

> 2) I believe compiling while ignoring the "short-granule" feature would
>     not add any incompatibilities with other code.  Is this correct?

As long as short granules are disabled in the runtime library, too.
And no other code in the same process is compiled using short granules
for stack instrumentation. Basically, a short-granule-unaware tag
check will see a short granule as a tag mismatch.That is because with
short granules, the actual tag is stored in the last byte of the
allocation, and the size of the allocation - in the memory tag.

> 3) Am I right in thinking that longjmp and setjmp are only handled in
>     the platform ABI? (I couldn't see any interceptors for them).

Yes. I think this is a simple omission coming from the fact that the
interceptor ABI have not really seen a lot of use outside of
compiler-rt tests.

>
> Thanks,
> Matthew