lkml.org 
[lkml]   [2022]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] pstore: migrate to crypto acomp interface (take 2)
On Mon, 17 Oct 2022 at 21:29, Kees Cook <keescook@chromium.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.

\
 
 \ /
  Last update: 2022-10-17 21:33    [W:0.058 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site