From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76467 invoked by alias); 14 Jul 2017 16:53:19 -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 76458 invoked by uid 89); 14 Jul 2017 16:53:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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; Fri, 14 Jul 2017 16:53:17 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4C4162CBE6B; Fri, 14 Jul 2017 16:53:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4C4162CBE6B Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 4C4162CBE6B Received: from localhost.localdomain (ovpn-116-196.phx2.redhat.com [10.3.116.196]) by smtp.corp.redhat.com (Postfix) with ESMTP id F096C7DE04; Fri, 14 Jul 2017 16:53:15 +0000 (UTC) Subject: Re: [PATCH][RFA/RFC] Stack clash mitigation patch 01/08 To: Segher Boessenkool Cc: "gcc-patches@gcc.gnu.org >> gcc-patches" References: <93ce7fc1-e41e-282f-a574-234a83d57d7d@redhat.com> <20170713003157.GW13471@gate.crashing.org> <470c6af6-0c13-34fb-8ccb-7c31d24181f2@redhat.com> <20170713213201.GI13471@gate.crashing.org> <4585bb1f-4f06-f6f1-056e-dbcdf26e1db4@redhat.com> <20170713233742.GO13471@gate.crashing.org> <65e5881f-3a86-2ad6-6b72-e6e114be02bd@redhat.com> <20170714163436.GW13471@gate.crashing.org> From: Jeff Law Message-ID: Date: Fri, 14 Jul 2017 16:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170714163436.GW13471@gate.crashing.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00849.txt.bz2 On 07/14/2017 10:34 AM, Segher Boessenkool wrote: > On Thu, Jul 13, 2017 at 10:35:55PM -0600, Jeff Law wrote: >>>> There's -fstack-check and -fstack-clash-protection. I think with the >>>> direction we're going they are fundamentally incompatible because >>>> neither the compiler nor kernel do anything to guarantee enough stack is >>>> available after hitting the guard for -fstack-clash-protection. >>> >>> Hrm, I have to think about that. >> Even if the kernel implements the reserved page stuff mentioned earlier >> in the thread, I'm not sure when we'd be able to reliably depend on that >> capability (or even check for it). >> >> ISTM that -fstack-check continues to be Ada centric and we have a new >> option to deal with stack-clash protection and the two simply just >> aren't allowed to be enabled together. > > So this essentially means Ada programs cannot get stack clash protection > at all? And if -fstack-check is really only useful for Ada, we shouldn't > mix up that option with the stack clash thing. It's not a simple yes/no. For Ada the model is that the entire application will be compiled with -fstack-check and that each function that allocates space probes 2-3 pages beyond their immediate need to ensure space to run the signal handler (damn the large register files :-) Those are absolutely critical to keep in mind. In combination they allow prologues to skip the first 2-3 page probes (they were done earlier in the call chain). So from a standpoint of probing each and every allocated page, Ada with -fstack-check will do that if and only if every function is compiled with -fstack-check. But the actual allocation/probing tends to look like this in the prologues allocate all the stack space probe third page probe fourth page probe fifth page etc So there's a race condition between the allocation point and when the probes execute which means an async signal handler could be running on a clashed stack/heap. So an Ada program fully compiled with -fstack-check will mostly be protected from a stack-clash style attack. They could achieve better protection by fixing the -fstack-check=specific prologue sequences so that they allocate and probe a page at a time. That (mostly) closes the issue with signal handlers running on a clashed stack/heap. They could achieve a level of protection in mixed code environments by not skipping page probes. But that would result in significantly worse code given the current implementation of -fstack-check. > > With what is in trunk so far, yeah ;-) In principle the "set up a stack > frame" part of the prologue can be made a separate shrink-wrapping > component and then we'd have to worry. But it would be complicated to > do that and there is no real benefit I see so far, so it won't happen. > Nothing for you to have to worry about in any case :-) That's consistent with my thoughts as well. You could separately wrap the allocation, but it's not likely to be that beneficial and it would seem to add a fair amount of complexity. jeff