U-Boot bootelf: Program Headers and Section Headers Describe Different Load Operations

An ELF file copied successfully into RAM is only the loader’s input.
U-Boot v2025.01 bootelf subsequently copies or clears
memory according to either program headers or section headers. Choosing
the wrong header path can produce a different destination layout even
though the same file and entry-point field are involved.

This article covers trusted, well-formed, target-compatible
executable ELF images with valid loader-visible headers. It does not
treat bootelf as a hardened parser for arbitrary files or
as a general dynamic linker.

Make the header choice
explicit

The command
guide assigns -p to program-header loading and
-s to section-header loading. The command
implementation initializes its flags to zero and sets the
program-header flag only for -p. With no such option, this
version takes the section-header path.

An explicit choice makes a boot script easier to audit against the
artifact’s linker layout. Do not infer the choice from the
.elf suffix or from the address at which the file was
downloaded.

Program loading follows
segments

In the ELF
loader, the program-header path processes PT_LOAD
entries. It copies p_filesz bytes from the file’s
p_offset to the address in p_paddr. If the
segment’s memory size is larger, it clears the remaining memory through
p_memsz.

The destination comes from the physical-address field in this
implementation, not from the file staging address and not from
p_vaddr. The ELF32 and ELF64 paths use the same basic
segment rule. A valid input must have consistent sizes and destinations
that are appropriate for the target’s accessible memory.

Section loading
follows allocated sections

The section-header path instead walks sections carrying
SHF_ALLOC, excluding entries with zero address or zero
size. Each eligible section uses sh_addr as its
destination. A SHT_NOBITS section is cleared; other
eligible sections are copied from their file offsets.

Thus the two paths describe different collections of writes.
Segment-level padding and zero-fill need not be identical to a
section-by-section reconstruction. A layout that is usable through
program headers must not be assumed usable through section headers after
its section metadata has been removed or altered.

Disabling
execution does not disable loading

The loader checks validity, performs the selected load operation, and
only then examines its autostart flag. If autostart is disabled, it
returns without calling the application, but the copies and clears have
already happened.

The command gets that flag through the environment
helper. Setting autostart=no disables execution in this
path; it does not turn bootelf into a read-only inspection
command. Do not use it to explore unknown destination addresses on a
running board.

The validity helper checks the ELF magic and executable type. That
limited acceptance check is not evidence of complete bounds checking,
safe overlap, correct architecture, authenticity or a compatible
application ABI. Those properties must be established before invoking
the loader.

Audit the artifact
without loading it first

Use a host-side ELF inspection tool to record the chosen header
table, file offsets, destination intervals, initialized lengths and
zero-fill lengths. Compare those intervals with the board’s memory map
and the staged file’s own extent. Avoid assuming that loader copies are
safe when source and destination overlap.

Check the entry-point contract separately. The loader normally
obtains it from the ELF header; the source also contains a PowerPC64
ELFv1 descriptor special case. No architecture-independent calling
convention follows from a valid numeric entry address.

For a controlled qualification image, use recognizable initialized
data and a separate zero-fill region, then verify the expected
destinations without executing the application. That is a proposed test
on an approved memory layout, not a test performed here.

The decision is which metadata defines the load. Resolve that before
examining application behavior, because a no-execution run can already
have changed the memory being diagnosed.