* dm-crypt error when CONFIG_CRYPTO_AUTHENC is disabled @ 2019-09-20 15:44 Thibaut Sautereau 2019-09-20 17:37 ` Mike Snitzer 0 siblings, 1 reply; 7+ messages in thread From: Thibaut Sautereau @ 2019-09-20 15:44 UTC (permalink / raw) To: dm-devel, Alasdair Kergon, Mike Snitzer; +Cc: linux-kernel Hi, I just got a dm-crypt "crypt: Error allocating crypto tfm" error when trying to "cryptsetup open" a volume. I found out that it was only happening when I disabled CONFIG_CRYPTO_AUTHENC. drivers/md/dm-crypt.c includes the crypto/authenc.h header and seems to use some CRYPTO_AUTHENC-related stuff. Therefore, shouldn't CONFIG_DM_CRYPT select CONFIG_CRYPTO_AUTHENC? -- Thibaut Sautereau CLIP OS developer ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dm-crypt error when CONFIG_CRYPTO_AUTHENC is disabled 2019-09-20 15:44 dm-crypt error when CONFIG_CRYPTO_AUTHENC is disabled Thibaut Sautereau @ 2019-09-20 17:37 ` Mike Snitzer 2019-09-20 19:21 ` Milan Broz 0 siblings, 1 reply; 7+ messages in thread From: Mike Snitzer @ 2019-09-20 17:37 UTC (permalink / raw) To: Thibaut Sautereau, Milan Broz; +Cc: dm-devel, Alasdair Kergon, linux-kernel On Fri, Sep 20 2019 at 11:44am -0400, Thibaut Sautereau <thibaut.sautereau@clip-os.org> wrote: > Hi, > > I just got a dm-crypt "crypt: Error allocating crypto tfm" error when > trying to "cryptsetup open" a volume. I found out that it was only > happening when I disabled CONFIG_CRYPTO_AUTHENC. > > drivers/md/dm-crypt.c includes the crypto/authenc.h header and seems to > use some CRYPTO_AUTHENC-related stuff. Therefore, shouldn't > CONFIG_DM_CRYPT select CONFIG_CRYPTO_AUTHENC? Yes, it looks like commit ef43aa38063a6 ("dm crypt: add cryptographic data integrity protection (authenticated encryption)") should've added 'select CRYPTO_AUTHENC' to dm-crypt's Kconfig. I'll let Milan weigh-in but that seems like the right way forward. Thanks for your report! Mike ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dm-crypt error when CONFIG_CRYPTO_AUTHENC is disabled 2019-09-20 17:37 ` Mike Snitzer @ 2019-09-20 19:21 ` Milan Broz 2019-09-20 21:27 ` Mike Snitzer 0 siblings, 1 reply; 7+ messages in thread From: Milan Broz @ 2019-09-20 19:21 UTC (permalink / raw) To: Mike Snitzer, Thibaut Sautereau; +Cc: dm-devel, Alasdair Kergon, linux-kernel On 20/09/2019 19:37, Mike Snitzer wrote: > On Fri, Sep 20 2019 at 11:44am -0400, > Thibaut Sautereau <thibaut.sautereau@clip-os.org> wrote: > >> Hi, >> >> I just got a dm-crypt "crypt: Error allocating crypto tfm" error when >> trying to "cryptsetup open" a volume. I found out that it was only >> happening when I disabled CONFIG_CRYPTO_AUTHENC. >> >> drivers/md/dm-crypt.c includes the crypto/authenc.h header and seems to >> use some CRYPTO_AUTHENC-related stuff. Therefore, shouldn't >> CONFIG_DM_CRYPT select CONFIG_CRYPTO_AUTHENC? > > Yes, it looks like commit ef43aa38063a6 ("dm crypt: add cryptographic > data integrity protection (authenticated encryption)") should've added > 'select CRYPTO_AUTHENC' to dm-crypt's Kconfig. I'll let Milan weigh-in > but that seems like the right way forward. No, I don't this so. It is like you use some algorithm that is just not compiled-in, or it is disabled in the current state (because of FIPS mode od so) - it fails to initialize it. I think we should not force dm-crypt to depend on AEAD - most users do not use authenticated encryption, it is perfectly ok to keep this compiled out. I do not see any principal difference from disabling any other crypto (if you disable XTS mode, it fails to open device that uses it). IMO the current config dependence is ok. Milan ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: dm-crypt error when CONFIG_CRYPTO_AUTHENC is disabled 2019-09-20 19:21 ` Milan Broz @ 2019-09-20 21:27 ` Mike Snitzer 2019-09-20 21:47 ` [dm-devel] " Eric Biggers 0 siblings, 1 reply; 7+ messages in thread From: Mike Snitzer @ 2019-09-20 21:27 UTC (permalink / raw) To: Milan Broz; +Cc: Thibaut Sautereau, dm-devel, Alasdair Kergon, linux-kernel On Fri, Sep 20 2019 at 3:21pm -0400, Milan Broz <gmazyland@gmail.com> wrote: > On 20/09/2019 19:37, Mike Snitzer wrote: > > On Fri, Sep 20 2019 at 11:44am -0400, > > Thibaut Sautereau <thibaut.sautereau@clip-os.org> wrote: > > > >> Hi, > >> > >> I just got a dm-crypt "crypt: Error allocating crypto tfm" error when > >> trying to "cryptsetup open" a volume. I found out that it was only > >> happening when I disabled CONFIG_CRYPTO_AUTHENC. > >> > >> drivers/md/dm-crypt.c includes the crypto/authenc.h header and seems to > >> use some CRYPTO_AUTHENC-related stuff. Therefore, shouldn't > >> CONFIG_DM_CRYPT select CONFIG_CRYPTO_AUTHENC? > > > > Yes, it looks like commit ef43aa38063a6 ("dm crypt: add cryptographic > > data integrity protection (authenticated encryption)") should've added > > 'select CRYPTO_AUTHENC' to dm-crypt's Kconfig. I'll let Milan weigh-in > > but that seems like the right way forward. > > No, I don't this so. It is like you use some algorithm that is just not compiled-in, > or it is disabled in the current state (because of FIPS mode od so) - it fails > to initialize it. > > I think we should not force dm-crypt to depend on AEAD - most users > do not use authenticated encryption, it is perfectly ok to keep this compiled out. > > I do not see any principal difference from disabling any other crypto > (if you disable XTS mode, it fails to open device that uses it). > > IMO the current config dependence is ok. That is a good point. I hadn't considered the kernel compiles just fine without CRYPTO_AUTHENC.. which it clearly does. SO I retract the question/thought of updating the Kconfig for dm-crypt in my previous mail. Though in hindsight: wonder whether the dm-integrity based dm-crypt authenticated encryption support should have been exposed as a proper CONFIG option within the DM_CRYPT section? Rather than lean on the crypto subsystem to happily stub out the dm-crypt AEAD and AUTHENC related code dm-crypt could've established #ifdef boundaries for that code. I'm open to suggestions and/or confirmation that the way things are now is perfectly fine. But I do see this report as something that should drive some improvement. Mike ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-devel] dm-crypt error when CONFIG_CRYPTO_AUTHENC is disabled 2019-09-20 21:27 ` Mike Snitzer @ 2019-09-20 21:47 ` Eric Biggers 2019-09-23 8:20 ` Thibaut Sautereau 0 siblings, 1 reply; 7+ messages in thread From: Eric Biggers @ 2019-09-20 21:47 UTC (permalink / raw) To: Mike Snitzer Cc: Milan Broz, Thibaut Sautereau, dm-devel, Alasdair Kergon, linux-kernel On Fri, Sep 20, 2019 at 05:27:46PM -0400, Mike Snitzer wrote: > On Fri, Sep 20 2019 at 3:21pm -0400, > Milan Broz <gmazyland@gmail.com> wrote: > > > On 20/09/2019 19:37, Mike Snitzer wrote: > > > On Fri, Sep 20 2019 at 11:44am -0400, > > > Thibaut Sautereau <thibaut.sautereau@clip-os.org> wrote: > > > > > >> Hi, > > >> > > >> I just got a dm-crypt "crypt: Error allocating crypto tfm" error when > > >> trying to "cryptsetup open" a volume. I found out that it was only > > >> happening when I disabled CONFIG_CRYPTO_AUTHENC. > > >> > > >> drivers/md/dm-crypt.c includes the crypto/authenc.h header and seems to > > >> use some CRYPTO_AUTHENC-related stuff. Therefore, shouldn't > > >> CONFIG_DM_CRYPT select CONFIG_CRYPTO_AUTHENC? > > > > > > Yes, it looks like commit ef43aa38063a6 ("dm crypt: add cryptographic > > > data integrity protection (authenticated encryption)") should've added > > > 'select CRYPTO_AUTHENC' to dm-crypt's Kconfig. I'll let Milan weigh-in > > > but that seems like the right way forward. > > > > No, I don't this so. It is like you use some algorithm that is just not compiled-in, > > or it is disabled in the current state (because of FIPS mode od so) - it fails > > to initialize it. > > > > I think we should not force dm-crypt to depend on AEAD - most users > > do not use authenticated encryption, it is perfectly ok to keep this compiled out. > > > > I do not see any principal difference from disabling any other crypto > > (if you disable XTS mode, it fails to open device that uses it). > > > > IMO the current config dependence is ok. > > That is a good point. I hadn't considered the kernel compiles just fine > without CRYPTO_AUTHENC.. which it clearly does. > > SO I retract the question/thought of updating the Kconfig for dm-crypt > in my previous mail. > > Though in hindsight: wonder whether the dm-integrity based dm-crypt > authenticated encryption support should have been exposed as a proper > CONFIG option within the DM_CRYPT section? Rather than lean on the > crypto subsystem to happily stub out the dm-crypt AEAD and AUTHENC > related code dm-crypt could've established #ifdef boundaries for that > code. > > I'm open to suggestions and/or confirmation that the way things are now > is perfectly fine. But I do see this report as something that should > drive some improvement. > FWIW, I think you're being saved right now by the craziness in the crypto subsystem Kconfig options: CONFIG_DM_CRYPT selects CONFIG_CBC, which selects CONFIG_CRYPTO_MANAGER, which selects CONFIG_CRYPTO_MANAGER2, which selects CONFIG_CRYPTO_AEAD2 (and all the other algorithm types, for that matter). This makes the AEAD API available. If this wasn't the case, dm-crypt's use of crypto_alloc_aead() would be causing a link error in some kernel configurations, since CONFIG_DM_CRYPT doesn't actually select the AEAD API itself. At some point I (or someone else up to the task) might try to fix the crypto subsystem to not make every template select every algorithm type. In that happens, we'll need to update the users like dm-crypt to explicitly select the algorithm types they're using, if they were being implicitly selected before. In any case, allowing users to compile out the AEAD support in dm-crypt would also be nice if it's not too difficult, since not everyone needs it. - Eric ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-devel] dm-crypt error when CONFIG_CRYPTO_AUTHENC is disabled 2019-09-20 21:47 ` [dm-devel] " Eric Biggers @ 2019-09-23 8:20 ` Thibaut Sautereau 2019-09-23 9:46 ` Milan Broz 0 siblings, 1 reply; 7+ messages in thread From: Thibaut Sautereau @ 2019-09-23 8:20 UTC (permalink / raw) To: Mike Snitzer, Milan Broz, dm-devel, Alasdair Kergon, linux-kernel On Fri, Sep 20, 2019 at 02:47:59PM -0700, Eric Biggers wrote: > On Fri, Sep 20, 2019 at 05:27:46PM -0400, Mike Snitzer wrote: > > On Fri, Sep 20 2019 at 3:21pm -0400, > > Milan Broz <gmazyland@gmail.com> wrote: > > > > > On 20/09/2019 19:37, Mike Snitzer wrote: > > > > On Fri, Sep 20 2019 at 11:44am -0400, > > > > Thibaut Sautereau <thibaut.sautereau@clip-os.org> wrote: > > > > > > > >> Hi, > > > >> > > > >> I just got a dm-crypt "crypt: Error allocating crypto tfm" error when > > > >> trying to "cryptsetup open" a volume. I found out that it was only > > > >> happening when I disabled CONFIG_CRYPTO_AUTHENC. > > > >> > > > >> drivers/md/dm-crypt.c includes the crypto/authenc.h header and seems to > > > >> use some CRYPTO_AUTHENC-related stuff. Therefore, shouldn't > > > >> CONFIG_DM_CRYPT select CONFIG_CRYPTO_AUTHENC? > > > > > > > > Yes, it looks like commit ef43aa38063a6 ("dm crypt: add cryptographic > > > > data integrity protection (authenticated encryption)") should've added > > > > 'select CRYPTO_AUTHENC' to dm-crypt's Kconfig. I'll let Milan weigh-in > > > > but that seems like the right way forward. > > > > > > No, I don't this so. It is like you use some algorithm that is just not compiled-in, > > > or it is disabled in the current state (because of FIPS mode od so) - it fails > > > to initialize it. > > > > > > I think we should not force dm-crypt to depend on AEAD - most users > > > do not use authenticated encryption, it is perfectly ok to keep this compiled out. > > > > > > I do not see any principal difference from disabling any other crypto > > > (if you disable XTS mode, it fails to open device that uses it). Fair enough. However, in the XTS case you mention, I think it's easier to remember that you set up XTS mode for your disk encryption and thus that you should enable it in your config. By the way, the CRYPTO_AUTHENC Kconfig help text only and specifically mentions IPsec, which can be a lot confusing for people trying to find out what option of which they got rid is actually causing an issue. On top of that, there's no hint in kernel logs about a particular algorithm, feature or Kconfig option that could be missing. Do we really expect people simply tuning their kernel configuration to go and read the source code to ensure they are not breaking their system? As for your "most users do not use authenticated encryption" argument, I agree, but note that cryptsetup with LUKS2 makes it quite easy to setup authenticated disk encryption, and I bet more and more people are using it. It's working most of the time because people are either using a distro kernel with everything enabled, or compiling their own one but being security-minded enough to use stuff like IPsec which then selects CRYPTO_AUTHENC. > > > > > > IMO the current config dependence is ok. > > > > That is a good point. I hadn't considered the kernel compiles just fine > > without CRYPTO_AUTHENC.. which it clearly does. > > > > SO I retract the question/thought of updating the Kconfig for dm-crypt > > in my previous mail. > > > > Though in hindsight: wonder whether the dm-integrity based dm-crypt > > authenticated encryption support should have been exposed as a proper > > CONFIG option within the DM_CRYPT section? Rather than lean on the > > crypto subsystem to happily stub out the dm-crypt AEAD and AUTHENC > > related code dm-crypt could've established #ifdef boundaries for that > > code. > > > > I'm open to suggestions and/or confirmation that the way things are now > > is perfectly fine. But I do see this report as something that should > > drive some improvement. > > > > FWIW, I think you're being saved right now by the craziness in the crypto > subsystem Kconfig options: CONFIG_DM_CRYPT selects CONFIG_CBC, which selects > CONFIG_CRYPTO_MANAGER, which selects CONFIG_CRYPTO_MANAGER2, which selects > CONFIG_CRYPTO_AEAD2 (and all the other algorithm types, for that matter). > This makes the AEAD API available. > > If this wasn't the case, dm-crypt's use of crypto_alloc_aead() would be causing > a link error in some kernel configurations, since CONFIG_DM_CRYPT doesn't > actually select the AEAD API itself. > > At some point I (or someone else up to the task) might try to fix the crypto > subsystem to not make every template select every algorithm type. In that > happens, we'll need to update the users like dm-crypt to explicitly select the > algorithm types they're using, if they were being implicitly selected before. > > In any case, allowing users to compile out the AEAD support in dm-crypt would > also be nice if it's not too difficult, since not everyone needs it. After reading all that, I'm wondering if this is not a good example of where the "imply" keyword should be used. Thanks for your hindsight, -- Thibaut Sautereau CLIP OS developer ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [dm-devel] dm-crypt error when CONFIG_CRYPTO_AUTHENC is disabled 2019-09-23 8:20 ` Thibaut Sautereau @ 2019-09-23 9:46 ` Milan Broz 0 siblings, 0 replies; 7+ messages in thread From: Milan Broz @ 2019-09-23 9:46 UTC (permalink / raw) To: Thibaut Sautereau, Mike Snitzer, dm-devel, Alasdair Kergon, linux-kernel On 23/09/2019 10:20, Thibaut Sautereau wrote: > > On top of that, there's no hint in kernel logs about a particular > algorithm, feature or Kconfig option that could be missing. Do we really > expect people simply tuning their kernel configuration to go and read > the source code to ensure they are not breaking their system? AFAIK all standard Linux kernels in distros have these options enabled, so it works out of the box. So it is the opposite view - if you are setting your kernel options, you need to dig much deeper... I can perhaps add some hint to userspace if this is detectable from errno though. Milan ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-09-23 9:47 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-09-20 15:44 dm-crypt error when CONFIG_CRYPTO_AUTHENC is disabled Thibaut Sautereau 2019-09-20 17:37 ` Mike Snitzer 2019-09-20 19:21 ` Milan Broz 2019-09-20 21:27 ` Mike Snitzer 2019-09-20 21:47 ` [dm-devel] " Eric Biggers 2019-09-23 8:20 ` Thibaut Sautereau 2019-09-23 9:46 ` Milan Broz
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).