4.10 aesni-intel no longer having lrw/ablk_helper dependencies?

Hi.

[arekm@xps ~]$ modinfo --set-version 4.9.6 aesni-intel | grep depends
depends: glue_helper,aes-x86_64,lrw,cryptd,ablk_helper

[arekm@xps ~]$ modinfo --set-version 4.10.0-rc5-00161-gfd694aaa46c7 aesni- intel |grep depends
depends: glue_helper,aes-x86_64,crypto_simd,cryptd

With 4.10.0 lrw and ablk_helper are no longer in dependencies while aesni-intel seem to still need these. My luks encrypted rootfs fails to unlock. Initrd generation script only installs modules based on dependencies and that seems to be a reason for luks unlock failure with 4.10rc - some missing modules.

Failure looks like that:

$ insmod path/to/aesni-intel.ko
dmesg gets logged:
"AVX2 version of gcm_enc/dec engaged
AES CTR mode by8 optimization enabled."
and insmod reports that it cannot insert aesni-intel because of unresolved 
symbol or unknown option but nothing more is logged in dmesg.

4.9.x works fine.

What did change/how to figure out deps now?

Both modules exist:
[arekm@xps ~]$ modinfo --set-version 4.10.0-rc5-00161-gfd694aaa46c7 lrw
filename: /lib/modules/4.10.0-rc5-00161-
gfd694aaa46c7/kernel/crypto/lrw.ko.xz

alias:          crypto-lrw
alias:          lrw
description:    LRW block cipher mode
license:        GPL
depends:        gf128mul
intree:         Y
vermagic:       4.10.0-rc5-00161-gfd694aaa46c7 SMP preempt mod_unload
signat:         PKCS#7

signer:
sig_key:
sig_hashalgo: md4

[arekm@xps ~]$ modinfo --set-version 4.10.0-rc5-00161-gfd694aaa46c7 ablk_helper
filename: /lib/modules/4.10.0-rc5-00161-
gfd694aaa46c7/kernel/crypto/ablk_helper.ko.xz

license:        GPL
depends:        cryptd
intree:         Y
vermagic:       4.10.0-rc5-00161-gfd694aaa46c7 SMP preempt mod_unload
signat:         PKCS#7

signer:
sig_key:
sig_hashalgo: md4

Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

Hi Arkadiusz,

First, aesni-intel no longer includes an LRW implementation itself. Instead, the generic LRW module must be selected. Internally it will use the aesni-intel accelerated ECB algorithm if available. So you need to make sure that the "lrw" module is included in the initrd if it's not already.

But I think the bigger problem is that aesni-intel couldn't be insmod'ed at all, which shouldn't happen. The problem might actually be related to the "pcbc" algorithm. Upon initialization, aesni-intel now tries to wrap "pcbc(__aes-aesni)" with the "fpu" template. This will fail if the "pcbc" module hasn't been inserted. I think this wasn't a problem before because the old code using ablk_helper instead of crypto_simd didn't try to find "pcbc" until someone asked for it, while now aesni-intel will try to find it immediately. And since aesni-intel has no direct dependency on pcbc, I'm guessing what happened is that pcbc didn't end up in your initrd even though it may have been built. (You can verify this by adding pcbc to your initrd and seeing if that works around the problem.)

Herbert, would it make any sense to solve this by creating a real dependency of aesni-intel on pcbc, by making aesni-intel reference an exported symbol in pcbc if IS_ENABLED(CONFIG_PCBC)? Or do you / did you have something else in mind?

I also think it's kind of weird that aesni-intel has to do anything with pcbc at all since it doesn't actually implement pcbc specifically; it's just wrapping it in the "fpu" template to avoid so many calls to kernel_fpu_begin/kernel_fpu_end. I wonder if there is a better solution to this, maybe even optimizing kernel_fpu_begin/kernel_fpu_end so that the wrapping isn't needed.

Eric

Thanks for the report. Does this patch fix the problem?

---8<---
Subject: crypto: aesni - Fix failure when pcbc module is absent

When aesni is built as a module together with pcbc, the pcbc module must be present for aesni to load. However, the pcbc module may not be present for reasons such as its absence on initramfs. This patch allows the aesni to function even if the pcbc module is enabled but not present.

index 7ad0ed7..93de8ea 100644
@@ -1089,9 +1089,9 @@ static void aesni_free_simds(void)
 		    aesni_simd_skciphers[i]; i++)
 		simd_skcipher_free(aesni_simd_skciphers[i]);
 
-	for (i = 0; i < ARRAY_SIZE(aesni_simd_skciphers2) &&
-		    aesni_simd_skciphers2[i].simd; i++)
-		simd_skcipher_free(aesni_simd_skciphers2[i].simd);
+	for (i = 0; i < ARRAY_SIZE(aesni_simd_skciphers2); i++)
+		if (aesni_simd_skciphers2[i].simd)
+			simd_skcipher_free(aesni_simd_skciphers2[i].simd);
 }
 
 static int __init aesni_init(void)

@@ -1172,7 +1172,7 @@ static int __init aesni_init(void)
 		simd = simd_skcipher_create_compat(algname, drvname, basename);
 		err = PTR_ERR(simd);
 		if (IS_ERR(simd))
-			goto unregister_simds;
+			continue;
 
 		aesni_simd_skciphers2[i].simd = simd;
 	}

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

No it won't but it's no big deal as pcbc(aes) isn't actually used anywhere so it's really just an example of using fpu. AFAIK pcbc is only ever used with fcrypt.

Cheers,

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt