Executable and Linkable Format

Executable and Linkable Format
Surueña · CC BY-SA 3.0 · source
Name	Executable and Linkable Format
Extension	.so, .o, .exe
Mime	application/x-elf
Owner	System V Application Binary Interface, UNIX System Laboratories
Released	1990
Type	Executable, Object code, Shared library

Executable and Linkable Format ELF is a common file format for executables, object code, shared libraries, and core dumps used on many operating systems and processor architectures. Originating from the System V Application Binary Interface work by AT&T and UNIX System Laboratories, ELF provides a flexible, extensible layout enabling linking, loading, and runtime relocation across diverse environments.

Overview

ELF was standardized in the System V ABI and later adopted by projects and institutions including AT&T, UNIX System Laboratories, Red Hat, Debian, SUSE, and Canonical to support platforms such as Linux kernel, FreeBSD, NetBSD, OpenBSD, Solaris, and AIX. Its design influenced or interacts with formats and tools from GNU Project, Intel Corporation, ARM, IBM, MIPS Technologies, and Power Architecture. Implementations are present in distributions and ecosystems maintained by organizations like The Linux Foundation, Debian Project, and Mozilla Foundation, and used by development toolchains from GCC and LLVM.

File Format and Structure

An ELF file is composed of a header, program header table, section header table, and payload segments or sections. The specification delineated in the System V ABI defines byte order and layout for CPUs such as x86, x86-64, ARM, ARM64, MIPS, PowerPC, and RISC-V. Toolchains from GNU Project and LLVM produce object files and shared objects that interoperate with linkers like GNU ld and Gold and loaders implemented in kernels for Linux kernel, FreeBSD, and Solaris.

ELF Header and Program/Section Headers

The ELF header identifies class (32-bit or 64-bit), endianness, and entry point, while program headers describe segments for runtime mapping and section headers describe named sections like .text, .data, .bss, .symtab, and .dynsym. Linkers and debuggers from the GNU Project, LLVM, and vendors such as Intel Corporation and IBM rely on these tables to perform relocation, symbol resolution, and to generate DWARF debug information compatible with tools like GDB and LLDB. Standards bodies such as IEEE and organizations like The Open Group have referenced or interoperated with ELF in cross-platform ABI discussions.

Linking, Loading, and Execution

Static and dynamic linking processes use ELF structures to resolve symbols, perform relocations, and generate runtime bindings via the dynamic linker/loader (ld.so) provided by implementations from GNU Project, Android, NetBSD, and OpenBSD. Runtime loader behavior affects startup libraries such as glibc, musl, and vendor libc implementations from IBM and Oracle. Execution semantics interact with kernel subsystems in Linux kernel and Solaris to map segments, enforce memory protections, and invoke entry points as defined by language runtimes like Java and Python when using native extensions.

Tooling and Utilities

A wide ecosystem of tools manipulate ELF files: linkers like GNU ld, Gold, and LLD; assemblers and compilers from GNU Project and LLVM; debuggers GDB and LLDB; binary utilities like GNU binutils (objdump, readelf, nm), and package builders used by Debian Project, Red Hat, SUSE, and Canonical. Reverse engineering and analysis suites from Hex-Rays and Binwalk-using communities, as well as forensic frameworks employed by institutions like CERT, operate on ELF images for inspection, symbol recovery, and emulation with projects such as QEMU.

Platform Variations and Extensions

Vendors and projects have extended or adapted ELF for platform-specific needs: Android uses ELF for its native libraries with custom loader behavior, Linux kernel supports extended program header semantics, and commercial UNIX variants from Oracle and IBM include vendor-specific dynamic tags and ABI conventions. Processor vendors including Intel Corporation, ARM, MIPS Technologies, and RISC-V define architecture-specific relocation types and calling conventions. Toolchains from GNU Project, LLVM, Intel Corporation, and IBM incorporate these extensions for cross-compilation and optimization.

Security Considerations and Hardening

Security hardening for ELF involves mitigations implemented by projects such as GNU Project (compiler hardening flags), Red Hat (operating system hardening policies), and OpenBSD (position-independent executables, W^X policies), alongside kernel features in Linux kernel like Address Space Layout Randomization and NX support. Techniques used by vendors and institutions including Google (hardened toolchains), Microsoft (PE vs ELF considerations in cross-platform tooling), and security teams in CERT focus on control-flow integrity, RELRO, stack canaries, and symbol visibility to reduce exploitation surface in ELF binaries. Static analysis and runtime monitoring tools from Microsoft Research, Google, and Mozilla Foundation are applied to ELF artifacts to detect vulnerabilities and enforce provenance and integrity in supply chain workflows.

Category:Executable file formats