From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64655 invoked by alias); 27 Jul 2017 16:21:10 -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 63541 invoked by uid 89); 27 Jul 2017 16:21:09 -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=-2.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:U*gnu-gabi, Hx-languages-length:1988 X-Spam-Status: No, score=-2.9 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-f51.google.com Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com) (209.85.218.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Jul 2017 16:21:08 +0000 Received: by mail-oi0-f51.google.com with SMTP id a9so111331095oih.0 for ; Thu, 27 Jul 2017 09:21:07 -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:content-transfer-encoding; bh=duq5uGyfCXpPWxoweSx0ZNRrCF9alt/Wu7dK460E658=; b=Yc7Kjol5dbZ8jthcTyDZSi/j0DubwcbSsfU0Y33ABdbPLJ75ghQqvHKm0r4LOSaZUK vin6IjNite/dj/UGl/vfFQmX/rPtMiIBbBMqVluxmX6WgVJvdolobTx50cViMo1wtM5W 5Gvnd4zADp5WeyWRVseuAwXM2psU6xSeLnauCJVjZyc1w36wliJmZ25b2/lAYr7INCa8 +9joqUW/KyvVYN6QnQMazv4PAN+1rtB9HywGz9FW/Zwuj/divpNNu8gjqU3M5t3NzNX6 JoJ7Li/4gCzGFnAtXEca1aW+6DusrPFjbY51PuMvnlivkNnOFFyODGqQeF0KpdrBpx80 ASLw== 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:content-transfer-encoding; bh=duq5uGyfCXpPWxoweSx0ZNRrCF9alt/Wu7dK460E658=; b=EkG+YPlD330U3bdsAAut1JMbrKzJPnP7d8Z+4zhMJKt/eonSBHbtc7K3kH9liO0pUG Onkz/ds3OpwMgLByaNpNxpAekE3cuyLkkzRNseCvWNcCKecAF4KuIN44HgzK+BR0LFSm u4EOuaWioTBgp9swyKixIZocfOpr8qzmzwJ0JmhUr9GefzauBZLHpei4LrW8JHYZrrxQ 5muCpddDWESVADIF/7ztz24171r3nAuAEebUmjEEwBEloZdfk0lMKSQUyvC+nwkuOAWw lH0KRHoztpwv5IIHzRN07wZwNjNmJks3sGzMsY4jQZaoxS31gXIDZKODUU6Q0ITmlngo 7g/w== X-Gm-Message-State: AIVw11318YjHvNLzGjERtSPFNGW/vN/fQ0ue+E7Qr/cmWSNGwHePJI2F cfy3UvmMfCyAByfXiGd0WU0w7CDmpQ== X-Received: by 10.202.8.70 with SMTP id 67mr687612oii.194.1501172466348; Thu, 27 Jul 2017 09:21:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.169.200 with HTTP; Thu, 27 Jul 2017 09:21:05 -0700 (PDT) In-Reply-To: <20561ce4-e433-618b-86fd-5d74dbf0e56e@redhat.com> References: <53356291-bb6d-3a69-3dc7-4a1f011942bd@redhat.com> <4a0a3d70-ff4b-9c99-810a-4537d5415594@redhat.com> <20561ce4-e433-618b-86fd-5d74dbf0e56e@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" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-q3/txt/msg00001.txt.bz2 On Thu, Jul 27, 2017 at 8:44 AM, Florian Weimer wrote: > On 06/28/2017 01:21 PM, H.J. Lu wrote: >> On Wed, Jun 28, 2017 at 2:58 AM, Florian Weimer wro= te: >>> On 06/22/2017 08:44 PM, H.J. Lu wrote: >>>>> The responsibilities for compliance are split between caller and call= ee, >>>>> which can live in different shared objects. I think it would be prud= ent >>>>> 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? >>> >>> I suggest to word the ABI requirement in such a way that it is possible >>> to verify if a shared object complies with it isolation, independent of >>> how its functions are called. >>> >> >> 99% of existing binaries are compatible with shadow stack. > > I find that surprising, or does this number to refer to x86-64 binaries > only? CET is x86 specific. You can take a look at the current CET changes for GCC at https://github.com/hjl-tools/gcc/tree/hjl/cet/reorg16 >> It is hard >> to tell just by looking at assembly instructions. If shadow stack is en= abled, >> compiler should turn on the SHSTK bit in output: >> >> [hjl@gnu-tools-1 32]$ readelf -n crtprec32.o >> >> Displaying notes found in: .note.gnu.property >> Owner Data size Description >> GNU 0x0000000c NT_GNU_PROPERTY_TYPE_0 >> Properties: x86 feature: IBT >> GNU 0x0000000c NT_GNU_PROPERTY_TYPE_0 >> Properties: x86 feature: SHSTK >> [hjl@gnu-tools-1 32]$ >> >> I don't know if it is sufficient for verification. > > The ABI document needs to specify what the flag means. I don't think > it's sufficient to essentially say, =E2=80=9Cthe toolchain did or did not= do > some unspecified stuff and we believe the binary is now compatible with > the shadow stack feature=E2=80=9D. > Please see CET x86-64 psABI: https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI and let me know if they are sufficient. Thanks. --=20 H.J.