Re: [PATCH 13/X] [libsanitizer][options] Add hwasan flags and argument parsing

["Andrey Konovalov via gcc-patches" <gcc-patches at gcc dot gnu dot org>]

On Thu, Nov 7, 2019 at 1:48 PM Matthew Malcomson
<Matthew.Malcomson@arm.com> wrote:
>
> On 05/11/2019 13:11, Andrey Konovalov wrote:
> > On Tue, Nov 5, 2019 at 12:34 PM Matthew Malcomson
> > <Matthew.Malcomson@arm.com> wrote:
> >>
> >> NOTE:
> >> ------
> >> I have defined a new macro of __SANITIZE_HWADDRESS__ that gets
> >> automatically defined when compiling with hwasan.  This is analogous to
> >> __SANITIZE_ADDRESS__ which is defined when compiling with asan.
> >>
> >> Users in the kernel have expressed an interest in using
> >> __SANITIZE_ADDRESS__ for both
> >> (https://lists.infradead.org/pipermail/linux-arm-kernel/2019-October/690703.html).
> >>
> >> One approach to do this could be to define __SANITIZE_ADDRESS__ with
> >> different values depending on whether we are compiling with hwasan or
> >> asan.
> >>
> >> Using __SANITIZE_ADDRESS__ for both means that code like the kernel
> >> which wants to treat the two sanitizers as alternate implementations of
> >> the same thing gets that automatically.
> >>
> >> My preference is to use __SANITIZE_HWADDRESS__ since that means any
> >> existing code will not be predicated on this (and hence I guess less
> >> surprises), but would appreciate feedback on this given the point above.
> >
> > +Evgenii Stepanov
> >
> > (A repost from my answer from the mentioned thread):
> >
> >> Similarly, I'm thinking I'll add no_sanitize_hwaddress as the hwasan
> >> equivalent of no_sanitize_address, which will require an update in the
> >> kernel given it seems you want KASAN to be used the same whether using
> >> tags or not.
> >
> > We have intentionally reused the same macros to simplify things. Is
> > there any reason to use separate macros for GCC? Are there places
> > where we need to use specifically no_sanitize_hwaddress and
> > __SANITIZE_HWADDRESS__, but not no_sanitize_address and
> > __SANITIZE_ADDRESS__?
> >
> >
>
> I've just looked through some open source repositories (via github
> search) that used the existing __SANITIZE_ADDRESS__ macro.
>
> There are a few repos that would want to use a feature macro for hwasan
> or asan in the exact same way as each other, but of the 31 truly
> different uses I found, 11 look like they would need to distinguish
> between hwasan and asan (where 4 uses I found I couldn't easily tell)
>
> NOTE
> - This is a count of unique uses, ignoring those repos which use a file
> from another repo.
> - I'm just giving links to the first of the relevant kind that I found,
> not putting effort into finding the "canonical" source of each repository.
>
>
> Places that need distinction (and their reasons):
>
> There are quite a few that use the ASAN_POISON_MEMORY_REGION and
> ASAN_UNPOISON_MEMORY_REGION macros to poison/unpoison memory themselves.
>   This abstraction doesn't quite make sense in a hwasan environment, as
> there is not really a "poisoned/unpoisoned" concept.
>
> https://github.com/laurynas-biveinis/unodb
> https://github.com/darktable-org/rawspeed
> https://github.com/MariaDB/server
> https://github.com/ralfbrown/framepac-ng
> https://github.com/peters/aom
> https://github.com/pspacek/knot-resolver-docker-fix
> https://github.com/harikrishnan94/sheap
>
>
> Some use it to record their compilation "type" as `-fsanitize=address`
> https://github.com/wallix/redemption
>
> Or to decide to set the environment variable ASAN_OPTIONS
> https://github.com/dephonatine/VBox5.2.18
>
> Others worry about stack space due to asan's redzones (hwasan has a much
> smaller stack memory overhead).
> https://github.com/fastbuild/fastbuild
> https://github.com/scylladb/seastar
> (n.b. seastar has a lot more conditioned code that would be the same
> between asan and hwasan).
>
>
> Each of these needs to know the difference between compiling with asan
> and hwasan, so I'm confident that having some way to determine that in
> the source code is a good idea.
>
>
> I also believe there could be code in the wild that would need to
> distinguish between hwasan and asan where the existence of tags could be
> problematic:
>
> - code already using the top-byte-ignore feature may be able to be used
> with asan but not hwasan.
> - Code that makes assumptions about pointer ordering (e.g. the autoconf
> program that looks for stack growth direction) could break on hwasan but
> not on asan.
> - Code looking for the distance between two objects in memory would need
> to account for tags in pointers.
>
>
> Hence I think this distinction is needed.

Evgenii, how does clang-compiled code dististinguishes whether it's
being compiled with ASAN or HWASAN?