linux-hardening - Re: [PATCH] pstore: migrate to crypto acomp interface (take 2)

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 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 20:14:14 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
        Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Tony Luck <tony.luck@...el.com>, linux-kernel@...r.kernel.org,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH] pstore: migrate to crypto acomp interface (take 2)

On Mon, 17 Oct 2022 at 20:01, Kees Cook <keescook@...omium.org> wrote:
>
> On Mon, Oct 17, 2022 at 01:26:12PM -0300, Guilherme G. Piccoli wrote:
> > On 06/10/2022 20:41, Kees Cook wrote:
> > > From: Ard Biesheuvel <ardb@...nel.org>
> > >
> > > The crypto 'compress' interface is deprecated, so before adding new
> > > features, migrate to the acomp interface. Note that we are only using
> > > synchronous implementations of acomp, so we don't have to deal with
> > > asynchronous completion.
>
> Ard, given your observation about all the per-cpu memory allocation,
> should pstore still go ahead with this conversion?
>

Well, the reason for doing this conversion was so that we could move
the 'worst case buffer size' logic into the individual drivers, as
Herbert would't allow that for legacy comp.

But as we found, we don't really care about the theoretical worst case
of an input that is incompressible - we can just pass the uncompressed
size as the upper bound, and if the crypto fails, we just store the
data uncompressed (which never happens in the first place with ASCII
text)

So once we use the same size for input and output, I was curious
whether we could encrypt in place, and get rid of the big_oops_buf.
And the answer is 'yes', precisely because we have this horrid per-CPU
allocation which serves as a bounce buffer. And this is not specific
to acomp, the old comp algorithms get wrapped in scomps which receive
the same treatment.

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?