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 21:33:06 +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 21:29, Kees Cook <keescook@...omium.org> wrote:
>
> On Mon, Oct 17, 2022 at 08:14:14PM +0200, Ard Biesheuvel wrote:
> > 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.
>
> Ah, in the sense that "in place" is actually happening in the per-cpu
> allocation, and only if it succeeds does the input buffer get
> overwritten?
>

Something like that IIRC.

> > 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?
>
> Well, my goal was to make the algo "pstore doesn't care". If someone
> picks deflate, do they still get all the per-cpu allocations?
>

Not if you use the library interface directly.

The issue with the percpu buffers is that they are only kept if any
scomp TFMs are active, but this is always the case for pstore, as you
don't want to allocate it on the panic path.