Re: RFC: Update x86 psABIs to support IBT

["H.J. Lu" <hjl.tools@gmail.com>]

On Wed, Feb 20, 2019 at 4:30 PM Rui Ueyama <ruiu@google.com> wrote:
>
> Hi H.J.Lu,
>
> I'm replying because I was wondering why the 2-PLT scheme was chosen to support Intel CET.
>
> On Tue, Feb 19, 2019 at 8:36 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> 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.
>
>
> 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 size, so keeping the PLT entry size would at least keep them from crashing. But 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 executed
>> would be cached.
>
>
> This is personally much more convincing answer than keeping the compatibility. 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 the 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.


-- 
H.J.