Just tried it, but all examples fail to compile with bin/pkg/native/wolfssl/wolfcrypt/src/wc_port.c:329:16: error: old-style function definition [-Werror=old-style-definition] wolfSSL_Mutex* wc_InitAndAllocMutex().

Once this is fixed, wolfssl_client and wolfssl_server compile and are working fine on native.

wolfssl_crypto_benchmark gives the following output and crashes with memory access error after the last line:

wolfSSL Crypto Benchmarks!
wolfCrypt Benchmark (min 1.0 sec each)
RNG      11050 kB took 1.001 seconds,   10.777 MB/s
AES-Enc  24000 kB took 1.000 seconds,   23.430 MB/s
AES-Dec  24150 kB took 1.000 seconds,   23.580 MB/s
ARC4     68225 kB took 1.000 seconds,   66.622 MB/s
RABBIT   87225 kB took 1.000 seconds,   85.162 MB/s
3DES      7925 kB took 1.001 seconds,    7.731 MB/s
MD5      118975 kB took 1.000 seconds,  116.186 MB/s
SHA      57450 kB took 1.000 seconds,   56.094 MB/s
SHA-256  24075 kB took 1.000 seconds,   23.503 MB/s

wolfssl_crypto_test still fails to compile with various old-style function definition errors in bin/pkg/native/wolfssl/wolfcrypt/test/test.c. After fixing them the test gives the following output and then crashes with mem access error again.

wolfSSL Crypto Test!
error    test passed!
base64   test passed!
base64   test passed!
MD5      test passed!
MD4      test passed!
SHA      test passed!
SHA-256  test passed!
Hash     test passed!
HMAC-MD5 test passed!
HMAC-SHA test passed!
HMAC-SHA256 test passed!
ARC4     test passed!
HC-128   test passed!
Rabbit   test passed!
DES      test passed!
DES3     test passed!
AES      test passed!
AES192   test passed!
AES256   test passed!
RANDOM   test passed!

Compiler version used: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Trying to compile it for any other platform fails for all of the examples.

Thanks @MichelRottleuthner for feedback. Initially tested on Mac OS (10.12.5, Sierra) w/ Apple LLVM version 8.1.0 (clang-802.0.42) Compiler.

Will work on resolving the noted issues for Ubuntu 16.04.4 w/ gcc v 5.4.0

Warmest Regards,

Kaleb

Hi @MichelRottleuthner,

I have pushed fixes for the old-style function defs here: wolfSSL/wolfssl#1029

Thanks again for your time and review. The reason for the seg faults were the default stack sizes set for the application on Ubuntu. Bumping default stack size to 24.5k (edit >) when exercising maximum functionality via the testing applications (<end edit) seems sufficient in my testing. I tested the following:

60K - Pass
30K - Pass
15K - SEGV
22.5K - SEGV
26.25 - Pass
24K - SEGV
24.5K - Pass

I did not optimize further after that (edit>) in the test apps. I made no adjustments to the stack sizes in the client/server applications as they appeared to work fine out-of-the-box on NATIVE platform (<end edit).

Warm Regards,

Kaleb

Thanks for your quick fix! Is there anything that can be done to further decrease memory usage of the test Applications to allow testing on very constrained devices?

@MichelRottleuthner

Is there anything that can be done to further decrease memory usage of the test Applications to allow testing on very constrained devices?

Yes of course. I can work on a more optimized build this coming week. What would be an "Ideal footprint" in your mind?

This and the following lines shouldn't be set to native statically and use $(BOARD) instead to allow building for other platforms.

Thanks I'll begin testing this on Monday!

Warm Regards,

Kaleb

RIOT/pkg/wolfssl/Makefile now references merged PR with old-style function def fixes here: wolfSSL/wolfssl@cc4ca6a

Adjusted default stack size to work for both MAC OS X (Sierra) and Ubuntu 16.04, increased from 26.25k (Ubuntu) to 35K (For MAC). Clang on mac results in less optimized binary and requires more stack.

Have a feeling this may be a never ending battle adjusting the stack on a per-device basis. SOLUTION: have it work for Native on both Mac and Linux, document stack reqs for the default examples and let developers adjust as needed for target board.

@MichelRottleuthner

Hi Michel, got busy there and now able to return to testing the suggestion. When changing Makefile from native to $(BOARD) I get the following error:

