Cross-compiling for ARMv5

[TokTias]

Hi !
I have been able to use libsodium in Ubuntu, but when cross-compiling it for ARMv5 I can execute sodium:init() with no problem nut then anything fails with a segmentation fault.
I have cross-compiled other applications and libraries for the same target with no issues.
Config : ./configure --host=armv5tejl-unknown-linux-gnueabihf --enable-static LDFLAGS=-static --prefix=/home/user/ARM

Make : make v=1 DESTDIR=/home/user(ARM

Code:

# include <stdio.h>
# include <stdlib.h>
# include <string.h>
# include "sodium.h"

int main (int argc,char *argv[])
{
  printf("Sodium_Init=%d\n",sodium_init()); // returns 0 = Ok
  unsigned char pbk[crypto_box_PUBLICKEYBYTES];
  unsigned char sbk[crypto_box_SECRETKEYBYTES];
  crypto_box_keypair(pbk,sbk); // <-- generates the segmentation fault
}

Compiled with:

arm-unknown-linux-gnueabi-gcc -O2 -Wall -Wno-switch-enum -L /home/user/ARM/ SodiumTst.c -o SodiumTst -lsodium

I have tried to follow the official instruction for ARM Cross-compiling at https://download.libsodium.org/doc/installation/index.html with no luck.
I have no nosys.specs file.

I also added a printf("Inside\n"); line as the first statement in the crypto_box_keypair() function and it never prints anything, thus the address of crypto_box_keypair seems to be wrong (at least it's not NULL).

Does anyone have a clue what I am doing wrong here ?

Cheers & TIA !
/T

[jedisct1]

Each release is tested on bare metal ARMv6 and ARMv7 servers, but only using Qemu emulation on ARMv5. I unfortunately don't have the hardware to test it on a real ARMv5 CPU.

All the tests are properly passing on emulated ARMv5; however, and unlike real hardware, Qemu may not trigger exceptions on unaligned accesses, no matter what the /proc/cpu/alignment settings are.

Can you compile the library with symbols and provide a backtrace in order to see where this happens? I highly suspect this is due to alignment issues.

[TokTias]

Hi !
Thanks for the hint.
All I got is when I call crypto_box_keypair() is:

Error signal 11:
SodiumTst [0x2a000dac]

Cheers !

[jedisct1]

Unfortunately, there is not much I can do without being able to test and without more information.

Can you provide a backtrace?

Also make sure that you are using a recent version of the GNU tools for ARM. Some versions have been known to generate code with incorrect alignment.

[TokTias]

Hi !
The result in my previous post is the only thing I get (using backtrace() in a SIGSEGV signal handler). Is there any other way to generate a more detailed backtrace in an embedded system ?

The GNU tools for ARM that I am using are working perfect for applications and several other 3:rd-party libraries (such as for example libao, libserial) so I don't think it's the culprit. )It's the version supplied by the factory of the ARMv5 system I am using.)

[jedisct1]

The fact that --specs=nosys.specs doesn't work is quite unexpected. Can you still try with the current stable version from https://launchpad.net/gcc-arm-embedded ? Then, the documented procedure with --specs=nosys.specs should work. You may want to add --enable-debug in order to get the symbols.

Can you run gdb on the device?

Then type:

$ gdb a.out
run
(let it crash)
bt

And you'll get a backtrace.

[TokTias]

Nope, no gdb. The target device has a rather stripped down version of Linux.

I'll try your suggestion later this weekend and post back here as soon as I got some kind of results.

[TokTias]

Right, I finally managed to make it run on my ARMv5 target by doing the following, many thanks for pointing me to the ARM toolchain that contained the nosys.spec & libnosys.a files :

• Downloaded ARM toolchain gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 from https://launchpad.net/gcc-arm-embedded
• Downloaded libsodium-1.0.7 from https://download.libsodium.org/libsodium/releases/

Note: This is for making a static libsodium.a

Example below assuming home folder = /home/user

tar xvjf gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2
tar xvzf libsodium-1.0.7.tar.gz
cp ./gcc-arm-none-eabi-4_9-2015q3/arm-none-eabi/lib/nosys.spec ./libsodium-1.0.7/
cp ./gcc-arm-none-eabi-4_9-2015q3/arm-none-eabi/lib/libnosys.a ./libsodium-1.0.7/

Folder gcc-arm-none-eabi-4_9-can be deleted at this point.

cd ./libsodium-1.0.7/
mkdir ARMv5
export LDFLAGS='-static -g --specs=nosys.specs -L/home/user/libsodium-1.0.7/ -lnosys -lc'
./configure --host=armv5tejl-unknown-linux-gnueabihf --enable-static --prefix=/home/user/libsodium-1.0.7/ARMv5/
make DESTDIR=/home/user/libsodium-1.0.7/ARMv5/

Key discoveries for me :

• Hint from jedisct1 where to get the ARM toolchain containing both the nosys.spec and libnosys.a files.
• Found out to add linker flag -lc to make libsodium with libc (contaning __libc_start_main, abort, __libc_csu_fini and __libc_csu_init)

Cheers !
/T

[mafaneh]

I've spent the last few days trying to import and compile libsodium for an NXP Kinetis MCU in Keil. I was able to get it to compile but at runtime when running the "combined mode" example for public key signature (https://download.libsodium.org/doc/public-key_cryptography/public-key_signatures.html) it always fails the verification. Am I missing something here? Is there anything special that needs to be done to build libsodium for an ARM M4 in Keil?

I've tried including the LDFLAGS listed above but it made no difference (from what I could tell).

[jedisct1]

Hi manafeh,

And thanks for reporting this.

How did you compile it exactly?

What exact tests are failing? Can you post their output and log?

[mafaneh]

Thanks for the prompt response.

I've tried compiling both as a separate library and including the source code with my application code. In both cases I am using ARM's Keil MDK IDE and compiler.

The example that fails is listed below - it always reports an Incorrect signature. I even tried the following:

• Ran the example on Ubuntu and saved the generated keys and the signed message (which succeeded)
• Ran the example on the embedded device using the keys I got on Ubuntu
• The message verification still failed and I got a different signed message
• Ran the example again on the embedded device, but this time skipped the key pair generation and the signing, instead I provided the signed message along with the public key (from Ubuntu example) and that still failed verification.

Let me know if you need me to provide any additional info.

---

#define MESSAGE (const unsigned char *) "test"
#define MESSAGE_LEN 4

unsigned char pk[crypto_sign_PUBLICKEYBYTES];
unsigned char sk[crypto_sign_SECRETKEYBYTES];
crypto_sign_keypair(pk, sk);

unsigned char signed_message[crypto_sign_BYTES + MESSAGE_LEN];
unsigned long long signed_message_len;

crypto_sign(signed_message, &signed_message_len,
            MESSAGE, MESSAGE_LEN, sk);

unsigned char unsigned_message[MESSAGE_LEN];
unsigned long long unsigned_message_len;
if (crypto_sign_open(unsigned_message, &unsigned_message_len,
                     signed_message, signed_message_len, pk) != 0) {
    /* Incorrect signature! */
}

[jedisct1]

Can you post the config.log file somewhere?

[mafaneh]

The build process is a bit more hidden from the user in Keil (and I'm pretty sure it's not using a GNU build system), so not sure how to obtain a config.log file. However, I was able to get a build log file - if that helps.

[mafaneh]

lib_sodium.build_log.txt

[jedisct1]

What libsodium version does that come from? Some files such as sign_edwards25519sha512batch.c do not exist any more in stable releases.

Can you run the regular ./configure script so that compiler-specific and platform-specific features are detected?