Impossible to build/run with PolarSSL on Raspberry Pi

[Balor]

Hi

When I try to build the lastest version available on Jenkins I get this error if I do the --with-crypto=polarssl

make[1]: * No rule to make target 'crypto-utils-polarssl.c', needed by 'crypto-utils-polarssl.o'. Stop.

This is the line I used to configure :

CFLAGS="-Os -march=native" ./configure --with-crypto=polarssl

[mike.dld]

Do you have libtransmission/crypto-utils-polarssl.c file in place (it looks like you don't)?

[mike.dld]

Okay, I see the issue now, crypto-utils-cyassl.c and crypto-utils-polarssl.c didn't make it into the package archive.

[mike.dld]

Fixed in r14459. Try it out and reopen if there are any other issues.

[Balor]

Now it does compile but doesn't run. I get a segfault for it. This is the log of GDB: ​http://pastebin.com/shkFEi53

In case: I have polarssl and openssl installed. I think transmission is linked with the wrong library or wrong version of libcrypto.

[mike.dld]

What is the output of thread apply all bt full in gdb? Does make check pass? Does building with --with-crypto=openssl produce working binary?

[Balor]

Make check fail on 2 test. The binary is runnable and load all the torrents, start getting peers and segfault on connection to peer.

Full log of GDB and log of make check: ​http://pastebin.com/3p7W3jJL

[mike.dld]

Internet search suggests (​http://openssl.6102.n7.nabble.com/Error-armv7-tick-openssl-td54067.html) that SIGILL is normal during OpenSSL initialization on ARM. Could you try executing handle SIGILL nostop noprint pass (and handle SIGPIPE nostop noprint pass for that matter) in GDB prompt before running the executable? This should lead us to the real crash location.

Another way would be to not use OpenSSL at all. Since you are building Transmission with PolarSSL, the only other code using OpenSSL is probably libcurl, which you could build with PolarSSL instead of OpenSSL as well. This probably won't fix the crash though if PolarSSL-specific code in Transmission is failing.

[Balor]

Okay when avoiding the SIGILL and the SIGPIPE I get the SEGFAULT directly from libpolarssl: ​http://pastebin.com/gPDVtcJC

I can't get rid of OpenSSL on the machine since it's used for other program.

[mike.dld]

Maybe you could build PolarSSL with debug info? It's hard to guess where the issue is currently and I'm starting to think it's not Transmission-related... I'll do my own testing with 1.3.9 once I'm home if you can't.

[Balor]

Is there an easy way to make transmission use a static version of polarSSL ? Then I can build it with it without having to replace the system lib.

[mike.dld]

Adding path to LDFLAGS might do it, like LDFLAGS="-L/static/lib/dir"

[Balor]

That did it. I compiled polarssl (same version as in the system) with debug symbol and linked it into transmission. Same segfault directly into polarSSL:

​http://pastebin.com/Ucy99wM9

[mike.dld]

Hmm, I suspected this form line numbers in the first backtrace. The code in question is (crypto-utils-polarssl.c:297..302):

#if POLARSSL_VERSION_NUMBER >= 0x01030000
  if (!check_result (dhm_calc_secret (handle, ret->key,
                                      &secret_key_length, my_rand, NULL)))
#else
  if (!check_result (dhm_calc_secret (handle, ret->key, &secret_key_length)))
#endif

With PolarSSL 1.3.9 (which is greater than 1.3.0), first call should be used (with 5 arguments), but judging from the stack the second one is being used (with 3 arguments) resulting in garbage passed in f_rng and p_rng arguments to dhm_calc_secret.

Do you maybe see warnings when crypto-utils-polarssl.c is being compiled? Are you sure that correct headers are being used and not ones from 1.2.x (search for polarssl/version.h in your build environment)?

[Balor]

No warning in compilation for crypto:

  CC       file-posix.o
file-posix.c: In function ‘tr_sys_file_preallocate’:
file-posix.c:871:1: warning: label ‘non_sparse_out’ defined but not used [-Wunused-label]
 non_sparse_out:
 ^
  CC       crypto-utils-polarssl.o
  AR       libtransmission.a

And

cat /usr/include/polarssl/version.h
...
/**
 * The version number x.y.z is split into three parts.
 * Major, Minor, Patchlevel
 */
#define POLARSSL_VERSION_MAJOR  1
#define POLARSSL_VERSION_MINOR  3
#define POLARSSL_VERSION_PATCH  9

/**
 * The single version number has the following structure:
 *    MMNNPP00
 *    Major version | Minor version | Patch version
 */
#define POLARSSL_VERSION_NUMBER         0x01030900
#define POLARSSL_VERSION_STRING         "1.3.9"
#define POLARSSL_VERSION_STRING_FULL    "PolarSSL 1.3.9"
...

[mike.dld]

Just to make sure, let's do a couple of tests.

First one, to only leave 1.3+ implementation:

libtransmission/crypto-utils-polarssl.c

@@ -294 +294 @@
 
   secret_key_length = handle->len;
 
-#if POLARSSL_VERSION_NUMBER >= 0x01030000
   if (!check_result (dhm_calc_secret (handle, ret->key,
                                       &secret_key_length, my_rand, NULL)))
-#else
-  if (!check_result (dhm_calc_secret (handle, ret->key, &secret_key_length)))
-#endif
     {
       tr_dh_secret_free (ret);
       return NULL;

Second one extends first one by making f_rng NULL:

libtransmission/crypto-utils-polarssl.c

@@ -294 +294 @@
 
   secret_key_length = handle->len;
 
-#if POLARSSL_VERSION_NUMBER >= 0x01030000
   if (!check_result (dhm_calc_secret (handle, ret->key,
-                                      &secret_key_length, my_rand, NULL)))
-#else
-  if (!check_result (dhm_calc_secret (handle, ret->key, &secret_key_length)))
-#endif
+                                      &secret_key_length, NULL, NULL)))
     {
       tr_dh_secret_free (ret);
       return NULL;

What are the results in both cases?

[Balor]

I found the problem I had on my configuration. Some months ago, I compiled and installed (without using checkinstall) the version 1.2.8 of PolarSSL (I remember trying to use it for OpenVPN) in /usr/local/.

It would seemed that it conflicted with the one installed from the repository in /usr/.

Once I cleaned my /usr/local/ directory from PolarSSL header and lib, transmission compiled without problem (and without any patch) and run flawlessly.

Only thing, the crypto-test still fail.

[mike.dld]

That's great news!

As for crypto-test, you could run it separately to see the line number it fails on (hopefully it's just a test issue).

[Balor]

I don't find how I can just run the crypto-test... How do I do that ?

[mike.dld]

The binary is in libtransmission/ subdirectory after build is completed.

[Balor]

here it is:

./crypto-test FAIL crypto-test.c:224, expected "5", got "6"

[mike.dld]

Replying to Balor:

./crypto-test FAIL crypto-test.c:224, expected "5", got "6"

The issue is caused by defect in libb64 decoding implementation when char is unsigned. I've contacted library author and will commit the fix as soon as I get a reply.

This ticket is fixed though, closing once more.

[mike.dld]

No word from libb64 author yet, so I've committed the fix locally (r14474). Crypto test should pass now.