#110 Linux kernel 2.6.26 packed using upx fails to boot

[Frans Pop]

Not sure if this should be a bug or feature request, but as it breaks our ability to a create boot floppy for the Debian Installer I'll call it a bug :-)

Starting with the about to be released version 2.6.26 of the Linux kernel, a kernel packed using upx will fail to boot with:
<snip>
SYSLINUX 3.70 <etc.>
boot:expert
Loading linux......................
Loading initrd.gz....ready.
Probing EDD (edd=off to disable)... ok
</snip>

And then the emulator crashes (both VirtualBox and qemu), or on real hardware the system reboots.

Cause is a change introduced early in the 2.6.26 development cycle that adds support for a "payload" inside the image.

Full details of the issue including a test case can be found here:
http://lkml.org/lkml/2008/7/10/9.

A reply from the author of the change in the kernel is available here:
http://lkml.org/lkml/2008/7/10/48

That mail also mentions a later change in 2.6.26 that adds a checksum that is probably invalidated by the compression, so correct functioning for a new release of upx should NOT solely be tested using the kernel from my testcase, but preferably using a kernel from the latest -rc or final release for 2.6.26.

[Frans Pop]

Logged In: YES
user_id=2142422
Originator: YES

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.

[John Reiser]

Logged In: YES
user_id=33687
Originator: NO

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

[John Reiser]

Logged In: YES
user_id=33687
Originator: NO

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?]