>>> On 09.08.13 at 19:03, "H.J. Lu" <hjl.to...@gmail.com> wrote: > 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.
Only if those registers are used for their primary purpose. The documentation specifically says that this isn't a requirement. But anyway, I see we're once again not going to get anywhere with this... Jan