linux-kernel - Re: [regression?] 2.6.26 floppy boot failure with kernel packed using 'upx'

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1215676061.3452.29.camel@cthulhu.hellion.org.uk>
Date:	Thu, 10 Jul 2008 08:47:41 +0100
From:	Ian Campbell <ijc@...lion.org.uk>
To:	Frans Pop <elendil@...net.nl>
Cc:	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [regression?] 2.6.26 floppy boot failure with kernel packed
	using 'upx'

On Thu, 2008-07-10 at 06:54 +0200, Frans Pop wrote:
> The issue can also be reproduced using qemu without booting the floppy
> itself. For the "bad" image:
> # Boots correctly (but fails when mounting root fs):
> $ qemu -kernel vmlinuz -hda /dev/zero
> # Fails:
> $ qemu -kernel vmlinuz.upx -hda /dev/zero

I can repro this.

> So, the primairy question here is:
> - is this a kernel regression because whatever changed is no longer valid
>   conform "kernel format specs", or
> - is this a latent issue in upx that somehow creates an invalid image, or
> - does this change effectively create a new "type" of image that upx
>   just doesn't yet know how to handle correctly?

This is the first time I've looked at UPX but from glancing through the
code it certainly appears to make a lot of assumptions about the
structure of the bzImage (to the point that it looks for specific code
sequences within the binary).

It seems that the way UPX works is that it extracts the compressed image
from the bzImage, recompresses it and rebuilds a new bzImage replacing
the decompression stage (and possibly some of the other 16 bit startup,
I'm not quite sure yet) with its own. The issue is that its new
decompressor does not understand the ELF format and expects a raw
binary.

I think that UPX probably has gone a bit beyond the documented
interfaces, but it's not unreasonable way. In fact the changeset which
you referenced (or one of the ones around it) actually adds further
documentation (in Documentation/x86/i386/boot.txt) and header fields to
aid in doing the sort of extraction UPX wants to do and documents more
explicitly the formats which can be expected to be found there. Also
around the same time a checksum field was defined which is invalidated
by the repacking.

All in all I'd say it should be treated as a new subtype/variant which
UPX should support. I'd say adding support for bzImage v2.08 to UPX
would be pretty easy for someone who knows the code base (I couldn't
even find the decompressor code, but then it's pre-coffee time here..).

Ian.
-- 
Ian Campbell

Fame lost its appeal for me when I went into a public restroom and an
autograph seeker handed me a pen and paper under the stall door.
		-- Marlo Thomas

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/