From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14475 invoked by alias); 21 Feb 2019 03:01:41 -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 14191 invoked by uid 89); 21 Feb 2019 03:01:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=waste X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_1,GIT_PATCH_2,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-oi1-f196.google.com Received: from mail-oi1-f196.google.com (HELO mail-oi1-f196.google.com) (209.85.167.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Feb 2019 03:01:20 +0000 Received: by mail-oi1-f196.google.com with SMTP id u128so259124oie.2 for ; Wed, 20 Feb 2019 19:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=L8NgEyo8maUCMARY84zWd8Oc+XKh5TVPs+jUSISCreY=; b=T6e5XFGb3v13+ky5E2VTlD3H3lUSXilvfMEk80kl+EsIiPZqUe2czFq+Ua4tFdLif0 F9ioCv6iIDBYjT/79lxtJBEj84btHbxBw5KltHtbHUjAn/Z8oselbpNzSpLh7xYk61T1 wNM80I4w1DN5b9KyCylJzNkwirph8zUBjmMuGt+a3UR1NSJIIUDlWYTG6dySEk1Os9UA 4adVJjVoXELnOEYEicE5G9jb8EYy9TTAOGb4jw6IgW//9Njow97S+AGtTfJLOUAqSuYW TD3Sfl675BknNnykc1Spdzv/kWMBptJS72tHZG6AlUbzn+NpH4f/b9GsUELRj+B19FJr rQSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=L8NgEyo8maUCMARY84zWd8Oc+XKh5TVPs+jUSISCreY=; b=b2D4X+7jrWrjulH6HfCfJLqw6l/hodh8oAxGlx43FMNTWoaF4FocV3OANmpwBdOkqy 8gfKuHz4G3+dNp2WvU2vPrfCGbzdyhL57MbVB02IGQa6//RltmVccE2ma+YK9iPOn738 GPtE6gdEdeMseAQKamOQe5GESZg1FgR/lJJ0gvXv8uA6sboZeyvQzwxlYJ+em99dYV8C oeRKA06Aw81tX3XHrS7gz3K3IgeTMZAEbyQfgagliLdCNQvnDaa9lq/+XFvWccc56sfj M5qmUVML9VnDLrc20EWyIXWYD8q0BxbfXdPNGPpu5uF+Ku1yUR9R0gbLjHFi0LDF6bsK HVBg== X-Gm-Message-State: AHQUAuZtVxAj3YurDjN3QlddMVGQbE+Iw98Dpm2VMxW2jlxIZ6cunGyT YFQCwNk7YYXaoKJX3DINV7J83avH59bJa8Muymo= X-Google-Smtp-Source: AHgI3IYcwuKOttWvfUFtpixpdPw0SHeIk2hPAiP4wWPlxvSD0CEZYXdQpmvDw1ZJ4LOcQJWNa7XbELobr6oziC8ylV4= X-Received: by 2002:aca:88b:: with SMTP id 133mr2835243oii.95.1550718073630; Wed, 20 Feb 2019 19:01:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Tue, 01 Jan 2019 00:00:00 -0000 Message-ID: Subject: Re: RFC: Update x86 psABIs to support IBT To: Rui Ueyama Cc: IA32 System V Application Binary Interface , "x86-64-abi@googlegroups.com" , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00006.txt.bz2 On Wed, Feb 20, 2019 at 4:30 PM Rui Ueyama wrote: > > Hi H.J.Lu, > > I'm replying because I was wondering why the 2-PLT scheme was chosen to s= upport Intel CET. > > On Tue, Feb 19, 2019 at 8:36 PM H.J. Lu wrote: >> >> On Tue, Jun 20, 2017 at 9:38 AM H.J. Lu wrote: >> > >> > On Tue, Jun 13, 2017 at 12:11 PM, H.J. Lu wrote: >> > > To support ENDBR in Intel Control-flow Enforcement Technology (CET) >> > > instructions: >> > > >> > > https://software.intel.com/sites/default/files/managed/4d/2a/control= -flow-enforcement-technology-preview.pdf >> > > >> > > following changes to i386 psABI are required. >> > >> > Here is the updated extension for both i386 and x86-64 psABI to >> > support IBT. I will post a binutls patch later. >> > >> > Any comments? >> > >> > -- >> > H.J. >> > --- >> > To support indirect branch tracking (IBT) in Intel Control-flow Enforc= ement >> > Technology (CET) instructions: >> > >> > https://software.intel.com/sites/default/files/managed/4d/2a/control-f= low-enforcement-technology-preview.pdf >> > >> > following changes to x86 psABI are required. >> > >> > To program properties, add >> > >> > #define GNU_PROPERTY_X86_FEATURE_1_AND 0xc0000002 >> > >> > #define GNU_PROPERTY_X86_FEATURE_1_IBT (1U << 0) >> > >> > to indicate that all executable sections are compatible with IBT when >> > ENDBR instruction is inserted at: >> > >> > a. All function entries whose addresses may be taken. >> > b. All branch targets whose addresses have been taken. >> > >> > GNU_PROPERTY_X86_FEATURE_1_IBT is set on output only if it is set on >> > all relocatable inputs, which means that the C library must be compiled >> > with IBT-enabled compiler. >> > >> > The followings changes are made to the Procedure Linkage Table (PLT) to >> > enable IBT: >> > >> > 1. For 64-bit x86-64, PLT is changed to: >> > >> > PLT0: push GOT[1] >> > bnd jmp *GOT[2] >> > nop >> > ... >> > PLTn: endbr64 >> > push namen_reloc_index >> > bnd jmp PLT0 >> > >> > together with the second PLT section: >> > >> > PLTn: endbr64 >> > bnd jmp *GOT[namen_index] >> > nop >> > >> > BND prefix is also added so that IBT-enabled PLT is compatible with MP= X. >> > >> > 2. For 32-bit x86-64 (x32) and i386, PLT is changed to >> > >> > PLT0: push GOT[1] >> > jmp *GOT[2] >> > nop >> > ... >> > PLTn: endbr64 # endbr32 for i386. >> > push namen_reloc_index >> > jmp PLT0 >> > >> > together with the second PLT section: >> > >> > PLTn: endbr64 # endbr32 for i386. >> > jmp *GOT[namen_index] >> > nop >> > >> > BND prefix isn't used since MPX isn't supported on x32 and BND registe= rs >> > aren't used in parameter passing on i386. >> > >> >> There are 2 reasons for this 2-PLT scheme: >> >> 1. Provide compatibility with other tools that have an hardcoded limit = of 16 >> bytes for an x86 PLT entry. > > > I don't think that the 2-PLT scheme actually provides compatibility with = existing tools. The new PLT uses different code instructions, and the usage= of the .plt section has changed as well. IIUC, foo@PLT is now resolved to = its entry in the second PLT instead of the first regular PLT. > > I know that some existing tools even crash if we change the PLT entry siz= e, so keeping the PLT entry size would at least keep them from crashing. Bu= t I'd think compatibility means more than that. > We are doing the best we can. >> 2. Improve code cache locality: since most of the instructions in .plt = would be >> executed only the first time a symbol is resolved they would waste space= in >> the cache and, by having a .plt.sec, only instructions that are often ex= ecuted >> would be cached. > > > This is personally much more convincing answer than keeping the compatibi= lity. The PLT section could be hot, and separating hot code from relatively= cold code could have an performance impact. But do you know how much is th= e impact? I wonder if there's a measurable difference if you simply extend = the PLT size to 32-byte. > We don't have such data. FWIW, we introduced 2 PLT scheme for MPX. This isn't a new thing in x86-64 psABI. --=20 H.J.