Add dm-crypt support for larger encryption sector (block) size

[GoogleCodeExporter]

dm-crypt: optionally support encryption block (sector) size (EXPERIMENTAL)

Add "block_size" optional parameter which specifies encryption
sector size (atomic unit of block device encryption).

References
http://www.saout.de/pipermail/dm-crypt/2013-January/003125.html
http://www.saout.de/pipermail/dm-crypt/2013-March/003202.html

Original issue reported on code.google.com by gmazyl...@gmail.com on 10 Mar 2013 at 3:02

[GoogleCodeExporter]

Original comment by gmazyl...@gmail.com on 17 Mar 2013 at 4:32

• Changed title: Add dm-crypt support for larger encryption sector (block) size

[GoogleCodeExporter]

Is that about chaining the 512B blocksizse used by dm-crypt?

Weren't there several potential security issues, when there were big block 
sizes?
I remember some issues and discussions we've had about this, at least with 
respect to XTS.

Cheers,
Chris.

Original comment by calestyo@gmail.com on 28 Jun 2013 at 6:10

[GoogleCodeExporter]

I would be very interested in this. It turns out, there are many embedded-type 
systems with on-board crypto accelerators, that fail to perform adequately when 
given small blocks to work with. Examples include mv_cesa, which is found in so 
many home NASes these days (all the orion/kirkwood boards, at least. This 
includes most of Synology and QNaps offerings)

As an example of the change in performance, here is a measurement of the 
mv_cesa hw crypto (through cryptodev)

[root@zephyr]~/2/openssl-0.9.8o #./apps/openssl speed -evp aes-128-cbc -engine 
cryptodev -elapsed
engine "cryptodev" set.
You have chosen to measure elapsed time instead of user CPU time.
To get the most accurate results, try to run this
program when this computer is idle.
Doing aes-128-cbc for 3s on 256 size blocks: 72677 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 512 size blocks: 64578 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 57081 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 16662 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 9369 aes-128-cbc's in 3.00s
OpenSSL 0.9.8o 01 Jun 2010
built on: Wed Aug 10 20:59:07 CEST 2011
options:bn(64,32) md2(int) rc4(ptr,int) des(idx,risc1,4,long) aes(partial) 
idea(int) blowfish(idx) 
compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHASH_MAX_LEN=64 
-DL_ENDIAN -DTERMIO -O2 -Wa,--noexecstack -g -Wall
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: ftime
The 'numbers' are in 1000s of bytes per second processed.
type            256 bytes    512 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc       6201.77k    11021.31k    19483.65k    45498.37k    51167.23k

As can clearly be seen, you can gain to whole orders of magnitude by going from 
(tiny to large block sizes). I hacked the openssl speed test to use larger 
block sizes (it defaults to test from 16b blocks up to 8k blocks).

On a real-world block size (512), the performance is 18-20 MB/s when used in 
the kernel (through dmcrypt), but only ~11MB/s when used through cryptodev, as 
can be seen here. But even through cryptodev, larger block sizes gain 
performance up to ~50MB/s, which would be fantastic for a dmcrypt-on-a-nas 
setup. Otherwise, we are stuck at about 5-10MB/s for dmcrypt-on-a-nas, which is 
just too slow for being practical in most real-world situations.

I hope this shows how much we are all looking forward to such a patch :)

Is there anything I can do to help? I don't have a lot of experience with 
kernel development, but a lot of programming experience in general. I'm happy 
to test patches of any kind.

Original comment by chriv...@gmail.com on 7 Nov 2013 at 11:32