JDK-8130341 : GHASH 32bit intrinsics has AEADBadTagException
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-07-02
  • Updated: 2020-01-16
  • Resolved: 2015-07-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9 Other
8u221Fixed 9 b75Fixed openjdk8u232Fixed
Related Reports
Duplicate :  
JDK-8131159 - com/sun/crypto/provider/Cipher/AES/TestGHASH.java failed with java.lang.NullPointerException
Duplicate :  
JDK-8130650 - com/sun/net/httpserver/Test6a.jia failed java.io.IOException: Error writing request body to server
Relates :  
JDK-8073108 - Use x86 and SPARC CPU instructions for GHASH acceleration
Description
Test compiler/codegen/7184394/TestAESMain.java  fails with the following exception:

javax.crypto.AEADBadTagException: Tag mismatch!
	at com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:517)
	at com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1037)
	at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:974)
	at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:479)
	at javax.crypto.Cipher.doFinal(Cipher.java:2377)
	at TestAESDecode.run(TestAESDecode.java:41)
	at TestAESMain.main(TestAESMain.java:83)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:502)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:92)
	at java.lang.Thread.run(Thread.java:745)

This exception doesn't happen with -XX:-UseGHASHIntrinsics (see JDK-8073108). Reproduces only on 32-bit builds. Have seen failures on linux and windows
Comments
Approved this together with JDK-8073108. Next time please add a proper 'Fix Request' comment!
26-11-2019
A review for the 8u backport of this fix has been requested by Yuri Gaevsky here: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-October/010437.html
21-11-2019
The symptoms of the failure after the test was fixed were random. My perf test failed in different parts of the GCM jdk stack, sometimes reporting a null pointer which was impossible; TestAESMain would fail mostly with TAG mismatch, but not always; and finally my reflection test to GHASH.java:processBlocks() which never failed. All tests worked fine in 64bit, making the 32bit assembly the obvious cause, but the reflection test contradicting that. Something was messing with memory randomly. Putting a save/restore of the registers around the assembly fixed the problem, clearly something in the stack was using a register that I had taken. I wonder if I'm only protecting against a bug somewhere else in the VM which assumes it has exclusive use of a register that it should not.
09-07-2015
I don't think its a random number issue. It looks like it fails intermittent as my perf test works about 3/4ths the time.. I'm suspicious of the assembly function given everything else is common code with 64bit. There are a couple problems with the test, one of which is that update(aad) should have used update(AAD), that I've fixed in my local copy. However I'm still seeing failures despite changes.
09-07-2015
ILW=incorrect behavior;AES-GCM 32bit intel, cpu specific;-XX:-UseGHASHIntrinsics=HLM=>P3
06-07-2015
Also there is a question why the test updates cipher text instead of AAD. I think in http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ce0c612ea443#l22.45 should be a cipher.updateAAD(aad) invoked instead of update(aad). But this minor question doesn't relates to the failure. Test fails both ways.
03-07-2015
It always reproduces with different random numbers. I don't think that this causes failures. It fails on 32 bit VM only
03-07-2015
Additional flags -server -Xmixed could be ignored since they are default values. Could be random number cause it.
02-07-2015
----------messages:(3/206)---------- command: main -Xbatch -DcheckOutput=true -Dmode=GCM TestAESMain reason: User specified action: run main/othervm/timeout=600 -Xbatch -DcheckOutput=true -Dmode=GCM TestAESMain elapsed time (seconds): 28.582 ----------System.out:(25/1727)---------- 1000000 iterations For random generator using seed: -6207549479708760575 To re-run test with same seed value please add "-Djdk.test.lib.random.seed=-6207549479708760575" to command line.
02-07-2015
cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 45 model name : Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz stepping : 7 cpu MHz : 1200.000 cache size : 20480 KB physical id : 0 siblings : 16 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 x2apic popcnt aes xsave avx lahf_lm ida arat epb xsaveopt pln pts dts tpr_shadow vnmi flexpriority ept vpid bogomips : 5785.70 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual
02-07-2015