From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46169 invoked by alias); 19 Jun 2017 18:21:42 -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 46151 invoked by uid 89); 19 Jun 2017 18:21:41 -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_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=outweigh, Hx-languages-length:1107, complications 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; Mon, 19 Jun 2017 18:21:40 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 53EA280F6B; Mon, 19 Jun 2017 18:21:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 53EA280F6B Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 53EA280F6B Received: from oldenburg.str.redhat.com (dhcp-192-212.str.redhat.com [10.33.192.212]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 71A7B17DCC; Mon, 19 Jun 2017 18:21:43 +0000 (UTC) Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC To: Joseph Myers , Jeff Law Cc: gcc-patches References: From: Florian Weimer Message-ID: <3acee4e1-1c60-90e5-f55f-146e817d9e62@redhat.com> Date: Mon, 19 Jun 2017 18:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01364.txt.bz2 On 06/19/2017 07:50 PM, Joseph Myers wrote: > 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.) I think architectures such as aarch64 without implied stack probing as part of the function call sequence would benefit most from an ABI agreement (splitting the probing responsibility in some way between caller and callee). For architectures with some form of implied probing, the complications from negotiating a guard region size between GCC, kernel, glibc, and perhaps even applications (see Jakub's comment about thread stacks) outweigh the performance gains. Thanks, Florian