On 11/21/19 3:59 PM, Matthew Malcomson wrote:
On 21/11/2019 13:10, Martin Liška wrote:
On 11/20/19 6:40 PM, Matthew Malcomson wrote:
On 20/11/2019 14:29, Martin Liška wrote:
On 11/7/19 7:37 PM, Matthew Malcomson wrote:
I have rebased this series onto Martin Liska's patches that take the
most
recent libhwasan from upstream LLVM.
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00340.html
a) For ASAN we do have bunch of parameters:
gcc --help=param | grep asan
asan-stack Enable asan stack protection.
asan-instrument-allocas Enable asan allocas/VLAs protection.
asan-globals Enable asan globals protection.
asan-instrument-writes Enable asan store operations protection.
asan-instrument-reads Enable asan load operations protection.
asan-memintrin Enable asan builtin functions
protection.
asan-use-after-return Enable asan detection of
use-after-return
bugs.
asan-instrumentation-with-call-threshold Use callbacks instead of
inline code if number of accesses in function becomes greater or equal
to this number.
We can probably use some of these in order to drive hwaddress in a
similar way. Most of them makes sense for hwaddress as well
I would prefer to keep the options different but would be happy to share
them if others want.
Works for me.
I figure that there will be some parameters that make sense for hwasan
but not for asan.
For example hwasan-random-frame-tag doesn't have any analogue for asan.
Re-using `asan-stack` for hwasan would mean we would then need to decide
between having options with either `hwasan` or `asan` prefix being able
to affect hwasan, or introducing a parameter `asan-random-frame-tag`
that has no meaning on asan.
Then, I would come up with additional hwasan-* parameters that can have
the same semantic as the for asan (if it makes sense).
Hello.
Do you mean that I should add the options and the ability to toggle
these features?
Yes please, but it can be certainly added incrementally.
The options that could eventually make sense for hwasan and that I
haven't implemented are:
hwasan-instrument-allocas
hwasan-instrument-writes
hwasan-instrument-reads
hwasan-memintrin
Works for me.
hwasan-globals could eventually be done, but that's certainly not
something I could implement quickly.
b) Apparently clang prints also value of all registers. Do we want to do
the same?
I believe this only happens on clang for inline checking (try testing
clang using the parameter `-mllvm --hwasan-instrument-with-calls` to see
without).
Are we talking about usage of __hwasan_check_x0_18?
Using `-mllvm --hwasan-instrument-with-calls` uses function calls like
`__hwasan_store4` (similar to the asan instrumentation with calls.
The __hwasan_check_x* functions are the "generated checking functions
with special calling conventions" I mentioned.
The special checking functions are generated to accept a calling
convention generated based on what would be optimal for where a check is
needed. This custom calling convention can then also be used to keep
track of what register values were around in the calling frame.
This was introduced in clang at revision: llvm-svn: 351920
Ah ok, I see. Apparently it saves a lot of code size and speed as well.
That's also a possible improvement.
https://reviews.llvm.org/D56954
This would be nice to have, but I'm not planning on looking at it any
time soon.
This is currently implemented in clang on top of two not-yet implemented
features: Inline instrumentation, and generated checking functions with
special calling conventions.
It's certainly not something I'm aiming to get into GCC 10.
Which is fine.
c) I'm a bit confused by the pointer tags, where clang does:
Yeah -- I left out a description of short-tags.
Hopefully my explanation in the below email helped.
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg01968.html
d) Are you planning to come up with inline stack variable
tagging/untagging for GCC 10?
To make sure I understand the question correctly:
I think you're asking about writing tags into the shadow memory.
Yes, which will be very similar to current ASAN code in
asan_emit_stack_protection.
I would expect a significant speed up from the inline shadow memory tag
emission?
Yes, I would also expect a significant speed up.
Honestly, I doubt I could get this done properly by the end of stage 3.
I'd be happy to give it a shot, but would not like to commit to it.
Sure, we should start first with a working implementation and speed up
patches can be added later.
f) I would rename ASAN_MARK in tree dumps to HWASAN_MARK, similarly to
what you did
for HWASAN_CHECK?
This is an artifact of a shortcut I made (and tried but probably failed
to explain well in
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00392.html).
For HWASAN_CHECK I introduced a new internal function that takes the
same arguments as ASAN_CHECK, hence this new function is printed
differently.
For HWASAN_MARK, I used a trick to avoid adding "almost duplicate" code
everywhere in the mid-end that checked for ASAN_MARK.
Then, in the sanopt pass (i.e. later on in compilation) I turn that
ASAN_MARK internal function into a HWASAN_MARK internal function.
This happens after all passes that check for ASAN_MARK so it should be a
problem .
I know that you are using ASAN_MARK in -fsanitize=hwaddress. What I said
is maybe we want to print in dump files {HW,.}ASAN_MARK based on what
sanitizer is used (as one can't utilize both at the same time). But it's
a nit.
Ah, I can certainly look into it.
It should be quite simple to fix that.
Thanks,
Martin
