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@xxxxxxxxxx> 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@xxxxxxxxxx> > 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@xxxxxxxxxx> > Acked-by: Eric Biggers <ebiggers@xxxxxxxxxx> > Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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
