linux-toradex.git/fs/ecryptfs/keystore.c, branch v2.6.37.2

ecryptfs: added ecryptfs_mount_auth_tok_only mount parameter

2010-10-29T15:31:36+00:00

This patch adds a new mount parameter 'ecryptfs_mount_auth_tok_only' to
force ecryptfs to use only authentication tokens which signature has
been specified at mount time with parameters 'ecryptfs_sig' and
'ecryptfs_fnek_sig'. In this way, after disabling the passthrough and
the encrypted view modes, it's possible to make available to users only
files encrypted with the specified authentication token.

Signed-off-by: Roberto Sassu 
Cc: Dustin Kirkland 
Cc: James Morris 
[Tyler: Clean up coding style errors found by checkpatch]
Signed-off-by: Tyler Hicks

ecryptfs: checking return code of ecryptfs_find_auth_tok_for_sig()

2010-10-29T15:31:36+00:00

This patch replaces the check of the 'matching_auth_tok' pointer with
the exit status of ecryptfs_find_auth_tok_for_sig().
This avoids to use authentication tokens obtained through the function
ecryptfs_keyring_auth_tok_for_sig which are not valid.

Signed-off-by: Roberto Sassu 
Cc: Dustin Kirkland 
Cc: James Morris 
Signed-off-by: Tyler Hicks

ecryptfs: release keys loaded in ecryptfs_keyring_auth_tok_for_sig()

2010-10-29T15:31:35+00:00

This patch allows keys requested in the function
ecryptfs_keyring_auth_tok_for_sig()to be released when they are no
longer required. In particular keys are directly released in the same
function if the obtained authentication token is not valid.

Further, a new function parameter 'auth_tok_key' has been added to
ecryptfs_find_auth_tok_for_sig() in order to provide callers the key
pointer to be passed to key_put().

Signed-off-by: Roberto Sassu 
Cc: Dustin Kirkland 
Cc: James Morris 
[Tyler: Initialize auth_tok_key to NULL in ecryptfs_parse_packet_set]
Signed-off-by: Tyler Hicks

fs/ecryptfs: Return -ENOMEM on memory allocation failure

2010-08-27T15:50:52+00:00

In this code, 0 is returned on memory allocation failure, even though other
failures return -ENOMEM or other similar values.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
@@
expression ret;
expression x,e1,e2,e3;
@@

ret = 0
... when != ret = e1
*x = \(kmalloc\|kcalloc\|kzalloc\)(...)
... when != ret = e2
if (x == NULL) { ... when != ret = e3
  return ret;
}
// 

Signed-off-by: Julia Lawall 
Signed-off-by: Tyler Hicks

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

2010-03-30T13:02:32+00:00

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.

Signed-off-by: Tejun Heo 
Guess-its-ok-by: Christoph Lameter 
Cc: Ingo Molnar 
Cc: Lee Schermerhorn

eCryptfs: Validate global auth tok keys

2009-09-23T14:10:32+00:00

When searching through the global authentication tokens for a given key
signature, verify that a matching key has not been revoked and has not
expired.  This allows the `keyctl revoke` command to be properly used on
keys in use by eCryptfs.

Acked-by: Serge Hallyn 
Cc: ecryptfs-devel@lists.launchpad.net
Cc: stable 
Signed-off-by: Tyler Hicks

eCryptfs: Filename encryption only supports password auth tokens

2009-09-23T14:10:32+00:00

Returns -ENOTSUPP when attempting to use filename encryption with
something other than a password authentication token, such as a private
token from openssl.  Using filename encryption with a userspace eCryptfs
key module is a future goal.  Until then, this patch handles the
situation a little better than simply using a BUG_ON().

Acked-by: Serge Hallyn 
Cc: ecryptfs-devel@lists.launchpad.net
Cc: stable 
Signed-off-by: Tyler Hicks

eCryptfs: Handle unrecognized tag 3 cipher codes

2009-09-23T14:10:31+00:00

Returns an error when an unrecognized cipher code is present in a tag 3
packet or an ecryptfs_crypt_stat cannot be initialized.  Also sets an
crypt_stat->tfm error pointer to NULL to ensure that it will not be
incorrectly freed in ecryptfs_destroy_crypt_stat().

Acked-by: Serge Hallyn 
Cc: ecryptfs-devel@lists.launchpad.net
Cc: stable 
Signed-off-by: Tyler Hicks

eCryptfs: Fix lockdep-reported AB-BA mutex issue

2009-09-23T14:10:30+00:00

Lockdep reports the following valid-looking possible AB-BA deadlock with
global_auth_tok_list_mutex and keysig_list_mutex:

  ecryptfs_new_file_context() ->
      ecryptfs_copy_mount_wide_sigs_to_inode_sigs() ->
          mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex);
          -> ecryptfs_add_keysig() ->
              mutex_lock(&crypt_stat->keysig_list_mutex);

vs

  ecryptfs_generate_key_packet_set() ->
      mutex_lock(&crypt_stat->keysig_list_mutex);
      -> ecryptfs_find_global_auth_tok_for_sig() ->
          mutex_lock(&mount_crypt_stat->global_auth_tok_list_mutex);

ie the two mutexes are taken in opposite orders in the two different
code paths.  I'm not sure if this is a real bug where two threads could
actually hit the two paths in parallel and deadlock, but it at least
makes lockdep impossible to use with ecryptfs since this report triggers
every time and disables future lockdep reporting.

Since ecryptfs_add_keysig() is called only from the single callsite in
ecryptfs_copy_mount_wide_sigs_to_inode_sigs(), the simplest fix seems to
be to move the lock of keysig_list_mutex back up outside of the where
global_auth_tok_list_mutex is taken.  This patch does that, and fixes
the lockdep report on my system (and ecryptfs still works OK).

