You're using the legacy crypto implementation with that configuration. OpenSSL is not in the picture.
Looking at the diffs between master and feature-openssl, there's not much jumping out at me that would have resolved the problem. There are some changes to the Makefile. The only other difference that may impact alignment issues is the delta in crypto/include/cipher.h. Here's the delta: @@ -163,6 +163,7 @@ typedef err_status_t (*cipher_set_iv_func_t) #ifdef FORCE_64BIT_ALIGN int pad; #endif + int algorithm; } cipher_t; Maybe your compiler has laid-out this struct differently due to this new member. You might try applying this modification to master to see if that resolves the problem. If not, then I would suspect something in the Makefile deltas. On 07/18/2013 02:36 PM, Daniel Pocock wrote: > On 18/07/13 20:17, John Foley wrote: >> I should clarify this better. The legacy crypto is still in the >> branch. It's pulled out depending on how you've configured the >> library. Can you provide the ./configure options you used to build >> the library? > > I just ran > > ./configure && make runtest > > > This is my host > Linux smetana 2.6.32-5-sparc64-smp #1 SMP Mon Feb 25 02:19:08 UTC 2013 > sparc64 GNU/Linux > > On master, the first test case fails, it is the same error output from > Debian bug 628583, but they all run on the branch: > > Build done. Please run 'make runtest' to run self tests. > running libsrtp test applications... > crypto/test/cipher_driver -v >/dev/null > crypto/test/kernel_driver -v >/dev/null > test/rdbx_driver -v >/dev/null > test/srtp_driver -v >/dev/null > test/roc_driver -v >/dev/null > test/replay_driver -v >/dev/null > test/dtls_srtp_driver >/dev/null > cd test; /home/pocock/ws/srtp/srtp-git/test/rtpw_test.sh >/dev/null > ./rtpw: couldn't open file /usr/share/dict/words > /home/pocock/ws/srtp/srtp-git/test/rtpw_test.sh: 64: kill: No such process > > libsrtp test applications passed. > make -C crypto runtest > make[1]: Entering directory `/home/pocock/ws/srtp/srtp-git/crypto' > test/env # print out information on the build environment > CPU set to big-endian (WORDS_BIGENDIAN == 1) > CPU set to RISC (CPU_RISC == 1) > using native 64-bit type (NO_64_BIT_MATH == 0) > using stdout for error reporting (ERR_REPORTING_STDOUT == 1) > using /dev/urandom as a random source (DEV_URANDOM == /dev/urandom) > running crypto test applications... > test `test/aes_calc 000102030405060708090a0b0c0d0e0f > 00112233445566778899aabbccddeeff` = 69c4e0d86a7b0430d8cdb78070b4c55a > test `test/aes_calc > 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f > 00112233445566778899aabbccddeeff` = 8ea2b7ca516745bfeafc49904b496089 > test/cipher_driver -v >/dev/null > test/datatypes_driver -v >/dev/null > test/stat_driver >/dev/null > test/sha1_driver -v >/dev/null > test/kernel_driver -v >/dev/null > test/rand_gen -n 256 >/dev/null > crypto test applications passed. > > > > > > >> >> >> On 07/18/2013 02:12 PM, John Foley wrote: >>> Which test case was failing? It's possible the test case is no >>> longer included in the feature-openssl branch. I pulled out all the >>> legacy crypto and math from libsrtp in that branch. Have you >>> confirmed the failing test case is still run under the >>> feature-openssl branch? >>> >>> >>> On 07/18/2013 01:42 PM, Daniel Pocock wrote: >>>> >>>> Further observation: the feature-openssl branch from git does not >>>> have the bus error, test cases run successfully on SPARC >>>> >>>> >>>> >>>> >>>> >>>> On 18/07/13 19:34, Daniel Pocock wrote: >>>>> On 18/07/13 17:26, John Foley wrote: >>>>>> We've seen BUS errors on some platforms. I'm not confident the >>>>>> following patch was ever pushed back to libsrtp. There's a chance this >>>>>> may resolve the problem on sparc. Unfortunately I don't have a sparc >>>>>> system to try this myself. >>>>> >>>>> >>>>> Thanks for this feedback >>>>> >>>>> The patch doesn't apply - all but one hunk fails >>>>> >>>>> I tried it against the Debian source package and I also tried >>>>> applying it against the repository >>>>> >>>>> https://github.com/cisco/libsrtp >>>>> >>>>> Can you tell me the SVN URL where you got this and I can try >>>>> checking it out and building it? >>>>> >>>>> >>>>> >>>>> >>>>>> Modified: branches/proto/libsrtp_30/srtp/include/srtp.h >>>>>> =================================================================== >>>>>> --- branches/proto/libsrtp_30/srtp/include/srtp.h 2013-04-24 >>>>>> 19:44:23 UTC (rev 1292) >>>>>> +++ branches/proto/libsrtp_30/srtp/include/srtp.h 2013-04-29 >>>>>> 14:17:03 UTC (rev 1293) >>>>>> @@ -52,6 +52,11 @@ >>>>>> >>>>>> #ifdef _MSC_VER >>>>>> #pragma pack(4) >>>>>> +#define PACK >>>>>> +#elif defined(__GNUC__) >>>>>> +#define PACK __attribute__ ((packed)) >>>>>> +#else >>>>>> +#define PACK >>>>>> #endif >>>>>> >>>>>> #include "crypto_kernel.h" >>>>>> >>>>>> Modified: branches/proto/libsrtp_30/srtp/include/srtp_priv.h >>>>>> =================================================================== >>>>>> --- branches/proto/libsrtp_30/srtp/include/srtp_priv.h 2013-04-24 >>>>>> 19:44:23 UTC (rev 1292) >>>>>> +++ branches/proto/libsrtp_30/srtp/include/srtp_priv.h 2013-04-29 >>>>>> 14:17:03 UTC (rev 1293) >>>>>> @@ -68,7 +68,7 @@ >>>>>> * fully pack the bit fields. >>>>>> */ >>>>>> >>>>>> -typedef struct { >>>>>> +typedef struct PACK { >>>>>> unsigned char cc : 4; /* CSRC count */ >>>>>> unsigned char x : 1; /* header extension flag */ >>>>>> unsigned char p : 1; /* padding flag */ >>>>>> @@ -82,7 +82,7 @@ >>>>>> >>>>>> #else /* BIG_ENDIAN */ >>>>>> >>>>>> -typedef struct { >>>>>> +typedef struct PACK { >>>>>> unsigned char version : 2; /* protocol version */ >>>>>> unsigned char p : 1; /* padding flag */ >>>>>> unsigned char x : 1; /* header extension flag */ >>>>>> @@ -96,7 +96,7 @@ >>>>>> >>>>>> #endif >>>>>> >>>>>> -typedef struct { >>>>>> +typedef struct PACK { >>>>>> uint16_t profile_specific; /* profile-specific info >>>>>> */ >>>>>> uint16_t length; /* number of 32-bit words in extension >>>>>> */ >>>>>> } srtp_hdr_xtnd_t; >>>>>> @@ -111,7 +111,7 @@ >>>>>> >>>>>> #ifndef WORDS_BIGENDIAN >>>>>> >>>>>> -typedef struct { >>>>>> +typedef struct PACK { >>>>>> unsigned char rc : 5; /* reception report count */ >>>>>> unsigned char p : 1; /* padding flag */ >>>>>> unsigned char version : 2; /* protocol version */ >>>>>> @@ -120,7 +120,7 @@ >>>>>> uint32_t ssrc; /* synchronization source */ >>>>>> } srtcp_hdr_t; >>>>>> >>>>>> -typedef struct { >>>>>> +typedef struct PACK { >>>>>> unsigned int index : 31; /* srtcp packet index in network order! */ >>>>>> unsigned int e : 1; /* encrypted? 1=yes */ >>>>>> /* optional mikey/etc go here */ >>>>>> @@ -130,7 +130,7 @@ >>>>>> >>>>>> #else /* BIG_ENDIAN */ >>>>>> >>>>>> -typedef struct { >>>>>> +typedef struct PACK { >>>>>> unsigned char version : 2; /* protocol version */ >>>>>> unsigned char p : 1; /* padding flag */ >>>>>> unsigned char rc : 5; /* reception report count */ >>>>>> @@ -139,7 +139,7 @@ >>>>>> uint32_t ssrc; /* synchronization source */ >>>>>> } srtcp_hdr_t; >>>>>> >>>>>> -typedef struct { >>>>>> +typedef struct PACK { >>>>>> unsigned int version : 2; /* protocol version >>>>>> */ >>>>>> unsigned int p : 1; /* padding flag >>>>>> */ >>>>>> unsigned int count : 5; /* varies by packet type >>>>>> */ >>>>>> @@ -147,7 +147,7 @@ >>>>>> uint16_t length; /* len of uint32s of packet less header >>>>>> */ >>>>>> } rtcp_common_t; >>>>>> >>>>>> -typedef struct { >>>>>> +typedef struct PACK { >>>>>> unsigned int e : 1; /* encrypted? 1=yes */ >>>>>> unsigned int index : 31; /* srtcp packet index */ >>>>>> /* optional mikey/etc go here */ >>>>>> >>>>>> >>>>>> >>>>>> On 07/18/2013 10:51 AM, Jonathan Lennox wrote: >>>>>>> Sparc failing with "Bus Error" usually indicates an unaligned access. >>>>>>> Other platforms tolerate this, but at some performance cost, so it's >>>>>>> good to get rid of it across the board. I wouldn't expect it to be a >>>>>>> security vulnerability. >>>>>>> >>>>>>> Can you pull the current GIT repo to see if it fails the same way? >>>>>>> >>>>>>> On Jul 18, 2013, at 7:47 AM, Daniel Pocock <dan...@pocock.com.au> wrote: >>>>>>> >>>>>>>> There is a long outstanding bug in Debian for sparc, specifically, bus >>>>>>>> error in the test cases: >>>>>>>> >>>>>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628583 >>>>>>>> >>>>>>>> While the error only appears on sparc it may be indicative of other >>>>>>>> problems >>>>>>>> >>>>>>>> Given concern about the recent CVE-2013-2139 (buffer overflow) it might >>>>>>>> also be helpful to try and correct things like this that suggest some >>>>>>>> coding issues still exist >>>>>>>> >>>>>>>> Has anybody already looked at the issue in the past? Does the stack >>>>>>>> trace suggest any particular problem? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> See everything from the browser to the database with AppDynamics >>>>>>>> Get end-to-end visibility with application monitoring from AppDynamics >>>>>>>> Isolate bottlenecks and diagnose root cause in seconds. >>>>>>>> Start your free trial of AppDynamics Pro today! >>>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >>>>>>>> _______________________________________________ >>>>>>>> Srtp-development mailing list >>>>>>>> srtp-developm...@lists.sourceforge.net >>>>>>>> https://lists.sourceforge.net/lists/listinfo/srtp-development >>>>>>> -- >>>>>>> Jonathan Lennox >>>>>>> jonat...@vidyo.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> See everything from the browser to the database with AppDynamics >>>>>>> Get end-to-end visibility with application monitoring from AppDynamics >>>>>>> Isolate bottlenecks and diagnose root cause in seconds. >>>>>>> Start your free trial of AppDynamics Pro today! >>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >>>>>>> _______________________________________________ >>>>>>> Srtp-development mailing list >>>>>>> srtp-developm...@lists.sourceforge.net >>>>>>> https://lists.sourceforge.net/lists/listinfo/srtp-development >>>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> See everything from the browser to the database with AppDynamics >>>>>> Get end-to-end visibility with application monitoring from AppDynamics >>>>>> Isolate bottlenecks and diagnose root cause in seconds. >>>>>> Start your free trial of AppDynamics Pro today! >>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Srtp-development mailing list >>>>>> srtp-developm...@lists.sourceforge.net >>>>>> https://lists.sourceforge.net/lists/listinfo/srtp-development >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> See everything from the browser to the database with AppDynamics >>>>> Get end-to-end visibility with application monitoring from AppDynamics >>>>> Isolate bottlenecks and diagnose root cause in seconds. >>>>> Start your free trial of AppDynamics Pro today! >>>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >>>>> >>>>> >>>>> _______________________________________________ >>>>> Srtp-development mailing list >>>>> srtp-developm...@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/srtp-development >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> See everything from the browser to the database with AppDynamics >>> Get end-to-end visibility with application monitoring from AppDynamics >>> Isolate bottlenecks and diagnose root cause in seconds. >>> Start your free trial of AppDynamics Pro today! >>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk >>> >>> >>> _______________________________________________ >>> Srtp-development mailing list >>> srtp-developm...@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/srtp-development >> >
<<attachment: foleyj.vcf>>
