linux.git/fs/ecryptfs/crypto.c, branch v3.10

eCryptfs: Use the ablkcipher crypto API

2013-05-09T23:55:07+00:00

Make the switch from the blkcipher kernel crypto interface to the
ablkcipher interface.

encrypt_scatterlist() and decrypt_scatterlist() now use the ablkcipher
interface but, from the eCryptfs standpoint, still treat the crypto
operation as a synchronous operation. They submit the async request and
then wait until the operation is finished before they return. Most of
the changes are contained inside those two functions.

Despite waiting for the completion of the crypto operation, the
ablkcipher interface provides performance increases in most cases when
used on AES-NI capable hardware.

Signed-off-by: Tyler Hicks 
Acked-by: Colin King 
Reviewed-by: Zeev Zilberman 
Cc: Dustin Kirkland 
Cc: Tim Chen 
Cc: Ying Huang 
Cc: Thieu Le 
Cc: Li Wang 
Cc: Jarkko Sakkinen

eCryptfs: remove unneeded checks in virt_to_scatterlist()

2013-01-29T00:38:37+00:00

This is always called with a valid "sg" pointer.  My static checker
complains because the call to sg_init_table() dereferences "sg" before
we reach the checks.

Signed-off-by: Dan Carpenter 
Signed-off-by: Tyler Hicks

fs/ecryptfs/crypto.c: make ecryptfs_encode_for_filename() static

2012-12-18T16:10:13+00:00

the function ecryptfs_encode_for_filename() is only used in this file

Signed-off-by: Cong Ding 
Signed-off-by: Tyler Hicks

eCryptfs: Improve statfs reporting

2012-02-16T22:06:21+00:00

statfs() calls on eCryptfs files returned the wrong filesystem type and,
when using filename encryption, the wrong maximum filename length.

If mount-wide filename encryption is enabled, the cipher block size and
the lower filesystem's max filename length will determine the max
eCryptfs filename length. Pre-tested, known good lengths are used when
the lower filesystem's namelen is 255 and a cipher with 8 or 16 byte
block sizes is used. In other, less common cases, we fall back to a safe
rounded-down estimate when determining the eCryptfs namelen.

https://launchpad.net/bugs/885744

Signed-off-by: Tyler Hicks 
Reported-by: Kees Cook 
Reviewed-by: Kees Cook 
Reviewed-by: John Johansen

eCryptfs: Fix oops when printing debug info in extent crypto functions

2012-01-25T20:43:42+00:00

If pages passed to the eCryptfs extent-based crypto functions are not
mapped and the module parameter ecryptfs_verbosity=1 was specified at
loading time, a NULL pointer dereference will occur.

Note that this wouldn't happen on a production system, as you wouldn't
pass ecryptfs_verbosity=1 on a production system. It leaks private
information to the system logs and is for debugging only.

The debugging info printed in these messages is no longer very useful
and rather than doing a kmap() in these debugging paths, it will be
better to simply remove the debugging paths completely.

https://launchpad.net/bugs/913651

Signed-off-by: Tyler Hicks 
Reported-by: Daniel DeFreez
Cc:

ecryptfs: Remove unnecessary variable initialization

2012-01-25T20:43:38+00:00

Removes unneeded variable initialization in ecryptfs_read_metadata(). Also adds
a small comment to help explain metadata reading logic.

[tyhicks@canonical.com: Pulled out of for-stable patch and wrote commit msg]
Signed-off-by: Tim Gardner 
Signed-off-by: Tyler Hicks

ecryptfs: Improve metadata read failure logging

2012-01-25T20:43:38+00:00

Print inode on metadata read failure. The only real
way of dealing with metadata read failures is to delete
the underlying file system file. Having the inode
allows one to 'find . -inum INODE`.

[tyhicks@canonical.com: Removed some minor not-for-stable parts]
Signed-off-by: Tim Gardner 
Reviewed-by: Kees Cook 
Cc: stable@vger.kernel.org
Signed-off-by: Tyler Hicks

eCryptfs: Extend array bounds for all filename chars

2011-11-23T21:43:53+00:00

From mhalcrow's original commit message:

    Characters with ASCII values greater than the size of
    filename_rev_map[] are valid filename characters.
    ecryptfs_decode_from_filename() will access kernel memory beyond
    that array, and ecryptfs_parse_tag_70_packet() will then decrypt
    those characters. The attacker, using the FNEK of the crafted file,
    can then re-encrypt the characters to reveal the kernel memory past
    the end of the filename_rev_map[] array. I expect low security
    impact since this array is statically allocated in the text area,
    and the amount of memory past the array that is accessible is
    limited by the largest possible ASCII filename character.

This patch solves the issue reported by mhalcrow but with an
implementation suggested by Linus to simply extend the length of
filename_rev_map[] to 256. Characters greater than 0x7A are mapped to
0x00, which is how invalid characters less than 0x7A were previously
being handled.

Signed-off-by: Tyler Hicks 
Reported-by: Michael Halcrow 
Cc: stable@kernel.org

eCryptfs: Prevent file create race condition

2011-11-23T21:39:38+00:00

The file creation path prematurely called d_instantiate() and
unlock_new_inode() before the eCryptfs inode info was fully
allocated and initialized and before the eCryptfs metadata was written
to the lower file.

This could result in race conditions in subsequent file and inode
operations leading to unexpected error conditions or a null pointer
dereference while attempting to use the unallocated memory.

https://launchpad.net/bugs/813146

Signed-off-by: Tyler Hicks 
Cc: stable@kernel.org

eCryptfs: Remove ecryptfs_header_cache_2

2011-05-29T19:24:25+00:00

Now that ecryptfs_lookup_interpose() is no longer using
ecryptfs_header_cache_2 to read in metadata, the kmem_cache can be
removed and the ecryptfs_header_cache_1 kmem_cache can be renamed to
ecryptfs_header_cache.

Signed-off-by: Tyler Hicks