From patchwork Tue Oct 29 09:37:30 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 286773 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 2100E2C0146 for ; Tue, 29 Oct 2013 20:37:44 +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:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=jdBwOF7R4s3ML14ak 2lO2J568DZ+9v8JEgRjZ67iDDFfdF3hkHqr5XCdo/FLPL4gDHxKo3mAL66bbpjOz AXrdOgKnOQ/X7L4aMX1N0LHpciZEsgUNuytC8cg/twzl2HTHIZdWtRtKFaCsd390 LI94ERAeOmPgcIE9nbNmO0i1Bk= 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:date :from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:in-reply-to; s=default; bh=viv3CcaANiEyMnlZSwdhGGU f9o8=; b=R2zhTmaP58j6HFW1DxrrCpV3dIS/c/KU0j6O31qcyjazLsHHwu7oL2k x/i9qtgpczFcUvL+Mv+zU+juEDs8SdqMAcQQnsmd2sU/mCjNEORQrCsmc0my6tJY QWTfBZALTl+S5+/6bvkLRqkcwsxQ0enQNiM2fCX2384IyX7o6v00= Received: (qmail 14406 invoked by alias); 29 Oct 2013 09:37:39 -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 14379 invoked by uid 89); 29 Oct 2013 09:37:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 4 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Oct 2013 09:37:37 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9T9bXId009107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 Oct 2013 05:37:33 -0400 Received: from tucnak.zalov.cz (vpn1-7-226.ams2.redhat.com [10.36.7.226]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r9T9bVw5027705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Oct 2013 05:37:33 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.7/8.14.7) with ESMTP id r9T9bVfO012759; Tue, 29 Oct 2013 10:37:31 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.7/8.14.7/Submit) id r9T9bU9o012758; Tue, 29 Oct 2013 10:37:30 +0100 Date: Tue, 29 Oct 2013 10:37:30 +0100 From: Jakub Jelinek To: Yury Gribov Cc: 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 Message-ID: <20131029093730.GV30970@tucnak.zalov.cz> Reply-To: Jakub Jelinek References: <524591E1.9060302@samsung.com> <20130927142529.GN30970@tucnak.zalov.cz> <5248FBF4.2050807@samsung.com> <525240F7.1010409@samsung.com> <525E2599.4020803@samsung.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <525E2599.4020803@samsung.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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: 2013-10-29 Jakub Jelinek Yury Gribov PR sanitizer/58543 * asan.c (asan_clear_shadow): Return bool whether the emitted loop (if any) updated shadow_mem's base. (asan_emit_stack_protection): If asan_clear_shadow returned true, adjust shadow_mem and prev_offset. Jakub --- gcc/asan.c.jj 2013-10-23 14:43:15.000000000 +0200 +++ gcc/asan.c 2013-10-29 10:26:56.085406934 +0100 @@ -878,10 +878,11 @@ asan_shadow_cst (unsigned char shadow_by /* Clear shadow memory at SHADOW_MEM, LEN bytes. Can't call a library call here though. */ -static void +static bool asan_clear_shadow (rtx shadow_mem, HOST_WIDE_INT len) { rtx insn, insns, top_label, end, addr, tmp, jump; + bool ret; start_sequence (); clear_storage (shadow_mem, GEN_INT (len), BLOCK_OP_NORMAL); @@ -893,12 +894,13 @@ asan_clear_shadow (rtx shadow_mem, HOST_ if (insn == NULL_RTX) { emit_insn (insns); - return; + return false; } gcc_assert ((len & 3) == 0); top_label = gen_label_rtx (); addr = force_reg (Pmode, XEXP (shadow_mem, 0)); + ret = addr == 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 +914,7 @@ asan_clear_shadow (rtx shadow_mem, HOST_ jump = get_last_insn (); gcc_assert (JUMP_P (jump)); add_int_reg_note (jump, REG_BR_PROB, REG_BR_PROB_BASE * 80 / 100); + return ret; } /* Insert code to protect stack vars. The prologue sequence should be emitted @@ -1048,7 +1051,14 @@ asan_emit_stack_protection (rtx base, HO (last_offset - prev_offset) >> ASAN_SHADOW_SHIFT); prev_offset = last_offset; - asan_clear_shadow (shadow_mem, last_size >> ASAN_SHADOW_SHIFT); + if (asan_clear_shadow (shadow_mem, last_size >> ASAN_SHADOW_SHIFT)) + { + shadow_mem + = adjust_automodify_address (shadow_mem, VOIDmode, + XEXP (shadow_mem, 0), + last_size >> ASAN_SHADOW_SHIFT); + prev_offset += last_size; + } last_offset = offset; last_size = 0; }