U-Boot env export: Do Not Treat -s as the Binary Write Limit
In U-Boot v2025.01, env export -s is not implemented as
a uniform destination-size limit across all export formats. The text
path passes the requested size to the serializer. The raw-binary and
checksum paths instead pass the compiled ENV_SIZE for their
data area.
That difference matters when a script reserves a small RAM buffer for
a few selected variables. Selecting fewer variables reduces their
encoded content, but does not reduce the fixed clearing span used by the
binary serializer in this version. Size the destination from the actual
implementation and build configuration before executing an export.
Separate the
documented option from each code path
The environment
command guide describes the three formats, the optional variable
list and the output-buffer size option. It also says a successful export
sets filesize.
The command
implementation, do_env_export(), parses the size as
hexadecimal. A nonzero requested size causes an initial clearing of that
many bytes at the destination. What happens next depends on the
format.
For text output, the call to hexport_r() receives the
requested size. For raw binary and checksum-protected output, the same
helper receives ENV_SIZE instead. Raw output starts at the
destination address; checksum-protected data starts at the
data member of the environment structure, after its
header.
Consequently, a small nonzero -s does not constrain the
binary helper to that small span. A larger requested size can also cause
a larger initial clearing. Treat both stages as writes when reviewing
the RAM region’s ownership.
Understand what
the serializer’s size controls
The hash-table
serializer first calculates a length for the selected entries. In
binary mode it counts raw value lengths, although the output loop can
add escapes for backslashes. This discussion assumes the selected values
contain no backslashes; that length check is not a general safety proof
for arbitrary values.
If its supplied size is nonzero and smaller than the calculated
requirement, the helper rejects the export. Otherwise, for a
caller-provided destination, it clears the entire supplied size before
writing the selected entries.
It returns that size, not merely the number of meaningful characters.
With a zero size, it derives a size from the selected content and its
terminator. The binary command branch never passes zero here: it
supplies the compiled data-area size even when the command-line size was
omitted.
Account for the
header and reported length
The environment
layout definition defines ENV_SIZE as
CONFIG_ENV_SIZE minus the environment header. That header
includes CRC storage and, for a redundant environment build, an
additional flags byte. Use the actual build’s layout rather than
assuming a universal header length.
There is a second version-specific detail: the binary branch sets
filesize to the serializer’s returned length plus the
data-member offset for both binary modes. Raw -b output did
not write that header before its data. Its reported length therefore
must not be interpreted as proof that a checksum header exists at the
destination.
For checksum mode, an explicit command-line size also influences the
CRC span independently of the fixed size passed to the serializer. Avoid
treating an arbitrary smaller size as a supported way to produce a
compact checksum environment. Verify the intended format and consumer
together.
Make the buffer contract
explicit
Before an approved export, record the format, selected variables,
compiled environment layout, initial clearing span, serializer clearing
span and the consumer’s expected length. Review the resulting accesses
under the stated value-content assumption and reserve an adequately
sized owned RAM region. Do not test an undersized region on a live
target.
No environment export or RAM write was performed here. The conclusion
is specific to this tagged implementation: a buffer option’s name is
insufficient evidence of a write bound when different format branches
pass different sizes to the serializer.
