Re: [openssl-dev] [openssl.org #3875] [PATCH] Add external X509_STORE to SSL_CTX

2015-06-18 Thread Short, Todd via RT
Updated this patch with new documentation.

Github link:
https://github.com/akamai/openssl/commit/34cd12929b479f0c229bb9d564e2d2eec3d8df5d

And attachment.
--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// One if by land, two if by sea, three if by the Internet.

On May 27, 2015, at 4:32 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add external X509_STORE to SSL_CTX

Add SSL_CTX_set_cert_store_ref() API to add an external X509_STORE to
an SSL_CTX. (There is no get API).
Github link:
https://github.com/akamai/openssl/commit/517559c8637cda3750b39017685742590f1b692e

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0018-Add-external-X509_STORE-to-SSL_CTX.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev




0018-RT3875-Add-external-X509_STORE-to-SSL_CTX.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)

2015-06-18 Thread gaurav maheshwari
It is compiling successfully and all openssl test are passing for ILP32
abi.
Thanks.

On Thu, Jun 18, 2015 at 4:22 PM, Andy Polyakov ap...@openssl.org wrote:

  I am compiling using the linaro aarch64 compiler for ILP32 ABI.
  *linux-armv4 *compilation
  with option -march =armv8_a  giving lots of compilation errors as
  compiler does not
  supports mnemonics.

 This is because toolchain referred to in one of previous messages is
 only capable of generating/compiling AArch64 code. linux-armv4 is
 equipped with AArch32 assembly and toolchain in question is indeed not
 capable of compiling it. But it doesn't mean that if you compile
 linux-armv4 target with right compiler you won't be able to run
 resulting binary code on AArch64 system. This actually works and worked
 from day one. Unlike abi=ilp32 that is (which is not actually
 upstream-ed yet according https://wiki.linaro.org/Platform/arm64-ilp32).
 Well, as for works from day one, you are likely to have to add 32-bit
 libc, but on Debian [or derivative] it's straightforward dpkg
 --add-architecture. Well, there also might be *processors* that don't
 support AArch32 (ARM specification allows it), but all those readily
 available now are all perfectly capable of executing linux-armv4
 targets. And when it comes to ARMv8 crypto extensions, they would
 deliver same performance as 64-bit code, so you don't loose anything.
 (Not to mention that binary can be universal and make best of any
 particular processor it executed on.)

  So I have tried to compile with new configuration
  for ilp32
  with aarch64_asm.
 
  linux-armilp32,gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
  SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK  DES_INT DES_UNROLL BF_PTR:
  ${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
  .so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
 
  In compilation with this configuration getting error* cannot represent
  BFD_RELOC_64 relocation in this object file format *in sha1-armv8.s.
 
  Obviously it would require some adjustments, because mabi=ilp32 was not
  considered when it was written. It might be sufficient to replace .quad
  with .long, but there is no way for me to tell for reasons discussed in
  the beginning. So that if there is some serious interest, then you have
  to explain yourself better than providing reference to
 releases.linaro.org.

 After having a look at available documentation, attached patch is likely
 to be sufficient to compile with -mabi=ilp32. But once again, I have no
 way to actually verify it and therefore no promises can be provided.


 ___
 openssl-dev mailing list
 To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)

2015-06-18 Thread Andy Polyakov
 It is compiling successfully and all openssl test are passing for ILP32
 abi.

There are remaining questions.

The fact that tests pass is definitely good sign, but there still is an
open and burning question. What if relocations were not resolved
correctly and run-time switch doesn't really work as intended. It's
possible to confirm this indirectly by comparing results for
'apps/openssl speed sha' and 'env OPENSSL_armcap=0 apps/openssl speed
sha'. Can you do that?

Development branch has more ARMv8 code. Can you test that too?

And last question is not really a question. All this ought to mean that
you have put together all those not-yet-upstreamed bits together, i.e.
glibc, multilib, kernel patches, huh? For public reference I want once
again to point out that additional ABI for AArch64 is work in very
progress, and so far the only way to compile 32-bit code and target
ARMv8 was to adhere to usual 32-bit ARM support (which does utilize
ARMv8 crypto extensions), and that is currently the supported way, for
good or bad.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3881] [PATCH] Instrument OpenSSL buffer heap memory usage

