| Message ID | 20150624141421.30466.28034.stgit@tstruk-mobl1 (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Herbert Xu |
| Headers | show |
On Wed, Jun 24, 2015 at 07:14:21AM -0700, Tadeusz Struk wrote: > rfc4106(gcm(aes)) uses cbc(aes) to generate hash key. cbc(aes) needs > chainiv, but the chainiv gets initialized after aesni_intel when both > are statically linked so the setkey fails. > This patch forces aesni_intel to be initialized after chainiv. > > Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> Aha, this could indeed the explain the setkey error that Linus saw. Once the AEAD conversion is complete this would actually become unnecessary because seqiv for blkcipher would disappear. Linus, could you confirm that you have AESNI built into the kernel and not as a module? However, this is still brittle because you have the same ordering issue with ctr. IOW aesni may be registered before ctr. In fact you don't actually need ctr here. You could just replace it with plain aes plus a xor. That should be more robust as you can then just use aesni for the aes and you wouldn't depend on anything external to aesni. Could you make a patch for that Tadeusz? Thanks!
On 06/25/2015 07:25 AM, Herbert Xu wrote: > On Wed, Jun 24, 2015 at 07:14:21AM -0700, Tadeusz Struk wrote: >> rfc4106(gcm(aes)) uses cbc(aes) to generate hash key. cbc(aes) needs >> chainiv, but the chainiv gets initialized after aesni_intel when both >> are statically linked so the setkey fails. >> This patch forces aesni_intel to be initialized after chainiv. >> >> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> > > Aha, this could indeed the explain the setkey error that Linus > saw. Once the AEAD conversion is complete this would actually > become unnecessary because seqiv for blkcipher would disappear. Yes, after the conversion is finished we can revert this patch. > > Linus, could you confirm that you have AESNI built into the kernel > and not as a module? > > However, this is still brittle because you have the same ordering > issue with ctr. IOW aesni may be registered before ctr. In fact > you don't actually need ctr here. You could just replace it with > plain aes plus a xor. So this will fix it for ctr too. > > That should be more robust as you can then just use aesni for the > aes and you wouldn't depend on anything external to aesni. > > Could you make a patch for that Tadeusz? I can start working on this after my vacation -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jun 25, 2015 at 7:25 AM, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > Linus, could you confirm that you have AESNI built into the kernel > and not as a module? Yes, confirmed. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c index ebcb981d..cb630a8 100644 --- a/arch/x86/crypto/aesni-intel_glue.c +++ b/arch/x86/crypto/aesni-intel_glue.c @@ -1537,7 +1537,7 @@ static void __exit aesni_exit(void) crypto_fpu_exit(); } -module_init(aesni_init); +late_initcall(aesni_init); module_exit(aesni_exit); MODULE_DESCRIPTION("Rijndael (AES) Cipher Algorithm, Intel AES-NI instructions optimized");
rfc4106(gcm(aes)) uses cbc(aes) to generate hash key. cbc(aes) needs chainiv, but the chainiv gets initialized after aesni_intel when both are statically linked so the setkey fails. This patch forces aesni_intel to be initialized after chainiv. Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> --- arch/x86/crypto/aesni-intel_glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html