[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211202035727.GC8138@gondor.apana.org.au>
Date: Thu, 2 Dec 2021 14:57:27 +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 Wed, Dec 01, 2021 at 07:51:25PM -0800, Kees Cook wrote:
>
> But the scomp API appears to be "internal only":
>
> include/crypto/internal/scompress.h:static inline int crypto_scomp_decompress(struct crypto_scomp *tfm,
>
> What's the correct API calling sequence to do a simple decompress?
OK we haven't wired up scomp to users because there was no user
to start with. So if you like you can create it just as we did
for shash.
The question becomes do you want to restrict your use-case to
synchronous-only algorithms, i.e., you will never be able to access
offload devices that support compression?
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).
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
Powered by blists - more mailing lists