On Thu, Nov 7, 2019 at 1:48 PM Matthew Malcomson <matthew.malcom...@arm.com> wrote: > > On 05/11/2019 13:11, Andrey Konovalov wrote: > > On Tue, Nov 5, 2019 at 12:34 PM Matthew Malcomson > > <matthew.malcom...@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?