public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: IA32 System V Application Binary Interface
	<ia32-abi@googlegroups.com>,
		"x86-64-abi@googlegroups.com" <x86-64-abi@googlegroups.com>,
	gnu-gabi@sourceware.org
Subject: Re: RFC: Update x86 psABIs to support IBT
Date: Tue, 01 Jan 2019 00:00:00 -0000	[thread overview]
Message-ID: <CAMe9rOpHcpenFJ7KuJ50AxCYC+y-OMRRg_1+X5g_KH=Y2-srcA@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOri65a9C3h+_hYLuY4XaZ2OGL+gauw7HTM9R9LoufJ58A@mail.gmail.com>

On Tue, Jun 20, 2017 at 9:38 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jun 13, 2017 at 12:11 PM, H.J. Lu <hjl.tools@gmail.com> 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 Enforcement
> Technology (CET) instructions:
>
> https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-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 MPX.
>
> 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 registers
> 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.
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 executed
would be cached.

-- 
H.J.

  reply	other threads:[~2019-02-20  4:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-01  0:00 H.J. Lu
2019-01-01  0:00 ` H.J. Lu [this message]
     [not found]   ` <CAJENXgtX3Foh2gAHt4yxOg92rSSnf9-WjBNn3fn3M3tgbDKpEw@mail.gmail.com>
2019-01-01  0:00     ` H.J. Lu
     [not found]       ` <CAJENXgvnZZHxb=2x4xwJPf8mtcxkaY+0TLLaawRoEA-gP=Topw@mail.gmail.com>
2019-01-01  0:00         ` H.J. Lu
     [not found]           ` <CAJENXgtB0eT=tqY7pKyaJDihcE2c9t+CW5s0_sU2hFNC6CN8Xw@mail.gmail.com>
2019-01-01  0:00             ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMe9rOpHcpenFJ7KuJ50AxCYC+y-OMRRg_1+X5g_KH=Y2-srcA@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=gnu-gabi@sourceware.org \
    --cc=ia32-abi@googlegroups.com \
    --cc=x86-64-abi@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).