Hi Chandan,

On Tue, Dec 04, 2018 at 03:26:46PM +0530, Chandan Rajendra wrote:

In order to have a common code base for fscrypt "post read" processing
for all filesystems which support encryption, this commit removes
filesystem specific build config option (e.g. CONFIG_EXT4_FS_ENCRYPTION)
and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose
value affects all the filesystems making use of fscrypt.

Signed-off-by: Chandan Rajendra <redacted>

[...]

-config F2FS_FS_ENCRYPTION
-	bool "F2FS Encryption"
-	depends on F2FS_FS
-	depends on F2FS_FS_XATTR
-	select FS_ENCRYPTION
-	help
-	  Enable encryption of f2fs 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.
-

[...]

-config UBIFS_FS_ENCRYPTION
-	bool "UBIFS Encryption"
-	depends on UBIFS_FS && UBIFS_FS_XATTR && BLOCK
-	select FS_ENCRYPTION
-	default n
-	help
-	  Enable encryption of UBIFS 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.

Will it cause problems that now f2fs encryption can be "enabled" without
F2FS_FS_XATTR, and ubifs encryption without UBIFS_FS_XATTR && BLOCK?

Otherwise I think this patch looks fine.  I'm a bit concerned about the bloat
from making FS_ENCRYPTION non-modular, but given that it will make sharing I/O
code much easier, it's probably worthwhile.

It would help to strip down the dependencies of FS_ENCRYPTION to just the stuff
needed for just AES-256-XTS and AES-256-CTS.  I already sent out a patch a
couple months ago (https://patchwork.kernel.org/patch/10589319/) to remove
CONFIG_CTR which isn't used at all; I'll remind Ted to apply that.  But we could
also drop CONFIG_SHA256, which is only needed for AES-128-CBC contents
encryption.  If we do that, it should be a separate patch, though.

Thanks,

- Eric