From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113088 invoked by alias); 17 Jul 2017 22:42:49 -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 113075 invoked by uid 89); 17 Jul 2017 22:42:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=punt X-HELO: EUR03-AM5-obe.outbound.protection.outlook.com Received: from mail-eopbgr30053.outbound.protection.outlook.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (40.107.3.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Jul 2017 22:42:45 +0000 Received: from AM5PR0802MB2610.eurprd08.prod.outlook.com (10.175.46.18) by AM5PR0802MB2611.eurprd08.prod.outlook.com (10.175.46.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.13; Mon, 17 Jul 2017 22:42:42 +0000 Received: from AM5PR0802MB2610.eurprd08.prod.outlook.com ([fe80::b567:13a:e52:92de]) by AM5PR0802MB2610.eurprd08.prod.outlook.com ([fe80::b567:13a:e52:92de%17]) with mapi id 15.01.1261.024; Mon, 17 Jul 2017 22:42:42 +0000 From: Wilco Dijkstra To: Jeff Law , GCC Patches CC: nd Subject: Re: [PATCH][RFA/RFC] Stack clash mitigation patch 07/08 Date: Mon, 17 Jul 2017 22:42:00 -0000 Message-ID: References: ,<5eb3783f-7a00-1361-461e-92b99bcb338b@redhat.com> In-Reply-To: <5eb3783f-7a00-1361-461e-92b99bcb338b@redhat.com> authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=arm.com; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;AM5PR0802MB2611;7:OnfieBM7FrXz1nZr204XnIIcMvEaaZCLubmfPJEIXjmustH/PYBUeONPa5xvs2yY72zslt4ZSSpxJF9YCVHVYr5Ibppg1KzGzFdB1ycfnAlNTcNtpA8Wiz5HBFVcb1v8QG4kEQzuKY2BPkQoxQsy1jPTkYQ1NAJ8YtnxjC50wkqKdzsEPkHYGifj3elXWq807XlSc2n3MwykkFl7a5ziDUP3/0CzpOl9sVZpIM3zS6MjOJO3oOv7uo3DZ7tN2aVJvRYBtRW6HoWxXJ4Fg+Yu5YL/VCHoZfv4WFBe4R67zVPZRwKfJjm9Fezv3JdFYE59+i7m4AfgkH554t8FNF+F8i88+3gkrYJuhMf49bu6voGcjIP3mtUzy4nBsJdQ3qop1reX8V/KGWd0JsuP/VfFW53Gu5WMtdlvl8I8V3WYIrbl39eCCTS+vJ8+3A/I6RiSV2hEwQ6XtBpy+xsYS5SEuFbJa7m0pbuPU57RshAY/qw0bSmCHnzZdch3pai3WeVJcleT5jZOFIsNPi9jBaqBDg052yV+eEPHDCGHXHGCRItvyPuw0yzVtYPvE5un1MkV0KFrFehPCSpKIZSG18V29VL41sE+/mRzTIAH4jjqoQB5gnXWr00gBz694r0kfYkwvG0eozyz3Pke8ei6pYoORZRitptGAxSW26sswlKXq8XBqPVhe3uZ9ouxG9deGfj8i8DZiaHYC1ehWe0qqWk4Q7t9u66tSnEXHMEyFaqEdMNHug1GLg999DIk9LaaWxGe6hND7WpwQkfNuyO+bWXa0YhPKnrPpARRZBqcaV2p+WQ= x-ms-office365-filtering-correlation-id: 64865c0b-bebc-492f-9160-08d4cd6522b1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:AM5PR0802MB2611; x-ms-traffictypediagnostic: AM5PR0802MB2611: nodisclaimer: True x-exchange-antispam-report-test: UriScan:(236129657087228)(256282310955234)(247924648384137); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(2017060910075)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:AM5PR0802MB2611;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:AM5PR0802MB2611; x-forefront-prvs: 0371762FE7 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(6009001)(39860400002)(39450400003)(39840400002)(39410400002)(39850400002)(39400400002)(377454003)(24454002)(2950100002)(6436002)(25786009)(53936002)(50986999)(76176999)(6246003)(54356999)(478600001)(72206003)(9686003)(33656002)(93886004)(3846002)(102836003)(6116002)(55016002)(99286003)(66066001)(305945005)(81166006)(2906002)(8676002)(74316002)(2900100001)(4326008)(6506006)(5250100002)(5660300001)(3660700001)(3280700002)(7696004)(53546010)(8936002)(189998001)(86362001)(38730400002)(7736002)(14454004)(229853002);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR0802MB2611;H:AM5PR0802MB2610.eurprd08.prod.outlook.com;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2017 22:42:42.2575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0802MB2611 X-SW-Source: 2017-07/txt/msg01009.txt.bz2 Jeff Law wrote:=A0=20=20=20 > On 07/17/2017 05:27 AM, Wilco Dijkstra wrote: > > A minimum guard size of 64KB seems reasonable even on systems with > > 4KB pages. However whatever the chosen guard size, you cannot defend > > against hostile code. An OS can of course increase the guard size well= =20 > > beyond the minimum required, but that's simply reducing the probability= - > > it is never going to block a big unchecked alloca. > That's a kernel issue and I'm not in a position to change that.=A0 On > systems with a 64bit address space, I'm keen to see the kernel team > increase the guard size, but it's not something I can unilaterally make > happen. Well if we want the stack guard catch cases with high probability even if s= ome or most of the code is unchecked, it must be made much larger. And the fact you can set the stack guard to zero in GLIBC is worrying as that would allo= w an attacker to trivially bypass the stack guard... > > Outgoing args are not an area for concern even with a 4KB stack guard. > They are a concern and as the size of the guard comes down, they become > an increasing concern, IMHO. At 4KB it's 1000 times more likely to have a frame that could skip the stack guard than outgoing args. That's before we consider alloca which is even more common. > > In 99% of the frames only one stack allocation is made. There are a few > > cases where the stack can be adjusted twice. > BUt we still have to deal with the cases where there are multiple > adjustments.=A0 Punting in the case of multiple adjustments isn't the > right thing to do.=A0 Some level of tracking is needed. I didn't say we should punt, just that no tracking is required. The AArch64= prolog code is extremely simple. The only adjustments that need to be checked are= =20 initial_adjust and final_adjust. Callee_adjust doesn't need any checks sinc= e it is=20 limited by the range of STP (ie. < 512) and if the locals are large, it is = zero. Anyway the only complex case is shrinkwrapping. We know that at least LR mu= st be saved before a call, but with -fomit-frame-pointer it doesn't always end up= at the bottom of the callee-saves. We could take its offset into account or force = it at offset 0. > > To be safe I think we first need to probe and then allocate. Or are the= re going > > to be extra checks in asynchronous interrupt handlers that check whethe= r SP is > > above the stack guard? > That hits the red zone, which is unfortunate.=A0 But it's acceptable IMHO. How do you mean? What will happen if SP points into the heap? Will the trap handler just write to it without any check? Wilco