RFR 8216597: SIGBUS in Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047

[David Holmes]

Hi Martin,

I applied your patch and ran it through tier4 testing on sparc but it 
still exhibited the SIGBUS crashes.

I can't help with the request to get a code dump sorry.

David
-----

PS. I don't follow security-dev. Thanks to Sean for the heads up.

> Hi,
> 
> After integrating JDK-6913047 [0] [1], a bug affecting Solaris SPARC was
> found. See JDK-8216597 [2] for further details.
> 
> This bug has been likely caused by an unaligned memory access.
> jdk-submit repo tests passed before integrating so it was not noticed.
> 
> There are a few direct memory accesses when loading attribute values
> (obtained from the 1st query) to the info array buffer, pointed by
> nativeKeyInfoArrayRawCkAttributesPtr:
> 
>   (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).type =
> (ckpAttributes+i)->type;
>   (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).ulValueLen =
> (ckpAttributes+i)->ulValueLen;
>   (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).pValue =
> nativeKeyInfoArrayRawDataPtr;
>   (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).pValue = 0;
>   (*(CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributesPtr).type =
> CKA_NETSCAPE_DB;
> 
> There is also a direct read access:
> 
>  *(CK_BBOOL*)(((CK_ATTRIBUTE_PTR)(((CK_ATTRIBUTE_PTR)nativeKeyInfoArrayRawCkAttributes)+sensitiveAttributePosition))->pValue
> 
> Whether or not these are 64-bit aligned depends on the value returned by
> GetByteArrayElements: if the buffer is not 8-bytes aligned (but 4),
> unaligned accesses would occur. This is unlikely though. Adding
> sizeof(unsigned long) to nativeKeyInfoArrayRawCkAttributesPtr first
> value should not cause issues because 1) sizeof(unsigned long) is 8 [3]
> and 2) CK_ATTRIBUTE alignment is 8 (larger member is a pointer).
> 
> Looks to me that the problem is caused when reading the CK_BBOOL value.
> This is a pointer to the data side of the buffer and there are no
> alignment guarantees there at all: data is compacted (to save space).
> 
> I cannot confirm because I'm unable to reproduce in my environment.
> However, and under the described hypothesis, I propose this patch:
> 
>  * http://cr.openjdk.java.net/~mbalao/webrevs/8216597/8216597.webrev.00/
>  * http://cr.openjdk.java.net/~mbalao/webrevs/8216597/8216597.webrev.00.zip
> 
> Can someone try it?
> 
> In case it fails again, I'd be grateful if someone can dump all the
> SPARC bytes of Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo
> function so I can see exactly what the instruction at 0x2e4 offset is
> (for the build without this patch).
> 
> @David Holmes: even though wrappedKeySizeWrappedKeyArrayPtr may have an
> unaligned value, looks to me that it's not directly used to access
> memory but used through memcpy.
> 
> Thanks,
> Martin.-
> 
> --
> [0] - https://bugs.openjdk.java.net/browse/JDK-6913047
> [1] - http://hg.openjdk.java.net/jdk/jdk/rev/5170dc2bcf64
> [2] - https://bugs.openjdk.java.net/browse/JDK-8216597
> [3] -
> https://docs.oracle.com/cd/E18752_01/html/817-6223/chp-typeopexpr-2.html