On Thu, Aug 8, 2013 at 12:19 AM, Jan Beulich <jbeul...@suse.com> wrote:
>>>> On 08.08.13 at 02:33, "H.J. Lu" <hjl.to...@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.
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.
--
H.J.
