linux-kernel - Re: [PATCH 1/9] crypto: add zbufsize() interface

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 linux-cve-announce 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]

Message-ID: <20211203022821.GA16082@gondor.apana.org.au>
Date:   Fri, 3 Dec 2021 13:28:21 +1100
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Kees Cook <keescook@...omium.org>
Cc:     Geliang Tang <geliangtang@...il.com>,
        Arnd Bergmann <arnd@...db.de>, Haren Myneni <haren@...ibm.com>,
        Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>,
        Tony Luck <tony.luck@...el.com>,
        Zhou Wang <wangzhou1@...ilicon.com>,
        linux-crypto <linux-crypto@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [PATCH 1/9] crypto: add zbufsize() interface

On Thu, Dec 02, 2021 at 12:10:13AM -0800, Kees Cook wrote:
>
> I'd rather just have a simple API that hid all the async (or sync) details
> and would work with whatever was the "best" implementation. Neither pstore
> nor the module loader has anything else to do while decompression happens.

Well that's exactly what the acomp interface is supposed to be.
It supports any algorithm, whether sync or async.  However, for
obvious reasons this interface has to be async.

> > Typically this would only make sense if you process a very small
> > amount of data, but this seems counter-intuitive with compression
> > (it does make sense with hashing where we often hash just 16 bytes).
> 
> pstore works on usually a handful of small buffers. (One of the largest
> I've seen is used by Chrome OS: 6 128K buffers.) Speed is not important
> (done at most 6 times at boot, and 1 time on panic), and, in fact,
> offload is probably a bad idea just to keep the machinery needed to
> store a panic log as small as possible.

In that case creating an scomp user interface is probably the best
course of action.

> Why can't crypto_comp_*() be refactored to wrap crypto_acomp_*() (and
> crypto_scomp_*())? I can see so many other places that would benefit from
> this. Here are just some of the places that appear to be hand-rolling
> compression/decompression routines that might benefit from this kind of
> code re-use and compression alg agnosticism:

We cannot provide async hardware through a sync-only interface
because that may lead to dead-lock.  For your use-cases you should
avoid using any async implementations.

The scomp interface is meant to be pretty much identical to the
legacy comp interface except that it supports integration with
acomp.

Because nobody has had a need for scomp we have not added an
interface for it so it only exists as part of the low-level API.
You're most welcome to expose it if you don't need the async
support part of acomp.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt