linux-toradex.git/drivers/md/dm-crypt.c, branch v3.14.34

dm crypt: use memzero_explicit for on-stack buffer

2015-01-08T18:00:48+00:00

commit 1a71d6ffe18c0d0f03fc8531949cc8ed41d702ee upstream.

Use memzero_explicit to cleanup sensitive data allocated on stack
to prevent the compiler from optimizing and removing memset() calls.

Signed-off-by: Milan Broz 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

dm crypt: fix access beyond the end of allocated space

2014-10-05T21:52:19+00:00

commit d49ec52ff6ddcda178fc2476a109cf1bd1fa19ed upstream.

The DM crypt target accesses memory beyond allocated space resulting in
a crash on 32 bit x86 systems.

This bug is very old (it dates back to 2.6.25 commit 3a7f6c990ad04 "dm
crypt: use async crypto").  However, this bug was masked by the fact
that kmalloc rounds the size up to the next power of two.  This bug
wasn't exposed until 3.17-rc1 commit 298a9fa08a ("dm crypt: use per-bio
data").  By switching to using per-bio data there was no longer any
padding beyond the end of a dm-crypt allocated memory block.

To minimize allocation overhead dm-crypt puts several structures into one
block allocated with kmalloc.  The block holds struct ablkcipher_request,
cipher-specific scratch pad (crypto_ablkcipher_reqsize(any_tfm(cc))),
struct dm_crypt_request and an initialization vector.

The variable dmreq_start is set to offset of struct dm_crypt_request
within this memory block.  dm-crypt allocates the block with this size:
cc->dmreq_start + sizeof(struct dm_crypt_request) + cc->iv_size.

When accessing the initialization vector, dm-crypt uses the function
iv_of_dmreq, which performs this calculation: ALIGN((unsigned long)(dmreq
+ 1), crypto_ablkcipher_alignmask(any_tfm(cc)) + 1).

dm-crypt allocated "cc->iv_size" bytes beyond the end of dm_crypt_request
structure.  However, when dm-crypt accesses the initialization vector, it
takes a pointer to the end of dm_crypt_request, aligns it, and then uses
it as the initialization vector.  If the end of dm_crypt_request is not
aligned on a crypto_ablkcipher_alignmask(any_tfm(cc)) boundary the
alignment causes the initialization vector to point beyond the allocated
space.

Fix this bug by calculating the variable iv_size_padding and adding it
to the allocated size.

Also correct the alignment of dm_crypt_request.  struct dm_crypt_request
is specific to dm-crypt (it isn't used by the crypto subsystem at all),
so it is aligned on __alignof__(struct dm_crypt_request).

Also align per_bio_data_size on ARCH_KMALLOC_MINALIGN, so that it is
aligned as if the block was allocated with kmalloc.

Reported-by: Krzysztof Kolasa 
Tested-by: Milan Broz 
Signed-off-by: Mikulas Patocka 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

dm crypt: fix cpu hotplug crash by removing per-cpu structure

2014-06-07T17:28:25+00:00

commit 610f2de3559c383caf8fbbf91e9968102dff7ca0 upstream.

The DM crypt target used per-cpu structures to hold pointers to a
ablkcipher_request structure.  The code assumed that the work item keeps
executing on a single CPU, so it didn't use synchronization when
accessing this structure.

If a CPU is disabled by writing 0 to /sys/devices/system/cpu/cpu*/online,
the work item could be moved to another CPU.  This causes dm-crypt
crashes, like the following, because the code starts using an incorrect
ablkcipher_request:

 smpboot: CPU 7 is now offline
 BUG: unable to handle kernel NULL pointer dereference at 0000000000000130
 IP: [] crypt_convert+0x12d/0x3c0 [dm_crypt]
 ...
 Call Trace:
  [] ? kcryptd_crypt+0x305/0x470 [dm_crypt]
  [] ? finish_task_switch+0x40/0xc0
  [] ? process_one_work+0x168/0x470
  [] ? worker_thread+0x10b/0x390
  [] ? manage_workers.isra.26+0x290/0x290
  [] ? kthread+0xaf/0xc0
  [] ? kthread_create_on_node+0x120/0x120
  [] ? ret_from_fork+0x7c/0xb0
  [] ? kthread_create_on_node+0x120/0x120

Fix this bug by removing the per-cpu definition.  The structure
ablkcipher_request is accessed via a pointer from convert_context.
Consequently, if the work item is rescheduled to a different CPU, the
thread still uses the same ablkcipher_request.

This change may undermine performance improvements intended by commit
c0297721 ("dm crypt: scale to multiple cpus") on select hardware.  In
practice no performance difference was observed on recent hardware.  But
regardless, correctness is more important than performance.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman

block: Convert drivers to immutable biovecs

2013-11-24T06:33:51+00:00

Now that we've got a mechanism for immutable biovecs -
bi_iter.bi_bvec_done - we need to convert drivers to use primitives that
respect it instead of using the bvec array directly.

Signed-off-by: Kent Overstreet 
Cc: Jens Axboe 
Cc: NeilBrown 
Cc: Alasdair Kergon 
Cc: dm-devel@redhat.com

block: Abstract out bvec iterator

2013-11-24T06:33:47+00:00

Immutable biovecs are going to require an explicit iterator. To
implement immutable bvecs, a later patch is going to add a bi_bvec_done
member to this struct; for now, this patch effectively just renames
things.

Signed-off-by: Kent Overstreet 
Cc: Jens Axboe 
Cc: Geert Uytterhoeven 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: "Ed L. Cashin" 
Cc: Nick Piggin 
Cc: Lars Ellenberg 
Cc: Jiri Kosina 
Cc: Matthew Wilcox 
Cc: Geoff Levand 
Cc: Yehuda Sadeh 
Cc: Sage Weil 
Cc: Alex Elder 
Cc: ceph-devel@vger.kernel.org
Cc: Joshua Morris 
Cc: Philip Kelleher 
Cc: Rusty Russell 
Cc: "Michael S. Tsirkin" 
Cc: Konrad Rzeszutek Wilk 
Cc: Jeremy Fitzhardinge 
Cc: Neil Brown 
Cc: Alasdair Kergon 
Cc: Mike Snitzer 
Cc: dm-devel@redhat.com
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: linux390@de.ibm.com
Cc: Boaz Harrosh 
Cc: Benny Halevy 
Cc: "James E.J. Bottomley" 
Cc: Greg Kroah-Hartman 
Cc: "Nicholas A. Bellinger" 
Cc: Alexander Viro 
Cc: Chris Mason 
Cc: "Theodore Ts'o" 
Cc: Andreas Dilger 
Cc: Jaegeuk Kim 
Cc: Steven Whitehouse 
Cc: Dave Kleikamp 
Cc: Joern Engel 
Cc: Prasad Joshi 
Cc: Trond Myklebust 
Cc: KONISHI Ryusuke 
Cc: Mark Fasheh 
Cc: Joel Becker 
Cc: Ben Myers 
Cc: xfs@oss.sgi.com
Cc: Steven Rostedt 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: "Rafael J. Wysocki" 
Cc: Herton Ronaldo Krzesinski 
Cc: Ben Hutchings 
Cc: Andrew Morton 
Cc: Guo Chao 
Cc: Tejun Heo 
Cc: Asai Thambi S P 
Cc: Selvan Mani 
Cc: Sam Bradshaw 
Cc: Wei Yongjun 
Cc: "Roger Pau Monné" 
Cc: Jan Beulich 
Cc: Stefano Stabellini 
Cc: Ian Campbell 
Cc: Sebastian Ott 
Cc: Christian Borntraeger 
Cc: Minchan Kim 
Cc: Jiang Liu 
Cc: Nitin Gupta 
Cc: Jerome Marchand 
Cc: Joe Perches 
Cc: Peng Tao 
Cc: Andy Adamson 
Cc: fanchaoting 
Cc: Jie Liu 
Cc: Sunil Mushran 
Cc: "Martin K. Petersen" 
Cc: Namjae Jeon 
Cc: Pankaj Kumar 
Cc: Dan Magenheimer 
Cc: Mel Gorman 6

tree-wide: use reinit_completion instead of INIT_COMPLETION

2013-11-15T00:32:21+00:00

Use this new function to make code more comprehensible, since we are
reinitialzing the completion, not initializing.

[akpm@linux-foundation.org: linux-next resyncs]
Signed-off-by: Wolfram Sang 
Acked-by: Linus Walleij  (personally at LCE13)
Cc: Ingo Molnar 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dm crypt: add TCW IV mode for old CBC TCRYPT containers

2013-11-09T23:20:20+00:00

dm-crypt can already activate TCRYPT (TrueCrypt compatible) containers
in LRW or XTS block encryption mode.

TCRYPT containers prior to version 4.1 use CBC mode with some additional
tweaks, this patch adds support for these containers.

This new mode is implemented using special IV generator named TCW
(TrueCrypt IV with whitening).  TCW IV only supports containers that are
encrypted with one cipher (Tested with AES, Twofish, Serpent, CAST5 and
TripleDES).

While this mode is legacy and is known to be vulnerable to some
watermarking attacks (e.g. revealing of hidden disk existence) it can
still be useful to activate old containers without using 3rd party
software or for independent forensic analysis of such containers.

(Both the userspace and kernel code is an independent implementation
based on the format documentation and it completely avoids use of
original source code.)

The TCW IV generator uses two additional keys: Kw (whitening seed, size
is always 16 bytes - TCW_WHITENING_SIZE) and Kiv (IV seed, size is
always the IV size of the selected cipher).  These keys are concatenated
at the end of the main encryption key provided in mapping table.

While whitening is completely independent from IV, it is implemented
inside IV generator for simplification.

The whitening value is always 16 bytes long and is calculated per sector
from provided Kw as initial seed, xored with sector number and mixed
with CRC32 algorithm.  Resulting value is xored with ciphertext sector
content.

IV is calculated from the provided Kiv as initial IV seed and xored with
sector number.

Detailed calculation can be found in the Truecrypt documentation for
version < 4.1 and will also be described on dm-crypt site, see:
http://code.google.com/p/cryptsetup/wiki/DMCrypt

The experimental support for activation of these containers is already
present in git devel brach of cryptsetup.

Signed-off-by: Milan Broz 
Signed-off-by: Mike Snitzer

dm crypt: properly handle extra key string in initialization

2013-11-09T23:20:20+00:00

Some encryption modes use extra keys (e.g. loopAES has IV seed) which
are not used in block cipher initialization but are part of key string
in table constructor.

This patch adds an additional field which describes the length of the
extra key(s) and substracts it before real key encryption setting.

The key_size always includes the size, in bytes, of the key provided
in mapping table.

The key_parts describes how many parts (usually keys) are contained in
the whole key buffer.  And key_extra_size contains size in bytes of
additional keys part (this number of bytes must be subtracted because it
is processed by the IV generator).

| K1 | K2 | .... | K64 |      Kiv       |
|----------- key_size ----------------- |
|                      |-key_extra_size-|
|     [64 keys]        |  [1 key]       | => key_parts = 65

Example where key string contains main key K, whitening key
Kw and IV seed Kiv:

|     K       |   Kiv   |       Kw      |
|--------------- key_size --------------|
|             |-----key_extra_size------|
|  [1 key]    | [1 key] |     [1 key]   | => key_parts = 3

Because key_extra_size is calculated during IV mode setting, key
initialization is moved after this step.

For now, this change has no effect to supported modes (thanks to ilog2
rounding) but it is required by the following patch.

Also, fix a sparse warning in crypt_iv_lmk_one().

Signed-off-by: Milan Broz 
Signed-off-by: Mike Snitzer

dm: stop using WQ_NON_REENTRANT

2013-08-23T13:02:13+00:00

dbf2576e37 ("workqueue: make all workqueues non-reentrant") made
WQ_NON_REENTRANT no-op and the flag is going away.  Remove its usages.

This patch doesn't introduce any behavior changes.

Signed-off-by: Tejun Heo 
Signed-off-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Acked-by: Joe Thornber

block: Convert some code to bio_for_each_segment_all()

2013-03-23T21:26:30+00:00

More prep work for immutable bvecs:

A few places in the code were either open coding or using the wrong
version - fix.

After we introduce the bvec iter, it'll no longer be possible to modify
the biovec through bio_for_each_segment_all() - it doesn't increment a
pointer to the current bvec, you pass in a struct bio_vec (not a
pointer) which is updated with what the current biovec would be (taking
into account bi_bvec_done and bi_size).

So because of that it's more worthwhile to be consistent about
bio_for_each_segment()/bio_for_each_segment_all() usage.

Signed-off-by: Kent Overstreet 
CC: Jens Axboe 
CC: NeilBrown 
CC: Alasdair Kergon 
CC: dm-devel@redhat.com
CC: Alexander Viro