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@xxxxxxxxxx/ [2] https://www.kernel.org/doc/html/latest/crypto/api-samples.html -- Kees Cook
