[gABI] RFC: add linker option support to ELF

[Saleem Abdulrasool]

Hi,

I would like to propose to add an extension to ELF to support embedded linker directives.  There is prior art to this in the form of COFF with its .drectve section, and on MachO with LC_LINKER_OPTIONS.  Such a mechanism could simplify the use of static libraries when they have external dependencies by implicitly providing linker options to add the required linkage.

Comments welcome.

Saleem

--- 

Embedded Linker Options

There are often external dependencies in static archives as well as generated code.  Users must explicitly add additional options to the driver when linking to ensure that the required libraries are linked.  Having this functionality would also allow the compiler to embed library dependency information into the object files when it knows that a library dependency has been introduced (e.g. via modules).

Linker Support

To the "Special Sections" section, adding the following:

          Name                    Type          Attributes

.note.linker-options    SHT_NOTE         0x0

The contents of this notes section could be interpreted as a structure with the following type:

#define CURRENT_LINKER_OPTIONS_VERSION 1

struct linker_options {

    uint32_t version;

    const char string[];

    uint32_t reserved;

};

The structure is versioned to permit future enhancements, with a 32-bit reserved field.  The expectation would be that the reserved field would currently be set to 0.

Because this is embedded as a notes section in the ELF object file, if the linker does not support this extension, the object file continues to function as expected, though the user must provide the linker flags manually.  Thus, backwards compatibility is preserved.

The contents of the string "string" should be interpreted as additional options as if passed on the command line.

Security Consideration

Because options could be injected which could introduce a security vulnerability, linkers should be prepared to filter the supplementary options.  As an example, a malicious user may interject a `-no-pie` option via the linker options, disabling ASLR.  In order to mitigate this type of attack, it would be advisable to have a strict and lenient modes for the interpretation of the linker options.  Explicitly stated options would be given precedence, and options extending beyond linkage would be filtered in the strict mode.  During strict mode execution, the linker may optionally warn when an option is ignored.  The linker could permit lenient mode via a `-z lenient-link-options` flag to permit greater flexibility.  The filtering could be effectively implemented by tracking option provenance for the `-z strict-link-options` mode.

[H.J. Lu]

I have a different proposal to embed more information:

https://sourceware.org/ml/gnu-gabi/2016-q1/msg00038.html

--
H.J.

[Saleem Abdulrasool]

I can see that that is has some similar ideas.  However, it seems the proposal that you pointed out went the route of LSB.  I think that the two can stand side-by-side.  This would give us the general mechanism for the flags (which that also pointed out is needed for various operations).  The remainder of the information that the alternate proposal would embed could continue to live as a Linux extension.

 

--
H.J.

--
You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
To post to this group, send email to gener...@googlegroups.com.
Visit this group at https://groups.google.com/group/generic-abi.
For more options, visit https://groups.google.com/d/optout.

--

Saleem Abdulrasool
compnerd (at) compnerd (dot) org

[Suprateeka R Hegde]

Hi

There is nothing to add here to gABI. This proposal comes under an
implementation to instantiate what gABI already provides through
http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section.

Many such instantiations have existed as part of vendor specific ELF as
required by gABI. For instance, On HP-UX we record these things for
various purposes. We also have a tool called footprints(1) that depend
on these ELF sections. In that way, there have been many .note.*
sections historically and has solved many technical requirements.

The proposal made by H.J., looks complete enough to me in this regard.
In fact it is a super-set with more specs and efficiency. You may want
to read earlier discussion on this on the gABI mailing list.

(As a side note, it is always good to follow existing ELF naming
conventions for new structs being added)

--
Supra

> <mailto:generic-abi%2Bunsu...@googlegroups.com>.

> To post to this group, send email to gener...@googlegroups.com

> <mailto:gener...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/generic-abi.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>

> --
> You received this message because you are subscribed to the Google
> Groups "Generic System V Application Binary Interface" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to generic-abi...@googlegroups.com

> <mailto:generic-abi...@googlegroups.com>.

> To post to this group, send email to gener...@googlegroups.com

> <mailto:gener...@googlegroups.com>.