On Fri, Sep 20 2019 at 3:21pm -0400,
Milan Broz <gmazyland@xxxxxxxxx> wrote:
> On 20/09/2019 19:37, Mike Snitzer wrote:
> > On Fri, Sep 20 2019 at 11:44am -0400,
> > Thibaut Sautereau <thibaut.sautereau@xxxxxxxxxxx> 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
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
