All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Geliang Tang <geliangtang@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>, Haren Myneni <haren@us.ibm.com>,
	Anton Vorontsov <anton@enomsg.org>,
	Colin Cross <ccross@android.com>, Tony Luck <tony.luck@intel.com>,
	Zhou Wang <wangzhou1@hisilicon.com>,
	linux-crypto <linux-crypto@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>
Subject: Re: [PATCH 1/9] crypto: add zbufsize() interface
Date: Wed, 1 Dec 2021 15:39:06 -0800	[thread overview]
Message-ID: <202112011529.699092F@keescook> (raw)
In-Reply-To: <20180808025319.32d57wtjpyyapwo5@gondor.apana.org.au>

On Wed, Aug 08, 2018 at 10:53:19AM +0800, Herbert Xu wrote:
> On Tue, Aug 07, 2018 at 11:10:10AM -0700, Kees Cook wrote:
> >
> > > 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()?
> 
> Yes and yes.  acomp is the primary interface and should support
> all the features in scomp.

*thread necromancy*

Okay, I'm looking at this again because of the need in the module loader
to know "worst case decompression size"[1]. I am at a loss for how (or
why) the acomp interface is the "primary interface".

For modules, all that would be wanted is this, where the buffer size can
be allocated on demand:

u8 *decompressed = NULL;
size_t decompressed_size = 0;

decompressed = decompress(decompressed, compressed, compressed_size, &decompressed_size);

For pstore, the compressed_size is fixed and the decompression buffer
must be preallocated (for catching panic dumps), so the worst-case size
needs to be known in advance:

u8 *decompressed = NULL;
size_t decompressed_worst_size = 0;
size_t decompressed_size = 0;

worst_case(&decompressed_worst_size, compressed_size);

decompressed = kmalloc(decompressed_worst_size, GFP_KERNEL);
...
decompressed_size = decompressed_worst_size;
decompress(decompressed, compressed, compressed_size, &decompressed_size);


I don't see anything like this in the kernel for handling a simple
buffer-to-buffer decompression besides crypto_comp_decompress(). The
acomp interface is wildly over-complex for this. What the right
way to do this? (I can't find any documentation that discusses
compress/decompress[2].)

-Kees

[1] https://lore.kernel.org/linux-modules/YaMYJv539OEBz5B%2F@google.com/
[2] https://www.kernel.org/doc/html/latest/crypto/api-samples.html

-- 
Kees Cook

  reply	other threads:[~2021-12-01 23:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-02 21:51 [PATCH 0/9] crypto: add zbufsize() interface Kees Cook
2018-08-02 21:51 ` [PATCH 1/9] " Kees Cook
2018-08-07  9:45   ` Herbert Xu
2018-08-07 18:10     ` Kees Cook
2018-08-08  2:53       ` Herbert Xu
2021-12-01 23:39         ` Kees Cook [this message]
2021-12-02  1:58           ` Herbert Xu
2021-12-02  3:51             ` Kees Cook
2021-12-02  3:57               ` Herbert Xu
2021-12-02  8:10                 ` Kees Cook
2021-12-03  2:28                   ` Herbert Xu
2021-12-03 20:49                     ` Dmitry Torokhov
2021-12-07  5:20                       ` Herbert Xu
2021-12-07  6:24                         ` Dmitry Torokhov
2021-12-07  6:27                           ` Herbert Xu
2018-08-02 21:51 ` [PATCH 2/9] crypto, 842: implement zbufsize() Kees Cook
2018-08-02 21:51 ` [PATCH 3/9] crypto, null: Implement zbufsize() Kees Cook
2018-08-02 21:51 ` [PATCH 4/9] crypto, lzo: " Kees Cook
2018-08-02 21:51 ` [PATCH 5/9] crypto, deflate: " Kees Cook
2018-08-02 21:51 ` [PATCH 6/9] crypto, zstd: " Kees Cook
2018-08-02 21:51 ` [PATCH 7/9] crypto, lz4: " Kees Cook
2018-08-02 21:51 ` [PATCH 8/9] crypto, lz4hc: " Kees Cook
2018-08-02 21:51 ` [PATCH 9/9] pstore: Use crypto_comp_zbufsize() Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202112011529.699092F@keescook \
    --to=keescook@chromium.org \
    --cc=anton@enomsg.org \
    --cc=arnd@arndb.de \
    --cc=ccross@android.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=geliangtang@gmail.com \
    --cc=haren@us.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=wangzhou1@hisilicon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.