From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68004 invoked by alias); 7 Nov 2019 15:51:44 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 67924 invoked by uid 89); 7 Nov 2019 15:51:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.8 required=5.0 tests=AWL,BAYES_00,ENV_AND_HDR_SPF_MATCH,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=ham version=3.3.1 spammy=H*f:sk:e5ff9f0, H*i:sk:e5ff9f0 X-HELO: mail-pg1-f194.google.com Received: from mail-pg1-f194.google.com (HELO mail-pg1-f194.google.com) (209.85.215.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 07 Nov 2019 15:51:41 +0000 Received: by mail-pg1-f194.google.com with SMTP id h27so2390185pgn.0 for ; Thu, 07 Nov 2019 07:51:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jOTezglOaklVHlvkULhknz7GAhfjNSPSn0bPm/UWWmk=; b=K9sweo99SCq3Uqz7cUPziOmdG+I1L+517a/vu28DUWxpyqFaeF2bMfMXvoNfsGzXT/ Ng1kXWMQ5tQ+mITK8yKmKtt4VzQVSQ17EyBanDprB9u3m4pPii/gTSYlMTjQRIh/7fG5 wsCpLLdzTJv6HZ3UlfcXVSPA4B6m6XTZN0f5ryVmBKj8asEjG2tI54m5AxgRpqC2ZMQD /1YuA38qTg0OQ2M7o6pVPZM4Ec+OGiMqsApbhTAHz37dTFayYYpsbfdPNXB2nT2oARZi kif3KJku211wx75v3+OvxRvt6Pn64JjP2Aagxzoh2C2jSw/7hSaVagf4Yoci9H4Fpu5R x1tw== MIME-Version: 1.0 References: <157295142743.27946.1142544630216676787.scripted-patch-series@arm.com> In-Reply-To: From: "Andrey Konovalov via gcc-patches" Reply-To: Andrey Konovalov Date: Thu, 07 Nov 2019 15:51:00 -0000 Message-ID: Subject: Re: [PATCH 13/X] [libsanitizer][options] Add hwasan flags and argument parsing To: Matthew Malcomson , Evgenii Stepanov Cc: "kcc@google.com" , "dvyukov@google.com" , "gcc-patches@gcc.gnu.org" , nd , Martin Liska , Richard Earnshaw , Kyrylo Tkachov , "dodji@redhat.com" , "jakub@redhat.com" , kasan-dev Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-11/txt/msg00521.txt.bz2 On Thu, Nov 7, 2019 at 1:48 PM Matthew Malcomson wrote: > > On 05/11/2019 13:11, Andrey Konovalov wrote: > > On Tue, Nov 5, 2019 at 12:34 PM Matthew Malcomson > > 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?