linux.git/fs/ecryptfs/crypto.c, branch v2.6.32

eCryptfs: Propagate vfs_read and vfs_write return codes

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

Errors returned from vfs_read() and vfs_write() calls to the lower
filesystem were being masked as -EINVAL.  This caused some confusion to
users who saw EINVAL instead of ENOSPC when the disk was full, for
instance.

Also, the actual bytes read or written were not accessible by callers to
ecryptfs_read_lower() and ecryptfs_write_lower(), which may be useful in
some cases.  This patch updates the error handling logic where those
functions are called in order to accept positive return codes indicating
success.

Cc: Eric Sandeen 
Acked-by: Serge Hallyn 
Cc: ecryptfs-devel@lists.launchpad.net
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: improved dependency checking and reporting

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

So, I compiled a 2.6.31-rc5 kernel with ecryptfs and loaded its module.
When it came time to mount my filesystem, I got this in dmesg, and it
refused to mount:

[93577.776637] Unable to allocate crypto cipher with name [aes]; rc = [-2]
[93577.783280] Error attempting to initialize key TFM cipher with name = [aes]; rc = [-2]
[93577.791183] Error attempting to initialize cipher with name = [aes] and key size = [32]; rc = [-2]
[93577.800113] Error parsing options; rc = [-22]

I figured from the error message that I'd either forgotten to load "aes"
or that my key size was bogus.  Neither one of those was the case.  In
fact, I was missing the CRYPTO_ECB config option and the 'ecb' module.
Unfortunately, there's no trace of 'ecb' in that error message.

I've done two things to fix this.  First, I've modified ecryptfs's
Kconfig entry to select CRYPTO_ECB and CRYPTO_CBC.  I also took CRYPTO
out of the dependencies since the 'select' will take care of it for us.

I've also modified the error messages to print a string that should
contain both 'ecb' and 'aes' in my error case.  That will give any
future users a chance of finding the right modules and Kconfig options.

I also wonder if we should:

	select CRYPTO_AES if !EMBEDDED

since I think most ecryptfs users are using AES like me.

Cc: ecryptfs-devel@lists.launchpad.net
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Dustin Kirkland 
Signed-off-by: Dave Hansen 
[tyhicks@linux.vnet.ibm.com: Removed extra newline, 80-char violation]
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: Remove unneeded locking that triggers lockdep false positives

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

In ecryptfs_destroy_inode(), inode_info->lower_file_mutex is locked,
and just after the mutex is unlocked, the code does:

 	kmem_cache_free(ecryptfs_inode_info_cache, inode_info);

This means that if another context could possibly try to take the same
mutex as ecryptfs_destroy_inode(), then it could end up getting the
mutex just before the data structure containing the mutex is freed.
So any such use would be an obvious use-after-free bug (catchable with
slab poisoning or mutex debugging), and therefore the locking in
ecryptfs_destroy_inode() is not needed and can be dropped.

Similarly, in ecryptfs_destroy_crypt_stat(), crypt_stat->keysig_list_mutex
is locked, and then the mutex is unlocked just before the code does:

 	memset(crypt_stat, 0, sizeof(struct ecryptfs_crypt_stat));

Therefore taking this mutex is similarly not necessary.

Removing this locking fixes false-positive lockdep reports such as the
following (and they are false-positives for exactly the same reason
that the locking is not needed):

=================================
[ INFO: inconsistent lock state ]
2.6.31-2-generic #14~rbd3
---------------------------------
inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
kswapd0/323 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (&inode_info->lower_file_mutex){+.+.?.}, at: [] ecryptfs_destroy_inode+0x34/0x100
{RECLAIM_FS-ON-W} state was registered at:
  [] mark_held_locks+0x6c/0xa0
  [] lockdep_trace_alloc+0xaf/0xe0
  [] kmem_cache_alloc+0x41/0x1a0
  [] get_empty_filp+0x7a/0x1a0
  [] dentry_open+0x36/0xc0
  [] ecryptfs_privileged_open+0x5c/0x2e0
  [] ecryptfs_init_persistent_file+0xa3/0xe0
  [] ecryptfs_lookup_and_interpose_lower+0x278/0x380
  [] ecryptfs_lookup+0x12a/0x250
  [] real_lookup+0xea/0x160
  [] do_lookup+0xb8/0xf0
  [] __link_path_walk+0x518/0x870
  [] path_walk+0x5c/0xc0
  [] do_path_lookup+0x5b/0xa0
  [] user_path_at+0x57/0xa0
  [] vfs_fstatat+0x3c/0x80
  [] vfs_stat+0x1b/0x20
  [] sys_newstat+0x24/0x50
  [] system_call_fastpath+0x16/0x1b
  [] 0xffffffffffffffff
irq event stamp: 7811
hardirqs last  enabled at (7811): [] call_rcu+0x5f/0x90
hardirqs last disabled at (7810): [] call_rcu+0x33/0x90
softirqs last  enabled at (3764): [] __do_softirq+0x14a/0x220
softirqs last disabled at (3751): [] call_softirq+0x1c/0x30

other info that might help us debug this:
2 locks held by kswapd0/323:
 #0:  (shrinker_rwsem){++++..}, at: [] shrink_slab+0x3d/0x190
 #1:  (&type->s_umount_key#35){.+.+..}, at: [] prune_dcache+0xd1/0x1b0

