linux-kernel - Re: [PATCH v3 2/2] initramfs: Allow again choice of the embedded initram compression algorithm

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: <20161021142154.211eb0ae3784e055429a92e3@linux-foundation.org>
Date:   Fri, 21 Oct 2016 14:21:54 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     klondike <klondike@...cosoft.net>
Cc:     linux-kernel@...r.kernel.org, P J P <ppandit@...hat.com>,
        Paul Bolle <pebolle@...cali.nl>
Subject: Re: [PATCH v3 2/2] initramfs: Allow again choice of the embedded
 initram compression algorithm

On Tue, 27 Sep 2016 22:32:59 +0200 klondike <klondike@...cosoft.net> wrote:

> Choosing the appropriate compression option when using an embeded initramfs
> can result in significant size differences in the resulting data.
> 
> This is caused by avoiding double compression of the initramfs contents.
> For example on my tests, choosing CONFIG_INITRAMFS_COMPRESSION_NONE when
> compressing the kernel using XZ) results in up to 500KiB differences (9MiB to
>  8.5MiB) in the kernel size as the dictionary will not get polluted with
> uncomprensible data and may reuse kernel data too.
> 
> Despite embedding an uncompressed initramfs, a user may want to allow for a
> compressed extra initramfs to be passed using the rd system, for example to
> boot a recovery system. Commit 9ba4bcb645898d562498ea66a0df958ef0e7a68c
> ("initramfs: read CONFIG_RD_ variables for initramfs compression") broke
> that behavior by making the choice based on CONFIG_RD_* instead of adding
> CONFIG_INITRAMFS_COMPRESSION_LZ4. Saddly, CONFIG_RD_* is also used to
> choose the supported RD compression algorithms by the kernel and a user may
> want to suppport more than one.
> 
> This patch also reverses 3e4e0f0a8756dade3023d1f47d50fbced7749788
> ("initramfs: remove "compression mode" choice") restoring back the
> "compression mode" choice and includes the CONFIG_INITRAMFS_COMPRESSION_LZ4
> option which was never added.
> 
> As a result the following options are added or readed affecting the embedded
> initramfs compression:
> INITRAMFS_COMPRESSION_NONE Do no compression
> INITRAMFS_COMPRESSION_GZIP Compress using gzip
> INITRAMFS_COMPRESSION_BZIP2 Compress using bzip2
> INITRAMFS_COMPRESSION_LZMA Compress using lzma
> INITRAMFS_COMPRESSION_XZ Compress using xz
> INITRAMFS_COMPRESSION_LZO Compress using lzo
> INITRAMFS_COMPRESSION_LZ4 Compress using lz4
> 
> These depend on the corresponding CONFIG_RD_* option being set (except NONE
> which has no dependencies).

As you sent them, these patches would be merged with

	From: klondike <klondike@...cosoft.net>
	Signed-off-by: Francisco Blas Izquierdo Riera (klondike) <klondike@...ndike.es>

Which is strange.  Different email addresses and "klondike" isn't a
real name.

So I'll rewrite the From: address to match the SOB address.

You can do this yourself by including an explicit From: line as the
first line of the changelog text.