UPX - a powerful executable packer

The bottom line is that linux-2.6.26 is too big. Even when UPX is fixed
to deal with the boot protocol, then a defconfig for i686 gets reduced by
only:
2749616 -> 2311693 84.07% bvmlinuz/386 vmlinuz
even when using --lzma compression. This is much bigger than a 1.44MB
floppy disk.

Regarding the boot protocol changes: the new HdrS fields .payload_offset
and .payload_size nicely tell _where_ the payload is, but *WHAT* is it?
There should be a .payload_type:
-1: uncompressed .bin
0: gzipped .bin
1: gzipped ELF
2: ...
Saying, "apply the usual heuristics and magic numbers to determine content
type" is an admission of poor design.

Next, the changes in boot protocol 2.08 could have been implemented so
that a CONFIG option offers the choice between gzipped .bin and gzipped
ELF. As of 2.6.26, all of the supposed benefits of using gzipped ELF are
outside the kernel; the boot file itself is bigger and the kernel has no
additional features. The option for backward compatibility should have
been preserved.

Finally, the CRC checksum is not well-defined, and its consumer is unknown
(which piece(s) of software care?). There are at least 12 different
algorithms, with 12 different 32-bit results, which satisfy the
"documented" feature. [What is the mapping between powers of x and bits in
the 32-bit constant which specifies the polynomial (little-endian or
big-endian)? What is the mapping between bits of the input stream and
powers of x? Specifically, is the partial dividend augmented 1, 8, or 32
bits at a time?]

The issue has been noted. Personal holidays intervene until Tuesday, July
15.

You may be interested to read the reply from Linus Torvalds:
http://lkml.org/lkml/2008/7/10/268

Basically he's offering to help guard against such regressions in the
future.