OpenSSL cross-compile for ARM
Hi group, I just built OpenSSL on my FC8 system for my ARM processor. The build went well but failed the 'make test' with this: $ make test Doing certs touch rehash.time testing... make[1]: Entering directory `/src/ARM/openssl/openssl-0.9.8h/test' make[2]: Entering directory `/src/ARM/openssl/openssl-0.9.8h' making all in apps... make[3]: Entering directory `/src/ARM/openssl/openssl-0.9.8h/apps' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/src/ARM/openssl/openssl-0.9.8h/apps' make[2]: Leaving directory `/src/ARM/openssl/openssl-0.9.8h' ../util/shlib_wrap.sh ./destest ../util/shlib_wrap.sh: line 91: /src/ARM/openssl/openssl-0.9.8h/test/destest: cannot execute binary file ../util/shlib_wrap.sh: line 91: /src/ARM/openssl/openssl-0.9.8h/test/destest: Success make[1]: *** [test_des] Error 1 make[1]: Leaving directory `/src/ARM/openssl/openssl-0.9.8h/test' make: *** [tests] Error 2 I also can't find libcrytpo.so, I have libvcrypto.a and libssl.a, but no *.so files? Where does the build put them?? -- William Estrada mrumun...@popdial.com Mt-Umunhum-Wireless.net ( http://64.124.13.3 ) Ymessenger: MrUmunhum __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1801] [BUGFIX] Segment fault when invoking AES_cbc_encrypt() on x86_64 with short input
On Wed, 2008-12-17 at 22:30 +0800, Andy Polyakov via RT wrote:
Fix two bugs in .Lcbc_slow_enc_in_place.
- At end of .Lcbc_slow_enc_in_place, %r10 instead of $_len should be
set to 16.
- In .Lcbc_slow_enc_in_place, %rdi should be initialized before stosb.
Thanks. The problem is addressed but in different way, see
http://cvs.openssl.org/chngview?cn=17698.
Signed-off-by: Huang Ying ying.hu...@intel.com
---
crypto/aes/asm/aes-x86_64.pl |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/crypto/aes/asm/aes-x86_64.pl
+++ b/crypto/aes/asm/aes-x86_64.pl
@@ -1994,10 +1994,12 @@ AES_cbc_encrypt:
??? What is it for version you have? In CVS .Lcbc_slow_enc_in_place
resided at line #1974! A.
I use CVS. It's an issue of patch sequence, I put another personal patch
before this one.
And, I find with the simple test program attached with the mail. The
output of CVS is different from that of openssl-0.9.8g if the specified
input length is less than 16.
Best Regards,
Huang Ying
#include openssl/aes.h
#include stdio.h
#include assert.h
#include stdlib.h
#include string.h
void print_arr(unsigned char buf[], int sz, char *prefix)
{
int i;
if (prefix)
printf(%s, prefix);
for (i = 0; i sz; i++)
printf(%02x, buf[i]);
printf(\n);
}
void test_cbc1(int in_len)
{
int ret;
AES_KEY key;
unsigned char user_key[16] = 123456;
unsigned char iv1[16] = 9876543210987654;
unsigned char iv2[16];
unsigned char in[16] = 1234567890;
unsigned char out[16];
memcpy(iv2, iv1, sizeof(iv1));
ret = AES_set_encrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(in, out, in_len, key, iv1, 1);
print_arr(out, sizeof(out),out: );
//AES_cbc_encrypt(in, in, in_len, key, iv2, 1);
//print_arr(in, sizeof(in), ip_out: );
ret = AES_set_decrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(out, in, in_len, key, iv2, 0);
print_arr(in, sizeof(in),out: );
}
void test_cbc2(int in_len)
{
int ret;
AES_KEY key;
unsigned char user_key[16] = 123456;
unsigned char iv1[16] = 9876543210987654;
unsigned char iv2[16];
unsigned char in[32] = 12345678901234567890123456789012;
unsigned char out[32];
in_len += 16;
memcpy(iv2, iv1, sizeof(iv1));
ret = AES_set_encrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(in, out, in_len, key, iv1, 1);
print_arr(out, sizeof(out), out: );
ret = AES_set_decrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(out, in, in_len, key, iv2, 0);
print_arr(in, sizeof(in), in: );
}
void test_cbc3(int in_len)
{
int ret;
AES_KEY key;
unsigned char user_key[16] = 123456;
unsigned char iv1[16] = 9876543210987654;
unsigned char iv2[16];
unsigned char in[80] = 1234567890123456789012345678901234567890
1234567890123456789012345678901234567890;
unsigned char out[80];
in_len += 64;
memcpy(iv2, iv1, sizeof(iv1));
ret = AES_set_encrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(in, out, in_len, key, iv1, 1);
print_arr(out, sizeof(out), out: );
ret = AES_set_decrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(out, in, in_len, key, iv2, 0);
print_arr(in, sizeof(in), in: );
}
int main(int argc, char *argv[])
{
int in_len;
in_len = argc 1 ? atoi(argv[1]) : 16;
test_cbc1(in_len);
test_cbc2(in_len);
test_cbc3(in_len);
return 0;
}
signature.asc
Description: This is a digitally signed message part
Re: [openssl.org #1801] [BUGFIX] Segment fault when invoking AES_cbc_encrypt() on x86_64 with short input
On Wed, 2008-12-17 at 22:30 +0800, Andy Polyakov via RT wrote:
Fix two bugs in .Lcbc_slow_enc_in_place.
- At end of .Lcbc_slow_enc_in_place, %r10 instead of $_len should be
set to 16.
- In .Lcbc_slow_enc_in_place, %rdi should be initialized before stosb.
Thanks. The problem is addressed but in different way, see
http://cvs.openssl.org/chngview?cn=17698.
Signed-off-by: Huang Ying ying.hu...@intel.com
---
crypto/aes/asm/aes-x86_64.pl |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/crypto/aes/asm/aes-x86_64.pl
+++ b/crypto/aes/asm/aes-x86_64.pl
@@ -1994,10 +1994,12 @@ AES_cbc_encrypt:
??? What is it for version you have? In CVS .Lcbc_slow_enc_in_place
resided at line #1974! A.
I use CVS. It's an issue of patch sequence, I put another personal patch
before this one.
And, I find with the simple test program attached with the mail. The
output of CVS is different from that of openssl-0.9.8g if the specified
input length is less than 16.
Best Regards,
Huang Ying
#include openssl/aes.h
#include stdio.h
#include assert.h
#include stdlib.h
#include string.h
void print_arr(unsigned char buf[], int sz, char *prefix)
{
int i;
if (prefix)
printf(%s, prefix);
for (i = 0; i sz; i++)
printf(%02x, buf[i]);
printf(\n);
}
void test_cbc1(int in_len)
{
int ret;
AES_KEY key;
unsigned char user_key[16] = 123456;
unsigned char iv1[16] = 9876543210987654;
unsigned char iv2[16];
unsigned char in[16] = 1234567890;
unsigned char out[16];
memcpy(iv2, iv1, sizeof(iv1));
ret = AES_set_encrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(in, out, in_len, key, iv1, 1);
print_arr(out, sizeof(out),out: );
//AES_cbc_encrypt(in, in, in_len, key, iv2, 1);
//print_arr(in, sizeof(in), ip_out: );
ret = AES_set_decrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(out, in, in_len, key, iv2, 0);
print_arr(in, sizeof(in),out: );
}
void test_cbc2(int in_len)
{
int ret;
AES_KEY key;
unsigned char user_key[16] = 123456;
unsigned char iv1[16] = 9876543210987654;
unsigned char iv2[16];
unsigned char in[32] = 12345678901234567890123456789012;
unsigned char out[32];
in_len += 16;
memcpy(iv2, iv1, sizeof(iv1));
ret = AES_set_encrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(in, out, in_len, key, iv1, 1);
print_arr(out, sizeof(out), out: );
ret = AES_set_decrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(out, in, in_len, key, iv2, 0);
print_arr(in, sizeof(in), in: );
}
void test_cbc3(int in_len)
{
int ret;
AES_KEY key;
unsigned char user_key[16] = 123456;
unsigned char iv1[16] = 9876543210987654;
unsigned char iv2[16];
unsigned char in[80] = 1234567890123456789012345678901234567890
1234567890123456789012345678901234567890;
unsigned char out[80];
in_len += 64;
memcpy(iv2, iv1, sizeof(iv1));
ret = AES_set_encrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(in, out, in_len, key, iv1, 1);
print_arr(out, sizeof(out), out: );
ret = AES_set_decrypt_key(user_key, 128, key);
assert(!ret);
AES_cbc_encrypt(out, in, in_len, key, iv2, 0);
print_arr(in, sizeof(in), in: );
}
int main(int argc, char *argv[])
{
int in_len;
in_len = argc 1 ? atoi(argv[1]) : 16;
test_cbc1(in_len);
test_cbc2(in_len);
test_cbc3(in_len);
return 0;
}
signature.asc
Description: PGP signature
Re: OpenSSL cross-compile for ARM
You are cross-compiling, which means that the platform that you're on cannot actually run the binaries that it builds. If you do not have any .so files, it may not be able to create shared libraries in that environment. The .a files, in that case, are static libraries. -Kyle H On Sun, Dec 21, 2008 at 2:06 PM, William Estrada mrumun...@popdial.com wrote: Hi group, I just built OpenSSL on my FC8 system for my ARM processor. The build went well but failed the 'make test' with this: $ make test Doing certs touch rehash.time testing... make[1]: Entering directory `/src/ARM/openssl/openssl-0.9.8h/test' make[2]: Entering directory `/src/ARM/openssl/openssl-0.9.8h' making all in apps... make[3]: Entering directory `/src/ARM/openssl/openssl-0.9.8h/apps' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/src/ARM/openssl/openssl-0.9.8h/apps' make[2]: Leaving directory `/src/ARM/openssl/openssl-0.9.8h' ../util/shlib_wrap.sh ./destest ../util/shlib_wrap.sh: line 91: /src/ARM/openssl/openssl-0.9.8h/test/destest: cannot execute binary file ../util/shlib_wrap.sh: line 91: /src/ARM/openssl/openssl-0.9.8h/test/destest: Success make[1]: *** [test_des] Error 1 make[1]: Leaving directory `/src/ARM/openssl/openssl-0.9.8h/test' make: *** [tests] Error 2 I also can't find libcrytpo.so, I have libvcrypto.a and libssl.a, but no *.so files? Where does the build put them?? -- William Estrada mrumun...@popdial.com Mt-Umunhum-Wireless.net ( http://64.124.13.3 ) Ymessenger: MrUmunhum __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1801] [BUGFIX] Segment fault when invoking AES_cbc_encrypt() on x86_64 with short input
--- a/crypto/aes/asm/aes-x86_64.pl +++ b/crypto/aes/asm/aes-x86_64.pl @@ -1994,10 +1994,12 @@ AES_cbc_encrypt: ??? What is it for version you have? In CVS .Lcbc_slow_enc_in_place resided at line #1974! A. I use CVS. It's an issue of patch sequence, I put another personal patch before this one. I should have guessed:-) And, I find with the simple test program attached with the mail. The output of CVS is different from that of openssl-0.9.8g if the specified input length is less than 16. The bug was present even in 0.9.8 and it was addressed at the same time, see http://cvs.openssl.org/chngview?cn=17699. For reference. One can argue that AES_cbc_encrypt could just as well require padded input, i.e. length divisible by 16. One can even argue that nobody is passing length not divisible by 16 anyway(*) and doing so wouldn't break anything. But the thing is that it's the way OpenSSL is (*all* cbc procedures are like this) and as it has been around for a while, it's hardly appropriate to change, as there is no way of knowing if anybody is dependent on this behavior. A. (*) most notably EVP (which by the way is *the* recommended interface to OpenSSL) does *not* pass length not divisible by 16, which is how bug is bound to slip through EVP-based tests. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #1595] [Bug] Text relocations in optimized libcrypto.so
I intend to dismiss this case as not our, but for-Debian-to-fix problem. Naturally with reservation for keeping my eyes open for possible solution in perlasm. Solution that will work with all supported platforms but even without -Bsymbolic, just for completeness sake. Though it will be low prio as we have no plans for stopping using -Bsymbolic. As closing note. crypto/perlasm in HEAD branch contains complete solution to the originating problem. The HEAD version was verified to work as drop-in replacement even in in 0.9.8-stable context, so those who insist on omitting -Bsymbolic can copy perlasm from HEAD to address the problem. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[PATCH RFC -v2] Add support to Intel AES-NI instruction set for x86_64 platform
This patch adds support to Intel AES-NI instruction set for x86_64 platform. Intel AES-NI is a new set of Single Instruction Multiple Data (SIMD) instructions that are going to be introduced in the next generation of Intel processor, as of 2009. These instructions enable fast and secure data encryption and decryption, using the Advanced Encryption Standard (AES), defined by FIPS Publication number 197. The architecture introduces six instructions that offer full hardware support for AES. Four of them support high performance data encryption and decryption, and the other two instructions support the AES key expansion procedure. The white paper can be downloaded from: http://softwarecommunity.intel.com/isn/downloads/intelavx/AES-Instructions-Set_WP.pdf AES-NI support is implemented as an engine in crypto/engine/. ChangeLog: v2: - AES-NI support is implemented as an engine instead of branch. - ECB and CBC modes are implemented in parallel style to take advantage of pipelined hardware implementation. - AES key scheduling algorithm is re-implemented with higher performance. Known issues: - How to add conditional compilation for eng_intel_asm.pl? It can not be compiled on non-x86 platform. - NID for CTR mode can not be found, how to support it in engine? - CFB1, CFB8, OFB1, OFB8 modes are not supported. If it is necessary to add AES-NI support for them, I can add them. Signed-off-by: Huang Ying ying.hu...@intel.com --- crypto/engine/Makefile | 11 crypto/engine/eng_all.c|3 crypto/engine/eng_intel.c | 589 ++ crypto/engine/eng_intel_asm.pl | 918 + 4 files changed, 1519 insertions(+), 2 deletions(-) --- /dev/null +++ b/crypto/engine/eng_intel.c @@ -0,0 +1,589 @@ +/* + * Support for Intel AES-NI intruction set + * Author: Huang Ying ying.hu...@intel.com + * + * Some code is copied from engines/e_padlock.c + * + * cfb and ofb mode code is copied from crypto/aes/aes_cfb.c and + * crypto/aes/aes_ofb.c. + */ + +/* + * Copyright (c) 1999-2001 The OpenSSL Project. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in + *the documentation and/or other materials provided with the + *distribution. + * + * 3. All advertising materials mentioning features or use of this + *software must display the following acknowledgment: + *This product includes software developed by the OpenSSL Project + *for use in the OpenSSL Toolkit. (http://www.OpenSSL.org/) + * + * 4. The names OpenSSL Toolkit and OpenSSL Project must not be used to + *endorse or promote products derived from this software without + *prior written permission. For written permission, please contact + *licens...@openssl.org. + * + * 5. Products derived from this software may not be called OpenSSL + *nor may OpenSSL appear in their names without prior written + *permission of the OpenSSL Project. + * + * 6. Redistributions of any form whatsoever must retain the following + *acknowledgment: + *This product includes software developed by the OpenSSL Project + *for use in the OpenSSL Toolkit (http://www.OpenSSL.org/) + * + * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY + * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR + * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR + * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, + * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED + * OF THE POSSIBILITY OF SUCH DAMAGE. + * + * + * This product includes cryptographic software written by Eric Young + * (e...@cryptsoft.com). This product includes software written by Tim + * Hudson (t...@cryptsoft.com). + * + */ + + +#include openssl/opensslconf.h + +#if !defined(OPENSSL_NO_HW) !defined(OPENSSL_NO_HW_INTEL_AES_NI) !defined(OPENSSL_NO_AES) + +#define INTEL_AES_MIN_ALIGN16 +#define ALIGN(x,a) (((unsigned long)(x)+(a)-1)(~((a)-1))) +#define INTEL_AES_ALIGN(x)
