Re: [PATCH] Revert "fscrypt: relax Kconfig dependencies for crypto API algorithms"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 17 Feb 2025 at 19:53, Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
>
> From: Eric Biggers <ebiggers@xxxxxxxxxx>
>
> This mostly reverts commit a0fc20333ee4bac1147c4cf75dea098c26671a2f.
> Keep the relevant parts of the comment added by that commit.
>
> The problem with that commit is that it allowed people to create broken
> configurations that enabled FS_ENCRYPTION but not the mandatory
> algorithms.  An example of this can be found here:
> https://lore.kernel.org/r/1207325.1737387826@xxxxxxxxxxxxxxxxxxxxxx/
>
> The commit did allow people to disable specific generic algorithm
> implementations that aren't needed.  But that at best allowed saving a
> bit of code.  In the real world people are unlikely to intentionally and
> correctly make such a tweak anyway, as they tend to just be confused by
> what all the different crypto kconfig options mean.
>
> Of course we really need the crypto API to enable the correct
> implementations automatically, but that's for a later fix.
>
> Cc: Ard Biesheuvel <ardb@xxxxxxxxxx>
> Cc: David Howells <dhowells@xxxxxxxxxx>
> Cc: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx>
> ---
>  fs/crypto/Kconfig | 20 ++++++++------------
>  1 file changed, 8 insertions(+), 12 deletions(-)
>

Acked-by: Ard Biesheuvel <ardb@xxxxxxxxxx>

> diff --git a/fs/crypto/Kconfig b/fs/crypto/Kconfig
> index 5aff5934baa12..332d828fe6fa5 100644
> --- a/fs/crypto/Kconfig
> +++ b/fs/crypto/Kconfig
> @@ -22,24 +22,20 @@ config FS_ENCRYPTION
>  # as Adiantum encryption, then those other modes need to be explicitly enabled
>  # in the crypto API; see Documentation/filesystems/fscrypt.rst for details.
>  #
>  # Also note that this option only pulls in the generic implementations of the
>  # algorithms, not any per-architecture optimized implementations.  It is
> -# strongly recommended to enable optimized implementations too.  It is safe to
> -# disable these generic implementations if corresponding optimized
> -# implementations will always be available too; for this reason, these are soft
> -# dependencies ('imply' rather than 'select').  Only disable these generic
> -# implementations if you're sure they will never be needed, though.
> +# strongly recommended to enable optimized implementations too.
>  config FS_ENCRYPTION_ALGS
>         tristate
> -       imply CRYPTO_AES
> -       imply CRYPTO_CBC
> -       imply CRYPTO_CTS
> -       imply CRYPTO_ECB
> -       imply CRYPTO_HMAC
> -       imply CRYPTO_SHA512
> -       imply CRYPTO_XTS
> +       select CRYPTO_AES
> +       select CRYPTO_CBC
> +       select CRYPTO_CTS
> +       select CRYPTO_ECB
> +       select CRYPTO_HMAC
> +       select CRYPTO_SHA512
> +       select CRYPTO_XTS
>
>  config FS_ENCRYPTION_INLINE_CRYPT
>         bool "Enable fscrypt to use inline crypto"
>         depends on FS_ENCRYPTION && BLK_INLINE_ENCRYPTION
>         help
>
> base-commit: 0ad2507d5d93f39619fc42372c347d6006b64319
> --
> 2.48.1
>
>




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]
  Powered by Linux