* RFH: Annotating ELF binaries @ 2016-11-04 15:02 Nick Clifton 2016-11-04 15:09 ` Joel Sherrill ` (3 more replies) 0 siblings, 4 replies; 25+ messages in thread From: Nick Clifton @ 2016-11-04 15:02 UTC (permalink / raw) To: libc-help, binutils, devel Hello Everyone, We (the tools team at Red Hat) are working on a project to add annotations to ELF binaries, so that we can answer various questions about them. We have set up a wiki page about the project here: https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects We would very much like this to be something more than just an internal project, and so we are reaching out to you for your opinions, suggestions and advice. If you are interested in being able answer questions such as 'how was this function compiled ?' or 'is this library compatible with this application ?' then please take a minute to have a look at the proposal. Thanks very much. Cheers Nick Clifton ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-04 15:02 RFH: Annotating ELF binaries Nick Clifton @ 2016-11-04 15:09 ` Joel Sherrill 2016-11-04 15:13 ` Tristan Gingold ` (2 subsequent siblings) 3 siblings, 0 replies; 25+ messages in thread From: Joel Sherrill @ 2016-11-04 15:09 UTC (permalink / raw) To: Nick Clifton, libc-help, binutils, devel, Chris Johns Hi Great idea! I recall Ada toolsets annotating objects long ago so there was a traceable record of how they were compiled, what source file version, etc. That all required closed source tools though. Chris Johns from RTEMS has been investigating add ELF annotations to RTEMS and Newlib to indicate which standards a particular method adheres to. We think this would assist in evaluating the conformance of a program to various standards. It hasn't reached the point of making a public proposal but the underlying idea of leveraging ELF annotation is similar. I have cc'ed him so he is aware of this. Perhaps there is some synergy. --joel On 11/4/2016 10:02 AM, Nick Clifton wrote: > Hello Everyone, > > We (the tools team at Red Hat) are working on a project to add > annotations to ELF binaries, so that we can answer various questions > about them. We have set up a wiki page about the project here: > > https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects > > We would very much like this to be something more than just an > internal project, and so we are reaching out to you for your opinions, > suggestions and advice. If you are interested in being able answer > questions such as 'how was this function compiled ?' or 'is this > library compatible with this application ?' then please take a minute > to have a look at the proposal. > > Thanks very much. > > Cheers > Nick Clifton > -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherrill@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35806 Support Available (256) 722-9985 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-04 15:02 RFH: Annotating ELF binaries Nick Clifton 2016-11-04 15:09 ` Joel Sherrill @ 2016-11-04 15:13 ` Tristan Gingold 2016-11-04 15:23 ` Nick Clifton 2016-11-04 18:34 ` Richard W.M. Jones 2016-11-04 23:58 ` Ian Lance Taylor 3 siblings, 1 reply; 25+ messages in thread From: Tristan Gingold @ 2016-11-04 15:13 UTC (permalink / raw) To: Nick Clifton; +Cc: libc-help, binutils, devel > On 04 Nov 2016, at 16:02, Nick Clifton <nickc@redhat.com> wrote: > > Hello Everyone, > > We (the tools team at Red Hat) are working on a project to add > annotations to ELF binaries, so that we can answer various questions > about them. We have set up a wiki page about the project here: > > https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects > > We would very much like this to be something more than just an > internal project, and so we are reaching out to you for your opinions, > suggestions and advice. If you are interested in being able answer > questions such as 'how was this function compiled ?' or 'is this > library compatible with this application ?' then please take a minute > to have a look at the proposal. This will generalise attributes used by some architectures (ppc, arm), won't it ? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-04 15:13 ` Tristan Gingold @ 2016-11-04 15:23 ` Nick Clifton 2016-11-04 15:55 ` Tristan Gingold 2017-01-13 20:26 ` H.J. Lu 0 siblings, 2 replies; 25+ messages in thread From: Nick Clifton @ 2016-11-04 15:23 UTC (permalink / raw) To: Tristan Gingold; +Cc: libc-help, binutils, devel Hi Tristan, >> https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects > This will generalise attributes used by some architectures (ppc, arm), won't it ? Yes. Or at least it would if implemented as currently proposed. Maybe a better solution would be to only record attributes where they are not already covered by some target specific solution. Personally I would prefer a nice, generalised solution, but the current target specific attributes are mandated by the particular ABIs and so presumably are not going to go away. Cheers Nick ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-04 15:23 ` Nick Clifton @ 2016-11-04 15:55 ` Tristan Gingold 2017-01-13 20:26 ` H.J. Lu 1 sibling, 0 replies; 25+ messages in thread From: Tristan Gingold @ 2016-11-04 15:55 UTC (permalink / raw) To: Nick Clifton; +Cc: libc-help, binutils, devel > On 04 Nov 2016, at 16:22, Nick Clifton <nickc@redhat.com> wrote: > > Hi Tristan, > >>> https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects > >> This will generalise attributes used by some architectures (ppc, arm), won't it ? > > Yes. Or at least it would if implemented as currently proposed. Maybe a better > solution would be to only record attributes where they are not already covered by > some target specific solution. > > Personally I would prefer a nice, generalised solution, but the current target > specific attributes are mandated by the particular ABIs and so presumably are not > going to go away. It would be nice to have self-describing properties: a property is compatible only with the same value or with values less or equal, or (even better) within a range. So that a user can add properties without changing tools. That would work only for some properties however. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-04 15:23 ` Nick Clifton 2016-11-04 15:55 ` Tristan Gingold @ 2017-01-13 20:26 ` H.J. Lu 2017-01-16 14:38 ` Nick Clifton 1 sibling, 1 reply; 25+ messages in thread From: H.J. Lu @ 2017-01-13 20:26 UTC (permalink / raw) To: Nick Clifton, Kirill A. Shutemov Cc: Tristan Gingold, libc-help, Binutils, devel On Fri, Nov 4, 2016 at 8:22 AM, Nick Clifton <nickc@redhat.com> wrote: > Hi Tristan, > >>> https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects > >> This will generalise attributes used by some architectures (ppc, arm), won't it ? > > Yes. Or at least it would if implemented as currently proposed. Maybe a better > solution would be to only record attributes where they are not already covered by > some target specific solution. > > Personally I would prefer a nice, generalised solution, but the current target > specific attributes are mandated by the particular ABIs and so presumably are not > going to go away. > > Cheers > Nick We have 2 different proposals for program properties. Mine: https://sourceware.org/ml/gnu-gabi/2016-q4/msg00025.html has a much smaller scope. New features on upcoming Intel platforms, like 5-level paging, need this extension for loader decision at run-time. How should we move forward with program property extensions? -- H.J. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2017-01-13 20:26 ` H.J. Lu @ 2017-01-16 14:38 ` Nick Clifton 2017-01-16 17:48 ` Carlos O'Donell 0 siblings, 1 reply; 25+ messages in thread From: Nick Clifton @ 2017-01-16 14:38 UTC (permalink / raw) To: H.J. Lu, Kirill A. Shutemov; +Cc: Tristan Gingold, libc-help, Binutils, devel Hi H.J. > We have 2 different proposals for program properties. Mine: > > https://sourceware.org/ml/gnu-gabi/2016-q4/msg00025.html > > has a much smaller scope. New features on upcoming Intel platforms, > like 5-level paging, need this extension for loader decision at run-time. > How should we move forward with program property extensions? I would like to combine the two approaches. Ie use your notes for properties that need to be examined at run-time (specifically the loader, although I imagine that the application itself might be interested in reading its own notes). Plus use the note scheme I am proposing for static analysis tools. I am currently using a gcc plugin to generate the notes, and I think that this should be extendable to generate your notes as well. (Using a plugin is advantageous in that it is not tied to the latest gcc release. It can be built to run with older gcc's, and it can be updated independently of the gcc release cycle). What do you think ? Cheers Nick ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2017-01-16 14:38 ` Nick Clifton @ 2017-01-16 17:48 ` Carlos O'Donell 2017-01-17 18:55 ` H.J. Lu 2017-01-18 17:02 ` Nick Clifton 0 siblings, 2 replies; 25+ messages in thread From: Carlos O'Donell @ 2017-01-16 17:48 UTC (permalink / raw) To: Nick Clifton, H.J. Lu, Kirill A. Shutemov Cc: Tristan Gingold, libc-help, Binutils, devel On 01/16/2017 09:37 AM, Nick Clifton wrote: > Hi H.J. > >> We have 2 different proposals for program properties. Mine: >> >> https://sourceware.org/ml/gnu-gabi/2016-q4/msg00025.html >> >> has a much smaller scope. New features on upcoming Intel platforms, >> like 5-level paging, need this extension for loader decision at run-time. >> How should we move forward with program property extensions? > > I would like to combine the two approaches. Ie use your notes for > properties that need to be examined at run-time (specifically the > loader, although I imagine that the application itself might be > interested in reading its own notes). Plus use the note scheme I > am proposing for static analysis tools. > > I am currently using a gcc plugin to generate the notes, and I think > that this should be extendable to generate your notes as well. (Using > a plugin is advantageous in that it is not tied to the latest gcc release. > It can be built to run with older gcc's, and it can be updated > independently of the gcc release cycle). > > What do you think ? I've added 2 questions to the Toolchain/Watermark wiki but will post them here for posterity: (1) What happened to SHT_GNU_ATTRIBUTES and how does it relate to what you are proposing? (2) What is being done to ensure the attributes are space and time efficient for dynamic link comparison in the dynamic linker? Speed of checking 10,000 DSOs (scalability) for ABI compatibility is going to be a very important requirement. Comments: (a) Ian requests clear separation between language and psABI notes. Notes are notes. The attribute system should be sufficiently flexible to handle both, and the "clear sepration" is just a documentation aspect, and still important, but just about writing down what the notes mean in clear detail. (b) Loadable notes and space/time efficiency vs. non-loadable notes and static analysis tools. Run-time checking of properties is radically different from offline checking of properties and we absolutely need two different designs to meet these needs. However, if we could weld the two together in a compatible way, that would be great. For example if the dynamic loader could map from a 'run-time property' to a 'link-time property' to increase the verbosity of the error in a failure scenario, then that might be beneficial. If we could translate 'link-time notes' into 'a collection of run-time properties' in a semi-automatic fashion given strict rules about the notes application, then that would also be awesome. (c) The case against SHT_GNU_ATTRIBUTES (Question 2). Not used. -- Then we should just use them for x86. IFUNC complication. -- Any new framework must be able to tolerate that a given interface may have a "range" of ABIs it works with, and those represent the set of ABIs it can change to. Attributes that don't allow sets of values are going to be problematic in the face of IFUNCs. No loadable segment. -- Correct. They were designed for link-time support only. Most attributes don't apply to dynamic loading. -- Correct. Space inefficient. Layout not optimal for loading. -- Correct. Time/Space inefficient. In summary SHT_GNU_ATTRIBUTES might not work for run-time properties, but what about link-time properties? Why not resuse this framework? -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2017-01-16 17:48 ` Carlos O'Donell @ 2017-01-17 18:55 ` H.J. Lu 2017-01-18 17:02 ` Nick Clifton 1 sibling, 0 replies; 25+ messages in thread From: H.J. Lu @ 2017-01-17 18:55 UTC (permalink / raw) To: Carlos O'Donell Cc: Nick Clifton, Kirill A. Shutemov, Tristan Gingold, libc-help, Binutils, devel On Mon, Jan 16, 2017 at 9:48 AM, Carlos O'Donell <carlos@redhat.com> wrote: > On 01/16/2017 09:37 AM, Nick Clifton wrote: >> Hi H.J. >> >>> We have 2 different proposals for program properties. Mine: >>> >>> https://sourceware.org/ml/gnu-gabi/2016-q4/msg00025.html >>> >>> has a much smaller scope. New features on upcoming Intel platforms, >>> like 5-level paging, need this extension for loader decision at run-time. >>> How should we move forward with program property extensions? >> >> I would like to combine the two approaches. Ie use your notes for >> properties that need to be examined at run-time (specifically the >> loader, although I imagine that the application itself might be >> interested in reading its own notes). Plus use the note scheme I >> am proposing for static analysis tools. >> >> I am currently using a gcc plugin to generate the notes, and I think >> that this should be extendable to generate your notes as well. (Using >> a plugin is advantageous in that it is not tied to the latest gcc release. >> It can be built to run with older gcc's, and it can be updated >> independently of the gcc release cycle). >> >> What do you think ? > > I've added 2 questions to the Toolchain/Watermark wiki but will post them > here for posterity: > > (1) What happened to SHT_GNU_ATTRIBUTES and how does it relate to what > you are proposing? > > (2) What is being done to ensure the attributes are space and time > efficient for dynamic link comparison in the dynamic linker? > Speed of checking 10,000 DSOs (scalability) for ABI compatibility is > going to be a very important requirement. > > Comments: > > (a) Ian requests clear separation between language and psABI notes. > > Notes are notes. The attribute system should be sufficiently flexible to > handle both, and the "clear sepration" is just a documentation aspect, > and still important, but just about writing down what the notes mean in > clear detail. > > (b) Loadable notes and space/time efficiency vs. non-loadable notes and > static analysis tools. > > Run-time checking of properties is radically different from offline > checking of properties and we absolutely need two different designs to > meet these needs. However, if we could weld the two together in a compatible > way, that would be great. For example if the dynamic loader could map from > a 'run-time property' to a 'link-time property' to increase the verbosity > of the error in a failure scenario, then that might be beneficial. If we > could translate 'link-time notes' into 'a collection of run-time properties' in > a semi-automatic fashion given strict rules about the notes application, > then that would also be awesome. > > (c) The case against SHT_GNU_ATTRIBUTES (Question 2). > > Not used. -- Then we should just use them for x86. > > IFUNC complication. -- Any new framework must be able to tolerate that > a given interface may have a "range" of ABIs it works with, and those > represent the set of ABIs it can change to. Attributes that don't allow > sets of values are going to be problematic in the face of IFUNCs. > > No loadable segment. -- Correct. They were designed for link-time support only. > > Most attributes don't apply to dynamic loading. -- Correct. Space inefficient. > > Layout not optimal for loading. -- Correct. Time/Space inefficient. > > In summary SHT_GNU_ATTRIBUTES might not work for run-time properties, but > what about link-time properties? Why not resuse this framework? > My property proposal is an extension of existing .note.ABI-tag and .note.gnu.build-id notes, which are loaded sections and don't require SHT_GNU_ATTRIBUTES. However, it only supports object scope property, not symbol scope property. It is sufficient for run-time loader, but inadequate for static tools. Should we evaluate 2 approaches as 2 orthogonal ones? Use loaded note to cover object scope properties and non-loaded note for symbol scope properties. -- H.J. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2017-01-16 17:48 ` Carlos O'Donell 2017-01-17 18:55 ` H.J. Lu @ 2017-01-18 17:02 ` Nick Clifton 2017-01-18 17:56 ` Joseph Myers 2017-01-19 20:22 ` Carlos O'Donell 1 sibling, 2 replies; 25+ messages in thread From: Nick Clifton @ 2017-01-18 17:02 UTC (permalink / raw) To: Carlos O'Donell, H.J. Lu, Kirill A. Shutemov Cc: Tristan Gingold, libc-help, Binutils, devel Hi Carlos, > I've added 2 questions to the Toolchain/Watermark wiki but will post them > here for posterity: Thanks - I'll try answering them here first, and if my answers make sense then I will update the wiki. > (1) What happened to SHT_GNU_ATTRIBUTES and how does it relate to what > you are proposing? Good question, and unfortunately I do not know the answer. The problem is, I have been unable to locate any documentation that describes SHT_GNU_ATTRIBUTES and how it is supposed to be used. I think that the two schemes are quite similar, although this new proposal is intended to be able to cope with attributes that only apply to part of an executable and not necessarily the executable as a whole. (Also, IMHO, my proposal has better documentation...) > (2) What is being done to ensure the attributes are space and time > efficient for dynamic link comparison in the dynamic linker? > Speed of checking 10,000 DSOs (scalability) for ABI compatibility is > going to be a very important requirement. I believe that H.J's design for the dynamic link notes does take efficiency into consideration, but I will leave that for him to comment on further. One thing that I have already done for the static notes is to implement a new option for objcopy called "--merge-notes" which eliminates redundancies. Theoretically this option could be extended to work with the dynamic notes too, helping to make them as space efficient as possible. Another possibility is that the linker could be extended so that when it creates a dynamic executable it also inserts a "master" dynamic linker note, which contains all of the information that the dynamic linker will need, without it having to search through all of the shared libraries used by the application. (This does assume that the shared libraries examined at static link time are the same ones that are loaded/used at dynamic link time). > (b) Loadable notes and space/time efficiency vs. non-loadable notes and > static analysis tools. > > Run-time checking of properties is radically different from offline > checking of properties and we absolutely need two different designs to > meet these needs. However, if we could weld the two together in a compatible > way, that would be great. For example if the dynamic loader could map from > a 'run-time property' to a 'link-time property' to increase the verbosity > of the error in a failure scenario, then that might be beneficial. I think that this might not be easy to do in a way that both imposes a low code-increase cost on the dynamic linker and a keep-the-dynamic-link-notes-small space requirement. There is no harm in investigating though. > If we > could translate 'link-time notes' into 'a collection of run-time properties' in > a semi-automatic fashion given strict rules about the notes application, > then that would also be awesome. Now this might well be feasible. I am thinking of another new option to objcopy here that examines the static notes and generates dynamic notes from them. This should be quite straightforward, provided that the static notes have captures the right information. Cheers Nick ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2017-01-18 17:02 ` Nick Clifton @ 2017-01-18 17:56 ` Joseph Myers 2017-01-19 20:22 ` Carlos O'Donell 1 sibling, 0 replies; 25+ messages in thread From: Joseph Myers @ 2017-01-18 17:56 UTC (permalink / raw) To: Nick Clifton Cc: Carlos O'Donell, H.J. Lu, Kirill A. Shutemov, Tristan Gingold, libc-help, Binutils, devel On Wed, 18 Jan 2017, Nick Clifton wrote: > Good question, and unfortunately I do not know the answer. The problem > is, I have been unable to locate any documentation that describes > SHT_GNU_ATTRIBUTES and how it is supposed to be used. See "Object Attributes" in as.texinfo. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2017-01-18 17:02 ` Nick Clifton 2017-01-18 17:56 ` Joseph Myers @ 2017-01-19 20:22 ` Carlos O'Donell 2017-01-20 16:55 ` H.J. Lu 1 sibling, 1 reply; 25+ messages in thread From: Carlos O'Donell @ 2017-01-19 20:22 UTC (permalink / raw) To: Nick Clifton, H.J. Lu, Kirill A. Shutemov, Joseph S. Myers Cc: Tristan Gingold, libc-help, Binutils, devel On 01/18/2017 12:02 PM, Nick Clifton wrote: > Hi Carlos, > >> I've added 2 questions to the Toolchain/Watermark wiki but will post them >> here for posterity: > > Thanks - I'll try answering them here first, and if my answers make sense > then I will update the wiki. > >> (1) What happened to SHT_GNU_ATTRIBUTES and how does it relate to what >> you are proposing? > > Good question, and unfortunately I do not know the answer. The problem > is, I have been unable to locate any documentation that describes > SHT_GNU_ATTRIBUTES and how it is supposed to be used. > > I think that the two schemes are quite similar, although this new proposal > is intended to be able to cope with attributes that only apply to part of > an executable and not necessarily the executable as a whole. (Also, IMHO, > my proposal has better documentation...) I'm including Joseph Myers in this discussion. It's very very well documented by ARM. The point of SHT_GNU_ATTRIBUTES is to mark a section as containing GNU-based Attributes for the object in question. Rather than have a generic SHT_NOTE. The GNU-based attributes can be applied to the file, section, or symbol (and extended further). Attributes can be anything you want them to be. Today most of the GNU-attributes are ABI related and the static linker uses them at link time to issue errors when objects of mixed incompatible ABIs are attempted to be used together. That is to say they are Tag_File-based attributes (see binutils source for this). The generic section which holds attributes is SHT_GNU_ATTRIBUTES, but machines can override this e.g. SHT_ARM_ATTRIBUTES for ARM-specific attributes. The ELF attributes section design was originally based on the need at the time from ARM for ARM EABI Attributes. See 4.3.6 Build Attributes: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf .gnu.attributes (section) * <format version>, currently 'A' (0x41) * <section length> (4 byte unsigned int in ELF endian order of all subsequent data) * "vendor name" ("GNU") for generic + NULL pointer. * <file-tag> <szie> (all things which are file scope) <attribute> * <section-tag> (all things which are section scope) <size> <section #> <attribute> * <symbol-tag> (all things which are symbol scope) <size> <symbol #> <attribute> The ARM documentation goes into a lot of detail about what attributes it supports. Given that we have a GNU-generic version of this... might we not extend things to a new Tag_Range and keep all the existing machinery we already have in binutils for processing all of these attributes? Again, the SHT_GNU_ATTRIBUTES section was never designed to be loaded by the dynamic linker, and it's the reason I recommend you look at the design and think about how we can avoid another attributes format that is incompatible with the one we already have in binutils. Harmonize the designs please :-) >> (2) What is being done to ensure the attributes are space and time >> efficient for dynamic link comparison in the dynamic linker? >> Speed of checking 10,000 DSOs (scalability) for ABI compatibility is >> going to be a very important requirement. > > I believe that H.J's design for the dynamic link notes does take efficiency > into consideration, but I will leave that for him to comment on further. It does, mostly be using bits, and AND/OR/EQ handling. I have yet to see exactly how it works. I might suggest we version the section like .gnu.attributes so we can increment the version if we have a flag day changing the layout. > One thing that I have already done for the static notes is to implement a > new option for objcopy called "--merge-notes" which eliminates redundancies. > Theoretically this option could be extended to work with the dynamic notes > too, helping to make them as space efficient as possible. OK. > Another possibility is that the linker could be extended so that when it > creates a dynamic executable it also inserts a "master" dynamic linker note, > which contains all of the information that the dynamic linker will need, > without it having to search through all of the shared libraries used by the > application. (This does assume that the shared libraries examined at static > link time are the same ones that are loaded/used at dynamic link time). We can't assume that unfortunately. >> (b) Loadable notes and space/time efficiency vs. non-loadable notes and >> static analysis tools. >> >> Run-time checking of properties is radically different from offline >> checking of properties and we absolutely need two different designs to >> meet these needs. However, if we could weld the two together in a compatible >> way, that would be great. For example if the dynamic loader could map from >> a 'run-time property' to a 'link-time property' to increase the verbosity >> of the error in a failure scenario, then that might be beneficial. > > I think that this might not be easy to do in a way that both imposes a low > code-increase cost on the dynamic linker and a keep-the-dynamic-link-notes-small > space requirement. There is no harm in investigating though. What I would like to see is parity between the notes the dynamic loader is using and the notes the static linker is using to generate warnings or outright link failures. >> If we >> could translate 'link-time notes' into 'a collection of run-time properties' in >> a semi-automatic fashion given strict rules about the notes application, >> then that would also be awesome. > > Now this might well be feasible. I am thinking of another new option to objcopy > here that examines the static notes and generates dynamic notes from them. This > should be quite straightforward, provided that the static notes have captures > the right information. Agreed. -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2017-01-19 20:22 ` Carlos O'Donell @ 2017-01-20 16:55 ` H.J. Lu 2017-01-20 19:02 ` Carlos O'Donell 0 siblings, 1 reply; 25+ messages in thread From: H.J. Lu @ 2017-01-20 16:55 UTC (permalink / raw) To: Carlos O'Donell Cc: Nick Clifton, Kirill A. Shutemov, Joseph S. Myers, Tristan Gingold, libc-help, Binutils, devel On Thu, Jan 19, 2017 at 12:22 PM, Carlos O'Donell <carlos@redhat.com> wrote: > On 01/18/2017 12:02 PM, Nick Clifton wrote: >> Hi Carlos, >> >>> I've added 2 questions to the Toolchain/Watermark wiki but will post them >>> here for posterity: >> >> Thanks - I'll try answering them here first, and if my answers make sense >> then I will update the wiki. >> >>> (1) What happened to SHT_GNU_ATTRIBUTES and how does it relate to what >>> you are proposing? >> >> Good question, and unfortunately I do not know the answer. The problem >> is, I have been unable to locate any documentation that describes >> SHT_GNU_ATTRIBUTES and how it is supposed to be used. >> >> I think that the two schemes are quite similar, although this new proposal >> is intended to be able to cope with attributes that only apply to part of >> an executable and not necessarily the executable as a whole. (Also, IMHO, >> my proposal has better documentation...) > > I'm including Joseph Myers in this discussion. > > It's very very well documented by ARM. > > The point of SHT_GNU_ATTRIBUTES is to mark a section as containing > GNU-based Attributes for the object in question. Rather than have a generic > SHT_NOTE. The GNU-based attributes can be applied to the file, section, or > symbol (and extended further). > > Attributes can be anything you want them to be. Today most of the GNU-attributes > are ABI related and the static linker uses them at link time to issue errors > when objects of mixed incompatible ABIs are attempted to be used together. > That is to say they are Tag_File-based attributes (see binutils source for this). > > The generic section which holds attributes is SHT_GNU_ATTRIBUTES, but machines > can override this e.g. SHT_ARM_ATTRIBUTES for ARM-specific attributes. > > The ELF attributes section design was originally based on the need at the time > from ARM for ARM EABI Attributes. > > See 4.3.6 Build Attributes: > > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf > > .gnu.attributes (section) > > * <format version>, currently 'A' (0x41) > * <section length> (4 byte unsigned int in ELF endian order of all subsequent data) > * "vendor name" ("GNU") for generic + NULL pointer. > * <file-tag> <szie> (all things which are file scope) <attribute> > * <section-tag> (all things which are section scope) <size> <section #> <attribute> > * <symbol-tag> (all things which are symbol scope) <size> <symbol #> <attribute> > > The ARM documentation goes into a lot of detail about what attributes it > supports. > > Given that we have a GNU-generic version of this... might we not extend things > to a new Tag_Range and keep all the existing machinery we already have in binutils > for processing all of these attributes? > > Again, the SHT_GNU_ATTRIBUTES section was never designed to be loaded by the > dynamic linker, and it's the reason I recommend you look at the design and think Run-time loader support is the motivation for my proposal. > about how we can avoid another attributes format that is incompatible with the > one we already have in binutils. > > Harmonize the designs please :-) > >>> (2) What is being done to ensure the attributes are space and time >>> efficient for dynamic link comparison in the dynamic linker? >>> Speed of checking 10,000 DSOs (scalability) for ABI compatibility is >>> going to be a very important requirement. >> >> I believe that H.J's design for the dynamic link notes does take efficiency >> into consideration, but I will leave that for him to comment on further. > > It does, mostly be using bits, and AND/OR/EQ handling. Any types of values can be embedded in the property notel. It is just another GNU note section, similar to [ 1] .note.gnu.build-id NOTE 00000174 000174 000024 00 A 0 0 4 [ 2] .note.ABI-tag NOTE 00000198 000198 000020 00 A 0 0 4 A property note section: Name Type Attributes .note.gnu.property SHT_NOTE SHF_ALLOC contains an array of properties. I expect the number of properties is limited, but extensible. > I have yet to see exactly how it works. Since the properties are in PT_NOTE segment, they are available to run-time loader, similar to NT_GNU_HWCAP. > > I might suggest we version the section like .gnu.attributes so we can > increment the version if we have a flag day changing the layout. > >> One thing that I have already done for the static notes is to implement a >> new option for objcopy called "--merge-notes" which eliminates redundancies. >> Theoretically this option could be extended to work with the dynamic notes >> too, helping to make them as space efficient as possible. > > OK. > >> Another possibility is that the linker could be extended so that when it >> creates a dynamic executable it also inserts a "master" dynamic linker note, >> which contains all of the information that the dynamic linker will need, >> without it having to search through all of the shared libraries used by the >> application. (This does assume that the shared libraries examined at static >> link time are the same ones that are loaded/used at dynamic link time). > > We can't assume that unfortunately. > >>> (b) Loadable notes and space/time efficiency vs. non-loadable notes and >>> static analysis tools. >>> >>> Run-time checking of properties is radically different from offline >>> checking of properties and we absolutely need two different designs to >>> meet these needs. However, if we could weld the two together in a compatible >>> way, that would be great. For example if the dynamic loader could map from >>> a 'run-time property' to a 'link-time property' to increase the verbosity >>> of the error in a failure scenario, then that might be beneficial. >> >> I think that this might not be easy to do in a way that both imposes a low >> code-increase cost on the dynamic linker and a keep-the-dynamic-link-notes-small >> space requirement. There is no harm in investigating though. > > What I would like to see is parity between the notes the dynamic loader > is using and the notes the static linker is using to generate warnings or outright > link failures. > >>> If we >>> could translate 'link-time notes' into 'a collection of run-time properties' in >>> a semi-automatic fashion given strict rules about the notes application, >>> then that would also be awesome. >> >> Now this might well be feasible. I am thinking of another new option to objcopy >> here that examines the static notes and generates dynamic notes from them. This >> should be quite straightforward, provided that the static notes have captures >> the right information. > > Agreed. > We can classify properties into 2 categories: used by run-time loader, not used by run-time loader. We put properties for run-time loader into .note.gnu.property section and the rest into GNU attribute section. -- H.J. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2017-01-20 16:55 ` H.J. Lu @ 2017-01-20 19:02 ` Carlos O'Donell 2017-01-20 19:06 ` H.J. Lu 0 siblings, 1 reply; 25+ messages in thread From: Carlos O'Donell @ 2017-01-20 19:02 UTC (permalink / raw) To: H.J. Lu Cc: Nick Clifton, Kirill A. Shutemov, Joseph S. Myers, Tristan Gingold, libc-help, Binutils, devel On 01/20/2017 11:55 AM, H.J. Lu wrote: > We can classify properties into 2 categories: used by run-time loader, > not used by run-time loader. We put properties for run-time loader into > .note.gnu.property section and the rest into GNU attribute section. Agreed. Can we use the same noun/adjective for our names? Is there any reason to use property over attribute? As a Friday bikeshed I suggest: .note.gnu.attributes - GNU Attributes optimized for the dynamic loader. -- New. Follows H.J's proposal. Bit-level, packed, and optimized for the dynamic loader processing. .gnu.attributes - GNU Attributes optimized for offline and static linker processing. -- Existing section. Discussions with Nick ongoing if we can continue to use existing infrastructure e.g. Tag_Range to extend this data. -- Cheers, Carlos. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2017-01-20 19:02 ` Carlos O'Donell @ 2017-01-20 19:06 ` H.J. Lu 2017-03-01 21:56 ` H.J. Lu 0 siblings, 1 reply; 25+ messages in thread From: H.J. Lu @ 2017-01-20 19:06 UTC (permalink / raw) To: Carlos O'Donell Cc: Nick Clifton, Kirill A. Shutemov, Joseph S. Myers, Tristan Gingold, libc-help, Binutils, devel On Fri, Jan 20, 2017 at 11:02 AM, Carlos O'Donell <carlos@redhat.com> wrote: > On 01/20/2017 11:55 AM, H.J. Lu wrote: >> We can classify properties into 2 categories: used by run-time loader, >> not used by run-time loader. We put properties for run-time loader into >> .note.gnu.property section and the rest into GNU attribute section. > > Agreed. > > Can we use the same noun/adjective for our names? > > Is there any reason to use property over attribute? Nothing other than avoiding confusion between note attribute vs non-note attribute. > As a Friday bikeshed I suggest: > > .note.gnu.attributes - GNU Attributes optimized for the dynamic loader. > -- New. Follows H.J's proposal. Bit-level, packed, and optimized for the > dynamic loader processing. > > .gnu.attributes - GNU Attributes optimized for offline and static linker > processing. > -- Existing section. Discussions with Nick ongoing if we can continue > to use existing infrastructure e.g. Tag_Range to extend this data. > Works for me. -- H.J. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2017-01-20 19:06 ` H.J. Lu @ 2017-03-01 21:56 ` H.J. Lu 2017-03-07 16:55 ` H.J. Lu 0 siblings, 1 reply; 25+ messages in thread From: H.J. Lu @ 2017-03-01 21:56 UTC (permalink / raw) To: Carlos O'Donell Cc: Nick Clifton, Kirill A. Shutemov, Joseph S. Myers, Tristan Gingold, libc-help, Binutils, devel On Fri, Jan 20, 2017 at 11:06 AM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Fri, Jan 20, 2017 at 11:02 AM, Carlos O'Donell <carlos@redhat.com> wrote: >> On 01/20/2017 11:55 AM, H.J. Lu wrote: >>> We can classify properties into 2 categories: used by run-time loader, >>> not used by run-time loader. We put properties for run-time loader into >>> .note.gnu.property section and the rest into GNU attribute section. >> >> Agreed. >> >> Can we use the same noun/adjective for our names? >> >> Is there any reason to use property over attribute? > > Nothing other than avoiding confusion between note attribute > vs non-note attribute. > >> As a Friday bikeshed I suggest: >> >> .note.gnu.attributes - GNU Attributes optimized for the dynamic loader. >> -- New. Follows H.J's proposal. Bit-level, packed, and optimized for the >> dynamic loader processing. >> >> .gnu.attributes - GNU Attributes optimized for offline and static linker >> processing. >> -- Existing section. Discussions with Nick ongoing if we can continue >> to use existing infrastructure e.g. Tag_Range to extend this data. >> > > Works for me. > > > -- > H.J. Here is the updated proposal with .note.gnu.attributes. -- H.J. --- Program Attribute Note There are cases where linker and run-time loader need more information about ELF objects beyond what the current gABI provides: 1. Minimum ISAs. Executables and shared objects, which are optimized specifically to run on a particular processor, will not run on processors which don't support the same set of ISAs. Since x86 only has EM_IAMCU, EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional information to tell if an executable or a shared object is compatible with available ISAs. 2. Stack size. Compilers may generate binaries which require larger stack size than normal. If run-time loader can query the stack size required by executable or shared object, it can increase stack size as needed. 3. Copy relocation and protected visibility are fundamentally incompatible. On one hand, copy relocation is the part of the psABI and is used to access global data defined in a shared object from the executable. It moves the definition of global data, which is defined in a share object, to the executable at run-time. On the other hand, protected visibility indicates that a symbol is defined locally in the shared object at run-time. Both can't be true at the same time. The current solution is to make protected symbol more or less like normal symbol, which prevents optimizing local access to protected symbol within the shared object. GNU attributes GNU binutils supports build attribute and run-time platform compatibility data in relocatable object files. Issues with GNU attributes: 1. Many architectures, including x86, don't support GNU attributes. 2. On x86, linking a relocatable object full of AVX instructions doesn't always make the resulting executables or shared libraries to require AVX to run since AVX functions may be called only via GNU_IFUNC at run-time. Linker can't set minimum ISAs just from ISAs used by input relocatable objects. 3. There is no program segment for GNU attributes in executables and shared objects. 4. Most of attributes aren't applicable to run-time loader. 5. The format of GNU attributes isn't optimal for run-time loader. A separate string table is used to store string attributes. gABI support for program attribute note To the "Special Sections" section, add: Name Type Attributes .note.gnu.attributes SHT_NOTE SHF_ALLOC A .note.gnu.attributes section contains at least one attribute note descriptor, starting with an attribute note descriptor header and followed by an array of attributes. The attribute note descriptor header has the following structure: typedef struct { Elf_Word namsz; Elf_Word descsz; Elf_Word type; unsigned char name[4]; } Elf_GNU_Notehdr; 1. namesz is 4. 2. descsz contains the size of the attribute array. 3. type specifies the attribute type: #define NT_GNU_ATTRIBUTE_TYPE_0 5 4. name is a null-terminated character string. It should be "GNU". Each array element represents one attribute with type, data size and data. In 64-bit objects, each element is an array of 8-byte words, whose first element is 4-byte type and data size, in the format of the target processor. In 32-bit objects, each element is an array of 4-byte words, whose first 2 elements are 4-byte type and data size, in the format of the target processor. An array element has the following structure: typedef struct { Elf_Word at_type; Elf_Word at_datasz; unsigned char at_data[AT_DATASZ]; unsigned char at_padding[AT_PADDING]; } Elf_Prop; where AT_DATASZ is the data size and AT_PADDING, if necessary, aligns array element to 8 or 4-byte alignment (depending on whether the file is a 64-bit or 32-bit object). The array elements are sorted by the attribute type. The interpretation of attribute array depends on at_type. Types of program attributes The last 3 bits of program attribute indicate how it should be processed. #define GNU_ATTRIBUTE_TYPE_SHIFT 3 #define GNU_ATTRIBUTE_TYPE_MASK (-(1 << GNU_ATTRIBUTE_TYPE_SHIFT)) #define GNU_ATTRIBUTE_EVAL_MASK ((1 << GNU_ATTRIBUTE_TYPE_SHIFT) - 1) #define GNU_ATTRIBUTE_EVAL_REQ 0 Linker should refuse to generate output if input attribute type is unknown. #define GNU_ATTRIBUTE_EVAL_EQ 1 Linker should refuse to generate output if input attribute data aren't identical. #define GNU_ATTRIBUTE_EVAL_OR 2 Output attribute data is logical OR of input attribute data. #define GNU_ATTRIBUTE_EVAL_AND 3 Output attribute data is logical AND of input attribute data. Linker should refuse to generate output for other evaluation values in input attribute type. #define GNU_ATTRIBUTE_LOPROC 0xb0000000 #define GNU_ATTRIBUTE_HIPROC 0xdfffffff #define GNU_ATTRIBUTE_LOUSER 0xe0000000 #define GNU_ATTRIBUTE_HIUSER 0xffffffff Proposed properties For NT_GNU_ATTRIBUTE_TYPE_0: #define GNU_ATTRIBUTE_STACK_SIZE \ ((1 << GNU_ATTRIBUTE_TYPE_SHIFT)|GNU_ATTRIBUTE_EVAL_REQ) Integer value for minimum stack size whose is 8 bytes in 64-bit object and 4 bytes in 32-bit object. #define GNU_ATTRIBUTE_NO_COPY_ON_PROTECTED \ ((2 << GNU_ATTRIBUTE_TYPE_SHIFT)|GNU_ATTRIBUTE_EVAL_REQ) Its at_datasz is 0. This indicates that there should be no copy relocations against protected data symbols. If a relocatable object contains this attribute, linker should treat protected data symbol as defined locally at run-time and copy this attribute to the output share object. Run-time loader should disallow copy relocations against protected data symbols defined in share objects with GNU_ATTRIBUTE_NO_COPY_ON_PROTECTED attribute. #define GNU_ATTRIBUTE_X86_ISA_1_USED \ ((0 << GNU_ATTRIBUTE_TYPE_SHIFT)|GNU_ATTRIBUTE_LOPROC|GNU_ATTRIBUTE_EVAL_OR) The x86 instruction sets indicated by the corresponding bits are used in program. But their support in the hardware is optional. #define GNU_ATTRIBUTE_X86_ISA_1_NEEDED \ ((1 << GNU_ATTRIBUTE_TYPE_SHIFT)|GNU_ATTRIBUTE_LOPROC|GNU_ATTRIBUTE_EVAL_OR) The x86 instruction sets indicated by the corresponding bits are used in program and they must be supported by the hardware. A bit set in GNU_ATTRIBUTE_X86_ISA_1_NEEDED must also be set in GNU_ATTRIBUTE_X86_ISA_1_USED. 4-byte integer value for the x86 instruction set support. #define GNU_ATTRIBUTE_X86_ISA_1_486 (1U << 0) #define GNU_ATTRIBUTE_X86_ISA_1_586 (1U << 1) #define GNU_ATTRIBUTE_X86_ISA_1_686 (1U << 2) #define GNU_ATTRIBUTE_X86_ISA_1_SSE (1U << 3) #define GNU_ATTRIBUTE_X86_ISA_1_SSE2 (1U << 4) #define GNU_ATTRIBUTE_X86_ISA_1_SSE3 (1U << 5) #define GNU_ATTRIBUTE_X86_ISA_1_SSSE3 (1U << 6) #define GNU_ATTRIBUTE_X86_ISA_1_SSE4_1 (1U << 7) #define GNU_ATTRIBUTE_X86_ISA_1_SSE4_2 (1U << 8) #define GNU_ATTRIBUTE_X86_ISA_1_AVX (1U << 9) #define GNU_ATTRIBUTE_X86_ISA_1_AVX2 (1U << 10) #define GNU_ATTRIBUTE_X86_ISA_1_AVX512F (1U << 11) #define GNU_ATTRIBUTE_X86_ISA_1_AVX512CD (1U << 12) #define GNU_ATTRIBUTE_X86_ISA_1_AVX512ER (1U << 13) #define GNU_ATTRIBUTE_X86_ISA_1_AVX512PF (1U << 14) #define GNU_ATTRIBUTE_X86_ISA_1_AVX512VL (1U << 15) #define GNU_ATTRIBUTE_X86_ISA_1_AVX512DQ (1U << 16) #define GNU_ATTRIBUTE_X86_ISA_1_AVX512BW (1U << 17) #define GNU_ATTRIBUTE_X86_ISA_1_ENDBR (1U << 18) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2017-03-01 21:56 ` H.J. Lu @ 2017-03-07 16:55 ` H.J. Lu 0 siblings, 0 replies; 25+ messages in thread From: H.J. Lu @ 2017-03-07 16:55 UTC (permalink / raw) To: Carlos O'Donell Cc: Nick Clifton, Kirill A. Shutemov, Joseph S. Myers, Tristan Gingold, libc-help, Binutils, devel On Wed, Mar 1, 2017 at 1:56 PM, H.J. Lu <hjl.tools@gmail.com> wrote: > On Fri, Jan 20, 2017 at 11:06 AM, H.J. Lu <hjl.tools@gmail.com> wrote: >> On Fri, Jan 20, 2017 at 11:02 AM, Carlos O'Donell <carlos@redhat.com> wrote: >>> On 01/20/2017 11:55 AM, H.J. Lu wrote: >>>> We can classify properties into 2 categories: used by run-time loader, >>>> not used by run-time loader. We put properties for run-time loader into >>>> .note.gnu.property section and the rest into GNU attribute section. >>> >>> Agreed. >>> >>> Can we use the same noun/adjective for our names? >>> >>> Is there any reason to use property over attribute? >> >> Nothing other than avoiding confusion between note attribute >> vs non-note attribute. >> >>> As a Friday bikeshed I suggest: >>> >>> .note.gnu.attributes - GNU Attributes optimized for the dynamic loader. >>> -- New. Follows H.J's proposal. Bit-level, packed, and optimized for the >>> dynamic loader processing. >>> >>> .gnu.attributes - GNU Attributes optimized for offline and static linker >>> processing. >>> -- Existing section. Discussions with Nick ongoing if we can continue >>> to use existing infrastructure e.g. Tag_Range to extend this data. >>> >> >> Works for me. >> >> >> -- >> H.J. > > Here is the updated proposal with .note.gnu.attributes. > > > -- > H.J. > --- > Program Attribute Note > > There are cases where linker and run-time loader need more information > about ELF objects beyond what the current gABI provides: > > 1. Minimum ISAs. Executables and shared objects, which are optimized > specifically to run on a particular processor, will not run on processors > which don't support the same set of ISAs. Since x86 only has EM_IAMCU, > EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional > information to tell if an executable or a shared object is compatible > with available ISAs. > 2. Stack size. Compilers may generate binaries which require larger stack > size than normal. If run-time loader can query the stack size required > by executable or shared object, it can increase stack size as needed. > 3. Copy relocation and protected visibility are fundamentally incompatible. > On one hand, copy relocation is the part of the psABI and is used to > access global data defined in a shared object from the executable. It > moves the definition of global data, which is defined in a share object, > to the executable at run-time. On the other hand, protected visibility > indicates that a symbol is defined locally in the shared object at > run-time. Both can't be true at the same time. The current solution > is to make protected symbol more or less like normal symbol, which > prevents optimizing local access to protected symbol within the shared > object. > > GNU attributes > > GNU binutils supports build attribute and run-time platform compatibility > data in relocatable object files. Issues with GNU attributes: > > 1. Many architectures, including x86, don't support GNU attributes. > 2. On x86, linking a relocatable object full of AVX instructions doesn't > always make the resulting executables or shared libraries to require AVX > to run since AVX functions may be called only via GNU_IFUNC at run-time. > Linker can't set minimum ISAs just from ISAs used by input relocatable > objects. > 3. There is no program segment for GNU attributes in executables and > shared objects. > 4. Most of attributes aren't applicable to run-time loader. > 5. The format of GNU attributes isn't optimal for run-time loader. A > separate string table is used to store string attributes. > > gABI support for program attribute note > > To the "Special Sections" section, add: > > Name Type Attributes > .note.gnu.attributes SHT_NOTE SHF_ALLOC > > A .note.gnu.attributes section contains at least one attribute note > descriptor, starting with an attribute note descriptor header and > followed by an array of attributes. The attribute note descriptor > header has the following structure: > > typedef struct { > Elf_Word namsz; > Elf_Word descsz; > Elf_Word type; > unsigned char name[4]; > } Elf_GNU_Notehdr; > > 1. namesz is 4. > 2. descsz contains the size of the attribute array. > 3. type specifies the attribute type: > > #define NT_GNU_ATTRIBUTE_TYPE_0 5 > > 4. name is a null-terminated character string. It should be "GNU". > > Each array element represents one attribute with type, data size and data. > In 64-bit objects, each element is an array of 8-byte words, whose first > element is 4-byte type and data size, in the format of the target processor. > In 32-bit objects, each element is an array of 4-byte words, whose first 2 > elements are 4-byte type and data size, in the format of the target > processor. An array element has the following structure: > > typedef struct { > Elf_Word at_type; > Elf_Word at_datasz; > unsigned char at_data[AT_DATASZ]; > unsigned char at_padding[AT_PADDING]; > } Elf_Prop; > > where AT_DATASZ is the data size and AT_PADDING, if necessary, aligns > array element to 8 or 4-byte alignment (depending on whether the file > is a 64-bit or 32-bit object). The array elements are sorted by the > attribute type. The interpretation of attribute array depends on at_type. > > Types of program attributes > > The last 3 bits of program attribute indicate how it should be > processed. > > #define GNU_ATTRIBUTE_TYPE_SHIFT 3 > #define GNU_ATTRIBUTE_TYPE_MASK (-(1 << GNU_ATTRIBUTE_TYPE_SHIFT)) > #define GNU_ATTRIBUTE_EVAL_MASK ((1 << GNU_ATTRIBUTE_TYPE_SHIFT) - 1) > > #define GNU_ATTRIBUTE_EVAL_REQ 0 > > Linker should refuse to generate output if input attribute type is > unknown. > > #define GNU_ATTRIBUTE_EVAL_EQ 1 > > Linker should refuse to generate output if input attribute data aren't > identical. > > #define GNU_ATTRIBUTE_EVAL_OR 2 > > Output attribute data is logical OR of input attribute data. > > #define GNU_ATTRIBUTE_EVAL_AND 3 > > Output attribute data is logical AND of input attribute data. > > Linker should refuse to generate output for other evaluation values in > input attribute type. > > #define GNU_ATTRIBUTE_LOPROC 0xb0000000 > #define GNU_ATTRIBUTE_HIPROC 0xdfffffff > #define GNU_ATTRIBUTE_LOUSER 0xe0000000 > #define GNU_ATTRIBUTE_HIUSER 0xffffffff > > Proposed properties > > For NT_GNU_ATTRIBUTE_TYPE_0: > > #define GNU_ATTRIBUTE_STACK_SIZE \ > ((1 << GNU_ATTRIBUTE_TYPE_SHIFT)|GNU_ATTRIBUTE_EVAL_REQ) > > Integer value for minimum stack size whose is 8 bytes in 64-bit object > and 4 bytes in 32-bit object. > > #define GNU_ATTRIBUTE_NO_COPY_ON_PROTECTED \ > ((2 << GNU_ATTRIBUTE_TYPE_SHIFT)|GNU_ATTRIBUTE_EVAL_REQ) > > Its at_datasz is 0. This indicates that there should be no copy > relocations against protected data symbols. If a relocatable object > contains this attribute, linker should treat protected data symbol as > defined locally at run-time and copy this attribute to the output share > object. Run-time loader should disallow copy relocations against > protected data symbols defined in share objects with > GNU_ATTRIBUTE_NO_COPY_ON_PROTECTED attribute. > > #define GNU_ATTRIBUTE_X86_ISA_1_USED \ > ((0 << GNU_ATTRIBUTE_TYPE_SHIFT)|GNU_ATTRIBUTE_LOPROC|GNU_ATTRIBUTE_EVAL_OR) > > The x86 instruction sets indicated by the corresponding bits are used > in program. But their support in the hardware is optional. > > #define GNU_ATTRIBUTE_X86_ISA_1_NEEDED \ > ((1 << GNU_ATTRIBUTE_TYPE_SHIFT)|GNU_ATTRIBUTE_LOPROC|GNU_ATTRIBUTE_EVAL_OR) > > The x86 instruction sets indicated by the corresponding bits are used > in program and they must be supported by the hardware. A bit set in > GNU_ATTRIBUTE_X86_ISA_1_NEEDED must also be set in > GNU_ATTRIBUTE_X86_ISA_1_USED. > > 4-byte integer value for the x86 instruction set support. > > #define GNU_ATTRIBUTE_X86_ISA_1_486 (1U << 0) > #define GNU_ATTRIBUTE_X86_ISA_1_586 (1U << 1) > #define GNU_ATTRIBUTE_X86_ISA_1_686 (1U << 2) > #define GNU_ATTRIBUTE_X86_ISA_1_SSE (1U << 3) > #define GNU_ATTRIBUTE_X86_ISA_1_SSE2 (1U << 4) > #define GNU_ATTRIBUTE_X86_ISA_1_SSE3 (1U << 5) > #define GNU_ATTRIBUTE_X86_ISA_1_SSSE3 (1U << 6) > #define GNU_ATTRIBUTE_X86_ISA_1_SSE4_1 (1U << 7) > #define GNU_ATTRIBUTE_X86_ISA_1_SSE4_2 (1U << 8) > #define GNU_ATTRIBUTE_X86_ISA_1_AVX (1U << 9) > #define GNU_ATTRIBUTE_X86_ISA_1_AVX2 (1U << 10) > #define GNU_ATTRIBUTE_X86_ISA_1_AVX512F (1U << 11) > #define GNU_ATTRIBUTE_X86_ISA_1_AVX512CD (1U << 12) > #define GNU_ATTRIBUTE_X86_ISA_1_AVX512ER (1U << 13) > #define GNU_ATTRIBUTE_X86_ISA_1_AVX512PF (1U << 14) > #define GNU_ATTRIBUTE_X86_ISA_1_AVX512VL (1U << 15) > #define GNU_ATTRIBUTE_X86_ISA_1_AVX512DQ (1U << 16) > #define GNU_ATTRIBUTE_X86_ISA_1_AVX512BW (1U << 17) > #define GNU_ATTRIBUTE_X86_ISA_1_ENDBR (1U << 18) Apparently, Nick has committed a patch to implement .note.gnu.property: https://sourceware.org/ml/binutils/2017-03/msg00005.html I will go with it. -- H.J. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-04 15:02 RFH: Annotating ELF binaries Nick Clifton 2016-11-04 15:09 ` Joel Sherrill 2016-11-04 15:13 ` Tristan Gingold @ 2016-11-04 18:34 ` Richard W.M. Jones 2016-11-07 14:28 ` Florian Weimer 2016-11-04 23:58 ` Ian Lance Taylor 3 siblings, 1 reply; 25+ messages in thread From: Richard W.M. Jones @ 2016-11-04 18:34 UTC (permalink / raw) To: Development discussions related to Fedora; +Cc: libc-help, binutils On Fri, Nov 04, 2016 at 03:02:22PM +0000, Nick Clifton wrote: > Hello Everyone, > > We (the tools team at Red Hat) are working on a project to add > annotations to ELF binaries, so that we can answer various questions > about them. We have set up a wiki page about the project here: > > https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects > > We would very much like this to be something more than just an > internal project, and so we are reaching out to you for your opinions, > suggestions and advice. If you are interested in being able answer > questions such as 'how was this function compiled ?' or 'is this > library compatible with this application ?' then please take a minute > to have a look at the proposal. My only comment would be - don't assume that GCC (and LLVM) are the only things which generate objects. Amongst others there are: - ocamlopt - GHC - golang (or is it using LLVM?) - raw assembler files - scripts that use objcopy and other techniques to turn data into object files I don't mean to say it's your responsibility to fix all these things, but good, clear documentation about exactly what to change is needed. This was missing at first when the execstack stuff was added years ago. Also the hardening stuff often doesn't apply in safe languages, so the tools you build around this shouldn't automatically assume no hardening == bad; or that 'long double' or 'wchar_t' are meaningful. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-04 18:34 ` Richard W.M. Jones @ 2016-11-07 14:28 ` Florian Weimer 2016-11-07 15:17 ` Richard W.M. Jones 0 siblings, 1 reply; 25+ messages in thread From: Florian Weimer @ 2016-11-07 14:28 UTC (permalink / raw) To: Richard W.M. Jones, Development discussions related to Fedora Cc: libc-help, binutils On 11/04/2016 07:34 PM, Richard W.M. Jones wrote: > Also the hardening stuff often doesn't apply in safe languages, so the > tools you build around this shouldn't automatically assume > no hardening == bad; or that 'long double' or 'wchar_t' are meaningful. Sorry, this isn't true. As long as you don't have a bytecode interpreter (which is a very attractive target for code injection attacks, to the degree that additional hardening may not matter at all), even supposedly memory-safe languages have type system trapdoors, or perhaps they do not enforce memory safety in the presence of data races. This means that many of the hardening settings still matter. Thanks, Florian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-07 14:28 ` Florian Weimer @ 2016-11-07 15:17 ` Richard W.M. Jones 0 siblings, 0 replies; 25+ messages in thread From: Richard W.M. Jones @ 2016-11-07 15:17 UTC (permalink / raw) To: Florian Weimer Cc: Development discussions related to Fedora, libc-help, binutils On Mon, Nov 07, 2016 at 03:28:12PM +0100, Florian Weimer wrote: > On 11/04/2016 07:34 PM, Richard W.M. Jones wrote: > > >Also the hardening stuff often doesn't apply in safe languages, so the > >tools you build around this shouldn't automatically assume > >no hardening == bad; or that 'long double' or 'wchar_t' are meaningful. > > Sorry, this isn't true. As long as you don't have a bytecode > interpreter (which is a very attractive target for code injection > attacks, to the degree that additional hardening may not matter at > all), even supposedly memory-safe languages have type system > trapdoors, or perhaps they do not enforce memory safety in the > presence of data races. This means that many of the hardening > settings still matter. I did say "often". If we take the OCaml case, then stack hardening is fairly useless since only simple values and pointers are stored there; and racing threads isn't possible. (Stronger enforcement of object boundaries on the minor heap could be a useful thing to have -- in 2015 a compiler bug caused a CVE which allowed you to overwrite object headers on the heap if you could cause an allocation of a certain very large size -- but by default it's not possible to over- or under-run an object allocation.) What you really want to know for OCaml code is whether it was compiled with the -unsafe flag which turns off bounds checking and/or any unsafe_* functions were called (same) or any Obj.* functions (subverts type safety). These would be very useful flags to have but are really nothing to do with C hardening settings -- they are OCaml-specific and they are "un-"hardening. They are also source code red flags which we already check for. My point anyway is that OCaml code is hardened by default and you have to take explicit steps or (in the CVE case) exploit a compiler bug to remove that hardening. Very different from C where even a careful and conscientous programmer can introduce security bugs by accident even when the compiler is working perfectly and so we have to do all this work to add second line defenses to our C compilers. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-04 15:02 RFH: Annotating ELF binaries Nick Clifton ` (2 preceding siblings ...) 2016-11-04 18:34 ` Richard W.M. Jones @ 2016-11-04 23:58 ` Ian Lance Taylor 2016-11-06 16:30 ` Florian Weimer 3 siblings, 1 reply; 25+ messages in thread From: Ian Lance Taylor @ 2016-11-04 23:58 UTC (permalink / raw) To: Nick Clifton; +Cc: libc-help, Binutils, devel On Fri, Nov 4, 2016 at 8:02 AM, Nick Clifton <nickc@redhat.com> wrote: > > We (the tools team at Red Hat) are working on a project to add > annotations to ELF binaries, so that we can answer various questions > about them. We have set up a wiki page about the project here: > > https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects > > We would very much like this to be something more than just an > internal project, and so we are reaching out to you for your opinions, > suggestions and advice. If you are interested in being able answer > questions such as 'how was this function compiled ?' or 'is this > library compatible with this application ?' then please take a minute > to have a look at the proposal. Wearing my Go hat, I observe that you are mixing together general properties ("Which (architecture specific) ABI variant is in use in object X?") with language-specific properties ("agree upon the format of long double?"). I encourage a clear separation of those two different kinds of notes. Ian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-04 23:58 ` Ian Lance Taylor @ 2016-11-06 16:30 ` Florian Weimer 2016-11-06 18:29 ` Ian Lance Taylor 0 siblings, 1 reply; 25+ messages in thread From: Florian Weimer @ 2016-11-06 16:30 UTC (permalink / raw) To: Ian Lance Taylor, Nick Clifton; +Cc: libc-help, Binutils, devel On 11/05/2016 12:57 AM, Ian Lance Taylor wrote: > On Fri, Nov 4, 2016 at 8:02 AM, Nick Clifton <nickc@redhat.com> wrote: >> >> We (the tools team at Red Hat) are working on a project to add >> annotations to ELF binaries, so that we can answer various questions >> about them. We have set up a wiki page about the project here: >> >> https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects >> >> We would very much like this to be something more than just an >> internal project, and so we are reaching out to you for your opinions, >> suggestions and advice. If you are interested in being able answer >> questions such as 'how was this function compiled ?' or 'is this >> library compatible with this application ?' then please take a minute >> to have a look at the proposal. > > Wearing my Go hat, I observe that you are mixing together general > properties ("Which (architecture specific) ABI variant is in use in > object X?") with language-specific properties ("agree upon the format > of long double?"). I encourage a clear separation of those two > different kinds of notes. I'm not sure how to draw the line. I consider the size and format of âlong doubleâ very much an ABI matter. The psABI uses C types throughout, although it is used for much more than just C . There is no language-independent name I know of for the floating point type larger than the type which resembles IEEE double precision floats. But I would expect that Ada's definition of Long_Long_Float would have to be adjusted to align with ABI changes in this area. Thanks, Florian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-06 16:30 ` Florian Weimer @ 2016-11-06 18:29 ` Ian Lance Taylor 2016-11-07 18:00 ` Joseph Myers 0 siblings, 1 reply; 25+ messages in thread From: Ian Lance Taylor @ 2016-11-06 18:29 UTC (permalink / raw) To: Florian Weimer; +Cc: Nick Clifton, libc-help, Binutils, devel On Sun, Nov 6, 2016 at 8:30 AM, Florian Weimer <fweimer@redhat.com> wrote: > On 11/05/2016 12:57 AM, Ian Lance Taylor wrote: >> >> On Fri, Nov 4, 2016 at 8:02 AM, Nick Clifton <nickc@redhat.com> wrote: >>> >>> >>> We (the tools team at Red Hat) are working on a project to add >>> annotations to ELF binaries, so that we can answer various questions >>> about them. We have set up a wiki page about the project here: >>> >>> https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects >>> >>> We would very much like this to be something more than just an >>> internal project, and so we are reaching out to you for your opinions, >>> suggestions and advice. If you are interested in being able answer >>> questions such as 'how was this function compiled ?' or 'is this >>> library compatible with this application ?' then please take a minute >>> to have a look at the proposal. >> >> >> Wearing my Go hat, I observe that you are mixing together general >> properties ("Which (architecture specific) ABI variant is in use in >> object X?") with language-specific properties ("agree upon the format >> of long double?"). I encourage a clear separation of those two >> different kinds of notes. > > > I'm not sure how to draw the line. I consider the size and format of “long > double” very much an ABI matter. Yes, it's an ABI matter, but it's specific to C/C++ programs. > The psABI uses C types throughout, although it is used for much more than > just C . There is no language-independent name I know of for the floating > point type larger than the type which resembles IEEE double precision > floats. But I would expect that Ada's definition of Long_Long_Float would > have to be adjusted to align with ABI changes in this area. The only sensible way to write the psABI is for it to say "this is how to pass an 80 or 128 bit floating point value." The psABI can't say "this is the size of the type 'long double'", because that is a matter for the language and perhaps the compiler. The best the ABI can do is say "In C/C++, the type 'long double' is 80 (or 128) bits," which is separate from the discussion of such a type should be passed between functions. Then each language can decide how to implement the appropriate type--whether it should be the same as the C/C++ type 'long double' or not. Ian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-06 18:29 ` Ian Lance Taylor @ 2016-11-07 18:00 ` Joseph Myers 2016-11-07 20:05 ` Florian Weimer 0 siblings, 1 reply; 25+ messages in thread From: Joseph Myers @ 2016-11-07 18:00 UTC (permalink / raw) To: Ian Lance Taylor; +Cc: Florian Weimer, Nick Clifton, libc-help, Binutils, devel On Sun, 6 Nov 2016, Ian Lance Taylor wrote: > The only sensible way to write the psABI is for it to say "this is how > to pass an 80 or 128 bit floating point value." The psABI can't say I would advise using IEEE 754-2008 names in psABIs where available (e.g. binary128). (Of course you need to deal with the non-IEEE types such as x86 extended precision, but IEEE names are standard and unambiguous up to endianness for binary interchange formats, and unambiguous up to endianness and BID / DPD choice for decimal interchange formats.) -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: RFH: Annotating ELF binaries 2016-11-07 18:00 ` Joseph Myers @ 2016-11-07 20:05 ` Florian Weimer 0 siblings, 0 replies; 25+ messages in thread From: Florian Weimer @ 2016-11-07 20:05 UTC (permalink / raw) To: Joseph Myers, Ian Lance Taylor; +Cc: Nick Clifton, libc-help, Binutils, devel On 11/07/2016 07:00 PM, Joseph Myers wrote: > On Sun, 6 Nov 2016, Ian Lance Taylor wrote: > >> The only sensible way to write the psABI is for it to say "this is how >> to pass an 80 or 128 bit floating point value." The psABI can't say > > I would advise using IEEE 754-2008 names in psABIs where available (e.g. > binary128). (Of course you need to deal with the non-IEEE types such as > x86 extended precision, but IEEE names are standard and unambiguous up to > endianness for binary interchange formats, and unambiguous up to > endianness and BID / DPD choice for decimal interchange formats.) Most people in the community don't have access to IEEE 754-2008 and therefore will not know what these terms mean (and considering how much stuff has been made up about IEEE 754 due to its secretive nature, I wouldn't want to rely on a paraphrase). Florian ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2017-03-07 16:55 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-11-04 15:02 RFH: Annotating ELF binaries Nick Clifton 2016-11-04 15:09 ` Joel Sherrill 2016-11-04 15:13 ` Tristan Gingold 2016-11-04 15:23 ` Nick Clifton 2016-11-04 15:55 ` Tristan Gingold 2017-01-13 20:26 ` H.J. Lu 2017-01-16 14:38 ` Nick Clifton 2017-01-16 17:48 ` Carlos O'Donell 2017-01-17 18:55 ` H.J. Lu 2017-01-18 17:02 ` Nick Clifton 2017-01-18 17:56 ` Joseph Myers 2017-01-19 20:22 ` Carlos O'Donell 2017-01-20 16:55 ` H.J. Lu 2017-01-20 19:02 ` Carlos O'Donell 2017-01-20 19:06 ` H.J. Lu 2017-03-01 21:56 ` H.J. Lu 2017-03-07 16:55 ` H.J. Lu 2016-11-04 18:34 ` Richard W.M. Jones 2016-11-07 14:28 ` Florian Weimer 2016-11-07 15:17 ` Richard W.M. Jones 2016-11-04 23:58 ` Ian Lance Taylor 2016-11-06 16:30 ` Florian Weimer 2016-11-06 18:29 ` Ian Lance Taylor 2016-11-07 18:00 ` Joseph Myers 2016-11-07 20:05 ` Florian Weimer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).