linux-kernel - Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency

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: <alpine.LRH.2.02.1601122111040.24452@file01.intranet.prod.int.rdu2.redhat.com>
Date:	Tue, 12 Jan 2016 21:13:19 -0500 (EST)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	Mark Brown <broonie@...nel.org>
cc:	device-mapper development <dm-devel@...hat.com>,
	Milan Broz <gmazyland@...il.com>, Jens Axboe <axboe@...nel.dk>,
	keith.busch@...el.com, linux-raid@...r.kernel.org,
	martin.petersen@...cle.com, Mike Snitzer <snitzer@...hat.com>,
	Baolin Wang <baolin.wang@...aro.org>,
	linux-block@...r.kernel.org, neilb@...e.com,
	LKML <linux-kernel@...r.kernel.org>, sagig@...lanox.com,
	Arnd Bergmann <arnd@...db.de>, tj@...nel.org,
	dan.j.williams@...el.com,
	Kent Overstreet <kent.overstreet@...il.com>,
	Alasdair G Kergon <agk@...hat.com>
Subject: Re: [dm-devel] [PATCH v2 0/2] Introduce the bulk IV mode for improving
 the crypto engine efficiency



On Tue, 12 Jan 2016, Mark Brown wrote:

> On Tue, Jan 12, 2016 at 06:31:19PM -0500, Mikulas Patocka wrote:
> > On Mon, 4 Jan 2016, Mark Brown wrote:
> 
> > > The main thing the out of tree req-dm-crypt code is doing was using a
> > > larger block size which does seem like a reasonable thing to allow
> > > people to tune for performance tradeofffs but I undertand that's a lot
> > > harder to achieve in a good way than one might hope.
> 
> > But as Milan pointed out, that larger block size doesn't work if you 
> > process requests with different sizes - the data encrypted with one 
> > request size won't match if you decrypt them with a different request 
> > size.
> 
> Sure, you need to fix that block size.
> 
> > Does the hardware encryption you are optimizing for allow setting 
> > arbitrary tweaks in XTS mode? What is the specific driver you are 
> > optimizing for?
> 
> This isn't targeted at a specific driver or system, it's trying to make
> dm-crypt better able to make use of hardware acceleration in general.

If the hardware acceleration doesn't allow to set arbitrary XTS tweak, 
then this "large block" optimization on XTS can't be done at all.

So, we need to know which driver(s) you want to optimize for and how do 
those driver(s) handle tweak generation.

Mikulas