Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221006234138.1835739-1-keescook@chromium.org>
 <191ec24d-35d4-e4e5-85f7-d7301984e647@igalia.com> <202210171100.5BAC4A5CC8@keescook>
 <CAMj1kXHzrRTVcxb5+hgUPV3tjekPcDWzVf6cG_Mc9JJmYBz2Mw@mail.gmail.com> <202210171227.35ED875219@keescook>
In-Reply-To: <202210171227.35ED875219@keescook>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Mon, 17 Oct 2022 21:33:06 +0200
Message-ID: <CAMj1kXEJQ8gh-iXZNL8bNcmV=JCmKHNp5BnhYthhSOyR5h79_g@mail.gmail.com>
Subject: Re: [PATCH] pstore: migrate to crypto acomp interface (take 2)
To:     Kees Cook <keescook@chromium.org>
Cc:     "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
        Anton Vorontsov <anton@enomsg.org>,
        Colin Cross <ccross@android.com>,
        Tony Luck <tony.luck@intel.com>, linux-kernel@vger.kernel.org,
        linux-hardening@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.