linux-toradex.git/fs/ext4/crypto_policy.c, branch v4.3-rc1

ext4 crypto: use a jbd2 transaction when adding a crypto policy

2015-07-17T15:16:47+00:00

Start a jbd2 transaction, and mark the inode dirty on the inode under
that transaction after setting the encrypt flag.  Otherwise if the
directory isn't modified after setting the crypto policy, the
encrypted flag might not survive the inode getting pushed out from
memory, or the the file system getting unmounted and remounted.

Signed-off-by: Theodore Ts'o

ext4 crypto: handle unexpected lack of encryption keys

2015-05-31T17:35:39+00:00

Fix up attempts by users to try to write to a file when they don't
have access to the encryption key.

Signed-off-by: Theodore Ts'o

ext4 crypto: policies may only be set on directories

2015-05-31T17:35:14+00:00

Thanks to Chao Yu  for pointing out we were
missing this check.

Signed-off-by: Theodore Ts'o

ext4 crypto: set up encryption info for new inodes in ext4_inherit_context()

2015-05-31T17:34:29+00:00

Set up the encryption information for newly created inodes immediately
after they inherit their encryption context from their parent
directories.

Signed-off-by: Theodore Ts'o

ext4: clean up superblock encryption mode fields

2015-05-18T17:18:47+00:00

The superblock fields s_file_encryption_mode and s_dir_encryption_mode
are vestigal, so remove them as a cleanup.  While we're at it, allow
file systems with both encryption and inline_data enabled at the same
time to work correctly.  We can't have encrypted inodes with inline
data, but there's no reason to prohibit unencrypted inodes from using
the inline data feature.

Signed-off-by: Theodore Ts'o

ext4 crypto: reorganize how we store keys in the inode

2015-05-18T17:17:47+00:00

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

ext4 crypto: add padding to filenames before encrypting

2015-05-01T20:56:50+00:00

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

ext4 crypto: enable encryption feature flag

2015-04-16T05:56:00+00:00

Also add the test dummy encryption mode flag so we can more easily
test the encryption patches using xfstests.

Signed-off-by: Michael Halcrow 
Signed-off-by: Theodore Ts'o

ext4 crypto: filename encryption facilities

2015-04-12T04:56:17+00:00

Signed-off-by: Uday Savagaonkar 
Signed-off-by: Ildar Muslukhov 
Signed-off-by: Michael Halcrow 
Signed-off-by: Theodore Ts'o

ext4 crypto: add ext4 encryption facilities

2015-04-12T04:43:56+00:00

On encrypt, we will re-assign the buffer_heads to point to a bounce
page rather than the control_page (which is the original page to write
that contains the plaintext). The block I/O occurs against the bounce
page.  On write completion, we re-assign the buffer_heads to the
original plaintext page.

On decrypt, we will attach a read completion callback to the bio
struct. This read completion will decrypt the read contents in-place
prior to setting the page up-to-date.

The current encryption mode, AES-256-XTS, lacks cryptographic
integrity. AES-256-GCM is in-plan, but we will need to devise a
mechanism for handling the integrity data.

Signed-off-by: Michael Halcrow 
Signed-off-by: Ildar Muslukhov 
Signed-off-by: Theodore Ts'o