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: <580A88B3.9030101@klondike.es>
Date:   Fri, 21 Oct 2016 23:29:23 +0200
From:   "Francisco Blas Izquierdo Riera (klondike)" <klondike@...ndike.es>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        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

Hello Andrew!

El 21/10/16 a las 23:21, Andrew Morton escribió:
> 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.
Ugh that was my mistake, the e-mail should have been sent from my
klondike@...ndike.es address. I guess at some point during sending I
messed it up. Sorry for that.
> So I'll rewrite the From: address to match the SOB address.
That's perfect, thanks :)
> You can do this yourself by including an explicit From: line as the
> first line of the changelog text.
Thanks! I'm still trying to learn how the kernel patching process works
so the tip is very appreciated.I'll be careful and use the From line
next time :)

Sincerely,
Klondike


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)