From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118679 invoked by alias); 22 Jun 2017 13:11:00 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 118540 invoked by uid 89); 22 Jun 2017 13:10:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org 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=sk:respons X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: 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; Thu, 22 Jun 2017 13:10:57 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DE280C02C701; Thu, 22 Jun 2017 13:10:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DE280C02C701 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DE280C02C701 Received: from oldenburg.str.redhat.com (unknown [10.36.118.53]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 052FE5C3FA; Thu, 22 Jun 2017 13:10:54 +0000 (UTC) Subject: Re: RFC: Update x86 psABI to support shadow stac To: "H.J. Lu" Cc: gnu-gabi@sourceware.org, IA32 System V Application Binary Interface , "x86-64-abi@googlegroups.com" References: From: Florian Weimer Message-ID: <53356291-bb6d-3a69-3dc7-4a1f011942bd@redhat.com> Date: Sun, 01 Jan 2017 00:00: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-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 22 Jun 2017 13:10:56 +0000 (UTC) X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00038.txt.bz2 On 06/22/2017 03:01 PM, H.J. Lu wrote: > On Thu, Jun 22, 2017 at 5:51 AM, Florian Weimer wrote: >> On 06/21/2017 05:25 PM, H.J. Lu wrote: >>> GNU_PROPERTY_X86_FEATURE_1_SHSTK is set on output only if it is set on >>> all relocatable inputs, which means that the C library must be compiled >>> with SHSTK-enabled compiler. >> >> I don't think this is sufficiently detailed for an ABI specification. >> It needs to say what an SHSTK-enabled compiler does. > > Compilers just need to make return address popped from shadow > stack match return address popped from normal stack. Nothing else? Would a writable GOT still be fine? The responsibilities for compliance are split between caller and callee, which can live in different shared objects. I think it would be prudent to formulate the requirement in such a way that compliance can be checked by looking at one DSO in isolation. Is there a requirement that the return address is popped from the same stack location where it was pushed by the call instruction? Or could you return with an elevated stack pointer if you copied the address first? Thanks, Florian