On Fri, Aug 9, 2013 at 12:08 AM, Jan Beulich <jbeul...@suse.com> wrote: >>>> On 08.08.13 at 18:01, "H.J. Lu" <hjl.to...@gmail.com> wrote: >> 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. > > 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.