The full output of lockdep fixed by this patch is:

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.31-2-generic #14~rbd2
-------------------------------------------------------
gdm/2640 is trying to acquire lock:
 (&mount_crypt_stat->global_auth_tok_list_mutex){+.+.+.}, at: [] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90

but task is already holding lock:
 (&crypt_stat->keysig_list_mutex){+.+.+.}, at: [] ecryptfs_generate_key_packet_set+0x58/0x2b0

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&crypt_stat->keysig_list_mutex){+.+.+.}:
       [] check_prev_add+0x2a7/0x370
       [] validate_chain+0x661/0x750
       [] __lock_acquire+0x237/0x430
       [] lock_acquire+0xa5/0x150
       [] __mutex_lock_common+0x4d/0x3d0
       [] mutex_lock_nested+0x46/0x60
       [] ecryptfs_add_keysig+0x5a/0xb0
       [] ecryptfs_copy_mount_wide_sigs_to_inode_sigs+0x59/0xb0
       [] ecryptfs_new_file_context+0xa6/0x1a0
       [] ecryptfs_initialize_file+0x4a/0x140
       [] ecryptfs_create+0x2d/0x60
       [] vfs_create+0xb4/0xe0
       [] __open_namei_create+0xc4/0x110
       [] do_filp_open+0xa01/0xae0
       [] do_sys_open+0x69/0x140
       [] sys_open+0x20/0x30
       [] system_call_fastpath+0x16/0x1b
       [] 0xffffffffffffffff

-> #0 (&mount_crypt_stat->global_auth_tok_list_mutex){+.+.+.}:
       [] check_prev_add+0x85/0x370
       [] validate_chain+0x661/0x750
       [] __lock_acquire+0x237/0x430
       [] lock_acquire+0xa5/0x150
       [] __mutex_lock_common+0x4d/0x3d0
       [] mutex_lock_nested+0x46/0x60
       [] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
       [] ecryptfs_generate_key_packet_set+0x105/0x2b0
       [] ecryptfs_write_headers_virt+0xc9/0x120
       [] ecryptfs_write_metadata+0xcd/0x200
       [] ecryptfs_initialize_file+0x6b/0x140
       [] ecryptfs_create+0x2d/0x60
       [] vfs_create+0xb4/0xe0
       [] __open_namei_create+0xc4/0x110
       [] do_filp_open+0xa01/0xae0
       [] do_sys_open+0x69/0x140
       [] sys_open+0x20/0x30
       [] system_call_fastpath+0x16/0x1b
       [] 0xffffffffffffffff

other info that might help us debug this:

2 locks held by gdm/2640:
 #0:  (&sb->s_type->i_mutex_key#11){+.+.+.}, at: [] do_filp_open+0x3cb/0xae0
 #1:  (&crypt_stat->keysig_list_mutex){+.+.+.}, at: [] ecryptfs_generate_key_packet_set+0x58/0x2b0

stack backtrace:
Pid: 2640, comm: gdm Tainted: G         C 2.6.31-2-generic #14~rbd2
Call Trace:
 [] print_circular_bug_tail+0xa8/0xf0
 [] check_prev_add+0x85/0x370
 [] ? __module_text_address+0x12/0x60
 [] validate_chain+0x661/0x750
 [] ? print_context_stack+0x85/0x140
 [] ? find_usage_backwards+0x38/0x160
 [] __lock_acquire+0x237/0x430
 [] lock_acquire+0xa5/0x150
 [] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
 [] ? check_usage_backwards+0x0/0xb0
 [] __mutex_lock_common+0x4d/0x3d0
 [] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
 [] ? ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
 [] ? mark_held_locks+0x6c/0xa0
 [] ? kmem_cache_alloc+0xfd/0x1a0
 [] ? trace_hardirqs_on_caller+0x14d/0x190
 [] mutex_lock_nested+0x46/0x60
 [] ecryptfs_find_global_auth_tok_for_sig+0x2e/0x90
 [] ecryptfs_generate_key_packet_set+0x105/0x2b0
 [] ecryptfs_write_headers_virt+0xc9/0x120
 [] ecryptfs_write_metadata+0xcd/0x200
 [] ? ecryptfs_init_persistent_file+0x60/0xe0
 [] ecryptfs_initialize_file+0x6b/0x140
 [] ecryptfs_create+0x2d/0x60
 [] vfs_create+0xb4/0xe0
 [] __open_namei_create+0xc4/0x110
 [] do_filp_open+0xa01/0xae0
 [] ? _raw_spin_unlock+0x5e/0xb0
 [] ? _spin_unlock+0x2b/0x40
 [] ? getname+0x3b/0x240
 [] ? alloc_fd+0xfa/0x140
 [] do_sys_open+0x69/0x140
 [] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [] sys_open+0x20/0x30
 [] system_call_fastpath+0x16/0x1b

Signed-off-by: Roland Dreier 
Signed-off-by: Tyler Hicks

eCryptfs: parse_tag_3_packet check tag 3 packet encrypted key size

2009-07-28T21:26:06+00:00

The parse_tag_3_packet function does not check if the tag 3 packet contains a
encrypted key size larger than ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES.

Signed-off-by: Ramon de Carvalho Valle 
[tyhicks@linux.vnet.ibm.com: Added printk newline and changed goto to out_free]
Signed-off-by: Tyler Hicks 
Cc: stable@kernel.org (2.6.27 and 30)
Signed-off-by: Linus Torvalds