Re: [PATCH 1/3] bootm: size the noload decompression buffer from the compressor header

On Mon, 2026-08-10 at 10:37 -0600, Tom Rini wrote:
> On Mon, Aug 10, 2026 at 10:32:12AM +0800, Aristo Chen wrote:
> > On Sun, Aug 9, 2026 at 11:27 PM Tom Rini <[email protected]> wrote:
> > > 
> > > On Sun, Aug 09, 2026 at 04:23:27AM +0000, Aristo Chen wrote:
> > > 
> > > > For a compressed kernel_noload image, bootm_load_os() allocates a
> > > > per-image decompression buffer of ALIGN(image_len * 8, SZ_1M). The 8x
> > > > multiplier is a heuristic: it comfortably covers what zstd and xz
> > > > achieve on real kernels, but any well-compressed payload (say, a big
> > > > run of zeros) can exceed it and fail decompression, and no fixed
> > > > multiplier is safe against arbitrarily compressible input.
> > > > 
> > > > Read the real uncompressed size from the compressor header instead.
> > > > Add a small helper image_decomp_get_uncompressed_size() that returns
> > > > the uncompressed size when the format carries one: gzip ISIZE, lzma
> > > > header uncompressed size, lz4 frame Content_Size when the FLG bit is
> > > > set, and zstd Frame_Content_Size. Other formats return -EOPNOTSUPP.
> > > > Bootm uses it to size the buffer to ALIGN(hdr_size, SZ_1M), capped at
> > > > CONFIG_SYS_BOOTM_LEN because the value is attacker-controlled, and
> > > > falls back to the 8x heuristic for formats without a size field
> > > > (bzip2, lzo, xz) or when the header lacks the size (some lzma or lz4
> > > > streams).
> > > 
> > > Have we gotten actual problem reports? This is a good bit of growth for
> > > a problem I'm not sure we're seeing. Thanks.
> > 
> > Thanks for the review! Honest answer: no bug report against the
> > current 8x multiplier has crossed the list. This is preventive rather
> > than reactive, and I should have made that clearer in the cover
> > letter.
> > 
> > The reasons for this patch set are:
> >   * The multiplier is fundamentally a heuristic. Nora raised the same
> > concern in the v1 round of the earlier
> > series(<https://lists.denx.de/pipermail/u-boot/2026-June/621575.html>):
> > "Deriving a buffer size from the compressed size is not possible, as
> > the compression ratio may be arbitrarily high for data with many
> > repetitions (for example ranges of 0x00 or 0xff)."She dropped her
> > replacement patch when we bumped 4x to 8x, but the underlying point
> > stands: any fixed factor can be defeated by a highly    compressible
> > payload, and further bumps are just moving the ceiling.
> 
> Yeah, I recall this. But we aren't really handling arbitrary data here,
> so it's not as much of a valid concern I think, without real examples.

It's probably not a problem when the OS image is a proper kernel, but if the
next image is a tiny loader itself, even a small amount of padding (either
inside the .data section or at the end of the image) might result in high
compression ratios.

While irrelevant for current U-Boot, one example would be OpenWrt's lzma-loader:
it has a build mode where the <100KiB binary is padded to 1MiB (I may be
remembering the exact numbers wrong) before compression to force a cache
writeback during decompression (to work around ancient U-Boot versions that did
not implement cache handling correctly.)

Specifically the case of kernel_noload would usually be used with EFI
applications, for which additional loaders (shim, systemd-boot, ...) are quite
common. The combination with FIT and compression is probably less common...

Nonetheless, I think a principled fix is preferable - I like the EFI-in-FIT
approach a lot (we may make that the default setup in our TQ-Systems standard
BSPs in the future), thus I would like the feature to be well-supported and
without known bugs.

Best,
Nora


> 
> >   * Simon suggested the header-size approach as the principled fix in
> > the same round (<https://lists.denx.de/pipermail/u-boot/2026-May/620121.html>):
> > "It might be worth updating image_decomp() to take a ulong size... I
> > believe in each case it is also possible to find out the decomp size
> > by looking at the header."
> 
> Which would make sense for a more general problem, or a less constrained
> system.
> 
> > So the growth buys correctness: the buffer size is derived from the
> > compressed stream itself, not from a multiplier guess that can be
> > defeated by any payload with a high enough compression ratio.
> > 
> > That said, I understand the "we're not seeing it" concern. If you
> > would rather wait for a concrete report, I am happy to drop the series
> > and re-send when one lands, or to shrink patch 1 to gzip only, which
> > cuts about 40 lines of parser code. Let me know which you prefer.
> 
> Yes, I'd like to wait and see what problem reports we get at this point,
> thanks.


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/