v2 [PATCH 0/X] Introduce HWASAN sanitizer to GCC

[Matthew Malcomson]

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

Do you mean that I should add the options and the ability to toggle 
these features?

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

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

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.

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

>>
>>