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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <49336038.lhIkHu2mkF@wuerfel>
Date:	Wed, 13 Jan 2016 11:17:04 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Mikulas Patocka <mpatocka@...hat.com>
Cc:	device-mapper development <dm-devel@...hat.com>,
	Mark Brown <broonie@...nel.org>,
	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,
	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 Tuesday 12 January 2016 21:18:12 Mikulas Patocka wrote:
> On Wed, 13 Jan 2016, Arnd Bergmann wrote:
> 
> > On Tuesday 12 January 2016 18:31:19 Mikulas Patocka wrote:
> > > 
> > > Another possibility is to use dm-crypt block size 4k and use a filesystem 
> > > with 4k blocksize on it (it will never send requests not aligned on 4k 
> > > boundary, so we could reject such requests with an error).
> > 
> > Is there ever a reason to use something other than 4K block size on
> > dm-crypt?
> > 
> >       Arnd
> 
> You can't use 4k block on CBC (and most other encryption modes). If only a 
> part of 4k block is written (and then system crash happens), CBC would 
> corrupt the block completely.
> 
> For example, suppose that EXT2 directory block is updated, the first 
> 512-byte sector is written and the rest of the sectors is not written 
> because of a crash. CBC would corrupt all sectors except the first one in 
> this case.
> 
> You could use 4k block on XTS and ECB.

Ah, I did not know that ext2 was doing sub-block writes. This may be
something to address in the ext4 code (and other file systems), as
a lot of flash storage devices (SD cards and eMMC) get really slow
when you do writes smaller than 4K because of the internal
read-modify-write cycle. Ideally you want to always drive those
using 64K writes (for reads, it doesn't matter much).

For hard drives, there are still a couple of older models that have
native 512 byte sectors, but the majority of new drivers also
prefers 4K writes. SSDs are typically optimized for 4K writes because
that is what they expect software to do, but they use larger writes
internally.

	Arnd