[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