linux-stable.git/drivers/md/dm-crypt.c, branch v3.0

Merge git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm

2011-03-26T03:51:44+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm:
  dm stripe: implement merge method
  dm mpath: allow table load with no priority groups
  dm mpath: fail message ioctl if specified path is not valid
  dm ioctl: add flag to wipe buffers for secure data
  dm ioctl: prepare for crypt key wiping
  dm crypt: wipe keys string immediately after key is set
  dm: add flakey target
  dm: fix opening log and cow devices for read only tables

dm crypt: wipe keys string immediately after key is set

2011-03-24T13:54:27+00:00

Always wipe the original copy of the key after processing it
in crypt_set_key().

Signed-off-by: Milan Broz 
Acked-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon

block: remove per-queue plugging

2011-03-10T07:52:07+00:00

Code has been converted over to the new explicit on-stack plugging,
and delay users have been converted to use the new API for that.
So lets kill off the old plugging along with aops->sync_page().

Signed-off-by: Jens Axboe

dm crypt: add loop aes iv generator

2011-01-13T19:59:55+00:00

This patch adds a compatible implementation of the block
chaining mode used by the Loop-AES block device encryption
system (http://loop-aes.sourceforge.net/) designed
by Jari Ruusu.

It operates on full 512 byte sectors and uses CBC
with an IV derived from the sector number, the data and
optionally extra IV seed.

This means that after CBC decryption the first block of sector
must be tweaked according to decrypted data.

Loop-AES can use three encryption schemes:
 version 1: is plain aes-cbc mode (already compatible)
 version 2: uses 64 multikey scheme with own IV generator
 version 3: the same as version 2 with additional IV seed
            (it uses 65 keys, last key is used as IV seed)

The IV generator is here named lmk (Loop-AES multikey)
and for the cipher specification looks like: aes:64-cbc-lmk

Version 2 and 3 is recognised according to length
of provided multi-key string (which is just hexa encoded
"raw key" used in original Loop-AES ioctl).

Configuration of the device and decoding key string will
be done in userspace (cryptsetup).
(Loop-AES stores keys in gpg encrypted file, raw keys are
output of simple hashing of lines in this file).

Based on an implementation by Max Vozeler:
  http://article.gmane.org/gmane.linux.kernel.cryptoapi/3752/

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon 
CC: Max Vozeler

dm crypt: add multi key capability

2011-01-13T19:59:54+00:00

This patch adds generic multikey handling to be used
in following patch for Loop-AES mode compatibility.

This patch extends mapping table to optional keycount and
implements generic multi-key capability.

With more keys defined the  string is divided into
several  sections and these are used for tfms.

The tfm is used according to sector offset
(sector 0->tfm[0], sector 1->tfm[1], sector N->tfm[N modulo keycount])
(only power of two values supported for keycount here).

Because of tfms per-cpu allocation, this mode can be take
a lot of memory on large smp systems.

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon 
Cc: Max Vozeler

dm crypt: add post iv call to iv generator

2011-01-13T19:59:54+00:00

IV (initialisation vector) can in principle depend not only
on sector but also on plaintext data (or other attributes).

Change IV generator interface to work directly with dmreq
structure to allow such dependence in generator.

Also add post() function which is called after the crypto
operation.

This allows tricky modification of decrypted data or IV
internals.

In asynchronous mode the post() can be called after
ctx->sector count was increased so it is needed
to add iv_sector copy directly to dmreq structure.
(N.B. dmreq always include only one sector in scatterlists)

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon

dm crypt: use io thread for reads only if mempool exhausted

2011-01-13T19:59:53+00:00

If there is enough memory, code can directly submit bio
instead queing this operation in separate thread.

Try to alloc bio clone with GFP_NOWAIT and only if it
fails use separate queue (map function cannot block here).

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon

dm crypt: scale to multiple cpus

2011-01-13T19:59:53+00:00

Currently dm-crypt does all the encryption work for a single dm-crypt
mapping in a single workqueue. This does not scale well when multiple
CPUs are submitting IO at a high rate. The single CPU running the single
thread cannot keep up with the encryption and encrypted IO performance
tanks.

This patch changes the crypto workqueue to be per CPU. This means
that as long as the IO submitter (or the interrupt target CPUs
for reads) runs on different CPUs the encryption work will be also
parallel.

To avoid a bottleneck on the IO worker I also changed those to be
per-CPU threads.

There is still some shared data, so I suspect some bouncing
cache lines. But I haven't done a detailed study on that yet.

Signed-off-by: Andi Kleen 
Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon

dm crypt: simplify compatible table output

2011-01-13T19:59:52+00:00

Rename cc->cipher_mode to cc->cipher_string and store the whole of the cipher
information so it can easily be printed when processing the DM_DEV_STATUS ioctl.

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon

dm crypt: set key size early

2011-01-13T19:59:49+00:00

Simplify key size verification (hexadecimal string) and
set key size early in constructor.

(Patch required by later changes.)

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon