linux-kernel - Re: [PATCH RFC] x86: Add CONFIG_KERNEL

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: <CAMj1kXF-GSB9Ty7X1h4u1uA6qhO1Y1UvVrNF=R+hk3PENRz7WA@mail.gmail.com>
Date: Wed, 22 Jan 2025 14:30:54 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Jann Horn <jannh@...gle.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, Masahiro Yamada <masahiroy@...nel.org>, 
	Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, linux-efi@...r.kernel.org, 
	Andrew Morton <akpm@...ux-foundation.org>, linux-kbuild@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] x86: Add CONFIG_KERNEL_UNCOMPRESSED support

Hi Jann,

On Tue, 21 Jan 2025 at 23:16, Jann Horn <jannh@...gle.com> wrote:
>
> Support storing the kernel uncompressed for developers who want to quickly
> iterate with one-off kernel builds.
> Store it in the usual format with a 4-byte length suffix and keep this new
> codepath as close as possible to the normal path where decompression
> happens.
>
> The other compression methods offered by the kernel take some time;
> even LZ4 (which the kernel uses at compression level 9) takes ~2.8
> seconds to compress a 110M large vmlinux.bin on my machine.
>
> An alternate approach to this would be to offer customization of the LZ4
> compression level through a kconfig variable; and yet another approach
> would be to abuse the existing gzip decompression logic by storing the
> kernel as "non-compressed" DEFLATE blocks, so that the decompression code
> will essentially end up just doing a bunch of memcpy() calls.
>

This all seems pretty complicated, and adding yet another
(pseudo-)compression method is not great in terms of maintenance
burden, especially because there are other consumers of the compressed
images (both for bzImage and EFI zboot)

Did you try running gzip with -1 instead of -9? On my build machine,
this reduces the compression time of a defconfig bzImage build from
4.3 seconds to 0.9 seconds.