linux-kernel - Re: [PATCH] init: bzip2 or lzma -compressed kernels and initrds

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]

Date:	Sun, 07 Sep 2008 00:59:25 +0200
From:	Alain Knaff <alain@...ff.lu>
To:	Leon Woestenberg <leon.woestenberg@...il.com>
CC:	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] init: bzip2 or lzma -compressed kernels and initrds

Leon Woestenberg wrote:
> Hello,
> 
> a small remark on the non-code parts:
> 
> On Sat, Sep 6, 2008 at 11:19 PM, Alain Knaff <alain@...ff.lu> wrote:
>> compressing the kernel with bzip2 or lzma rather than gzip. Both
>> compressors give smaller sizes than gzip.  Moreover, lzma's
>> decompresses faster than gzip.
>>
> versus
> 
>> +config KERNEL_GZIP
>> +       bool "Gzip"
>> +       help
>> +         The old and tried gzip compression. Its compression ratio is
>> +        the poorest among the 3 choices; however its speed (both
>> +        compression and decompression) is the fastest.
>> +
> 
> This seems contradictionary information.

Oops, sorry for that. Actually the Kconfig text is correct. On
decompression, Lzma is faster than bzip2 but slower than gzip:

Compressor	Compression	Decompression	Size
gzip -9		1,01s		0,11s		833069
lzma -9		3,43s		0,24s		705125
bzip2 -9	2,88s		0,38s		777706

On compression, lzma is actually slowest of the 3, but that should be of
little concern, as this happens only once, whereas decompression happens
many times (on each boot).

So, overall lzma looks like the best (acceptable decompression speed,
best decompression ratio). I only included Bzip2 because it's much
better known than lzma.

> However, I welcome more compression options in kernel and filesystem
> land, so I'm very interested in this patch.

Thanks for your interest and warm welcome :)

> Recently, on the filesystem side there seems to be some effort to
> modularize the decompressors, instead of the use of #ifdef's.
> 
> The other architectures (especially used in embedded) need to hook in
> on this, getting rid of the many out-of-tree patches for kernel/fs
> decompression.
> 
> Regards,

Unfortunately, I didn't have any such machine available for testing, so
I just for Intel 32/64.

However, the changes in the Assembly part (head_32.S and head_64.S) are
trivial, so should be easy to port. The only change to these files is
the offset where the uncompressed size of the file may be found (4 bytes
from the end for gzip, and 5 from the start for lzma).

misc.c, where the bulk of the "architecture-specific" change is, is
actually not that architecture-specific, and could maybe be moved to a
common part? Diff'ing the boot/compressed/misc.c's of various
architectures shows (at first glance) mostly version differences: some
architectures get some changes/enhancements earlier than others. It's as
if the various architectures were stuck at some different points in the
past as compared to Intel...

most of the other files are architecture-independant anyways (the stuff
in lib/ and init/)

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