linux-kernel - Re: [PATCH v1 0/3] zram: introduce crypto-backend api

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241121155307.GE2668855@google.com>
Date: Fri, 22 Nov 2024 00:53:07 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Alexey Romanov <avromanov@...utedevices.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
	"minchan@...nel.org" <minchan@...nel.org>,
	"axboe@...nel.dk" <axboe@...nel.dk>,
	"terrelln@...com" <terrelln@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>
Subject: Re: [PATCH v1 0/3] zram: introduce crypto-backend api

On (24/11/21 12:11), Alexey Romanov wrote:
> > Sorry, no, we are not adding this for a hypothetical scenario.
> > 
> > > For example, he can use some driver with hardware compression support.
> > 
> > Such as?  Pretty much all H/W compression modules (I'm aware of)
> > that people use with zram are out-of-tree.
> 
> At least we have this:
> 
> drivers/crypto/nx/nx-common-powernv.c:1043:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> drivers/crypto/nx/nx-common-pseries.c:1020:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> drivers/crypto/cavium/zip/zip_main.c:377:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> drivers/crypto/cavium/zip/zip_main.c:392:    .cra_flags        = CRYPTO_ALG_TYPE_COMPRESS,
> 
> Anyway, if we want to completely abandon Crypto API

It's more complicated than that.

> these modules still need to be supported in zram.

We support what we have always claimed we supported, namely
what is listed in drivers/block/zram/Kconfig.  That's how one
enables a particular algorithm in zram - during zram configuration.
If those algos are not in zram's Kconfig after so many years,
then it's most likely because people don't use them with zram.
If we ever need backends for those H/W algos, then I really would
prefer a patch from folks that have a corresponding hardware to
run and test it on.  The thing is, zram, in its current form and
shape, imposes strict requirements on comp implementation.

So we should not add algos just because they are there (especially
H/W algos) that's how we added 842, lz4hc many years ago and now
have to carry them around.  We are not doing that again.