Makefile:4: *** Recursive variable `BOARD' references itself (eventually). Stop.

How to best handle this issue in the RIOT makefile system?

Regards,

Kaleb

When you replace native in one of the examples Makefiles it's clear that you get that error, because that's where you define the BOARD variable initially. What I referred to in my comment are the lines below all: git-download in the package Makefile where you use native in the path. This shouldn't be like that because you get another build path if you build for another platform (i.e. call make BOARD=some-board).

Hi @MichelRottleuthner,

Perfect, thank you for clarifying!

• KH

@MichelRottleuthner

The outdated diff resulted in confusion on my end. Apologies. Fix is in.

Still have it on my list to do an "optimized" build, do you have a recommended target footprint (compiled size) and stack use in mind for this "optimized build"?

• KH

I don't actually have a specific number in mind. I just asked out of interest because RIOT supports multiple platforms that have way smaller RAM than what is used as stack size in the wolfssl tests. Of course not all of them are realistic targets e.g. Arduino Uno seems to be out of reach with it's 2k RAM ;) ...I'd just be interested in "how tiny is possible" to support as many RIOT platforms as possible.
Did you already test compiling for some other platforms supported by RIOT?

@MichelRottleuthner

I have not yet had a chance to build for any of the other platforms but it is definitely on my TODO list!

I'd just be interested in "how tiny is possible" to support as many RIOT platforms as possible.

Cool. I will do two additional examples we have a "Lean-TLS" build that I will setup an example for and also a "Lean-PSK" build that is even smaller. I'll try to get examples of each up here soon. Should I do those examples in this same PR or open a separate PR for those?

Regards,

KH

I wouldn't mind having those examples added to this PR, as it would allow to possibly find more bugs and make the build of wolfssl more stable. Also its easier for testing in this stage. Another thing to consider is that some of the examples (e.g. the crypto test) may be better placed under tests/. I'd really like to hear other peoples opinions on this.

@MichelRottleuthner

Hi Michel,

The end of the year here has picked up in activity quite a bit. Could we schedule this for review as is with the requested changes already implemented?

The "Optimized" example is still on our TO-DO list but I am not sure we will have time to implement it before RIOT SUMMIT 2017. The wolfSSL team is eager to see this initial kick-off merged for the relationship between wolfSSL and RIOT.

• KH

For me the optimized example is not really important and I think that can be done later. What is important: it should be possible to build and run the examples/tests at least for the hardware plattforms that have sufficient memory. If this package only works with native it doesn't make sence to add it. The last time I tried I couldn't build for any board without running into various errors. Unfortunately I won't have much time in the next weeks so it would be nice if someone else can join. @tobhe I know you are eager to use wolfSSL on RIOT ;) @PeterKietzmann we talked about this recently, do you have someone in mind who would like to help here?

@MichelRottleuthner: I am indeed eager to use this, but I also don't have much time at the moment.
@kaleb-himes: I tried building the four examples:
On native, the test and benchmark examples are building and working, wolfssl_client and wolfssl_server both fail:

wolfssl_server/main.c:116:9: error: implicit declaration of function ‘wolfSSL_CTX_use_certificate_file’; did you mean ‘wolfSSL_CTX_use_certificate_buffer’? [-Werror=implicit-function-declaration]
     if (wolfSSL_CTX_use_certificate_file(ctx, CERT_FILE, SSL_FILETYPE_PEM)

wolfssl_server/main.c:124:9: error: implicit declaration of function ‘wolfSSL_CTX_use_PrivateKey_file’; did you mean ‘wolfSSL_CTX_use_PrivateKey_buffer’? [-Werror=implicit-function-declaration]
     if (wolfSSL_CTX_use_PrivateKey_file(ctx, KEY_FILE, SSL_FILETYPE_PEM)

wolfssl_client/main.c:111:9: error: implicit declaration of function ‘wolfSSL_CTX_load_verify_locations’; did you mean ‘wolfSSL_CTX_load_verify_buffer’? [-Werror=implicit-function-declaration]
     if (wolfSSL_CTX_load_verify_locations(ctx, CERT_FILE, NULL)

Other boards than native fail with:

wolfssl/wolfssl/wolfcrypt/wc_port.h:121:17: error: unknown type name 'pthread_mutex_t'
         typedef pthread_mutex_t wolfSSL_Mutex;

wolfssl/wolfssl/io.h:120:22: fatal error: sys/socket.h: No such file or directory
             #include <sys/socket.h>

I would recommend replacing those with riot api functions before merging.

Also, i would consider moving the test and benchmark from examples/ to tests/, as that's what they are more useful for.

Hi @MichelRottleuthner and @tobhe,

I got busy there for a few weeks but will be back on this in the coming week. We're eager to get this PR in before the RIOT Summit 2017.

I can make the change to move test and benchmark to "test" directory and adjust the defines to exclude threading support. In reality though there is no magic build for every platform. This is to get people access to the library to begin using it but they will need to adjust some of the settings depending on the platform. We have a porting guide for this purpose on our website here: https://wolfssl.com/wolfSSL/Docs-wolfssl-porting-guide.html

Regards,

• KH

@kaleb-himes how to proceed with this?

this needs work, but should stay on release schedule -> postpone

@smlng,

Sorry for the delay, yes this needs work but I agree would like to keep it on release schedule -> postpone. As the full time support guy here at wolfSSL I have been extremely busy without time to dedicate to testing and implementing support for specific target devices. I would like to add support for at least an Atmel (Now microchip) and one or two other devices before we target a merge.

Quick question (since IRC is pretty dead on the weekends)
Trying to test our crypto sources on a samd21 xplained pro and seeing major optimization failures by the compiler. Am I missing a setting somewhere? Do I need to install a different toolchain?

wolfcrypt_test/bin/native/wolfssl/wolfcrypt/src

-rw-r--r--   1 kalebhimes  staff   8.7K Jan 28 16:42 sha256.d
-rw-r--r--   1 kalebhimes  staff   8.0K Jan 28 16:42 sha256.o

Update makefile line from BOARD ?= native to BOARD ?= samd21-xpro
wolfcrypt_test/bin/samd21-xpro/wolfssl/wolfcrypt/src

-rw-r--r--   1 kalebhimes  staff   5.9K Jan 28 16:46 sha256.d
-rw-r--r--   1 kalebhimes  staff    87K Jan 28 16:46 sha256.o <--- why so much bloat??

Hi @kaleb-himes, (IIRC) on native the object file does not contain external shared libraries it depends on, but for samr21-xpro the target is cross-compiled, hence the object file contains all external library function. You should compare the binaries sizes the linker reports at the end of make, but even then you'll see (large) differences between varying platforms, e.g., thread stack sizes differ by cpu and specifically for native they are rather large.

Maybe @gebart and @kaspar030 can also give some more info and reasoning on this?

Hi @smlng,

Even if I compile that file on a Mac osx with full debug symbols the largest I can get sha256 to compile is 21k. I still think there is something else going on here to result in a file 87k large. Any thoughts?

21K Jan 25 17:16 src_libwolfssl_la-sha256.o

Also this is just the example I went with. I also have files on Mac OS X and the native build that should only be compiling to 7k or 8k and on the samd21-xpro build they are as large as 68k. This does not fit with the explanation above as these even smaller c sources files have no OS level dependencies.

Building those same files in Atmel Studio the sizes are comparable to the sizes I see on the native builds. Only when building with RIOT-OS for the samd21-xpro do they become very bloated.

@kaleb-himes did you look into where the bytes are located? Useful tools include size, objdump and nm

@gebart,

Thank you so much for the suggestions! The major factor apparently contributing to the bloat are listed below, I've included line numbers for reference and I am attaching the result of running objdump -D aes.o. It is quite obviously debug sections causing the issues. I have already set:

CFLAGS += -DNDEBUG

Apparently that is not the correct flag to be using for disabling debugging. Could you tell me how to turn off debugging?

objdump-report.txt

 4128 Disassembly of section .debug_info: 
 5820 Disassembly of section .debug_abbrev: 
 6116 Disassembly of section .debug_loc: 
 6761 Disassembly of section .debug_aranges:
 6787 Disassembly of section .debug_ranges: 
 6829 Disassembly of section .debug_macro: 
... you'll get the idea below...
 8659 Disassembly of section .debug_macro: 
 8669 Disassembly of section .debug_macro:
 8682 Disassembly of section .debug_macro:
 8701 Disassembly of section .debug_macro:  
 8711 Disassembly of section .debug_macro:
 8737 Disassembly of section .debug_macro:
 8780 Disassembly of section .debug_macro:
 8809 Disassembly of section .debug_macro: 
 8825 Disassembly of section .debug_macro: 
 8838 Disassembly of section .debug_line: 
 9464 Disassembly of section .debug_str:
Goes to line
18109 in the disassembly.

The debugging sections are only symbol definitions for gdb, they are not copied to the actual device ROM. Use size to figure out how much memory is actually used.
For the samr21-xpro:

arm-none-eabi-size bin/samr21-xpro/my/object/path/sha256.o

@kaleb-himes how is it going? I'd really like to move forward with this.
I tried to run the client/server on real hardware, but there are still some compile errors. After resolving them by fixing a few includes and adding lwip I got it to compile but it didn't work (failed somewhere in socket implementation of lwip).
Because the "default" transport layer used on RIOT is UDP I think it would make sense to focus on a simple DTLS example (like @emmanuelsearch stated above). That way we get rid of the lwip-dependency and can use RIOTs own network stack. Adapting the wolfSSL dtls example should be a good starting point, no? A look at the dtls-echo example could help with the necessary modules in the Makefile and maybe some functions for a shell interface of the example.
Let me know if I can help you with anything so we can finally get this going :)

@MichelRottleuthner

That would be great! Thank you for providing a clear path forward and goal, it makes it much easier for me to allocate / dedicate the time to it. I'll see if I can free up some room in my schedule this week to start working on putting together a DTLS example that will work and test it on two separate devices!

• KH

@MichelRottleuthner,

Apologies my other obligations have delayed any updates. One of my colleagues will be attending RIOT Summit 2018 in September @danielinux. I have sent him your comments and added him as a collaborator on this PR! Many thanks for your patience as we have many tasks competing for priorities RIOT OS is right at the top of our list for open source efforts and we very much look forward to continued efforts between wolfSSL and the RIOT Community!

• Kaleb

Hi all,
In order to rebase on latest master, I've made a new PR #9894 from an updated branch, which overrides this one. I would appreciate some feedback/reviews/comments to plan the next steps.

Thanks!

@danielinux so we can close this PR? do you mind updating https://www.wolfssl.com/wolfssl-riot-os-examples/ to the latest PR? i've started there and ended up in #9894

@danielinux so we can close this PR?

yes please

do you mind updating https://www.wolfssl.com/wolfssl-riot-os-examples/ to the latest PR? i've started there and ended up in #9894

We will take care of it.

Thanks

closing in favour of #10308