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: <alpine.LRH.2.02.1601130816560.11671@file01.intranet.prod.int.rdu2.redhat.com>
Date:	Wed, 13 Jan 2016 10:00:21 -0500 (EST)
From:	Mikulas Patocka <mpatocka@...hat.com>
To:	Arnd Bergmann <arnd@...db.de>
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 Wed, 13 Jan 2016, Arnd Bergmann wrote:

> 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

Ext2 is not doing sub-block writes.

Generally, disks and SSDs do not guarantee 4k write atomicity (only disks 
with hardware 4k sector guarantee it).

For example, ext2 writes a full 4k block, only part of the block is 
written to the disk and then power failure happens. On the next reboot CBC 
will corrupt the unwritten part of the 4k block.

Mikulas

> 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
>