Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#5881 closed Bug (fixed)

Impossible to build/run with PolarSSL on Raspberry Pi

Reported by: Balor Owned by: mike.dld
Priority: Normal Milestone: 2.90
Component: libtransmission Version: 2.84+
Severity: Blocker Keywords:
Cc:

Description

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

Change History (23)

comment:1 Changed 6 years ago by mike.dld

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

comment:2 Changed 6 years ago by mike.dld

  • Owner changed from jordan to mike.dld
  • Status changed from new to assigned

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

comment:3 Changed 6 years ago by mike.dld

  • Milestone changed from None Set to 2.90
  • Resolution set to fixed
  • Status changed from assigned to closed

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

comment:4 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by Balor

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Summary changed from Impossible to build with PolarSSL on Raspberry Pi to Impossible to build/run with PolarSSL on Raspberry Pi

comment:6 Changed 6 years ago by 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?

comment:7 Changed 6 years ago by 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

comment:8 Changed 6 years ago by 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.

comment:9 Changed 6 years ago by 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.

comment:10 Changed 6 years ago by 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.

comment:11 Changed 6 years ago by 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.

comment:12 Changed 6 years ago by mike.dld

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

comment:13 Changed 6 years ago by 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

comment:14 follow-up: Changed 6 years ago by 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)?

comment:15 in reply to: ↑ 14 Changed 6 years ago by 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"
...

comment:16 Changed 6 years ago by 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

     
    294294
    295295  secret_key_length = handle->len;
    296296
    297 #if POLARSSL_VERSION_NUMBER >= 0x01030000
    298297  if (!check_result (dhm_calc_secret (handle, ret->key,
    299298                                      &secret_key_length, my_rand, NULL)))
    300 #else
    301   if (!check_result (dhm_calc_secret (handle, ret->key, &secret_key_length)))
    302 #endif
    303299    {
    304300      tr_dh_secret_free (ret);
    305301      return NULL;

Second one extends first one by making f_rng NULL:

  • libtransmission/crypto-utils-polarssl.c

     
    294294
    295295  secret_key_length = handle->len;
    296296
    297 #if POLARSSL_VERSION_NUMBER >= 0x01030000
    298297  if (!check_result (dhm_calc_secret (handle, ret->key,
    299                                       &secret_key_length, my_rand, NULL)))
    300 #else
    301   if (!check_result (dhm_calc_secret (handle, ret->key, &secret_key_length)))
    302 #endif
     298                                      &secret_key_length, NULL, NULL)))
    303299    {
    304300      tr_dh_secret_free (ret);
    305301      return NULL;

What are the results in both cases?

comment:17 Changed 6 years ago by 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.

comment:18 Changed 6 years ago by 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).

comment:19 Changed 6 years ago by Balor

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

comment:20 Changed 6 years ago by mike.dld

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

comment:21 follow-up: Changed 6 years ago by Balor

here it is:

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

comment:22 in reply to: ↑ 21 Changed 6 years ago by mike.dld

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

comment:23 Changed 6 years ago by mike.dld

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

Note: See TracTickets for help on using tickets.