Re: [RFC PATCH 01/21] crypto: scomp - Revert "add support for deflate rfc1950 (zlib)"

2023-08-03 Thread Giovanni Cabiddu
On Thu, Aug 03, 2023 at 11:59:00AM +0200, Ard Biesheuvel wrote:
> Any clue why zlib_deflate was chosen in this case?
I believe it was done for integrity.
The output of zlib_deflate is raw deflate with an header and a footer
defined in rfc1950. The footer contains a checksum which gets
calculated over the uncompressed data during compression and checked
after decompression.

-- 
Giovanni


Re: [RFC PATCH 01/21] crypto: scomp - Revert "add support for deflate rfc1950 (zlib)"

2023-08-03 Thread Giovanni Cabiddu
Hi Ard,

On Tue, Jul 18, 2023 at 01:58:27PM +0100, Ard Biesheuvel wrote:
> This reverts commit a368f43d6e3a001e684e9191a27df384fbff12f5.
> 
> "zlib-deflate" was introduced 6 years ago, but it does not have any
> users. So let's remove the generic implementation and the test vectors,
> but retain the "zlib-deflate" entry in the testmgr code to avoid
> introducing warning messages on systems that implement zlib-deflate in
> hardware.
> 
> Note that RFC 1950 which forms the basis of this algorithm dates back to
> 1996, and predates RFC 1951, on which the existing IPcomp is based and
> which we have supported in the kernel since 2003. So it seems rather
> unlikely that we will ever grow the need to support zlib-deflate.
> 
> Signed-off-by: Ard Biesheuvel 
Support for zlib-deflate was added for [1] but that work was not
completed.

Based on [2], either we leave this SW implementation or we remove the HW
implementations in the QAT [3] and in the Hisilicon Zip [4] drivers.

[1] 
https://patchwork.kernel.org/project/linux-btrfs/patch/1467083180-111750-1-git-send-email-weigang...@intel.com/
[2] https://lore.kernel.org/lkml/ziw%2fjtxdg6o1o...@gondor.apana.org.au/
[3] 
https://elixir.bootlin.com/linux/latest/source/drivers/crypto/intel/qat/qat_common/qat_comp_algs.c#L457
[4] 
https://elixir.bootlin.com/linux/latest/source/drivers/crypto/hisilicon/zip/zip_crypto.c#L754

Regards,

-- 
Giovanni