This is the mail archive of the
mailing list for the binutils project.
Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: "GCC Development" <gcc at gcc dot gnu dot org>, "Ian Lance Taylor" <iant at google dot com>, "Roland McGrath" <roland at hack dot frob dot com>, "David L Kreitzer" <david dot l dot kreitzer at intel dot com>, "Milind Girkar" <milind dot girkar at intel dot com>, "Binutils" <binutils at sourceware dot org>, "GNU C Library" <libc-alpha at sourceware dot org>
- Date: Fri, 09 Aug 2013 08:08:22 +0100
- Subject: Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
- References: <CAMe9rOp=1v38F_aV-pbv50YOGSEr_ju+byZP1L_G_h4bm5Ad3w at mail dot gmail dot com> <20130724233621 dot DA6942C08C at topped-with-meat dot com> <CAKOQZ8zn2KHayUrdKPOB0ys0Y794c5-t8Zw6hefeB5NGXTXKRw at mail dot gmail dot com> <CAMe9rOrbU--x0vZWB0mdjwJo6U5CsOJ6h_7tnwaeya8VHcujGw at mail dot gmail dot com> <CAMe9rOq6jBhmJeuYJBbf3yBd6xB8_8YZC=hJBLkKr702v0iJag at mail dot gmail dot com> <5203628F02000078000EA1EE at nat28 dot tlf dot novell dot com> <CAMe9rOqaueuycEF-MTJx0Z49aM15MqV-iosfh9YMOZcQVoPfQA at mail dot gmail dot com>
>>> On 08.08.13 at 18:01, "H.J. Lu" <firstname.lastname@example.org> wrote:
> On Thu, Aug 8, 2013 at 12:19 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 08.08.13 at 02:33, "H.J. Lu" <email@example.com> wrote:
>>> We use the .gnu_attribute directive to record an object attribute:
>>> Tag_GNU_X86_EXTERN_BRANCH = 4,
>>> for the types of external branch instructions in relocatable files.
>>> /* All external branch instructions are legacy. */
>>> Val_GNU_X86_EXTERN_BRANCH_LEGACY = 0,
>>> /* There is at lease one external branch instruction with BND prefix. */
>>> Val_GNU_X86_EXTERN_BRANCH_BND = 1,
>>> An x86 feature note section, .note.x86-feature, is used to indicate
>>> features in executables and shared library. The contents of this note
>>> section are:
>>> .section .note.x86-feature
>>> .align 4
>>> .long .L1 - .L0
>>> .long .L3 - .L2
>>> .long 1
>>> .asciz "x86 feature"
>>> .align 4
>>> .long FeatureFlag (Feature flag)
>>> The current valid bits in FeatureFlag are
>>> #define NT_X86_FEATURE_PLT_BND (0x1 << 0)
>>> It should be set if PLT entry has BND prefix to preserve bound registers.
>>> The remaining bits in FeatureFlag are reserved.
>>> When merging Tag_GNU_X86_EXTERN_BRANCH, if any input relocatable
>>> file has Tag_GNU_X86_EXTERN_BRANCH set to Val_GNU_X86_EXTERN_BRANCH_BND,
>>> the resulting Tag_GNU_X86_EXTERN_BRANCH value should be
>>> When generating executable or shared library, if PLT is needed and
>>> Tag_GNU_X86_EXTERN_BRANCH value is Val_GNU_X86_EXTERN_BRANCH_BND,
>>> the 32-byte PLT entry should be used and the feature note section should
>>> be generated with the NT_X86_FEATURE_PLT_BND bit set to 1 and the feature
>>> note section should be included in PT_NOTE segment. The benefit of the
>>> note section is it is backward compatible with existing run-time and tools.
>> While I can see the purpose of the attribute section, I don't see
>> what the note section is for: You don't mention at all what it's
>> consumed for, and I also can't see how it validly would be for
>> anything. That's because iirc note section contents, if not
>> understood by the consumer, is required to not have any effect
>> on the correctness of the program. Hence if loaded on a system
>> that MPX capable, has an MPX aware kernel, but no MPX aware
>> user space (apart from this one executable or shared library, or
>> a set thereof), it ought to still work correctly. Which - afaict - it
>> won't if the dynamic loader itself isn't MPX aware.
> The note section isn't required for correctness. But it can be used
> by ld.so to select an alternate MPX aware shared library in a different
> directory, instead of a legacy one.
Okay, that clarifies your intentions with the note section. However,
then you need something else to make sure an MPX aware app can't
load on an MPX enabled kernel without MPX-enabled ld.so.
> There is another way to encode this information in the first entry
> of PLT:
> 0: ff 35 00 00 00 00 pushq GOT+8(%rip)
> 6: f2 ff 25 00 00 00 00 bnd jmpq *GOT+16(%rip)
> d: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
> 12: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
> 19: 0f 1f 80 00 00 00 01 nopl 0x1000000(%rax)
> We can encode PLT property in 10 (4 + 4 + 2) bytes of
> displacements of 3 nops. In this example, the first bit
> of the last byte of PLT0 is 1.
While a nice idea, I think that's worse, because much harder to
determine from simply dumping information for a given binary.