2015-06-18 Thread Short, Todd via RT
Updates to the buffer heap memory usage patch:
Updated documentation.

Github link:
https://github.com/akamai/openssl/commit/222f0d2d94be8b92c306c062320fd15b59a9000a

And attached file.

Thank you,

--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// One if by land, two if by sea, three if by the Internet.

On May 30, 2015, at 3:48 AM, Joy Tu via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description:  Instrument OpenSSL buffer heap memory usage

Added function to register callbacks to allocate and free data buffers.

These callbacks can then allocate and free the memory as needed, while
also recording buffer allocations.

This permits a user-definable implementation of FREE_BUFLIST, which has been 
removed.

(Yes, documentation is lacking at this point).

Github link:

https://github.com/akamai/openssl/commit/4a6d71bbd2f4fe38ebcbe2f9917a1c7fedd117f8

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0022-Instrument-OpenSSL-buffer-heap-memory-usage.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



0021-RT3881-Instrument-OpenSSL-buffer-heap-memory-usage.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3865] [Patch] Add DISALLOW_RENEGOTIATION option

2015-06-18 Thread Short, Todd via RT
Hello,

Please find an updated patch that includes updated documentation.

Github link:

https://github.com/akamai/openssl/commit/9f3a6ecb83e80cbfebc038a860d5ce63817e0098

Thanks.
--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// One if by land, two if by sea, three if by the Internet.

On May 26, 2015, at 2:56 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add DISALLOW_RENEGOTIATION option

Add support to disallow renegotiation in openssl
The bit definition may need to change when pulled.

Github link:
https://github.com/akamai/openssl/commit/fcab621995d55d8873a02a96d5a8157f38469ebb

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.

0010-Add-DISALLOW_RENEGOTIATION-option.patch
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev




0010-RT3865-Add-DISALLOW_RENEGOTIATION-option.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3868] [PATCH] Add SSL_get0_peer_certificate()

2015-06-18 Thread Short, Todd via RT
Hello,

We have an updated version of the patch that includes updated documentation.

GitHub link:
https://github.com/akamai/openssl/commit/980d0b6e67dce0088dcb49e6fa66bbb868f43000

And attachment

Thanks,

--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// One if by land, two if by sea, three if by the Internet.



0013-RT3868-Add-SSL_get0_peer_certificate.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3869] [PATCH] Add shared session lists in SSL_CTX

2015-06-18 Thread Short, Todd via RT
Hello,

We have an updated patch for this: updated documentation

Github link:
https://github.com/akamai/openssl/commit/246b86ee329c70cbf8c822e852cc31e1076d53fd

And attachment.

Thanks,
--
-Todd Short
// tsh...@akamai.com
// One if by land, two if by sea, three if by the Internet.

On May 26, 2015, at 4:29 PM, Short, Todd via RT r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add shared session lists in SSL_CTX

Support for shared session lists via SSL_CTX_share_session_cache().
Added locking during the sharing and cleanup.

Github link:
https://github.com/akamai/openssl/commit/fe1e4ac33a89e9176af0b645eafc2aaec5fc2266

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0014-Add-shared-session-lists-in-SSL_CTX.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev




0014-RT3869-Add-shared-session-lists-in-SSL_CTX.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3870] [PATCH] Async TLSEXT servername support.

2015-06-18 Thread Short, Todd via RT
Hello,

We have an updated patch for this, which includes updated documentation, 
unit-tests and copyright.

Github link:
https://github.com/akamai/openssl/commit/1f26946f7e5cf85b20c3b97a8c0e6a869f9a04fa

--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// One if by land, two if by sea, three if by the Internet.

On May 26, 2015, at 4:29 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Async TLSEXT servername support.

Adds support for processing the servername TLSEXT asynchronously,
using the SSL_WANT_EVENT mechanism (RT 3724).

Github link:
https://github.com/akamai/openssl/commit/0205cc4eee7084e65a69995293ad584f7da21fa9

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.

0015-Async-TLSEXT-servername-support.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



0015-RT3870-Async-TLSEXT-servername-support.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3874] [PATCH] Add certificate verify data to SSL struct

