From patchwork Tue Oct 29 12:25:33 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 286824 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id D0D6B2C0340 for ; Tue, 29 Oct 2013 23:27:07 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; q=dns; s=default; b=v+Ci1uj+64TBwhk1 wZUCdN2n2VvShOMZeiCzYDJckCPzwGKQr1Lid1HP2swmVt9Se2jyg+7jMZE9Rsk+ qTvPUULByFYWf2yYzhShMyMiU/sr5Ojt3oK+3rztUrpDYjDaOO9ZYQ4HfHJ3rNMA uSCy46ZnZxgeozKPi0R+DqCzXRc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; s=default; bh=rD0tJBNhavBB7b9U/qUSd6 yL4wc=; b=lgKBu1+cDHkiBnikxpBdDTxUnqwEwZRwq32w8UCtpwfQa5e583T7Le OQ0HOAxJu9SU3HKQXNFMXTKZpkopTDaTLpIeV3MH3sp32TibjOtUU0o8BFjWhSPh ku198JbHKPynd6mQkybDZOtMoOJYcvEGOsM0z2yAK9eEu8rCpxuqY= Received: (qmail 25814 invoked by alias); 29 Oct 2013 12:26:59 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 25781 invoked by uid 89); 29 Oct 2013 12:26:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp12.uk.ibm.com Received: from e06smtp12.uk.ibm.com (HELO e06smtp12.uk.ibm.com) (195.75.94.108) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 29 Oct 2013 12:26:57 +0000 Received: from /spool/local by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 29 Oct 2013 12:26:54 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 29 Oct 2013 12:26:51 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 069A0219005F; Tue, 29 Oct 2013 12:26:51 +0000 (GMT) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9TCPNrS64946244; Tue, 29 Oct 2013 12:25:23 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r9TCPZD7001494; Tue, 29 Oct 2013 06:25:35 -0600 Received: from sandifor-thinkpad.stglab.manchester.uk.ibm.com (sig-9-145-208-77.de.ibm.com [9.145.208.77]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r9TCPYHw001459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 29 Oct 2013 06:25:34 -0600 From: Richard Sandiford To: Jakub Jelinek Mail-Followup-To: Jakub Jelinek , Yury Gribov , gcc-patches@gcc.gnu.org, dodji@gcc.gnu.org, dvyukov@gcc.gnu.org, kcc@gcc.gnu.org, GarbuzovViacheslav , Evgeny Gavrin , rsandifo@linux.vnet.ibm.com Cc: Yury Gribov , gcc-patches@gcc.gnu.org, dodji@gcc.gnu.org, dvyukov@gcc.gnu.org, kcc@gcc.gnu.org, GarbuzovViacheslav , Evgeny Gavrin Subject: Re: [PATCH] Invalid unpoisoning of stack redzones on ARM References: <524591E1.9060302@samsung.com> <20130927142529.GN30970@tucnak.zalov.cz> <5248FBF4.2050807@samsung.com> <525240F7.1010409@samsung.com> <525E2599.4020803@samsung.com> <20131029093730.GV30970@tucnak.zalov.cz> Date: Tue, 29 Oct 2013 12:25:33 +0000 In-Reply-To: <20131029093730.GV30970@tucnak.zalov.cz> (Jakub Jelinek's message of "Tue, 29 Oct 2013 10:37:30 +0100") Message-ID: <87bo28z2ki.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13102912-8372-0000-0000-0000079B226F Jakub Jelinek writes: > On Wed, Oct 16, 2013 at 09:35:21AM +0400, Yury Gribov wrote: >> >>> I've recently submitted a bug report regarding invalid >> unpoisoning of stack frame redzones >> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543). Could someone >> take a look at proposed patch (a simple one-liner) and check whether >> it's ok for commit? >> >> >> >> Can you please be more verbose >> > >> > Do you think the proposed patch is ok or should I provide some >> additional info? >> >> Jakub, Dodji, >> >> Any updates on this one? Note that this bug is a huge blocker for >> using AddressSanitizer on ARM platforms. > > Sorry for the delay, I finally found time to look at it. > While your patch fixes the issue, I wonder if for the case where > shadow_mem before the asan_clear_shadow call is already of the form > (mem (reg)) it isn't better to just adjust next asan_clear_shadow > base from the end of the cleared region rather than from the start of it, > because the end will be already in the right pseudo, while with your > approach it needs to be done in a different register and potentially > increase register pressure. So here is (completely untested) alternate fix: Hmm, it just seems wrong to be assigning to registers returned by force_reg and expand_binop though. Would this variation be OK? Thanks, Richard Index: gcc/asan.c =================================================================== --- gcc/asan.c (revision 204124) +++ gcc/asan.c (working copy) @@ -876,9 +876,10 @@ } /* Clear shadow memory at SHADOW_MEM, LEN bytes. Can't call a library call here - though. */ + though. If the address of the next byte is in a known register, return + that register, otherwise return null. */ -static void +static rtx asan_clear_shadow (rtx shadow_mem, HOST_WIDE_INT len) { rtx insn, insns, top_label, end, addr, tmp, jump; @@ -893,12 +894,12 @@ if (insn == NULL_RTX) { emit_insn (insns); - return; + return 0; } gcc_assert ((len & 3) == 0); top_label = gen_label_rtx (); - addr = force_reg (Pmode, XEXP (shadow_mem, 0)); + addr = copy_to_mode_reg (Pmode, XEXP (shadow_mem, 0)); shadow_mem = adjust_automodify_address (shadow_mem, SImode, addr, 0); end = force_reg (Pmode, plus_constant (Pmode, addr, len)); emit_label (top_label); @@ -912,6 +913,7 @@ jump = get_last_insn (); gcc_assert (JUMP_P (jump)); add_int_reg_note (jump, REG_BR_PROB, REG_BR_PROB_BASE * 80 / 100); + return addr; } /* Insert code to protect stack vars. The prologue sequence should be emitted @@ -1048,7 +1050,15 @@ (last_offset - prev_offset) >> ASAN_SHADOW_SHIFT); prev_offset = last_offset; - asan_clear_shadow (shadow_mem, last_size >> ASAN_SHADOW_SHIFT); + rtx end_addr = asan_clear_shadow (shadow_mem, + last_size >> ASAN_SHADOW_SHIFT); + if (end_addr) + { + shadow_mem + = adjust_automodify_address (shadow_mem, VOIDmode, end_addr, + last_size >> ASAN_SHADOW_SHIFT); + prev_offset += last_size; + } last_offset = offset; last_size = 0; }