[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5j+dPqpJZbO_AuGsNqJzq7XGcB2deXA5RELWv1-Ywi5QOA@mail.gmail.com>
Date: Tue, 7 Aug 2018 11:10:10 -0700
From: Kees Cook <keescook@...omium.org>
To: Herbert Xu <herbert@...dor.apana.org.au>
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>
Subject: Re: [PATCH 1/9] crypto: add zbufsize() interface
On Tue, Aug 7, 2018 at 2:45 AM, Herbert Xu <herbert@...dor.apana.org.au> wrote:
> On Thu, Aug 02, 2018 at 02:51:10PM -0700, Kees Cook wrote:
>> When pstore was refactored to use the crypto compress API in:
>>
>> commit cb3bee0369bc ("pstore: Use crypto compress API")
>>
>> nearly all the pstore-specific compression routines were replaced with
>> the existing crypto compression API. One case remained: calculating the
>> "worst case" compression sizes ahead of time so it could have a buffer
>> preallocated for doing compression (which was called "zbufsize").
>>
>> To make pstore fully algorithm-agnostic, the compression API needs to
>> grow this functionality. This adds the interface to support querying the
>> "worst case" estimate, with a new "zbufsize" routine that each compressor
>> can implement. The per-compressor implementations come in later commits.
>>
>> Signed-off-by: Kees Cook <keescook@...omium.org>
>> ---
>> crypto/compress.c | 9 +++++++++
>> include/crypto/internal/scompress.h | 11 +++++++++++
>> include/linux/crypto.h | 12 ++++++++++++
>> 3 files changed, 32 insertions(+)
>>
>> diff --git a/crypto/compress.c b/crypto/compress.c
>> index f2d522924a07..29a80bb3b9d3 100644
>> --- a/crypto/compress.c
>> +++ b/crypto/compress.c
>> @@ -33,12 +33,21 @@ static int crypto_decompress(struct crypto_tfm *tfm,
>> dlen);
>> }
>>
>> +static int crypto_zbufsize(struct crypto_tfm *tfm,
>> + unsigned int slen, unsigned int *dlen)
>> +{
>> + if (!tfm->__crt_alg->cra_compress.coa_zbufsize)
>> + return -ENOTSUPP;
>> + return tfm->__crt_alg->cra_compress.coa_zbufsize(tfm, slen, dlen);
>> +}
>
> Please don't add new features to the old compress interface. Any
> new improvements should be added to scomp/acomp only. Users who
> need new features should be converted.
So, keep crypto_scomp_zbufsize() and drop crypto_comp_zbufsize() and
crypto_zbufsize()? Should I add crypto_acomp_zbufsize()?
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists