From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82665 invoked by alias); 28 Jul 2017 20:54:47 -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 82548 invoked by uid 89); 28 Jul 2017 20:54:42 -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.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=claim X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no 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-f52.google.com Received: from mail-oi0-f52.google.com (HELO mail-oi0-f52.google.com) (209.85.218.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Jul 2017 20:54:40 +0000 Received: by mail-oi0-f52.google.com with SMTP id a9so143014269oih.0 for ; Fri, 28 Jul 2017 13:54:40 -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=Xa1dbwCpkD1gT4R/Jvdzh0sbIABWtbP5ZswxikFtYx0=; b=QURd8uAfTY1+bf46LwHYwr4QygnJ8dIN14zcHs0cJfZFNTR+yXQUsIAHFCeocvXO2N AwSElVLxQap6VYRxoLZoHxFLrOMdLuiHNk7huw/ogN2iVdiKgoKpbD4cam/Z9CqWoZOd y5vJPKtoRTP1gH1ZH0l9+JQqoN1NXy7W8FhsCAcMv/PytA2WryI7EkTh7fW+ccuq3UjK Rw7CByaZ8uDWaalpiHhmdKtqep8vi5/sEhBN1gWEefNjQ0Y/Wj7azAtaBFV7ASynAKgH 0iNhe2B/m4nFeu3RHUhBjyrN3QFqfFN9oOKkgvlKZHZ679W8k3nsdfOLgT1aIspgdXtn pfyA== 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=Xa1dbwCpkD1gT4R/Jvdzh0sbIABWtbP5ZswxikFtYx0=; b=rgFhR9ItKfPUG/raUbZm/Qwz8iLhSxyS90BLZ6Gc8kAg+l9Aoc3AqltnyA7BjUEpTL 9GAFw2H3lAO82EiUJO1L6xPiHA8qYHqNcjSni4fk/76HROepZ5xqxEKZ3XqXxNLs5OTA FxhZ9OOYpKZSVN4AdCF0wLTt+O0olph/pu0cv3DPYslMtM5oBz0BJxlLZZukcf3geWBs w1hzIA9Rt9jxLSQ41JCrjXqLQvLbUU51SFBDMlCDnWcjkF87ldqCRu0z7z+q+susupRy pv4Vge+fFptCvC6BcPEYRXxk0wwAZiMuYMh7HaqU089DICuQ5zElcUfpAhLd6TN6w9QV qB3w== X-Gm-Message-State: AIVw111/PxVuKpmNpTJX3D6ULVV1y5voSQ0pY7M//5bPjCMGUiqVL+cK BsazwBlka1MfiJd2Ek4fTT9KqbVInzzk X-Received: by 10.202.219.198 with SMTP id s189mr8833810oig.103.1501275279130; Fri, 28 Jul 2017 13:54:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.169.200 with HTTP; Fri, 28 Jul 2017 13:54:38 -0700 (PDT) In-Reply-To: <2cf0aaad-7c15-6040-2e5b-5e92ffaf011e@redhat.com> References: <53356291-bb6d-3a69-3dc7-4a1f011942bd@redhat.com> <4a0a3d70-ff4b-9c99-810a-4537d5415594@redhat.com> <20561ce4-e433-618b-86fd-5d74dbf0e56e@redhat.com> <2cf0aaad-7c15-6040-2e5b-5e92ffaf011e@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-q3/txt/msg00003.txt.bz2 On Fri, Jul 28, 2017 at 7:59 AM, Florian Weimer wrote: > On 07/27/2017 06:21 PM, H.J. Lu wrote: >> 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 wrote: >>>>> On 06/22/2017 08:44 PM, H.J. Lu wrote: >>>>>>> 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? >>>>> >>>>> 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 > > So i386 is supported? Then I find your claim about 99% compatibility Yes, i386 is supported. > surprising because LLVM uses this instruction sequence > > calll .L0$pb > .L0$pb: > popl %ebx > .Ltmp0: > addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp0-.L0$pb), %ebx > > to set %ebx to the GOT pointer. > This is called "call 0" and it won't push on shadow stack. CET document will be updated to reflect it. -- H.J.