18 Jan, 2011
2 commits
-
Commit cb55d21f6fa19d8c6c2680d90317ce88c1f57269 revealed a number of
missing 'z' length modifiers in calls to ecryptfs_printk() when
printing variables of type size_t. This patch fixes those compiler
warnings.Signed-off-by: Tyler Hicks
-
Add __attribute__((format... to __ecryptfs_printk
Make formats and arguments match.
Add casts to (unsigned long long) for %llu.Signed-off-by: Joe Perches
[tyhicks: 80 columns cleanup and fixed typo]
Signed-off-by: Tyler Hicks
29 Oct, 2010
3 commits
-
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 -
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 -
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
27 Aug, 2010
1 commit
-
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
30 Mar, 2010
1 commit
-
…it slab.h inclusion from percpu.h
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 allmodconfig8. 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 <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
23 Sep, 2009
4 commits
-
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 -
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 -
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 -
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/0x90but task is already holding lock:
(&crypt_stat->keysig_list_mutex){+.+.+.}, at: [] ecryptfs_generate_key_packet_set+0x58/0x2b0which 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
[] 0xffffffffffffffffother 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/0x2b0stack 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/0x1bSigned-off-by: Roland Dreier
Signed-off-by: Tyler Hicks
29 Jul, 2009
2 commits
-
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 -
Tag 11 packets are stored in the metadata section of an eCryptfs file to
store the key signature(s) used to encrypt the file encryption key.
After extracting the packet length field to determine the key signature
length, a check is not performed to see if the length would exceed the
key signature buffer size that was passed into parse_tag_11_packet().Thanks to Ramon de Carvalho Valle for finding this bug using fsfuzzer.
Signed-off-by: Tyler Hicks
Cc: stable@kernel.org (2.6.27 and 30)
Signed-off-by: Linus Torvalds
01 Apr, 2009
1 commit
-
Use kzfree() instead of memset() + kfree().
Signed-off-by: Johannes Weiner
Reviewed-by: Pekka Enberg
Acked-by: Tyler Hicks
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Mar, 2009
1 commit
-
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
07 Jan, 2009
4 commits
-
Kerneldoc updates for ecryptfs_parse_tag_70_packet().
Signed-off-by: Michael Halcrow
Cc: Dustin Kirkland
Cc: Eric Sandeen
Cc: Tyler Hicks
Cc: David Kleikamp
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Correct several format string data type specifiers. Correct filename size
data types; they should be size_t rather than int when passed as
parameters to some other functions (although note that the filenames will
never be larger than int).Signed-off-by: Michael Halcrow
Cc: Dustin Kirkland
Cc: Eric Sandeen
Cc: Tyler Hicks
Cc: David Kleikamp
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
%Z is a gcc-ism. Using %z instead.
Signed-off-by: Michael Halcrow
Cc: Dustin Kirkland
Cc: Eric Sandeen
Cc: Tyler Hicks
Cc: David Kleikamp
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This patchset implements filename encryption via a passphrase-derived
mount-wide Filename Encryption Key (FNEK) specified as a mount parameter.
Each encrypted filename has a fixed prefix indicating that eCryptfs should
try to decrypt the filename. When eCryptfs encounters this prefix, it
decodes the filename into a tag 70 packet and then decrypts the packet
contents using the FNEK, setting the filename to the decrypted filename.
Both unencrypted and encrypted filenames can reside in the same lower
filesystem.Because filename encryption expands the length of the filename during the
encoding stage, eCryptfs will not properly handle filenames that are
already near the maximum filename length.In the present implementation, eCryptfs must be able to produce a match
against the lower encrypted and encoded filename representation when given
a plaintext filename. Therefore, two files having the same plaintext name
will encrypt and encode into the same lower filename if they are both
encrypted using the same FNEK. This can be changed by finding a way to
replace the prepended bytes in the blocked-aligned filename with random
characters; they are hashes of the FNEK right now, so that it is possible
to deterministically map from a plaintext filename to an encrypted and
encoded filename in the lower filesystem. An implementation using random
characters will have to decode and decrypt every single directory entry in
any given directory any time an event occurs wherein the VFS needs to
determine whether a particular file exists in the lower directory and the
decrypted and decoded filenames have not yet been extracted for that
directory.Thanks to Tyler Hicks and David Kleikamp for assistance in the development
of this patchset.This patch:
A tag 70 packet contains a filename encrypted with a Filename Encryption
Key (FNEK). This patch implements functions for writing and parsing tag
70 packets. This patch also adds definitions and extends structures to
support filename encryption.Signed-off-by: Michael Halcrow
Cc: Dustin Kirkland
Cc: Eric Sandeen
Cc: Tyler Hicks
Cc: David Kleikamp
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
20 Nov, 2008
1 commit
-
I have received some reports of out-of-memory errors on some older AMD
architectures. These errors are what I would expect to see if
crypt_stat->key were split between two separate pages. eCryptfs should
not assume that any of the memory sent through virt_to_scatterlist() is
all contained in a single page, and so this patch allocates two
scatterlist structs instead of one when processing keys. I have received
confirmation from one person affected by this bug that this patch resolves
the issue for him, and so I am submitting it for inclusion in a future
stable release.Note that virt_to_scatterlist() runs sg_init_table() on the scatterlist
structs passed to it, so the calls to sg_init_table() in
decrypt_passphrase_encrypted_session_key() are redundant.Signed-off-by: Michael Halcrow
Reported-by: Paulo J. S. Silva
Cc: "Leon Woestenberg"
Cc: Tim Gardner
Cc:
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Oct, 2008
1 commit
-
The netlink transport code has not worked for a while and the miscdev
transport is a simpler solution. This patch removes the netlink code and
makes the miscdev transport the only eCryptfs kernel to userspace
transport.Signed-off-by: Tyler Hicks
Cc: Michael Halcrow
Cc: Dustin Kirkland
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 Jul, 2008
1 commit
-
Mounting with invalid key signatures should probably fail, if they were
specifically requested but not available.Also fix case checks in process_request_key_err() for the right sign of
the errnos, as spotted by Jan Tluka.Signed-off-by: Eric Sandeen
Reviewed-by: Jan Tluka
Acked-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
29 Apr, 2008
1 commit
-
Update the versioning information. Make the message types generic. Add an
outgoing message queue to the daemon struct. Make the functions to parse
and write the packet lengths available to the rest of the module. Add
functions to create and destroy the daemon structs. Clean up some of the
comments and make the code a little more consistent with itself.[akpm@linux-foundation.org: printk fixes]
Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Feb, 2008
1 commit
-
Only the lower byte of cipher_code is ever used, so it makes sense
for its type to be u8.Signed-off-by: Trevor Highland
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
18 Dec, 2007
1 commit
-
ecryptfs_destroy_mount_crypt_stat() checks whether each
auth_tok->global_auth_tok_key is nonzero and if so puts that key. However,
in some early mount error paths nothing has initialized the pointer, and we
try to key_put() garbage. Running the bad cipher tests in the testsuite
exposes this, and it's happy with the following change.Signed-off-by: Eric Sandeen
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
23 Oct, 2007
1 commit
-
Signed-off-by: Jens Axboe
17 Oct, 2007
11 commits
-
Remove assignments in if-statements.
Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Andrew Morton wrote:
> Please check that all the newly-added global symbols do indeed need
> to be global.Change symbols in keystore.c and crypto.o to static if they do not
need to be global.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Andrew Morton wrote:
> > struct mutex *tfm_mutex = NULL;
>
> This initialisation looks like it's here to kill bogus gcc warning
> (if it is, it should have been commented). Please investigate
> uninitialized_var() and __maybe_unused sometime.Remove some unnecessary variable initializations. There may be a few
more such intializations remaining in the code base; a future patch
will take care of those.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Andrew Morton wrote:
From: mhalcrow@us.ibm.com
> > +/**
> > + * decrypt_passphrase_encrypted_session_key - Decrypt the session key
> > + * with the given auth_tok.
> > *
> > * Returns Zero on success; non-zero error otherwise.
> > */
>
> That comment purports to be a kerneldoc-style comment. But
>
> - kerneldoc doesn't support multiple lines on the introductory line
> which identifies the name of the function (alas). So you'll need to
> overflow 80 cols here.
>
> - the function args weren't documented
>
> But the return value is! People regularly forget to do that. And
> they frequently forget to document the locking prerequisites and the
> permissible calling contexts (process/might_sleep/hardirq, etc)
>
> (please check all ecryptfs kerneldoc for this stuff sometime)This patch cleans up some of the existing comments and makes a couple
of line break tweaks. There is more work to do to bring eCryptfs into
full kerneldoc-compliance.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
fs/ecryptfs/keystore.c: In function 'parse_tag_1_packet':
fs/ecryptfs/keystore.c:557: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
fs/ecryptfs/keystore.c: In function 'parse_tag_3_packet':
fs/ecryptfs/keystore.c:690: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
fs/ecryptfs/keystore.c: In function 'parse_tag_11_packet':
fs/ecryptfs/keystore.c:836: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
fs/ecryptfs/keystore.c: In function 'write_tag_1_packet':
fs/ecryptfs/keystore.c:1413: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
fs/ecryptfs/keystore.c:1413: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int'
fs/ecryptfs/keystore.c: In function 'write_tag_11_packet':
fs/ecryptfs/keystore.c:1472: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
fs/ecryptfs/keystore.c: In function 'write_tag_3_packet':
fs/ecryptfs/keystore.c:1663: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
fs/ecryptfs/keystore.c:1663: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int'
fs/ecryptfs/keystore.c: In function 'ecryptfs_generate_key_packet_set':
fs/ecryptfs/keystore.c:1778: warning: passing argument 2 of 'write_tag_11_packet' from incompatible pointer type
fs/ecryptfs/main.c: In function 'ecryptfs_parse_options':
fs/ecryptfs/main.c:363: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix up the Tag 11 writing code to handle size limits and boundaries more
explicitly. It looks like the packet length was 1 shorter than it should have
been, chopping off the last byte of the key identifier. This is largely
inconsequential, since it is not much more likely that a key identifier
collision will occur with 7 bytes rather than 8. This patch fixes the packet
to use the full number of bytes that were originally intended to be used for
the key identifier.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix up the Tag 11 parsing code to handle size limits and boundaries more
explicitly. Pay attention to *8* bytes for the key identifier (literal data),
no more, no less.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix up the Tag 3 parsing code to handle size limits and boundaries more
explicitly.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix up the Tag 1 parsing code to handle size limits and boundaries more
explicitly. Initialize the new auth_tok's flags.Signed-off-by: Michael Halcrow
Cc: Josef Sipek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Use list_for_each_entry_safe() when wiping the authentication token list.
Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add support structures for handling multiple keys. The list in crypt_stat
contains the key identifiers for all of the keys that should be used for
encrypting each file's File Encryption Key (FEK). For now, each inode
inherits this list from the mount-wide crypt_stat struct, via the
ecryptfs_copy_mount_wide_sigs_to_inode_sigs() function.This patch also removes the global key tfm from the mount-wide crypt_stat
struct, instead keeping a list of tfm's meant for dealing with the various
inode FEK's. eCryptfs will now search the user's keyring for FEK's parsed
from the existing file metadata, so the user can make keys available at any
time before or after mounting.Now that multiple FEK packets can be written to the file metadata, we need to
be more meticulous about size limits. The updates to the code for writing out
packets to the file metadata makes sizes and limits more explicit, uniformly
expressed, and (hopefully) easier to follow.Signed-off-by: Michael Halcrow
Cc: "Serge E. Hallyn"
Cc: David Howells
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
17 Feb, 2007
1 commit
-
eCryptfs is gobbling a lot of stack in ecryptfs_generate_key_packet_set()
because it allocates a temporary memory-hungry ecryptfs_key_record struct.
This patch introduces a new kmem_cache for that struct and converts
ecryptfs_generate_key_packet_set() to use it.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
15 Feb, 2007
1 commit
-
After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there. Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm. I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).Signed-off-by: Tim Schmielau
Acked-by: Russell King
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
13 Feb, 2007
1 commit
-
Open-code flag checking and manipulation.
Signed-off-by: Michael Halcrow
Signed-off-by: Trevor Highland
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds