From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27229 invoked by alias); 23 Oct 2014 10:09:56 -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 27209 invoked by uid 89); 23 Oct 2014 10:09:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mailout4.w1.samsung.com Received: from mailout4.w1.samsung.com (HELO mailout4.w1.samsung.com) (210.118.77.14) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (DES-CBC3-SHA encrypted) ESMTPS; Thu, 23 Oct 2014 10:09:54 +0000 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout4.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NDW004C57100160@mailout4.w1.samsung.com> for gcc-patches@gcc.gnu.org; Thu, 23 Oct 2014 11:12:36 +0100 (BST) Received: from eusync3.samsung.com ( [203.254.199.213]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id 49.2E.04619.DE3D8445; Thu, 23 Oct 2014 11:09:49 +0100 (BST) Received: from a.ryabinin ([106.109.129.143]) by eusync3.samsung.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0NDW000ZZ6WB4J10@eusync3.samsung.com>; Thu, 23 Oct 2014 11:09:49 +0100 (BST) Message-id: <5448D3EB.9030402@samsung.com> Date: Thu, 23 Oct 2014 10:11:00 -0000 From: Andrey Ryabinin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-version: 1.0 To: Jakub Jelinek Cc: Yury Gribov , GCC Patches , Konstantin Serebryany , Dmitry Vyukov , Konstantin Khlebnikov Subject: Re: [PATCHv4] Enable -fsanitize-recover for KASan References: <54095E23.6050900@samsung.com> <5416B3A2.4050200@samsung.com> <54299507.7090800@samsung.com> <5448AA21.9080601@samsung.com> <20141023071353.GY10376@tucnak.redhat.com> <5448AE0D.2080207@samsung.com> <5448CF90.2040001@samsung.com> <20141023095532.GD10376@tucnak.redhat.com> In-reply-to: <20141023095532.GD10376@tucnak.redhat.com> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-SW-Source: 2014-10/txt/msg02355.txt.bz2 On 10/23/2014 01:55 PM, Jakub Jelinek wrote: > On Thu, Oct 23, 2014 at 01:51:12PM +0400, Andrey Ryabinin wrote: >> IMO we don't need different versions of __asan_load* and __asan_load*_noabort, because >> -fno-sanitize-recover=kernel-address will never work with the linux kernel. >> >> I already said this before, and repeat this once again: >> There is few places in kernel where we validly touch poisoned memory, >> so we need to disable error reporting in runtime for such memory accesses. >> I use per-thread flag which is raised before the valid access to poisoned memory. >> This flag checked in __asan_report*() function. If it raised then we shouldn't print any error message, >> just silently exit from report. > > Can't you just use __attribute__((no_sanitize_address)) on the functions > that have such a code? Or you could use special macros for those accesses > (which could e.g. call function to read memory or write memory, implemented > in assembly or in __attribute__((no_sanitize_address)) function), or Those are quite generic functions used from a lot of places. So we want to instrument them in general, but there are few call sites which use those functions for poisoned memory. > temporarily unpoison and poison again. > That's a bit tricky. State of shadow memory is unknown, so we would need to store shadow somewhere before unpoisoning to restore it later. > Jakub >