From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81800 invoked by alias); 20 Jun 2017 08:27:40 -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 81763 invoked by uid 89); 20 Jun 2017 08:27:38 -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,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=site X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Jun 2017 08:27:37 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8ACB7344; Tue, 20 Jun 2017 01:27:35 -0700 (PDT) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 585573F41F; Tue, 20 Jun 2017 01:27:34 -0700 (PDT) Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC To: Jeff Law , Joseph Myers Cc: gcc-patches References: From: "Richard Earnshaw (lists)" Message-ID: Date: Tue, 20 Jun 2017 08:27:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2017-06/txt/msg01404.txt.bz2 On 19/06/17 20:04, Jeff Law wrote: > On 06/19/2017 11:50 AM, Joseph Myers wrote: >> On Mon, 19 Jun 2017, Jeff Law wrote: >> >>> A key point to remember is that you can never have an allocation >>> (potentially using more than one allocation site) which is larger than a >>> page without probing the page. >> >> There's a platform ABI issue here. At least some kernel fixes for these >> stack issues, as I understand it, increase the size of the stack guard to >> more than a single page. It would be possible to define the ABI to >> require such a larger guard for protection and so reduce the number of >> (non-alloca/VLA-using) functions that need probes generated, depending on >> whether a goal is to achieve security on kernels without such a fix. >> (Thinking in terms of how to get to enabling such probes by default.) > On 32 bit platforms we don't have a lot of address space left, so we > have to be careful about creating too large of a guard. > > On 64 bit platforms we have a lot more freedom and I suspect larger > guards, mandated by the ABI would be useful, if for no other reason than > allowing us to allocate more stack without probing. A simple array of > PATH_MAX characters triggers probing right now. I suspect (but didn't > bother to confirm) that PATH_MAX array are what causes git to have so > many large stacks. > > Also if we look at something like ppc and aarch64, we've currently got > the PROBE_INTERVAL set to 4k. But in reality they're using much larger > page sizes. So we could improve things there as well. > There are aarch64 linux systems using 4k pages for compatibility with existing aarch32 binaries. R. > > jeff >