linux-kernel - Re: PATCH/RFC: bzImage payload as compressed ELF file.

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: <479E6323.5030200@zytor.com>
Date:	Mon, 28 Jan 2008 15:20:03 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ian Campbell <ijc@...lion.org.uk>
CC:	linux-kernel@...r.kernel.org, Jeremy Fitzhardinge <jeremy@...p.org>
Subject: Re: PATCH/RFC: bzImage payload as compressed ELF file.

Ian Campbell wrote:
> 
> What would be the preferred way of allowing bootloaders/domain builders
> to find the compressed payload? Tacking the offset from the end onto the
> end as I have done for the moment seems pretty skanky...
> 

As Jeremy already mentioned, putting a pointer to the compressed ELF 
image in the bzImage header (and bumping the version number to 2.08) is 
the right way to go about it.  The compression format (for now, always 
gzip) can then be identified in the usual way via compression format 
magic number.

As I've previously expressed, I'm much happier with this approach than 
having the compressor portion itself be an ELF image, so I'm happy to 
see this patch.  However, I think it needs to ride a cycle in -mm, so 
although I didn't see any problems from a cursory look I might not get a 
chance to do a detailed review until the merge window is over.

	-hpa
--
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/