This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jan Beulich <JBeulich at suse 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, 9 Aug 2013 10:03:48 -0700
- 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> <5204B18602000078000EA907 at nat28 dot tlf dot novell dot com>
On Fri, Aug 9, 2013 at 12:08 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 08.08.13 at 18:01, "H.J. Lu" <hjl.tools@gmail.com> 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" <hjl.tools@gmail.com> wrote:
>>>> We use the .gnu_attribute directive to record an object attribute:
>>>>
>>>> enum
>>>> {
>>>> Tag_GNU_X86_EXTERN_BRANCH = 4,
>>>> };
>>>>
>>>> for the types of external branch instructions in relocatable files.
>>>>
>>>> enum
>>>> {
>>>> /* 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
>>>> .L0:
>>>> .asciz "x86 feature"
>>>> .L1:
>>>> .align 4
>>>> .L2:
>>>> .long FeatureFlag (Feature flag)
>>>> .L3:
>>>>
>>>> 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
>>>> Val_GNU_X86_EXTERN_BRANCH_BND.
>>>>
>>>> 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.
The MPX enabled app will still run correctly. ld.so will clear the bound
registers (that makes unlimited bound) for the first call with lazy binding.
>> 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.
>
I agree. That is why a note section is better.
--
H.J.