Does appending arbitrary data to an ELF file violate the ELF spec?

Question

I would like to add some information to an ELF file, but it ideally needs to be done in a way that a program can easily read this information without understanding ELF or using tools outside a normal standard language library. I was thinking of simply appending this data to the end of the ELF file (with some sort of sentinel to indicate the start of the data so the reading program can just seek backward to the sentinel), but I wanted to make sure this doesn't violate the ELF spec first. I'm not interested in whether a particular loader works fine with such appended data; I want to know if the ELF spec itself guarantees anything so that I can know different ELF-compliant loaders will be happy with it.

I see that questions like this have been asked before, but either assuming that this appending is ok or with no direct responses:

• Accessing data appended to an ELF binary
• Add source code to elf file

As far as I can tell, the ELF spec is here:

• http://www.muppetlabs.com/~breadbox/software/ELF.txt

I couldn't determine with a few searches whether the property I want is unambiguously allowed by that spec.

Answer 1

The specification does not really say anything about it, so one could argue for "it's undefined behavior to have trailing data". On the other hand, the ELF specification is rather clear about its expectations: “sections and segments have no specified order. Only the ELF header has a fixed position in the file.”, which gives sufficient room to embed data one way or another, using a section, or doing without one [this is then unreferenced data!].

This "data freedom" has been exploited since at least the end of the 1980s; consider "self-extracting archives" where a generic unpacking code stub is let loose on a trailing data portion.

In fact, you can find such implicit feature even in non-executable data formats, such as RIFF and PNG. Not all formats allow this of course; in particular those where data is defined to runs until EOF rather than for a fixed length stored in some header. (Consider ZIP: appending data is not possible, but prepending is, which is what leads to EXE-ZIPs being readable by both (unmodified) unzip programs and operating systems.)

There is just one drawback to using unreferenced data like this: when reading and saving a file, you can lose this data.