From: Eric Biggers <ebiggers@xxxxxxxxxx> The help text for CONFIG_FS_ENCRYPTION and the fscrypt.rst documentation file both list the filesystems that support fscrypt. CephFS added support for fscrypt in v6.6, so add CephFS to the list. Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> --- Documentation/filesystems/fscrypt.rst | 18 +++++++++--------- fs/crypto/Kconfig | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 8d38b47b7b83c..e86b886b64d0e 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -24,29 +24,29 @@ completeness this documentation covers the kernel's API anyway.) Unlike dm-crypt, fscrypt operates at the filesystem level rather than at the block device level. This allows it to encrypt different files with different keys and to have unencrypted files on the same filesystem. This is useful for multi-user systems where each user's data-at-rest needs to be cryptographically isolated from the others. However, except for filenames, fscrypt does not encrypt filesystem metadata. Unlike eCryptfs, which is a stacked filesystem, fscrypt is integrated -directly into supported filesystems --- currently ext4, F2FS, and -UBIFS. This allows encrypted files to be read and written without -caching both the decrypted and encrypted pages in the pagecache, -thereby nearly halving the memory used and bringing it in line with -unencrypted files. Similarly, half as many dentries and inodes are -needed. eCryptfs also limits encrypted filenames to 143 bytes, -causing application compatibility issues; fscrypt allows the full 255 -bytes (NAME_MAX). Finally, unlike eCryptfs, the fscrypt API can be -used by unprivileged users, with no need to mount anything. +directly into supported filesystems --- currently ext4, F2FS, UBIFS, +and CephFS. This allows encrypted files to be read and written +without caching both the decrypted and encrypted pages in the +pagecache, thereby nearly halving the memory used and bringing it in +line with unencrypted files. Similarly, half as many dentries and +inodes are needed. eCryptfs also limits encrypted filenames to 143 +bytes, causing application compatibility issues; fscrypt allows the +full 255 bytes (NAME_MAX). Finally, unlike eCryptfs, the fscrypt API +can be used by unprivileged users, with no need to mount anything. fscrypt does not support encrypting files in-place. Instead, it supports marking an empty directory as encrypted. Then, after userspace provides the key, all regular files, directories, and symbolic links created in that directory tree are transparently encrypted. Threat model ============ diff --git a/fs/crypto/Kconfig b/fs/crypto/Kconfig index 2d0c8922f6350..5aff5934baa12 100644 --- a/fs/crypto/Kconfig +++ b/fs/crypto/Kconfig @@ -4,21 +4,21 @@ config FS_ENCRYPTION select CRYPTO select CRYPTO_HASH select CRYPTO_SKCIPHER select CRYPTO_LIB_SHA256 select KEYS help Enable encryption of files and directories. This feature is similar to ecryptfs, but it is more memory efficient since it avoids caching the encrypted and decrypted pages in the page cache. Currently Ext4, - F2FS and UBIFS make use of this feature. + F2FS, UBIFS, and CephFS make use of this feature. # Filesystems supporting encryption must select this if FS_ENCRYPTION. This # allows the algorithms to be built as modules when all the filesystems are, # whereas selecting them from FS_ENCRYPTION would force them to be built-in. # # Note: this option only pulls in the algorithms that filesystem encryption # needs "by default". If userspace will use "non-default" encryption modes such # as Adiantum encryption, then those other modes need to be explicitly enabled # in the crypto API; see Documentation/filesystems/fscrypt.rst for details. # base-commit: 0fc24a6549f9b6efc538b67a098ab577b1f9a00e -- 2.43.0
