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

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20241119130438.3vkopcmnmmwgmxha@cab-wsm-0029881>
Date: Tue, 19 Nov 2024 13:04:44 +0000
From: Alexey Romanov <avromanov@...utedevices.com>
To: Christoph Hellwig <hch@...radead.org>
CC: "minchan@...nel.org" <minchan@...nel.org>, "senozhatsky@...omium.org"
	<senozhatsky@...omium.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>, kernel <kernel@...rdevices.ru>
Subject: Re: [PATCH v1 3/3] zram: introduce crypto-api backend

Hi Christoph,

On Tue, Nov 19, 2024 at 04:34:52AM -0800, Christoph Hellwig wrote:
> On Tue, Nov 19, 2024 at 03:27:13PM +0300, Alexey Romanov wrote:
> > Since we use custom backend implementation, we remove the ability
> > for users to use algorithms from crypto backend. This breaks
> > backward compatibility, user doesn't necessarily use one of the
> > algorithms from "custom" backends defined in zram folder.
> > For example, he can use some driver with hardware compression support.
> > 
> > This patch adds opinion to enable Crypto API: add ZRAM_BACKEND_CRYPTO_API.
> > Option is enabled by default, because in previously version of ZRAM
> > it was possible to choose any alogirthm using Crypto API. This is
> > also done for backward compatibility purposes.
> 
> Which crypto API algorithm do you care about?  You should probably
> just add a backend for that instead of a double indirection.
> 

Should I create backend_*.c file for every compression algo driver?
Okay, there aren't many of them now. But what will do, for example,
when there will be 250 such compression drivers?

And also your approach doesn't allow working with loadable modules.
For example, we may have only binary module (without sources) from
vendor SDK that provieds a driver for data compression. 

This is an even bigger problem.

-- 
Thank you,
Alexey