linux-kernel - Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG

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: <20160603082152.GA30551@gondor.apana.org.au>
Date:	Fri, 3 Jun 2016 16:21:52 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Baolin Wang <baolin.wang@...aro.org>
Cc:	Jens Axboe <axboe@...nel.dk>, Alasdair G Kergon <agk@...hat.com>,
	Mike Snitzer <snitzer@...hat.com>,
	"open list:DEVICE-MAPPER (LVM)" <dm-devel@...hat.com>,
	David Miller <davem@...emloft.net>,
	Eric Biggers <ebiggers3@...il.com>,
	Joonsoo Kim <js1304@...il.com>, tadeusz.struk@...el.com,
	smueller@...onox.de, Masanari Iida <standby24x7@...il.com>,
	Shaohua Li <shli@...nel.org>,
	Dan Williams <dan.j.williams@...el.com>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Sagi Grimberg <sagig@...lanox.com>,
	Kent Overstreet <kent.overstreet@...il.com>,
	Keith Busch <keith.busch@...el.com>, Tejun Heo <tj@...nel.org>,
	Ming Lei <ming.lei@...onical.com>,
	Mark Brown <broonie@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	linux-crypto@...r.kernel.org, linux-block@...r.kernel.org,
	"open list:SOFTWARE RAID (Multiple Disks) SUPPORT" 
	<linux-raid@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v2 2/3] crypto: Introduce CRYPTO_ALG_BULK flag

On Fri, Jun 03, 2016 at 04:15:28PM +0800, Baolin Wang wrote:
>
> Suppose the cbc(aes) algorithm, which can not be handled through bulk
> interface, it need to map the data sector by sector.
> If we also handle the cbc(aes) algorithm with bulk interface, we need
> to divide the sg table into sectors and need to allocate request
> memory for each divided sectors (As Mike pointed out  this is in the
> IO mapping
> path and we try to avoid memory allocations at all costs -- due to the
> risk of deadlock when issuing IO to stacked block devices (dm-crypt
> could be part of a much more elaborate IO stack). ), that will
> introduce more messy things I think.

Perhaps I'm not making myself very clear.  If you move the IV
generation into the crypto API, those crypto API algorithms will
be operating at the sector level.

For example, assuming you're doing lmk, then the algorithm would
be called lmk(cbc(aes)) and it will take as its input one or more
sectors and for each sector it should generate an IV and operate
on it.

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt