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. > * 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. -- Tom
signature.asc
Description: PGP signature
