The following issue has been fixed with the patch attached to this post (it has been verified to work on my setup).
Here's some comment from the author (Nikos Mavrogiannopoulos) on the issue: "It seems the openssl digests option was never tested with cryptodev. The code as I understand it wouldn't work with either openbsd or linux cryptodev. The attached patch fixes the issues found and makes some optimizations for cryptodev-linux (without sacrificing openbsd cryptodev support)." Regards, Frank > -----Original Message----- > From: owner-openssl-us...@openssl.org [mailto:owner-openssl- > us...@openssl.org] On Behalf Of Frank > Sent: Monday, February 20, 2012 13:11 > To: openssl-users@openssl.org > Subject: segfault with cryptodev in openssl 1.0.0g > > Hi, > > I get the following segfault when connecting to openssl s_server > w/tls1.0 when cryptodev is enabled (openssl 1.0.0g on Debian Wheezy on > armv5 eabi, recompiled with -DHAVE_CRYPTODEV), and with cryptodev-linux > (1.1) providing the cryptodev interface: > > (gdb) run s_server -cert default_blank.crt -key default_blank.key - > accept 8888 -WWW -tls1 > > memcpy () at ../ports/sysdeps/arm/memcpy.S:100 > 100 ../ports/sysdeps/arm/memcpy.S: No such file or directory. > in ../ports/sysdeps/arm/memcpy.S > (gdb) bt > #0 memcpy () at ../ports/sysdeps/arm/memcpy.S:100 > #1 0xb6ecb760 in cryptodev_digest_copy (to=<optimized out>, > from=<optimized out>) at eng_cryptodev.c:820 > #2 0xb6edac18 in EVP_MD_CTX_copy_ex (out=0xbeffed34, in=0x9b860) at > digest.c:324 > #3 0xb6fa6014 in tls1_mac (ssl=0x9ac30, md=0xbeffedb8 "\214\202߶", > send=0) at t1_enc.c:918 > #4 0xb6f9f398 in ssl3_get_record (s=0x9ac30) at s3_pkt.c:464 > #5 ssl3_read_bytes (s=0x9ac30, type=-1226870784, buf=0x0, len=654540, > peek=0) at s3_pkt.c:961 > #6 0xb6fa0b80 in ssl3_get_message (s=0x9ac30, st1=<optimized out>, > stn=8609, mt=-1, max=514, ok=0xbeffeea4) at s3_both.c:426 > #7 0xb6f95490 in ssl3_get_cert_verify (s=0x9ac30) at s3_srvr.c:2708 > #8 0xb6f96b18 in ssl3_accept (s=0x9ac30) at s3_srvr.c:582 > #9 0xb6f9f844 in ssl3_read_bytes (s=0x9ac30, type=-1224751056, > buf=0xb6ffcf40 "\312\343\370\266\024ii\r", len=-1090523196, peek=0) at > s3_pkt.c:941 > #10 0xb6f9d00c in ssl3_read_internal (s=0x9ac30, buf=0x99c28, len=4096, > peek=0) at s3_lib.c:3274 > #11 0xb6faf1f4 in SSL_read (s=<optimized out>, buf=<optimized out>, > num=<optimized out>) at ssl_lib.c:954 > #12 0xb6fbb6f8 in ssl_read (b=0x9bc38, out=0x99c28 "N", outl=4096) at > bio_ssl.c:168 > #13 0xb6ecd938 in BIO_read (b=0x9bc38, out=0x99c28, outl=4096) at > bio_lib.c:212 > #14 0xb6ed0c6c in buffer_gets (b=0x99bb8, buf=0x95bb0 "N", size=16382) > at bf_buff.c:494 > #15 0xb6ecdcb4 in BIO_gets (b=0x99bb8, in=0x95bb0 "N", inl=16383) at > bio_lib.c:313 > #16 0x000391f0 in ?? () > #17 0x000391f0 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt > stack?) > > Is this a bug in the cryptodev engine of openssl 1.0.0g? > > Regards, > Frank
cryptodev-digests.diff
Description: Binary data
