RFR(L): 8002074: Support for AES on SPARC

Wed Nov 20 11:16:20 PST 2013

This looks good.

Thanks,
Vladimir

On 11/20/13 11:00 AM, Shrinivas Joshi wrote:
> Hi Vladimir, Vitaly,
>
> Thanks again for reviewing this change. Please find updated webrev at
> http://cr.openjdk.java.net/~kvn/8002074/webrev.03/ which incorporates
> the changes that you suggested.
>
> -Shrinivas
>
> On 11/15/2013 12:30 PM, Shrinivas Joshi wrote:
>> Hi Vladimir,
>>
>> Thanks for the feedback. I will make these changes and update the webrev.
>>
>> -Shrinivas
>>
>> On 11/15/2013 12:22 PM, Vladimir Kozlov wrote:
>>> Shrinivas,
>>>
>>> I suggested before to use loops to generated less code lines in
>>> stubs. For example, next:
>>>
>>> +     // load expanded key
>>> +     __ ldf(FloatRegisterImpl::D, key, 0, F0);
>>> +     __ ldf(FloatRegisterImpl::D, key, 8, F2);
>>> +     ...
>>> +     __ ldf(FloatRegisterImpl::D, key, 152, F38);
>>>
>>> could be replaced with
>>>
>>>     // load expanded key
>>>     for (int i = 0; i < 40; i += 2) {
>>>       __ ldf(FloatRegisterImpl::D, key, i*4, as_FloatRegister(i));
>>>     }
>>>
>>> Next:
>>>
>>> +     __ aes_eround01(F4, F54, F56, F58); //round 1
>>> +     __ aes_eround23(F6, F54, F56, F60);
>>> +     __ aes_eround01(F8, F58, F60, F54); //round 2
>>> +     __ aes_eround23(F10, F58, F60, F56);
>>>       ...
>>> +     __ aes_eround01(F36, F54, F56, F58); //round 9
>>> +     __ aes_eround23(F38, F54, F56, F60);
>>>
>>> could be:
>>>
>>>     for (int i = 4; i < 36; i += 8) {
>>>       __ aes_eround01(as_FloatRegister(i  ), F54, F56, F58); //round 1
>>>       __ aes_eround23(as_FloatRegister(i+2), F54, F56, F60);
>>>       __ aes_eround01(as_FloatRegister(i+4), F58, F60, F54); //round 2
>>>       __ aes_eround23(as_FloatRegister(i+6), F58, F60, F56);
>>>     }
>>>     __ aes_eround01(F36, F54, F56, F58); //round 9
>>>     __ aes_eround23(F38, F54, F56, F60);
>>>
>>>
>>> And other places where there is repetitive pattern.
>>>
>>> Thanks,
>>> Vladimir
>>>
>>> On 11/14/13 6:34 PM, Shrinivas Joshi wrote:
>>>> Hi,
>>>>
>>>> Can I please request reviews for the following change? Target JDK
>>>> release for this change would be the next update of JDK 8 / JDK 9.
>>>>
>>>> Thanks,
>>>> -Shrinivas
>>>>
>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8002074
>>>> Webrev: http://cr.openjdk.java.net/~kvn/8002074/webrev.02/
>>>>
>>>> Summary: This change adds intrinsics/stub routines support for
>>>> single-block and multi-block (as used by Cipher Block Chaining mode)
>>>> AES
>>>> encryption and decryption operations on the SPARC platform. These
>>>> intrinsics are available only when the application is configured to use
>>>> SunJCE crypto provider. These stubs make use of efficient hardware AES
>>>> instructions and thus offer significant performance improvements over
>>>> JITed code. AES intrinsics are enabled by default on SPARC platforms
>>>> that support AES instructions. They can be explicitly enabled or
>>>> disabled on the command-line using UseAES and UseAESIntrinsics JVM
>>>> flags.
>>>>
>>>> Summary of source code changes:
>>>>     * src/cpu/sparc/vm/assembler_sparc.hpp
>>>>        - Adds support for all 3-operand and 4-operand SPARC AES
>>>> instructions. Also adds support for floating-point XOR (FXORs/FXORd)
>>>> instructions. FXOR instructions are used in the AES stub routines
>>>>     * src/cpu/sparc/vm/stubGenerator_sparc.cpp
>>>>        - Defines stubs for single-block and multi-block AES encryption
>>>> and decryption routines supporting all key sizes (128-bit, 192-bit and
>>>> 256-bit).
>>>>        - Current SPARC AES decryption instructions are not compatible
>>>> with SunJCE expanded decryption key format. Thus decryption stubs read
>>>> the original key (passed as an input parameter) and perform decryption
>>>> key expansion using hardware instructions.
>>>>        - Multi-block decryption stub can perform decryption for 2 *
>>>> 16-byte blocks at a time.
>>>>        - Encryption stubs use SunJCE expanded encryption key as
>>>> their is
>>>> no incompatibility issue between SPARC AES encryption instructions and
>>>> SunJCE expanded encryption keys.
>>>>     * src/cpu/sparc/vm/sparc.ad, src/cpu/x86/vm/x86.ad and
>>>> src/share/vm/opto/matcher.hpp
>>>>        - The additional original key array reference parameter is
>>>> required only on the SPARC platform. This code guards it from being
>>>> passed to the x86 AES stub routines.
>>>>     * src/cpu/sparc/vm/vm_version_sparc.cpp,
>>>> src/cpu/sparc/vm/vm_version_sparc.hpp and
>>>> src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp
>>>>        - Detect AES capabilities of the underlying CPU.
>>>>        - Enable UseAES and UseAESIntrinsics flags if the underlying CPU
>>>> supports AES instructions and neither of them is explicitly disabled on
>>>> the command-line. Generate warning message if either of these flags are
>>>> enabled on the command-line whereas the underlying CPU does not support
>>>> AES instructions.
>>>>     * src/share/vm/classfile/vmSymbols.hpp
>>>>        - Fix for "8012900: CICO ignores AAD in GCM mode" changes return
>>>> type of com.sun.crypto.provider.CipherBlockChaining.encrypt() and
>>>> com.sun.crypto.provider.CipherBlockChaining.decrypt() from void to int.
>>>> Method signature in intrinsics definition had to be changed
>>>> accordingly.
>>>>     * src/share/vm/opto/library_call.cpp
>>>>        - Adds a new method to read 'lastKey' field of
>>>> com.sun.crypto.provider.AESCrypt class which holds the original key.
>>>>        - Passes additional input parameter, original key array
>>>> reference, to the AES stubs only on the SPARC platform.
>>>>        - Addresses change in return value from 'void' to 'int' in case
>>>> of multi-block CBC stubs.
>>>>     * src/share/vm/opto/runtime.cpp
>>>>        - Reads the additional input parameter (original key reference)
>>>> only on SPARC platform.
>>>>        - Addresses change in return value from 'void' to 'int' in case
>>>> of multi-block CBC stubs.
>>>>     * hotspot/test/compiler/7184394/TestAESMain.java
>>>>        - This test case was contributed as part of the x86 AES
>>>> intrinsics work by Tom Deneau @AMD. Fixed incorrect nano-second to
>>>> milli-second conversion code. Added warm-up phase since this test case
>>>> can also be used for performance testing.
>>>>
>>>> Testing: jtreg, ctw, nsk and JPRT
>>>
>>>
>>
>>
>>
>