linux-kernel - Re: [PATCH 0/2] Add support for ZSTD-compressed 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]

Date:   Tue, 10 Oct 2017 14:55:10 -0700
From:   hpa@...or.com
To:     Nick Terrell <terrelln@...com>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
        x86@...nel.org, kernel-team@...com, Chris Mason <clm@...com>,
        Yann Collet <cyan@...com>, Rene Rebe <rene@...ctcode.com>
Subject: Re: [PATCH 0/2] Add support for ZSTD-compressed kernel

On October 10, 2017 2:22:42 PM PDT, Nick Terrell <terrelln@...com> wrote:
>Hi,
>
>This patch set adds support for a ZSTD-compressed kernel and ramdisk
>images in the kernel boot process. It only integrates the support with
>x86, though the first patch is generic to all architectures.
>
>Zstandard requires slightly more memory during the kernel decompression
>on x86 (192 KB vs 64 KB), and the memory usage is independent of the
>window size.
>
>Zstandard requires memory proprortional to the window size used during
>compression for decompressing the ramdisk image, since streaming mode
>is
>used. Newer versions of zstd (1.3.2+) list the window size of a file
>with `zstd -lv <file>'. The absolute maximum amount of memory required
>is just over 8 MB.
>
>Thanks,
>Nick Terrell
>
>Nick Terrell (2):
>  lib: Add support for ZSTD-compressed kernel
>  x86: Add support for ZSTD-compressed kernel
>
> Documentation/x86/boot.txt        |   6 +-
> arch/x86/Kconfig                  |   1 +
> arch/x86/boot/compressed/Makefile |   5 +-
> arch/x86/boot/compressed/misc.c   |   4 +
> arch/x86/boot/header.S            |   8 +-
> arch/x86/include/asm/boot.h       |   6 +-
> include/linux/decompress/unzstd.h |  26 +++
> init/Kconfig                      |  14 +-
> lib/Kconfig                       |   4 +
> lib/Makefile                      |   1 +
> lib/decompress.c                  |   5 +
>lib/decompress_unzstd.c           | 341
>++++++++++++++++++++++++++++++++++++++
> lib/xxhash.c                      |  21 ++-
> lib/zstd/decompress.c             |   2 +
> lib/zstd/fse_decompress.c         |   9 +-
> scripts/Makefile.lib              |  15 ++
> usr/Kconfig                       |  22 +++
> 17 files changed, 465 insertions(+), 25 deletions(-)
> create mode 100644 include/linux/decompress/unzstd.h
> create mode 100644 lib/decompress_unzstd.c

And, pray tell, what are the actual results? What is the trade-off of kernel size versus decompression performance versus the other algorithms that we already support? Adding algorithms for their own sake is a bad thing not a good thing.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.