linux.git/fs/crypto/crypto.c, branch v4.12

fscrypt: remove broken support for detecting keyring key revocation

2017-03-15T17:12:05+00:00

Filesystem encryption ostensibly supported revoking a keyring key that
had been used to "unlock" encrypted files, causing those files to become
"locked" again.  This was, however, buggy for several reasons, the most
severe of which was that when key revocation happened to be detected for
an inode, its fscrypt_info was immediately freed, even while other
threads could be using it for encryption or decryption concurrently.
This could be exploited to crash the kernel or worse.

This patch fixes the use-after-free by removing the code which detects
the keyring key having been revoked, invalidated, or expired.  Instead,
an encrypted inode that is "unlocked" now simply remains unlocked until
it is evicted from memory.  Note that this is no worse than the case for
block device-level encryption, e.g. dm-crypt, and it still remains
possible for a privileged user to evict unused pages, inodes, and
dentries by running 'sync; echo 3 > /proc/sys/vm/drop_caches', or by
simply unmounting the filesystem.  In fact, one of those actions was
already needed anyway for key revocation to work even somewhat sanely.
This change is not expected to break any applications.

In the future I'd like to implement a real API for fscrypt key
revocation that interacts sanely with ongoing filesystem operations ---
waiting for existing operations to complete and blocking new operations,
and invalidating and sanitizing key material and plaintext from the VFS
caches.  But this is a hard problem, and for now this bug must be fixed.

This bug affected almost all versions of ext4, f2fs, and ubifs
encryption, and it was potentially reachable in any kernel configured
with encryption support (CONFIG_EXT4_ENCRYPTION=y,
CONFIG_EXT4_FS_ENCRYPTION=y, CONFIG_F2FS_FS_ENCRYPTION=y, or
CONFIG_UBIFS_FS_ENCRYPTION=y).  Note that older kernels did not use the
shared fs/crypto/ code, but due to the potential security implications
of this bug, it may still be worthwhile to backport this fix to them.

Fixes: b7236e21d55f ("ext4 crypto: reorganize how we store keys in the inode")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Eric Biggers 
Signed-off-by: Theodore Ts'o 
Acked-by: Michael Halcrow

fscrypt: factor out bio specific functions

2017-01-01T21:18:49+00:00

That way we can get rid of the direct dependency on CONFIG_BLOCK.

Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
Reported-by: Arnd Bergmann 
Reported-by: Randy Dunlap 
Reviewed-by: Eric Biggers 
Reviewed-by: Christoph Hellwig 
Reviewed-by: David Gstir 
Signed-off-by: Richard Weinberger 
Signed-off-by: Theodore Ts'o

fscrypt: Rename FS_WRITE_PATH_FL to FS_CTX_HAS_BOUNCE_BUFFER_FL

2016-12-11T21:33:18+00:00

... to better explain its purpose after introducing in-place encryption
without bounce buffer.

Signed-off-by: David Gstir 
Signed-off-by: Theodore Ts'o

fscrypt: Delay bounce page pool allocation until needed

2016-12-11T21:33:11+00:00

Since fscrypt users can now indicated if fscrypt_encrypt_page() should
use a bounce page, we can delay the bounce page pool initialization util
it is really needed. That is until fscrypt_operations has no
FS_CFLG_OWN_PAGES flag set.

Signed-off-by: David Gstir 
Signed-off-by: Theodore Ts'o

fscrypt: Cleanup page locking requirements for fscrypt_{decrypt,encrypt}_page()

2016-12-11T21:26:12+00:00

Rename the FS_CFLG_INPLACE_ENCRYPTION flag to FS_CFLG_OWN_PAGES which,
when set, indicates that the fs uses pages under its own control as
opposed to writeback pages which require locking and a bounce buffer for
encryption.

Signed-off-by: David Gstir 
Signed-off-by: Theodore Ts'o

fscrypt: Cleanup fscrypt_{decrypt,encrypt}_page()

2016-12-11T21:26:12+00:00

- Improve documentation
- Add BUG_ON(len == 0) to avoid accidental switch of offs and len
parameters
- Improve variable names for readability

Signed-off-by: David Gstir 
Signed-off-by: Theodore Ts'o

fscrypt: Never allocate fscrypt_ctx on in-place encryption

2016-12-11T21:26:11+00:00

In case of in-place encryption fscrypt_ctx was allocated but never
released. Since we don't need it for in-place encryption, we skip
allocating it.

Fixes: 1c7dcf69eea3 ("fscrypt: Add in-place encryption mode")

Signed-off-by: David Gstir 
Signed-off-by: Theodore Ts'o

fscrypt: Use correct index in decrypt path.

2016-12-11T21:26:10+00:00

Actually use the fs-provided index instead of always using page->index
which is only set for page-cache pages.

Fixes: 9c4bb8a3a9b4 ("fscrypt: Let fs select encryption index/tweak")

Signed-off-by: David Gstir 
Signed-off-by: Theodore Ts'o

fscrypt: move non-public structures and constants to fscrypt_private.h

2016-12-11T21:26:09+00:00

Signed-off-by: Theodore Ts'o 
Reviewed-by: Eric Biggers

fscrypt: unexport fscrypt_initialize()

2016-12-11T21:26:08+00:00

The fscrypt_initalize() function isn't used outside fs/crypto, so
there's no point making it be an exported symbol.

Signed-off-by: Theodore Ts'o 
Reviewed-by: Eric Biggers