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 )
On Sun, Jan 29, 2017 at 10:31:59PM +0100, Arkadiusz Miskiewicz wrote:
> 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:
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
On Mon, Jan 30, 2017 at 05:42:35PM +0100, Arkadiusz Miśkiewicz wrote:
> On Monday 30 of January 2017, Eric Biggers wrote:
>
> > 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.)
>
> (hardcoded) loading of pcbc fixed my problem, intel-aesni loaded fine and luks
> partition unlocked correctly.
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.
Reported-by: Arkadiusz Miśkiewicz <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index 7ad0ed7..93de8ea 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -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
On Wed, Feb 01, 2017 at 05:08:03PM +0100, Arkadiusz Miśkiewicz wrote:
>
> q: Will later loading of pcbc (so intel-aseni loaded from initrd, no pcbc
> available, rootfs gets mounted; pcbc is loaded) enable its "functionality" for
> intel-aesni just like it would be available at intel-aesni load time ?
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