Message-ID: <CAMj1kXHTxc2PM1mz3pm-UEcmch9YG5QKF+JKAUNe9b+1L0OnfA@mail.gmail.com>
Date:   Mon, 17 Oct 2022 23:01:35 +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 22:36, Kees Cook <keescook@...omium.org> wrote:
>
> On Mon, Oct 17, 2022 at 10:13:52PM +0200, Ard Biesheuvel wrote:
> > On Mon, 17 Oct 2022 at 22:11, Kees Cook <keescook@...omium.org> wrote:
> > >
> > > On Mon, Oct 17, 2022 at 09:45:08PM +0200, Ard Biesheuvel wrote:
> > > > On Mon, 17 Oct 2022 at 21:40, Kees Cook <keescook@...omium.org> wrote:
> > > > > Okay, so strictly speaking, eliminating the per-CPU allocation is an
> > > > > improvement. Keeping scomp and doing in-place compression will let
> > > > > pstore use "any" compressions method.
> > > >
> > > > I'm not following the point you are making here.
> > >
> > > Sorry, I mean to say that if I leave scomp in pstore, nothing is "worse"
> > > (i.e. the per-cpu allocation is present in both scomp and acomp). i.e.
> > > no regression either way, but if we switch to a distinct library call,
> > > it's an improvement on the memory utilization front.
> > >
> > > > > Is there a crypto API that does _not_ preallocate the per-CPU stuff?
> > > > > Because, as you say, it's a huge amount of memory on the bigger
> > > > > systems...
> > > >
> > > > The library interface for each of the respective algorithms.
> > >
> > > Where is the crypto API for just using the library interfaces, so I
> > > don't have to be tied to a specific algo?
> > >
> >
> > That doesn't exist, that is the point.
>
> Shouldn't something like that exist, though?
>

Well, if what you have in mind is a pluggable API where abstract
compress() invocations can be backed by different implementations,
you'll soon find that you don't want to compile every alternative into
the kernel statically, and you'll need some kind of module dispatch.
That brings you very close to the crypto API already.

However, the main mismatch between the crypto API and a library
interface is the use of scatterlists, and this is the reason we have
those per-cpu buffers in the first place, as the underlying algos
don't operate on scatterlists, and so you need a scratch buffer to
hold the data. Another complication is that you cannot test for
in-place operation as easily by comparing src and dst pointers, given
that distinct scatterlists for src and may still describe the same
buffer in memory.

All this complexity is there to abstract from the differences between
software algos and h/w accelerators, but there only exists a single
instance of the latter in the tree, for HiSilicon SoCs, so this is
obviously not a resounding success.

In summary, we're better off sticking with the legacy comp interface,
but unfortunately, due to the way that has been plumbed into the
scomp/acomp with scatterlists version, that doesn't really help us get
rid of the memory overhead.


> > But how does the algo matter when you are dealing with mere kilobytes
> > of ASCII text?
>
> Sure, though, this is how we got here -- every couple of years, someone
> added another library interface to another compression aglo.

But why? How does that make a meaningful difference for compressing kernel logs?

> I tore all
> that out so we could avoid having to choose a single one, but was left
> with the zbufsize mess (that, yes, doesn't matter). So now pstore can
> just not care what compression is chosen.
>

What I propose is to simply hard wire pstore to a single existing
library implementation, and forget about the crypto API entirely.

We know the pros, given the above. So what would we lose that is
valuable by doing this?

Powered by blists - more mailing lists