All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	Chandan Rajendra <chandan@linux.vnet.ibm.com>,
	linux-fscrypt@vger.kernel.org
Subject: Re: [v2 PATCH] fscrypt: Allow modular crypto algorithms
Date: Sun, 22 Dec 2019 10:45:45 -0600	[thread overview]
Message-ID: <20191222164545.GA157733@zzz.localdomain> (raw)
In-Reply-To: <20191222084155.n4mbomsw6pl4c7kv@gondor.apana.org.au>

On Sun, Dec 22, 2019 at 04:41:55PM +0800, Herbert Xu wrote:
> On Sat, Dec 21, 2019 at 05:44:28PM -0600, Eric Biggers wrote:
> >
> > I'm not sure this is a good idea, since there will probably need to be more
> > places where built-in code calls into fs/crypto/ too.
> 
> Clearly it's going to be too much trouble for now.  I may revisit
> this once the fscrypt code has settled down a little.
> 
> However, we can at least build the algorithms as modules, like this:
> 
> ---8<---
> The commit 643fa9612bf1 ("fscrypt: remove filesystem specific
> build config option") removed modular support for fs/crypto.  This
> causes the Crypto API to be built-in whenever fscrypt is enabled.
> This makes it very difficult for me to test modular builds of
> the Crypto API without disabling fscrypt which is a pain.
> 
> As fscrypt is still evolving and it's developing new ties with the
> fs layer, it's hard to build it as a module for now.
> 
> However, the actual algorithms are not required until a filesystem
> is mounted.  Therefore we can allow them to be built as modules.
> 
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
> 
> diff --git a/fs/crypto/Kconfig b/fs/crypto/Kconfig
> index ff5a1746cbae..ae929fbc0f29 100644
> --- a/fs/crypto/Kconfig
> +++ b/fs/crypto/Kconfig
> @@ -1,7 +1,19 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  config FS_ENCRYPTION
>  	bool "FS Encryption (Per-file encryption)"
> +	select KEYS
>  	select CRYPTO
> +	select CRYPTO_SKCIPHER
> +	select CRYPTO_HASH
> +	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.
> +
> +config FS_ENCRYPTION_TRI
> +	tristate
>  	select CRYPTO_AES
>  	select CRYPTO_CBC
>  	select CRYPTO_ECB
> @@ -9,10 +21,3 @@ config FS_ENCRYPTION
>  	select CRYPTO_CTS
>  	select CRYPTO_SHA512
>  	select CRYPTO_HMAC
> -	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.
> diff --git a/fs/ext4/Kconfig b/fs/ext4/Kconfig
> index ef42ab040905..5de0bcc50d37 100644
> --- a/fs/ext4/Kconfig
> +++ b/fs/ext4/Kconfig
> @@ -10,6 +10,7 @@ config EXT3_FS
>  	select CRC16
>  	select CRYPTO
>  	select CRYPTO_CRC32C
> +	select FS_ENCRYPTION_TRI if FS_ENCRYPTION
>  	help
>  	  This config option is here only for backward compatibility. ext3
>  	  filesystem is now handled by the ext4 driver.
> diff --git a/fs/f2fs/Kconfig b/fs/f2fs/Kconfig
> index 652fd2e2b23d..9ccaec60af47 100644
> --- a/fs/f2fs/Kconfig
> +++ b/fs/f2fs/Kconfig
> @@ -6,6 +6,7 @@ config F2FS_FS
>  	select CRYPTO
>  	select CRYPTO_CRC32
>  	select F2FS_FS_XATTR if FS_ENCRYPTION
> +	select FS_ENCRYPTION_TRI if FS_ENCRYPTION
>  	help
>  	  F2FS is based on Log-structured File System (LFS), which supports
>  	  versatile "flash-friendly" features. The design has been focused on
> diff --git a/fs/ubifs/Kconfig b/fs/ubifs/Kconfig
> index 69932bcfa920..ea2d43829c18 100644
> --- a/fs/ubifs/Kconfig
> +++ b/fs/ubifs/Kconfig
> @@ -12,6 +12,7 @@ config UBIFS_FS
>  	select CRYPTO_ZSTD if UBIFS_FS_ZSTD
>  	select CRYPTO_HASH_INFO
>  	select UBIFS_FS_XATTR if FS_ENCRYPTION
> +	select FS_ENCRYPTION_TRI if FS_ENCRYPTION
>  	depends on MTD_UBI
>  	help
>  	  UBIFS is a file system for flash devices which works on top of UBI.

Okay, this approach looks fine.  But can you rename the option to something more
self-explanatory like FS_ENCRYPTION_ALGS, and add a comment?  Like:

# Filesystems supporting encryption must select this if FS_ENCRYPTION.  This
# allows the algorithms to be built as modules when all the filesystems are.
config FS_ENCRYPTION_ALGS
	tristate
	select CRYPTO_AES
	select CRYPTO_CBC
	select CRYPTO_ECB
	select CRYPTO_XTS
	select CRYPTO_CTS
	select CRYPTO_SHA512
	select CRYPTO_HMAC

  reply	other threads:[~2019-12-22 16:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-21 14:30 [PATCH] fscrypt: Restore modular support Herbert Xu
2019-12-21 23:44 ` Eric Biggers
2019-12-22  8:41   ` [v2 PATCH] fscrypt: Allow modular crypto algorithms Herbert Xu
2019-12-22 16:45     ` Eric Biggers [this message]
2019-12-23  7:46       ` [v3 " Herbert Xu
2019-12-24 22:38         ` Eric Biggers
2019-12-27  2:47           ` [v4 " Herbert Xu
2020-01-03 17:04             ` Eric Biggers
2019-12-24 11:44 ` [PATCH] fscrypt: Restore modular support kbuild test robot
2019-12-24 11:44   ` kbuild test robot
2019-12-24 11:58 ` kbuild test robot
2019-12-24 11:58   ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191222164545.GA157733@zzz.localdomain \
    --to=ebiggers@kernel.org \
    --cc=chandan@linux.vnet.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jaegeuk@kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.