Toolchain/Watermark

Markup for ELF objects

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 and the size of an enum). This would be both at link time and at load time.
• 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.
• 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.

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