Wednesday, June 19, 2013

Side note on ELF notes

ELF file may contain section .note which may contain numerous additional implementation defined values. Each value is opaque from the ELF specification point of view which only describes the structure of its header. That's because notes are considered optional and implementation may ignore the notes it can not understand.

However, this particular case of note headers resembles export keyword introduced by C++03, ignored by most compilers and eventually removed in C++11. The problem with ELF note is that all implementations use slightly different note header format than the one described by the specification.

According to ELF format note contains 5 fields:
  • namesz and name: The latter is representation of the entry owner (null terminated string) used mainly to avoid conflicts between custom, implementation defined notes. The former is the size of that representation.
  • descsz and desc: The actual note value and the size of that value.
  • type: Note type used to correctly interpret its value.

ELF specification clearly states that all these fields should be 4-byte (8-byte on 64-bit processors) aligned and appropriately padded. That's what standard says. In reality, all systems in BSD family, Linux,  GNU tools, illumos, Solaris, etc use 4-bit alignment on both 32-bit and 64-bit architectures. A comment in the illumos source code claims that it is due to the mistake in the initial 64-bit port and in order to maintain compatibility was not corrected. Nothing serious, but may cause some confusion to anyone not aware of that.

The actual note owners, types and the way of interpreting its values is not documented by ELF specification in any way. Moreover, since they are all implementation defined there is no documentation at all. Another thing that makes working with ELF notes a bit more unpleasant.

In addition to all this, one would expect that a pair name:type identifies a way of interpreting a note. That's correct assumption but care must be taken when introducing new note types since some note types are interpreted in certain way regardless of the note owner. Basically, there is a set of notes used in core files which owner is usually CORE. However, some implementations store them with different owners (e.g. FreeBSD) as a result most implementations of tools that read ELF notes assumes that the note owner is CORE if it does not recognize the actual one. This means that the only way to reliably avoid conflicts is to use custom note owner and note types that are not used by the owner CORE.

Useful links