2015-06-18 Thread Short, Todd
Hello:

We have an updated patch with documentation for this.

Github link:
https://github.com/akamai/openssl/commit/e431afa72e77da4463c8cdcac8893336b9b32b04

And attachment.

Thanks,

--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// One if by land, two if by sea, three if by the Internet.

On May 27, 2015, at 4:32 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add certificate verify data to SSL struct

Add app_verify_callback and app_verify_arg to the SSL structure and add
SSL_SESSION_set_verify_result() API. The values are copied from the
SSL_CTX into the SSL. There is also an SSL_set_cert_verify_callback() API.

Github link:
https://github.com/akamai/openssl/commit/a7d729491c2dacd4dae01eb49e1ca3ff797133ff

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0017-Add-certificate-verify-data-to-SSL-struct.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3874] [PATCH] Add certificate verify data to SSL struct

2015-06-18 Thread Short, Todd via RT
Hello:

We have an updated patch with documentation for this.

Github link:
https://github.com/akamai/openssl/commit/e431afa72e77da4463c8cdcac8893336b9b32b04

And attachment.

Thanks,

--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// One if by land, two if by sea, three if by the Internet.

On May 27, 2015, at 4:32 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add certificate verify data to SSL struct

Add app_verify_callback and app_verify_arg to the SSL structure and add
SSL_SESSION_set_verify_result() API. The values are copied from the
SSL_CTX into the SSL. There is also an SSL_set_cert_verify_callback() API.

Github link:
https://github.com/akamai/openssl/commit/a7d729491c2dacd4dae01eb49e1ca3ff797133ff

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0017-Add-certificate-verify-data-to-SSL-struct.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] [openssl.org #3873] [PATCH] Add traffic counters

2015-06-18 Thread Short, Todd via RT
Hello,

We have an updated patch for this: includes documentation.

Github link:
https://github.com/akamai/openssl/commit/956053b4b4a6f374df939c3d830cb1a095428ac9

And attachment.

Thanks,
--
-Todd Short
// tsh...@akamai.commailto:tsh...@akamai.com
// One if by land, two if by sea, three if by the Internet.

On May 27, 2015, at 4:32 PM, Short, Todd via RT 
r...@openssl.orgmailto:r...@openssl.org wrote:

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add traffic counters

Add data counters to SSL structure bytes_written and bytes_read
Includes SSL_get_byte_counters() API.

Github link:
https://github.com/akamai/openssl/commit/517559c8637cda3750b39017685742590f1b692e

And attachment.

Thank you.
--
-Todd Short
// tsh...@akamai.com
// “One if by land, two if by sea, three if by the Internet.”

0016-Add-traffic-counters.patch___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev





0016-RT3873-Add-traffic-counters.patch
Description: Binary data
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] [openssl.org #3915] BUG/PATCH: ssl_sess.c no longer compiles when no-tlsext is specified

2015-06-18 Thread geoff_l...@mcafee.com via RT
From ticket 2720, it seems the official position is that no-tlsext is NOT 
supported.  However, for those who still try to use it, the recent fixes for 
CVE-2015-1791 seem to have introduced more problems for the 0.9.8 code base 
(and maybe others - not sure).

This report can be added to RT#2720.

@@ -151,12 +151,12 @@
 * the case of an error whilst halfway through constructing dest
 */
dest-ciphers = NULL;
 #ifndef OPENSSL_NO_TLSEXT
dest-tlsext_hostname = NULL;
-#endif
dest-tlsext_tick = NULL;
+#endif
memset(dest-ex_data, 0, sizeof(dest-ex_data));
 
/* We deliberately don't copy the prev and next pointers */
dest-prev = NULL;
dest-next = NULL;
@@ -185,20 +185,20 @@
dest-tlsext_hostname = BUF_strdup(src-tlsext_hostname);
if (dest-tlsext_hostname == NULL) {
goto err;
}
}
-#endif
 
if (ticket != 0) {
dest-tlsext_tick = BUF_memdup(src-tlsext_tick, 
src-tlsext_ticklen);
if(dest-tlsext_tick == NULL)
goto err;
} else {
dest-tlsext_tick_lifetime_hint = 0;
dest-tlsext_ticklen = 0;
}
+#endif
 