stack backtrace:
Pid: 323, comm: kswapd0 Tainted: G         C 2.6.31-2-generic #14~rbd3
Call Trace:
 [] print_usage_bug+0x18c/0x1a0
 [] ? check_usage_forwards+0x0/0xc0
 [] mark_lock_irq+0xf2/0x280
 [] mark_lock+0x137/0x1d0
 [] ? fsnotify_clear_marks_by_inode+0x30/0xf0
 [] mark_irqflags+0xc6/0x1a0
 [] __lock_acquire+0x287/0x430
 [] lock_acquire+0xa5/0x150
 [] ? ecryptfs_destroy_inode+0x34/0x100
 [] ? __lock_acquire+0x237/0x430
 [] __mutex_lock_common+0x4d/0x3d0
 [] ? ecryptfs_destroy_inode+0x34/0x100
 [] ? fsnotify_clear_marks_by_inode+0x30/0xf0
 [] ? ecryptfs_destroy_inode+0x34/0x100
 [] ? _raw_spin_unlock+0x5e/0xb0
 [] mutex_lock_nested+0x46/0x60
 [] ecryptfs_destroy_inode+0x34/0x100
 [] destroy_inode+0x87/0xd0
 [] generic_delete_inode+0x12c/0x1a0
 [] iput+0x62/0x70
 [] dentry_iput+0x98/0x110
 [] d_kill+0x50/0x80
 [] prune_one_dentry+0xa3/0xc0
 [] __shrink_dcache_sb+0x271/0x290
 [] prune_dcache+0x109/0x1b0
 [] shrink_dcache_memory+0x3f/0x50
 [] shrink_slab+0x12d/0x190
 [] balance_pgdat+0x4d7/0x640
 [] ? finish_task_switch+0x40/0x150
 [] ? isolate_pages_global+0x0/0x60
 [] kswapd+0x117/0x170
 [] ? autoremove_wake_function+0x0/0x40
 [] ? kswapd+0x0/0x170
 [] kthread+0x9e/0xb0
 [] child_rip+0xa/0x20
 [] ? restore_args+0x0/0x30
 [] ? kthread+0x0/0xb0
 [] ? child_rip+0x0/0x20

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

eCryptfs: Fix data corruption when using ecryptfs_passthrough

2009-04-22T08:54:13+00:00

ecryptfs_passthrough is a mount option that allows eCryptfs to allow
data to be written to non-eCryptfs files in the lower filesystem.  The
passthrough option was causing data corruption due to it not always
being treated as a non-eCryptfs file.

The first 8 bytes of an eCryptfs file contains the decrypted file size.
This value was being written to the non-eCryptfs files, too.  Also,
extra 0x00 characters were being written to make the file size a
multiple of PAGE_CACHE_SIZE.

Signed-off-by: Tyler Hicks

eCryptfs: NULL crypt_stat dereference during lookup

2009-03-22T18:20:43+00:00

If ecryptfs_encrypted_view or ecryptfs_xattr_metadata were being
specified as mount options, a NULL pointer dereference of crypt_stat
was possible during lookup.

This patch moves the crypt_stat assignment into
ecryptfs_lookup_and_interpose_lower(), ensuring that crypt_stat
will not be NULL before we attempt to dereference it.

Thanks to Dan Carpenter and his static analysis tool, smatch, for
finding this bug.

Signed-off-by: Tyler Hicks 
Acked-by: Dustin Kirkland 
Cc: Dan Carpenter 
Cc: Serge Hallyn 
Signed-off-by: Linus Torvalds

eCryptfs: Allocate a variable number of pages for file headers

2009-03-22T18:20:43+00:00

When allocating the memory used to store the eCryptfs header contents, a
single, zeroed page was being allocated with get_zeroed_page().
However, the size of an eCryptfs header is either PAGE_CACHE_SIZE or
ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE (8192), whichever is larger, and is
stored in the file's private_data->crypt_stat->num_header_bytes_at_front
field.

ecryptfs_write_metadata_to_contents() was using
num_header_bytes_at_front to decide how many bytes should be written to
the lower filesystem for the file header.  Unfortunately, at least 8K
was being written from the page, despite the chance of the single,
zeroed page being smaller than 8K.  This resulted in random areas of
kernel memory being written between the 0x1000 and 0x1FFF bytes offsets
in the eCryptfs file headers if PAGE_SIZE was 4K.

This patch allocates a variable number of pages, calculated with
num_header_bytes_at_front, and passes the number of allocated pages
along to ecryptfs_write_metadata_to_contents().

Thanks to Florian Streibelt for reporting the data leak and working with
me to find the problem.  2.6.28 is the only kernel release with this
vulnerability.  Corresponds to CVE-2009-0787

Signed-off-by: Tyler Hicks 
Acked-by: Dustin Kirkland 
Reviewed-by: Eric Sandeen 
Reviewed-by: Eugene Teo 
Cc: Greg KH 
Cc: dann frazier 
Cc: Serge E. Hallyn 
Cc: Florian Streibelt 
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds

eCryptfs: don't encrypt file key with filename key

2009-03-14T18:57:22+00:00

eCryptfs has file encryption keys (FEK), file encryption key encryption
keys (FEKEK), and filename encryption keys (FNEK).  The per-file FEK is
encrypted with one or more FEKEKs and stored in the header of the
encrypted file.  I noticed that the FEK is also being encrypted by the
FNEK.  This is a problem if a user wants to use a different FNEK than
their FEKEK, as their file contents will still be accessible with the
FNEK.

This is a minimalistic patch which prevents the FNEKs signatures from
being copied to the inode signatures list.  Ultimately, it keeps the FEK
from being encrypted with a FNEK.

Signed-off-by: Tyler Hicks 
Cc: Serge Hallyn 
Acked-by: Dustin Kirkland 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds