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  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:   Mon, 17 Oct 2022 21:11:02 +0200
From:   Ard Biesheuvel <>
To:     "Guilherme G. Piccoli" <>
Cc:     Kees Cook <>,
        Anton Vorontsov <>,
        Colin Cross <>,
        Tony Luck <>,,
Subject: Re: [PATCH] pstore: migrate to crypto acomp interface (take 2)

On Mon, 17 Oct 2022 at 20:23, Guilherme G. Piccoli <> wrote:
> On 17/10/2022 15:14, Ard Biesheuvel wrote:
> > [...]
> >
> > So at that point, I wondered what the point is of all this complexity.
> > Do we really need 6 different algorithms to compress a couple of K of
> > ASCII text on a code path that is ice cold by definition? Wouldn't it
> > be better to drop the crypto API altogether here, and just use GZIP
> > via the library interface?
> Skipping all the interesting and more complex parts, I'd just want to
> consider zstd maybe?

I just made the point that it doesn't matter. So on the one hand, I
don't have any objections to ZSTD per se. But I do wonder if it is the
best choice when it comes to code size etc. Perhaps one of the
compression algorithms is guaranteed to be compiled in anyway?

> Quite fast and efficient - it's what we're using by
> default on Steam Deck.
> I'm not sure what is the gzip library interface - you mean skipping the
> scomp/legacy comp interface, and make use directly of gzip?

zlib_deflate() and friends.

Powered by blists - more mailing lists