From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95895 invoked by alias); 24 Oct 2019 10:08:54 -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 95886 invoked by uid 89); 24 Oct 2019 10:08:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=(unknown) X-HELO: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 24 Oct 2019 10:08:52 +0000 Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 2C87BB65B; Thu, 24 Oct 2019 10:08:50 +0000 (UTC) Subject: Re: [Patch 0/X] [WIP][RFC][libsanitizer] Introduce HWASAN to GCC To: Matthew Malcomson , "gcc-patches@gcc.gnu.org" Cc: "dodji@redhat.com" , nd , "kcc@google.com" , "jakub@redhat.com" , "dvyukov@google.com" References: <156778058239.16148.17480879484406897649.scripted-patch-series@arm.com> <9f0727e1-1e6b-ae5f-f854-52557afe0a2b@suse.cz> <8a277aa7-7db7-55d0-0b8e-6e2fe08292b0@arm.com> From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <5ad30365-a8b9-61ca-98c0-a1f5f2c8bba9@suse.cz> Date: Thu, 24 Oct 2019 10:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <8a277aa7-7db7-55d0-0b8e-6e2fe08292b0@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg01729.txt.bz2 On 10/23/19 1:01 PM, Matthew Malcomson wrote: > Hi Martin, Hello. > > I'm getting close to putting up a patch series that I believe could go > in before stage1 close. > > I currently have to do testing on sanitizing the kernel, and track down > a bootstrap comparison diff in the code handling shadow-stack cleanup > during exception unwinding. > > I just thought I'd answer these questions below to see if there's > anything I extra could to do to make reviewing easier. I welcome that approach. > > On 23/09/19 09:02, Martin Liška wrote: >> Hi. >> >> As mentioned in the next email thread, there are main objectives >> that will help me to make a proper patch review: >> >> 1) Make first libsanitizer merge from trunk, it will remove the need >> of the backports that you made. Plus I will be able to apply the >> patchset on the current master. > Done >> 2) I would exclude the setjmp/longjmp - these should be upstreamed first >> in libsanitizer. > > Will exclude in the patch series, upstreaming under progress > (https://reviews.llvm.org/D69045) > >> 3) I would like to see a two HWASAN options that will clearly separate the >> 2 supported modes: TBI without MTE and MTE. Here I would appreciate to have >> a compiler farm machine with TBI which we can use for testing. > > I went back and looked at clang to see that it uses > `-fsanitize=hwaddress` and `-fsanitize=memtag`, which are completely > different options. > > I'm now doing the same, with the two sanitizers just using similar code > paths. > > In fact, I'm not going to have the MTE instrumentation ready by the end > of stage1, so my aim is to just put the `-fsanitize=hwaddress` sanitizer > in, but send some outline code to the mailing list to demonstrate how > `-fsanitize=memtag` would fit in. As well here. That will make it easier to merge -fsanitize=hwaddress first. > > > ## w.r.t. a compiler farm machine with TBI > > Any AArch64 machine has this feature. However in order to use the > sanitizer the kernel needs to allow "tagged pointers" in syscalls. If so, then it will be very easy to grab a machine and run 5.4 kernel in it. So I'll will be able to test the patches. > > The kernel has allowed these tagged pointers in syscalls (once it's been > turned on with a relevant prctl) in mainline since 5.4-rc1 (i.e. the > start of this month). > > My testing has been on a virtual machine with a mainline kernel built > from source. > > Given that I'm not sure how you want to proceed. > Could we set up a virtual machine on the compiler farm? > > >> 4) About the BUILTIN expansion: you provided a patch for couple of them. My question >> is whether the list is complete? > > The list of BUILTINs was nowhere near complete at the time I posted the > RFC patches. > > Since then I've added features and correspondingly added BUILTINs. > > Now I believe I've added all the BUILTIN's into sanitizer.def this > sanitizer will need. > >> 5) I would appreciate the patch set to be split into less logical parts, e.g. >> libsanitizer changes; option introduction; stack variable handling (colour/uncolour/alignment); >> hwasan pass and other GIMPLE-related changes; RTL hooks, new RTL instructions and expansion changes. >> > > Will do! Great. Thanks, Martin > >> Thank you, >> Martin >> >> >