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

Matthew Malcomson via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 12 09:23:19 PDT 2019


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

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

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

Thanks,
Matthew


More information about the llvm-dev mailing list