Re: Error in generic/397 test script?

[Eric Biggers <ebiggers@kernel.org>]

On Mon, Jan 20, 2025 at 09:46:29AM -0800, Eric Biggers wrote:
> On Mon, Jan 20, 2025 at 05:41:40PM +0000, David Howells wrote:
> > Eric Biggers <ebiggers@kernel.org> wrote:
> > 
> > > It would be enlightening to understand what the issue was here.  Did you
> > > explicitly disable these options, overriding the imply, without providing a
> > > replacement?  Or was this another issue specific to unmerged kernel patches?
> > 
> > I enabled CONFIG_FS_ENCRYPTION in addition to the options I normally use, but
> > didn't realise I needed to enable CONFIG_CRYPTO_XTS as well.
> > 
> > David
> > 
> 
> So you had an explicit '# CONFIG_CRYPTO_XTS is not set' somewhere in your
> kconfig that overrode the imply, right?
> 
> Wondering if the following commit should maybe be reconsidered:
> 
>     commit a0fc20333ee4bac1147c4cf75dea098c26671a2f
>     Author: Ard Biesheuvel <ardb@kernel.org>
>     Date:   Wed Apr 21 09:55:10 2021 +0200
> 
>         fscrypt: relax Kconfig dependencies for crypto API algorithms
>         
>         Even if FS encryption has strict functional dependencies on various
>         crypto algorithms and chaining modes. those dependencies could potentially
>         be satisified by other implementations than the generic ones, and no link
>         time dependency exists on the 'depends on' claused defined by
>         CONFIG_FS_ENCRYPTION_ALGS.
>         
>         So let's relax these clauses to 'imply', so that the default behavior
>         is still to pull in those generic algorithms, but in a way that permits
>         them to be disabled again in Kconfig.
>         
>         Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
>         Acked-by: Eric Biggers <ebiggers@google.com>
>         Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

By the way, CRYPTO_XTS is basically useless.  E.g. on x86_64 you really want
CRYPTO_AES_NI_INTEL.  I should probably throw in a selection of that (similar to
what CONFIG_WIREGUARD does where it selects optimized code for each arch),
though I've been hoping for this to be properly solved at the crypto API level.

- Eric