RFR: 8073108: GHASH Intrinsics

[Anthony Scarpino]

On 02/17/2015 10:41 AM, Vladimir Kozlov wrote:
> On 2/17/15 10:31 AM, Anthony Scarpino wrote:
>> On 02/16/2015 06:01 PM, Vladimir Kozlov wrote:
>>> There is #ifdef _WIN64 in stubGenerator_x86_32.cpp. It is not needed
>>> since it is 32-bit code.
>>
>> Sure.. Do I still need to save the xmm6 and xmm7 on 32bit code, or is
>> all of the register saving only for Windows 64bit?
>
> No, in 32-bit you don't need to save xmm6 and xmm7.

Ok, thanks

>
>>
>>>
>>> I see you switched off -DcheckOutput=false for GCM testing and return
>>> from compareArrays() after length compare. Is it because it can't be
>>> done or you did not have time to add needed code?
>>
>> I'll have to double check, but I believe -DcheckOutput can be turned
>> back on.  I suspect I never updated the @run lines after I changed
>> compareArrays()
>
> In void compareArrays(byte b[], byte exp[]) {
>
> You have:
>
> +    if (mode.equals("GCM"))
> +      return;
>       for (int i=0; i< exp.length; i++) {
>         if (b[i] != exp[i]) {
>
> So current changes do not compare arrays elements for GCM. That is why I
> asked.

I did this because there are checks in GCM to prevent reusing IVs.  The 
current design of the hotspot test reuses IVs so that the encrypted or 
decrypted result is returned o compare, which is ok for CBC and ECB. 
Since I wasn't able to get a reproducible result for GCM, I skipped the 
array checking.  What I am depending on to test GCM is the TestGHASH 
test in the jdk repo, which is a Known Answer Test, to make sure the 
GHASH intrinsics are correct to the spec.

All that being said, I will look at this again.  I originally didn't 
want to completely redesign the hotspot tests when I had TestGHASH 
already, but I'll go back to see what changes I can do to hopefully get 
compareArrays working.

Tony