An error occurred fetching the project authors.
- 14 Mar, 2009 1 commit
-
-
Tyler Hicks authored
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 <tyhicks@linux.vnet.ibm.com> Cc: Serge Hallyn <serue@us.ibm.com> Acked-by:
Dustin Kirkland <kirkland@canonical.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 07 Feb, 2009 1 commit
-
-
Tyler Hicks authored
The addition of filename encryption caused a regression in unencrypted filename symlink support. ecryptfs_copy_filename() is used when dealing with unencrypted filenames and it reported that the new, copied filename was a character longer than it should have been. This caused the return value of readlink() to count the NULL byte of the symlink target. Most applications don't care about the extra NULL byte, but a version control system (bzr) helped in discovering the bug. Signed-off-by:
-
- 06 Jan, 2009 7 commits
-
-
Michael Halcrow authored
Flesh out the comments for ecryptfs_decode_from_filename(). Remove the return condition, since it is always 0. Signed-off-by:
Michael Halcrow <mhalcrow@us.ibm.com> Cc: Dustin Kirkland <dustin.kirkland@gmail.com> Cc: Eric Sandeen <sandeen@redhat.com> Cc: Tyler Hicks <tchicks@us.ibm.com> Cc: David Kleikamp <shaggy@us.ibm.com> Signed-off-by:
-
Michael Halcrow authored
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 authored
%Z is a gcc-ism. Using %z instead. Signed-off-by:
-
Michael Halcrow authored
Make the requisite modifications to ecryptfs_filldir(), ecryptfs_lookup(), and ecryptfs_readlink() to call out to filename encryption functions. Propagate filename encryption policy flags from mount-wide crypt_stat to inode crypt_stat. Signed-off-by:
-
Michael Halcrow authored
These functions support encrypting and encoding the filename contents. The encrypted filename contents may consist of any ASCII characters. This patch includes a custom encoding mechanism to map the ASCII characters to a reduced character set that is appropriate for filenames. Signed-off-by:
-
Michael Halcrow authored
Extensions to the header file to support filename encryption. Signed-off-by:
-
Michael Halcrow authored
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:
-
- 30 Oct, 2008 1 commit
-
-
Eric Sandeen authored
When ecryptfs allocates space to write crypto headers into, before copying it out to file headers or to xattrs, it looks at the value of crypt_stat->num_header_bytes_at_front to determine how much space it needs. This is also used as the file offset to the actual encrypted data, so for xattr-stored crypto info, the value was zero. So, we kzalloc'd 0 bytes, and then ran off to write to that memory. (Which returned as ZERO_SIZE_PTR, so we explode quickly). The right answer is to always allocate a page to write into; the current code won't ever write more than that (this is enforced by the (PAGE_CACHE_SIZE - offset) length in the call to ecryptfs_generate_key_packet_set). To be explicit about this, we now send in a "max" parameter, rather than magically using PAGE_CACHE_SIZE there. Also, since the pointer we pass down the callchain eventually gets the virt_to_page() treatment, we should be using a alloc_page variant, not kzalloc (see also 7fcba054) Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Acked-by:
-
- 28 Jul, 2008 1 commit
-
-
Eric Sandeen authored
With SLUB debugging turned on in 2.6.26, I was getting memory corruption when testing eCryptfs. The root cause turned out to be that eCryptfs was doing kmalloc(PAGE_CACHE_SIZE); virt_to_page() and treating that as a nice page-aligned chunk of memory. But at least with SLUB debugging on, this is not always true, and the page we get from virt_to_page does not necessarily match the PAGE_CACHE_SIZE worth of memory we got from kmalloc. My simple testcase was 2 loops doing "rm -f fileX; cp /tmp/fileX ." for 2 different multi-megabyte files. With this change I no longer see the corruption. Signed-off-by:
Rik van Riel <riel@redhat.com> Cc: <stable@kernel.org> [2.6.25.x, 2.6.26.x] Signed-off-by:
-
- 24 Jul, 2008 1 commit
-
-
Harvey Harrison authored
Fixes the following sparse warnings: fs/ecryptfs/crypto.c:1036:8: warning: cast to restricted __be32 fs/ecryptfs/crypto.c:1038:8: warning: cast to restricted __be32 fs/ecryptfs/crypto.c:1077:10: warning: cast to restricted __be32 fs/ecryptfs/crypto.c:1103:6: warning: incorrect type in assignment (different base types) fs/ecryptfs/crypto.c:1105:6: warning: incorrect type in assignment (different base types) fs/ecryptfs/crypto.c:1124:8: warning: incorrect type in assignment (different base types) fs/ecryptfs/crypto.c:1241:21: warning: incorrect type in assignment (different base types) fs/ecryptfs/crypto.c:1244:30: warning: incorrect type in assignment (different base types) fs/ecryptfs/crypto.c:1414:23: warning: cast to restricted __be32 fs/ecryptfs/crypto.c:1417:32: warning: cast to restricted __be16 Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by:
-
- 24 May, 2008 1 commit
-
-
Cyrill Gorcunov authored
Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by:
-
- 29 Apr, 2008 2 commits
-
-
Harvey Harrison authored
__FUNCTION__ is gcc-specific, use __func__ Signed-off-by:
-
Adrian Bunk authored
Remove the no longer used ecryptfs_header_cache_0. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by:
-
- 06 Feb, 2008 6 commits
-
-
Eric Sandeen authored
Jeff Moyer pointed out that a mount; umount loop of ecryptfs, with the same cipher & other mount options, created a new ecryptfs_key_tfm_cache item each time, and the cache could grow quite large this way. Looking at this with mhalcrow, we saw that ecryptfs_parse_options() unconditionally called ecryptfs_add_new_key_tfm(), which is what was adding these items. Refactor ecryptfs_get_tfm_and_mutex_for_cipher_name() to create a new helper function, ecryptfs_tfm_exists(), which checks for the cipher on the cached key_tfm_list, and sets a pointer to it if it exists. This can then be called from ecryptfs_parse_options(), and new key_tfm's can be added only when a cached one is not found. With list locking changes suggested by akpm. Signed-off-by:
-
Trevor Highland authored
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 <trevor.highland@gmail.com> Cc: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by:
-
Michael Halcrow authored
The printk statements that result when the user does not have the proper key available could use some refining. Signed-off-by:
-
Trevor Highland authored
There is no need to keep re-setting the same key for any given eCryptfs inode. This patch optimizes the use of the crypto API and helps performance a bit. Signed-off-by:
-
Michael Halcrow authored
Remove internal references to header extents; just keep track of header bytes instead. Headers can easily span multiple pages with the recent persistent file changes. Signed-off-by:
-
Adrian Bunk authored
- make the following needlessly global code static: - crypto.c:ecryptfs_lower_offset_for_extent() - crypto.c:key_tfm_list - crypto.c:key_tfm_list_mutex - inode.c:ecryptfs_getxattr() - main.c:ecryptfs_init_persistent_file() - remove the no longer used mmap.c:ecryptfs_lower_page_cache - #if 0 the unused read_write.c:ecryptfs_read() Signed-off-by:
-
- 23 Dec, 2007 2 commits
-
-
Eric Sandeen authored
Thanks to Josef Bacik for finding these. A couple of ecryptfs error paths don't properly unlock things they locked. Signed-off-by:
-
Eric Sandeen authored
Passing a cipher name > 32 chars on mount results in an overflow when the cipher name is printed, because the last character in the struct ecryptfs_key_tfm's cipher_name string was never zeroed. Signed-off-by:
-
- 05 Nov, 2007 2 commits
-
-
Michael Halcrow authored
Release the crypt_stat hash mutex on allocation error. Check for error conditions when doing crypto hash calls. Signed-off-by:
Kazuki Ohta <kazuki.ohta@gmail.com> Signed-off-by:
-
Michael Halcrow authored
The extent_offset is getting incremented twice per loop iteration through any given page. It should only be getting incremented once. This bug should only impact hosts with >4K page sizes. Signed-off-by:
-
- 27 Oct, 2007 1 commit
-
-
Herbert Xu authored
This patch fixes the errors made in the users of the crypto layer during the sg_init_table conversion. It also adds a few conversions that were missing altogether. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 24 Oct, 2007 1 commit
-
-
Jens Axboe authored
Most drivers need to set length and offset as well, so may as well fold those three lines into one. Add sg_assign_page() for those two locations that only needed to set the page, where the offset/length is set outside of the function context. Signed-off-by:Jens Axboe <jens.axboe@oracle.com>
-
- 22 Oct, 2007 1 commit
-
-
Jens Axboe authored
Signed-off-by:
-
- 16 Oct, 2007 12 commits
-
-
Michael Halcrow authored
The functions that eventually call down to ecryptfs_read_lower(), ecryptfs_decrypt_page(), and ecryptfs_copy_up_encrypted_with_header() should have the responsibility of managing the page Uptodate status. This patch gets rid of some of the ugliness that resulted from trying to push some of the page flag setting too far down the stack. Signed-off-by:
-
Michael Halcrow authored
Replace some magic numbers with sizeof() equivalents. Signed-off-by:
-
Michael Halcrow authored
The switch to read_write.c routines and the persistent file make a number of functions unnecessary. This patch removes them. Signed-off-by:
-
Michael Halcrow authored
Update data types and add casts in order to avoid potential overflow issues. Signed-off-by:
-
Michael Halcrow authored
Rather than open a new lower file for every eCryptfs file that is opened, truncated, or setattr'd, instead use the existing lower persistent file for the eCryptfs inode. Change truncate to use read_write.c functions. Change ecryptfs_getxattr() to use the common ecryptfs_getxattr_lower() function. Signed-off-by:
-
Michael Halcrow authored
Update the metadata read/write functions and grow_file() to use the read_write.c routines. Do not open another lower file; use the persistent lower file instead. Provide a separate function for crypto.c::ecryptfs_read_xattr_region() to get to the lower xattr without having to go through the eCryptfs getxattr. Signed-off-by:
-
Michael Halcrow authored
Replace page encryption and decryption routines and inode size write routine with versions that utilize the read_write.c functions. Signed-off-by:
-
Michael Halcrow authored
Remove assignments in if-statements. Signed-off-by:
-
Michael Halcrow authored
There is no point to keeping a separate header_extent_size and an extent_size. The total size of the header can always be represented as some multiple of the regular data extent size. [randy.dunlap@oracle.com: ecryptfs: fix printk format warning] Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Michael Halcrow authored
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 authored
Andrew Morton wrote: From: mhalcrow@us.ibm.com <mhalcrow@halcrow.austin.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 authored
Andrew Morton wrote: > > +int ecryptfs_destruct_crypto(void) > > ecryptfs_destroy_crypto would be more grammatically correct ;) Grammatical fix for some function names. Signed-off-by:
-
