From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117582 invoked by alias); 19 Jun 2017 22:10:36 -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 117565 invoked by uid 89); 19 Jun 2017 22:10:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=Its, H*M:4fe9, cons 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 22:10:34 +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 24D948046A; Mon, 19 Jun 2017 22:10:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 24D948046A Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 24D948046A Received: from oldenburg.str.redhat.com (ovpn-116-107.ams2.redhat.com [10.36.116.107]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5C045189BD; Mon, 19 Jun 2017 22:10:37 +0000 (UTC) Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC To: Jeff Law , Joseph Myers Cc: gcc-patches References: <3acee4e1-1c60-90e5-f55f-146e817d9e62@redhat.com> From: Florian Weimer Message-ID: <04e52860-9f4a-4fe9-be85-def23645b05b@redhat.com> Date: Mon, 19 Jun 2017 22:10: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/msg01384.txt.bz2 On 06/20/2017 12:05 AM, Jeff Law wrote: > On 06/19/2017 03:56 PM, Joseph Myers wrote: >> On Mon, 19 Jun 2017, Florian Weimer wrote: >> >>> 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 >> >> I'd expect that, regardless of architecture, if calls don't write to the >> stack, the caller has to save its own return address somewhere before >> making a call, which means writing the saved link register. > True, but the callee doesn't know the offset where the caller saved the > return address. In fact, different callers could have stored it at > different offsets. AFAICT for these targets we just have to make a > worst case assumption about the caller. There are also some weird corner cases like this one: H. Baker, “CONS Should Not CONS Its Arguments, Part II: Cheney on the M.T.A.” . So I think some sort of convention is needed here. Thanks, Florian