From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1031 invoked by alias); 22 Jun 2017 18:45: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 1002 invoked by uid 89); 22 Jun 2017 18:44: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=-3.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS 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: mail-oi0-f41.google.com Received: from mail-oi0-f41.google.com (HELO mail-oi0-f41.google.com) (209.85.218.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Jun 2017 18:44:58 +0000 Received: by mail-oi0-f41.google.com with SMTP id p187so13973506oif.3 for ; Thu, 22 Jun 2017 11:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xo+BTQrj+duqQvkQS1eqk+eo4BnM2rixJbv/BSDMsrE=; b=d0g5mGfYXhm8rkD9LmxvV6mz7Dr+hjf2w4Z5wDxrxAWi5AJdnkOuauwLba8Bm+QDAk iHMaKNmn/qQF5q8BWtWBV4Ekp6P0bJxoBOUfT4Yo1Mtww4QrD3L+3LPvNTiwNVEOFW8P GDzwjtf41zAemdX6HTZCI3xzOYIif0VfCXEAzN5rp5Fyd+o0HK4afES7/ibcuVfW146H /dVON6bNEW6sdySne5s/J4m5+lm1FZ9/cNbTuR8efTSGTeVO0PSWagUCzh+R+i7ZmM63 ebARMTLrXx6Pwoz+kQ56O6wJJr1EiSw/hanDcd0LN/Wa3Yn2NGB8x1XB5vFSGr/njIDw nSlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xo+BTQrj+duqQvkQS1eqk+eo4BnM2rixJbv/BSDMsrE=; b=k0zby7r52ccHqxxSDDuBaMdMeD9FEDayDb0hzZcPJJKV8loTfjLIxgNTDbMEQFXygL Shjkkq2P+azRcLn+54UMl36XsXGoegvBDP+xAZpjTj7bVzsLPPY457K0Bx3OIf3cGyKM WBjOD+Ne6P4+wXPYEEccnsI2G+kawgl44e1HzMmcOOWZQ0SRRBc6BApKWs+yehFrk2VA +noeAAN7b4FSil4u0Y8KkF44cwPs6GSaGHi5wGHwne4TKwga+OFZ28wJmjOi0hTuyuwN nJ58ldrCn8w1itI2p476gqKtzWmX6khvuD5QznqU8slc5pFLxSaLW4s5eMQmR5Wt9Vqv aD6g== X-Gm-Message-State: AKS2vOyS1LahjBSuzVp6X7JfAUP3AmMFCSx7q2BkqUgxurCTHjIcEP/q lpCMOAgd3CQnHr+vQxvKqrpCetSeGFlC X-Received: by 10.202.104.144 with SMTP id o16mr2333996oik.158.1498157096946; Thu, 22 Jun 2017 11:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.141.84 with HTTP; Thu, 22 Jun 2017 11:44:56 -0700 (PDT) In-Reply-To: <53356291-bb6d-3a69-3dc7-4a1f011942bd@redhat.com> References: <53356291-bb6d-3a69-3dc7-4a1f011942bd@redhat.com> From: "H.J. Lu" Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: RFC: Update x86 psABI to support shadow stac To: Florian Weimer Cc: gnu-gabi@sourceware.org, IA32 System V Application Binary Interface , "x86-64-abi@googlegroups.com" , "Shanbhogue, Vedvyas" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00039.txt.bz2 On Thu, Jun 22, 2017 at 6:10 AM, Florian Weimer wrote: > 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? Writable GOT is OK. > 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. What do you mean by it? > 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? Stack location isn't checked. Only the popped return address is checked. Vedvyas can confirm it. -- H.J.