return dest;
 err:
SSLerr(SSL_F_SSL_SESSION_DUP, ERR_R_MALLOC_FAILURE);
SSL_SESSION_free(dest);


Geoff

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


[openssl-dev] HMAC ABI fix.

2015-06-18 Thread scott . opensshdev . 2015

Hi,

We use openssl extensively in our product, today we upgraded from openssl 
1.0.2b to 1.0.2c (we build everything from source so the ABI change from 
1.0.2a to 1.0.2b didn't affect us), and are seeing issues.  I think I have 
tracked it down to the lines below from HMAC_init_ex, which were introduced 
as part of the HMAC ABI fix (1030f89f5ea238820645e3d34049eb1bd30e81c4):


+/* If we are changing MD then we must have a key */
+if (md != NULL  md != ctx-md  (key == NULL || len  0))
+return 0;

previously you could call HMAC_init_ex with an evp_md and a NULL key, this 
would save the evp_md in the HMAC_ctx and return, now it just returns and 
on first call you need to provide both a key and an evp_md.  Before I go 
and modify our code, is this change intentional ?


The docs (http://www.openssl.org/docs/crypto/hmac.html) state:

HMAC_Init_ex() initialises or reuses a HMAC_CTX structure to use the 
function evp_md and key key. Either can be NULL, in which case the existing 
one will be reused. HMAC_CTX_init() must have been called before the first 
use of an HMAC_CTX in this function.


Thanks in advance for the clarification,

Scott Harrison

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] HMAC ABI fix.

2015-06-18 Thread Matt Caswell


On 18/06/15 23:55, scott.opensshdev.2...@scottrix.co.uk wrote:
 Hi,
 
 We use openssl extensively in our product, today we upgraded from
 openssl 1.0.2b to 1.0.2c (we build everything from source so the ABI
 change from 1.0.2a to 1.0.2b didn't affect us), and are seeing issues. 
 I think I have tracked it down to the lines below from HMAC_init_ex,
 which were introduced as part of the HMAC ABI fix
 (1030f89f5ea238820645e3d34049eb1bd30e81c4):
 
 +/* If we are changing MD then we must have a key */
 +if (md != NULL  md != ctx-md  (key == NULL || len  0))
 +return 0;
 
 previously you could call HMAC_init_ex with an evp_md and a NULL key,
 this would save the evp_md in the HMAC_ctx and return, now it just
 returns and on first call you need to provide both a key and an evp_md. 
 Before I go and modify our code, is this change intentional ?

Yes. The previous code was quite broken in this area - this change
seemed the least impact option without breaking the ABI and resolving
the issues.

 The docs (http://www.openssl.org/docs/crypto/hmac.html) state:
 
 HMAC_Init_ex() initialises or reuses a HMAC_CTX structure to use the
 function evp_md and key key. Either can be NULL, in which case the
 existing one will be reused. HMAC_CTX_init() must have been called
 before the first use of an HMAC_CTX in this function.

In order to reuse an existing one there has to be something there in the
first place to reuse - so whilst what you were doing worked, I don't
think that was guaranteed by the documentation! Although actually the
docs probably need updating because I don't think it ever makes sense to
change the MD and reuse the key (the previous code wouldn't have worked
doing this anyway).

Matt

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


Re: [openssl-dev] 32 bit compilation of armv8 assembly support(openssl-1.0.2a)

2015-06-18 Thread Andy Polyakov
 I am compiling using the linaro aarch64 compiler for ILP32 ABI.
 *linux-armv4 *compilation
 with option -march =armv8_a  giving lots of compilation errors as
 compiler does not
 supports mnemonics.

This is because toolchain referred to in one of previous messages is
only capable of generating/compiling AArch64 code. linux-armv4 is
equipped with AArch32 assembly and toolchain in question is indeed not
capable of compiling it. But it doesn't mean that if you compile
linux-armv4 target with right compiler you won't be able to run
resulting binary code on AArch64 system. This actually works and worked
from day one. Unlike abi=ilp32 that is (which is not actually
upstream-ed yet according https://wiki.linaro.org/Platform/arm64-ilp32).
Well, as for works from day one, you are likely to have to add 32-bit
libc, but on Debian [or derivative] it's straightforward dpkg
--add-architecture. Well, there also might be *processors* that don't
support AArch32 (ARM specification allows it), but all those readily
available now are all perfectly capable of executing linux-armv4
targets. And when it comes to ARMv8 crypto extensions, they would
deliver same performance as 64-bit code, so you don't loose anything.
(Not to mention that binary can be universal and make best of any
particular processor it executed on.)

 So I have tried to compile with new configuration
 for ilp32
 with aarch64_asm.

 linux-armilp32,gcc: -O3 -mabi=ilp32 -Wall::-D_REENTRANT::-ldl:
 SIXTY_FOUR_BIT RC4_CHAR RC4_CHUNK  DES_INT DES_UNROLL BF_PTR:
 ${aarch64_asm}::dlfcn:linux-shared:-fPIC:-mabi=ilp32:
 .so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),

 In compilation with this configuration getting error* cannot represent 
 BFD_RELOC_64 relocation in this object file format *in sha1-armv8.s.  
 
 Obviously it would require some adjustments, because mabi=ilp32 was not
 considered when it was written. It might be sufficient to replace .quad
 with .long, but there is no way for me to tell for reasons discussed in
 the beginning. So that if there is some serious interest, then you have
 to explain yourself better than providing reference to releases.linaro.org.

After having a look at available documentation, attached patch is likely
to be sufficient to compile with -mabi=ilp32. But once again, I have no
way to actually verify it and therefore no promises can be provided.

diff --git a/crypto/sha/asm/sha1-armv8.pl b/crypto/sha/asm/sha1-armv8.pl
index a8c08c2..5ef9dc2 100644
--- a/crypto/sha/asm/sha1-armv8.pl
+++ b/crypto/sha/asm/sha1-armv8.pl
@@ -171,7 +171,11 @@ $code.=___;
 .type	sha1_block_data_order,%function
 .align	6
 sha1_block_data_order:
+#ifdef	__ILP32__
+	ldrsw	x16,.LOPENSSL_armcap_P
+#else
 	ldr	x16,.LOPENSSL_armcap_P
+#endif
 	adr	x17,.LOPENSSL_armcap_P
 	add	x16,x16,x17
 	ldr	w16,[x16]
@@ -309,7 +313,11 @@ $code.=___;
 .long	0x8f1bbcdc,0x8f1bbcdc,0x8f1bbcdc,0x8f1bbcdc	//K_40_59
 .long	0xca62c1d6,0xca62c1d6,0xca62c1d6,0xca62c1d6	//K_60_79
 .LOPENSSL_armcap_P:
+#ifdef	__ILP32__
+.long	OPENSSL_armcap_P-.
+#else
 .quad	OPENSSL_armcap_P-.
+#endif
 .asciz	SHA1 block transform for ARMv8, CRYPTOGAMS by appro\@openssl.org
 .align	2
 .comm	OPENSSL_armcap_P,4,4
diff --git a/crypto/sha/asm/sha512-armv8.pl b/crypto/sha/asm/sha512-armv8.pl
index d009f3f..7d69f0f 100644
--- a/crypto/sha/asm/sha512-armv8.pl
+++ b/crypto/sha/asm/sha512-armv8.pl
@@ -169,7 +169,11 @@ $code.=___;
 $func:
 ___
 $code.=___	if ($SZ==4);
+#ifdef	__ILP32__
+	ldrsw	x16,.LOPENSSL_armcap_P
+#else
 	ldr	x16,.LOPENSSL_armcap_P
+#endif
 	adr	x17,.LOPENSSL_armcap_P
 	add	x16,x16,x17
 	ldr	w16,[x16]
@@ -311,7 +315,11 @@ $code.=___;
 .size	.LK$BITS,.-.LK$BITS
 .align	3
 .LOPENSSL_armcap_P:
+#ifdef	__ILP32__
+	.long	OPENSSL_armcap_P-.
+#else
 	.quad	OPENSSL_armcap_P-.
+#endif
 .asciz	SHA$BITS block transform for ARMv8, CRYPTOGAMS by appro\@openssl.org
 .align	2
 ___
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev