Toolchain/Watermark

Markup for ELF objects

{This page is here in order to encourage discussion about this project. It is hoped that anyone who is interested will edit this page to add their questions, comments and ideas}.

This project intends to add markers to ELF objects so that it is possible to determine whether they have certain properties. The three overarching goals are:

• Determine if all objects implement the same ABI (e.g., they agree upon the format of long double). This would be both at link time and at load time. This would also need to include negative properties so that, for example, if a shared library does not use the wchar_t type, then it can be linked with an application that uses any size of wchar_t. Ideally we want to be able to find the answer to these questions:
  • Which (architecture specific) ABI variant is in use in object X and is it compatible with object Y ?
  • What are the sizes of the basic types used in object X ? (For those types not explicitly covered by the ABI, eg enum and wchat_t). If the object does not use a particular type then this should be discoverable as well.

• Determine if an object was compiled according to applicable security polices (e.g., -fstack-protector-strong was used at compile time). This also includes the ability to check which tool(s) were used to create the object, so that, for example, it is possible to determine if the object was compiled with an out of date version of the compiler. Questions that we want to be able to answer here include:
  • Has every function in object X been compiled with option Y ?
  • Has every function in object X been compiled with version Y of the compiler (or newer) ?
  • Has object X been linked with option Y enabled (eg relro) ?

• Determine the run-time requirements of the object (e.g. the hardware version they need, or the amount of stack space that they require). This could also be extended to cover symbols that need special binding considerations. For example functions that call execve might need immediate binding even if the rest of the executable uses lazy binding. So questions in this section include:
  • Which symbols in object X posses attribute Y, given that this affects the loading of X.
  • What hardware resources are needed by object X ? (Architecture, memory footprint, stack size, more ?)

One issue with determining this information is that it is possible for a single ELF object to have multiple, possibly conflicting, properties. For example an object might contain ifuncs which support different hardware versions, or function specific optimizations may have been used to change the security of individual functions.

A second issue is that if this information is going to be used at load-time, then it has to fast and simple to access and process. The loader is a highly optimized program and changes to it need to be small and robust.

A side issue is that storing this information in an ELF object will increase its size. If lots of information is stored in a space inefficient way then this could prove a problem for getting this proposal accepted by package maintainers.

Implementation

The current plan for implementing this proposal is a two pronged approach using ELF Notes. One, small, set of notes would be stored in an allocatable section, and would just contain the information needed by the loader. This is the scheme proposed by H.J.Lu. A second, non-allocatable section would contain more detailed notes that can be analysed by separate, static, tools. This second section would have the ability to record per-function information (actually per-symbol information) as well as file level and application level information. The necessary information would be gathered by a gcc plugin, so there would be no need to modify the compiler sources directly.

Wiki page categories

We use wiki categories to track progress.

• Proposed properties subject to discussion and revision.
• Accepted properties pending implementation.
• Implemented properties