From patchwork Tue Aug 30 09:38:41 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Edlinger X-Patchwork-Id: 664072 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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3sNk444ygwz9s9W for ; Tue, 30 Aug 2016 19:38:58 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=oXQOlHqk; dkim-atps=neutral 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:date:message-id:references:in-reply-to :content-type:content-id:content-transfer-encoding:mime-version; q=dns; s=default; b=iEOX4xxIBV1Q7RE2/grIF+nZpozHDuZKCNGhRWatI9m Wx4MKvS74E54mBk8Nr0qj7UNfYe5ejoN5FMZaaQuYQtIc/s0s0u9k399NuFHcRID s7yM3Lkvo5kvXbbF089Dx1o+8YjMrj2rHFcB7A5akcVMk7SfFYXqbSIZUqGblx2Y = 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:date:message-id:references:in-reply-to :content-type:content-id:content-transfer-encoding:mime-version; s=default; bh=VUeU3OWRw/l5wYWykaZ2FsroGkQ=; b=oXQOlHqkmZkEGfA2W g4TSODhvJpbQ6P2FNtsXJfqMJAM+3ukeMRFga+mvd0uwV/ByPaBmbhtX3XVqoMt7 JcCHHoGmRGbqGCJs3cTIDsDpgPcceVS00xJmUsYdAe74UejF5UW0lrsYxG6G8psB kL3/7YlwrDtk1K2ffqjsUu0NdQ= Received: (qmail 125008 invoked by alias); 30 Aug 2016 09:38:49 -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 124990 invoked by uid 89); 30 Aug 2016 09:38:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=no version=3.3.2 spammy=Hx-spam-relays-external:sk:SNT004-, H*RU:sk:SNT004-, Hx-spam-relays-external:sk:snt004-, H*RU:sk:snt004- X-HELO: SNT004-OMC3S42.hotmail.com Received: from snt004-omc3s42.hotmail.com (HELO SNT004-OMC3S42.hotmail.com) (65.54.51.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 30 Aug 2016 09:38:47 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com ([65.55.90.135]) by SNT004-OMC3S42.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 30 Aug 2016 02:38:45 -0700 Received: from DB5EUR01FT033.eop-EUR01.prod.protection.outlook.com (10.152.4.52) by DB5EUR01HT004.eop-EUR01.prod.protection.outlook.com (10.152.4.89) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6; Tue, 30 Aug 2016 09:38:43 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com (10.152.4.55) by DB5EUR01FT033.mail.protection.outlook.com (10.152.4.248) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Tue, 30 Aug 2016 09:38:43 +0000 Received: from AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) by AM4PR0701MB2162.eurprd07.prod.outlook.com ([10.167.132.147]) with mapi id 15.01.0599.010; Tue, 30 Aug 2016 09:38:41 +0000 From: Bernd Edlinger To: Tom de Vries , Marek Polacek CC: Jeff Law , "gcc-patches@gcc.gnu.org" , Jakub Jelinek , "H.J. Lu" Subject: Re: [PATCH] Fix PR64078 Date: Tue, 30 Aug 2016 09:38:41 +0000 Message-ID: References: <20150907100700.GC30849@redhat.com> <55EF3690.8030201@redhat.com> <55F050D5.3020408@redhat.com> <20150917150026.GC27588@redhat.com> <55FAECA8.3070909@redhat.com> <20150917180838.GE27588@redhat.com> <7fcd8db4-af35-a0fe-fc5a-f7999d0c5fca@mentor.com> <963e7657-0e40-9d73-f199-ffc709761428@mentor.com> In-Reply-To: <963e7657-0e40-9d73-f199-ffc709761428@mentor.com> authentication-results: spf=softfail (sender IP is 10.152.4.55) smtp.mailfrom=hotmail.de; mentor.com; dkim=none (message not signed) header.d=none; mentor.com; dmarc=none action=none header.from=hotmail.de; received-spf: SoftFail (protection.outlook.com: domain of transitioning hotmail.de discourages use of 10.152.4.55 as permitted sender) x-ms-exchange-messagesentrepresentingtype: 1 x-eopattributedmessage: 0 x-forefront-antispam-report: CIP:10.152.4.55; IPV:NLI; CTRY:; EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5EUR01HT004; H:AM4PR0701MB2162.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; x-microsoft-exchange-diagnostics: 1; DB5EUR01HT004; 6:WfUfFSOQNLypIvp+UZ+EqJCtwklgZ8QBOAIPTKsb968ipJks055DD5CdCnJeHwQglbItQGe22j0eTRb1Wx5S9U5y0aaI5Nq21/KQ3cwNWFrTrK/Ol97+ISSINLOfddkCREokxZrKGDmwAZ+5sPYcibF1NikJZ0209VGySGWBf/bHTGo7JgFBS9022ElCzqrVcffXZTLAuSzMWN2bF46SYkJ2LFp0XY5N2IWnhcnyMa/9zDibDWe+0acau02LAn6DdF4fpcuZdInSbocwRw+cDcHeAp/RD09IyI+xvGLNZUWqEgJkrBzQIbUsMZLMWaX1; 5:bIt7vKzoPL0I+bxt1XR42bjLnc7Ad/4dZ11lXHzo6UUTpDJOTb6/yWWWMbpfqelJV0RwWi8WpTgX06MqgBf3o/Da3YtPof4ChX3PaoEVI1r/RAgBG88w6MsJEzPiTfAdu1+/ADtqqUvzX+gXrgTnLw==; 24:jVZ/iZRYOwNdc3Bry210AFShskkdaleE74vINE+AXPjsGDKjPehvHpx7jVY34vN/acC3RD0wjOq4hRCuNfJx4CUewwq325DY+BQCGAvukhI=; 7:zxe6/uSMAJTvw7nC8JvwMeqiJNLD2H/1hmnDI32UMQRnySodEW6MwLUUNaPORMzBTT8wOdHuX88mdJOhjHUMk76xRp2D6csfrgIVQr61T7kwmLT6Y6TFezBEtws+J6+FcxCqr2qy+FCDiKml2zCiFEme2hXPww+Pj8LGoAbkGsRYdBCPXcCzPNgwW/LUzE/x5J8s8ELpeplffgajlEYNJqp6s35l3vMSfDZ9KKl7ulRN977PogyxzUyvUT8OI/RC x-ms-office365-filtering-correlation-id: 733f12bb-a65c-4ac5-7a38-08d3d0b96d29 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(1601124038)(1601125047); SRVR:DB5EUR01HT004; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:DB5EUR01HT004; BCL:0; PCL:0; RULEID:; SRVR:DB5EUR01HT004; x-forefront-prvs: 0050CEFE70 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <1F6D533970969F4290B13922D3773FC1@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 09:38:41.8822 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR01HT004 On 08/30/16 10:21, Tom de Vries wrote: > On 29/08/16 18:43, Bernd Edlinger wrote: >> Thanks! >> >> Actually my patch missed to fix one combination: -m32 with -fpic >> >> make check-gcc-c++ RUNTESTFLAGS="ubsan.exp=object-size-9.c --tool_opts >> '-m32 -fpic'" >> >> FAIL: c-c++-common/ubsan/object-size-9.c -O2 execution test >> FAIL: c-c++-common/ubsan/object-size-9.c -O2 -flto >> -fno-use-linker-plugin -flto-partition=none execution test >> >> The problem here is that the functions f2 and f3 access a stack- >> based object out of bounds and that is inlined in main and >> therefore smashes the return address of main in this case. >> >> A possible fix could look like follows: >> >> Index: object-size-9.c >> =================================================================== >> --- object-size-9.c (revision 239794) >> +++ object-size-9.c (working copy) >> @@ -93,5 +93,9 @@ >> #endif >> f4 (12); >> f5 (12); >> +#ifdef __cplusplus >> + /* Stack may be smashed by f2/f3 above. */ >> + __builtin_exit (0); >> +#endif >> return 0; >> } >> >> >> Do you think that this should be fixed too? > > I think it should be fixed. Ideally, we'd prevent the out-of-bounds > writes to have harmful effects, but I'm not sure how to enforce that. > > This works for me: > ... > diff --git a/gcc/testsuite/c-c++-common/ubsan/object-size-9.c > b/gcc/testsuite/c-c++-common/ubsan/object-size-9.c > index 46f1fb9..fec920d 100644 > --- a/gcc/testsuite/c-c++-common/ubsan/object-size-9.c > +++ b/gcc/testsuite/c-c++-common/ubsan/object-size-9.c > @@ -31,6 +31,7 @@ static struct C > f2 (int i) > { > struct C x; > + struct C x2; > x.d[i] = 'z'; > return x; > } > @@ -45,6 +46,7 @@ static struct C > f3 (int i) > { > struct C x; > + struct C x2; > char *p = x.d; > p += i; > *p = 'z'; > ... > > But I have no idea how stable this solution is. > At least x2 could not be opimized away, as it is no POD, but there is no guarantee, that x2 comes after x on the stack. Another possibility, which seems to work as well: Thanks Bernd. Index: gcc/testsuite/c-c++-common/ubsan/object-size-9.c =================================================================== --- gcc/testsuite/c-c++-common/ubsan/object-size-9.c (revision 239794) +++ gcc/testsuite/c-c++-common/ubsan/object-size-9.c (working copy) @@ -30,7 +30,7 @@ f1 (struct T x, int i) static struct C f2 (int i) { - struct C x; + struct C x __attribute__ ((aligned(16))); x.d[i] = 'z'; return x; } @@ -44,7 +44,7 @@ f2 (int i) static struct C f3 (int i) { - struct C x; + struct C x __attribute ((aligned(16))); char *p = x.d; p += i; *p = 'z';