summaryrefslogtreecommitdiffstats
path: root/fs/ext4/crypto_fname.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* ext4 crypto: remove duplicate header filezilong.liu2015-07-281-1/+0
| | | | | | | Remove key.h which is included twice in crypto_fname.c Signed-off-by: zilong.liu <liuziloong@gmail.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: check for too-short encrypted file namesTheodore Ts'o2015-07-171-0/+4
| | | | | | | | | | | | | An encrypted file name should never be shorter than an 16 bytes, the AES block size. The 3.10 crypto layer will oops and crash the kernel if ciphertext shorter than the block size is passed to it. Fortunately, in modern kernels the crypto layer will not crash the kernel in this scenario, but nevertheless, it represents a corrupted directory, and we should detect it and mark the file system as corrupted so that e2fsck can fix this. Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: allocate the right amount of memory for the on-disk symlinkTheodore Ts'o2015-05-311-10/+15
| | | | | | | | Previously we were taking the required padding when allocating space for the on-disk symlink. This caused a buffer overrun which could trigger a krenel crash when running fsstress. Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: clean up error handling in ext4_fname_setup_filenameTheodore Ts'o2015-05-311-19/+16
| | | | | | | | | Fix a potential memory leak where fname->crypto_buf.name wouldn't get freed in some error paths, and also make the error handling easier to understand/audit. Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: use per-inode tfm structureTheodore Ts'o2015-05-311-47/+1
| | | | | | | | | | | | | As suggested by Herbert Xu, we shouldn't allocate a new tfm each time we read or write a page. Instead we can use a single tfm hanging off the inode's crypt_info structure for all of our encryption needs for that inode, since the tfm can be used by multiple crypto requests in parallel. Also use cmpxchg() to avoid races that could result in crypt_info structure getting doubly allocated or doubly freed. Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: get rid of ci_mode from struct ext4_crypt_infoTheodore Ts'o2015-05-181-2/+2
| | | | | | | The ci_mode field was superfluous, and getting rid of it gets rid of an unused hole in the structure. Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: reorganize how we store keys in the inodeTheodore Ts'o2015-05-181-209/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a pretty massive patch which does a number of different things: 1) The per-inode encryption information is now stored in an allocated data structure, ext4_crypt_info, instead of directly in the node. This reduces the size usage of an in-memory inode when it is not using encryption. 2) We drop the ext4_fname_crypto_ctx entirely, and use the per-inode encryption structure instead. This remove an unnecessary memory allocation and free for the fname_crypto_ctx as well as allowing us to reuse the ctfm in a directory for multiple lookups and file creations. 3) We also cache the inode's policy information in the ext4_crypt_info structure so we don't have to continually read it out of the extended attributes. 4) We now keep the keyring key in the inode's encryption structure instead of releasing it after we are done using it to derive the per-inode key. This allows us to test to see if the key has been revoked; if it has, we prevent the use of the derived key and free it. 5) When an inode is released (or when the derived key is freed), we will use memset_explicit() to zero out the derived key, so it's not left hanging around in memory. This implies that when a user logs out, it is important to first revoke the key, and then unlink it, and then finally, to use "echo 3 > /proc/sys/vm/drop_caches" to release any decrypted pages and dcache entries from the system caches. 6) All this, and we also shrink the number of lines of code by around 100. :-) Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: separate kernel and userspace structure for the keyTheodore Ts'o2015-05-181-23/+10
| | | | | | | | | | | | | Use struct ext4_encryption_key only for the master key passed via the kernel keyring. For internal kernel space users, we now use struct ext4_crypt_info. This will allow us to put information from the policy structure so we can cache it and avoid needing to constantly looking up the extended attribute. We will do this in a spearate patch. This patch is mostly mechnical to make it easier for patch review. Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: don't allocate a page when encrypting/decrypting file namesTheodore Ts'o2015-05-181-52/+20
| | | | Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: optimize filename encryptionTheodore Ts'o2015-05-181-91/+64
| | | | | | | | | | | | | | Encrypt the filename as soon it is passed in by the user. This avoids our needing to encrypt the filename 2 or 3 times while in the process of creating a filename. Similarly, when looking up a directory entry, encrypt the filename early, or if the encryption key is not available, base-64 decode the file syystem so that the hash value and the last 16 bytes of the encrypted filename is available in the new struct ext4_filename data structure. Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: add padding to filenames before encryptingTheodore Ts'o2015-05-011-2/+10
| | | | | | | | | | | This obscures the length of the filenames, to decrease the amount of information leakage. By default, we pad the filenames to the next 4 byte boundaries. This costs nothing, since the directory entries are aligned to 4 byte boundaries anyway. Filenames can also be padded to 8, 16, or 32 bytes, which will consume more directory space. Change-Id: Ibb7a0fb76d2c48e2061240a709358ff40b14f322 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: simplify and speed up filename encryptionTheodore Ts'o2015-05-011-133/+135
| | | | | | | | | Avoid using SHA-1 when calculating the user-visible filename when the encryption key is available, and avoid decrypting lots of filenames when searching for a directory entry in a directory block. Change-Id: If4655f144784978ba0305b597bfa1c8d7bb69e63 Signed-off-by: Theodore Ts'o <tytso@mit.edu>
* ext4 crypto: filename encryption facilitiesMichael Halcrow2015-04-121-0/+709
Signed-off-by: Uday Savagaonkar <savagaon@google.com> Signed-off-by: Ildar Muslukhov <ildarm@google.com> Signed-off-by: Michael Halcrow <mhalcrow@google.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>