linux-kernel - Re: Driver supporting HW decompression and SW decompression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240830053811.GA28271@hu-cgoldswo-sd.qualcomm.com>
Date: Thu, 29 Aug 2024 22:38:39 -0700
From: Chris Goldsworthy <quic_cgoldswo@...cinc.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: Chris Goldsworthy <quic_cgoldswo@...cinc.com>,
        "David S. Miller"
	<davem@...emloft.net>,
        <linux-crypto@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: Driver supporting HW decompression and SW decompression

On Sat, Mar 16, 2024 at 12:40:33PM +0800, Herbert Xu wrote:
> On Fri, Mar 15, 2024 at 05:26:21PM -0700, Chris Goldsworthy wrote:
> > Hi There,
> > 
> > If a compression driver were submitted upstream that used HW LZO decompression
> > and SW LZO compression, could it be accepted? It would be geared towards
> > decompressing boot images on IOT-type targets with exteremely limited secondary
> > storage.
> 
> Who is the intended user in the kernel? In general, Crypto API
> drivers will be accepted if there is at least one in-kernel user.

Hi Herbert,

Digging this up again after we've settled on more design choices internally.
We're planning for this block to use LZ4, and in the kernel we'd like to use
it with zswap.

For our implementation, we intend on capping the size of our history window to 4
KB, in order to reduce the area of the block, which would mean that we're only
guaranteed to be able to compress 4 KB buffers (the LZ4 spec uses a 64 KB
history window).

IAA faced a similar limitation [1], but I just want to make sure our situations
are identical w.r.t. being able to get out driver accepted.  SW will be able to
decompress compressed content we produce, we just can't compress buffers of
arbitrary sizes (users would need to break them into individual 4 KB requests).

Thanks,

Chris.

[1] https://lore.kernel.org/linux-crypto/ZLsvdS6NbaetDFe1@gondor.apana.org.au/