Re: [x86-64 psABI] RFC: Extend x86-64 PLT entry to support MPX

[Ilya Enkovich <enkovich dot gnu at gmail dot com>]

Hi all,

I'd like to restart discussion on this topic. I see two viable options
in this thread for PLT entry for MPX.

The first one is to use new relocation for calls requiring extended
PLT. Linker may decide then which PLT entries should be extended and
use 16 byte entries when possible. The only question here is how
dynamic linker may detect MPX binary and try to search for MPX shared
libraries. Does it have access to PLT section to check it? Isn't still
better to just use note section?

The second one is a note section. It does not have as good granularity
as new relocation but in the most cases all calls in MPX object file
would require extended PLT. Therefore linker create extended PLT entry
if it used by function from object files marked with the MPX note
section. The only drawback here is that old linker will just silently
ignore this note section and user have to check linker version.

Due to mentioned drawback of the second approach I would vote for the
new relocation but still with note section for dynamic liker.

Thanks,
Ilya



2013/8/19 H.J. Lu <hjl.tools@gmail.com>:
> On Wed, Aug 14, 2013 at 8:49 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Tue, Jul 23, 2013 at 12:49:06PM -0700, H.J. Lu wrote:
>>> There are 2 psABI considerations:
>>>
>>>  1. Should PLT entries in all binaries, with and without MPX, be changed
>>>     to 32-byte or just the necessary ones?
>>
>> Ugh, please don't.
>>
>>>  2. Only branch to PLT entry with BND prefix needs 32-byte PLT entry. If
>>>     we use 32-byte PLT entry only when needed, it can be decided by:
>>>     a. A new MPX PLT relocation:
>>>        i. No new run-time relocation since MPX PLT relocation is
>>>       resolved to branch to PLT entry at link-time.
>>>        ii. Pro: No new section.
>>>        iii. Con:
>>>         Need a new relocation.
>>>         Can't mark executable nor shared library.
>>
>> I think I prefer new relocation, @mpxplt or similar.  The linker could then
>> use the 32-byte PLT slot for both @plt and @mpxplt relocs if there is at
>> least one @mpxplt reloc for the symbol, otherwise it would use 16-byte PLT
>> slot.  And you can certainly mark executables or PIEs or shared libraries
>> this way, the linker could do that if it creates any 32-byte PLT slot.
>
> We don't have to add @mpxplt since we have "bnd" prefix.  We also
> need to handle "bnd call foo" in executable.  We can add new BND
> version relocation for R_X86_64_PC32 and R_X86_64_PLT32, instead
> of using the GNU attribute section.  Which approach is preferred?
>
> --
> H.J.