Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
wolfSSL pkg addition with examples #10308
This patch superseeds PR #9894 and contains wolfSSL support in a RIOT pkg.
This patch includes:
Testing procedure: sock_udp
Compile and run dtls-wolfssl
wolfSSL works on any 32-bit target with support for
The test procedure for native riot-to-riot test is the following:
Prepare the bridge interface linking two tuntap:
Run the server
copy the server address
Run the client
Testing procedure: full TCP/IP TLS demo
The wolfSSL library package temporarly lives in the feature branch https://github.com/danielinux/wolfssl/tree/riot-os until the new callbacks for GNRC are merged in.
Thanks to @cladmi for reviewing the modules integration and helping with modularization of the single components.
Thanks to @bergzand for testing wolfcrypt_ed25519 and suggesting code-size optimization settings.
Please consider for inclusion.
Any feedback is welcome.
It would be nice to hear any comment about this PR.
wolfSSL's support original PR (#7348) is almost two years old while typing this. Since then, we have widely improved the integration. Now we have a proper pkg, we build single wolfcrypt/wolfssl components into separate modules, and we support both posix and GNRC socket interfaces.
The latest version of this code is a few weeks old and is based on wolfSSL 4.0.0-stable.
I have updated this branch regularly in the past months, to sync up to latest RIOT and wolfSSL master branches and test/fix the examples.
I finally found some time to spend on this PR and I'm willing to help wherever I can to get this merged.
That being said, let's move on to the technical stuff.
I didn't do a detailed code review yet but when quickly browsing thru the code I couldn't spot major problems.
While I generally like to have more than one or two examples/tests, I think it adds unnecessary complexity for getting a first version of a new feature in.
When trying to build
The system setup used.
Here is a first overview of what I found working on which platform:
The failed ones under dtlss didn't actually print an error on the server side but made the client fail to connect.
Do you have any hints on what I could try to further investigate?
Some low priority comments regarding the shell commands of dtls-wolfssl:
I understand how difficult it can be to find time to review these PR, so no worries!
Kudos to @cladmi for the patience guiding me through this part.
WolfSSL support can integrate with either GNRC (via wolfssl + gnrc_sock_udp/tcp) or POSIX socket calls (via wolfssl_socket + posix_socket modules).
I agree we could remove these examples if they are not needed/less interesting,
I've checked the problem with compiling these tests, it's due to a missing
These are wolfcrypt-only test/benchmark units, that have also been used to
On some platforms, I expect that there might not be enough resources (code
I'll push a fix for this.
Error -125 is 'out of memory error'. The target could not provide the memory
Sounds like a memory problem again, wolfSSL_new is failing to create the session
Stack (or more likely heap) might be a problem initializing large objects (TLS session) on some platforms. Wolfcrypt-only tests have more chances to run on those.
Perhaps I should add targets to add targets to BOARD_INSUFFICIENT_MEMORY depending
I took notes about these, I will fix the dtls example behavior.
Ok. IIRC, wolfssl also has some option to work with static memory - isn't that used for RIOT? If it is used, I'd actually expect that the build would fail with some "region whatever overflowed" message for too constrained devices. If not, what needs to be done to use static memory?
If there is a way to let it fail on build we can use
I just tested (only compilation for now) of the wolfssl_client/server applications with your fix. Building for an arm-none-eabi-gcc target (nucleo-l476rg) failed with implicit declaration of
regarding wolfcrypt-ed25519-verify, wolfssl_crypto_benchmark, wolfssl_crypto_test:
I wonder if the binary size grows too much if those get combined into a singe application providing three test commands?
Thanks for adding the fixes. I tried again with
Coming from the main the crash happens in the
For arm-none-eabi targets I can't compile. Removing strnlen or adding
To actually enable radio support on platforms that come with a radio
I gave the
Additionally I needed to add
Static memory 'moves' the problem of using the heap by allocating large objects in the stack, and it's genereally more memory consuming than normal allocations, because it also pre-allocates large pools of static memory to be able to be flexible enough for a generic use case. I have asked @kaleb-himes and he recommends to keep WOLFSSL_STATIC off in memory constrained environments.
Makes sense. I didn't know how variable the size of the buffers are that wolfssl needs (and by that how bad the overhead of static memory would be). That also means that we have to either exclude all platforms that have no proper implementation of malloc available (e.g. only one-way-malloc on MSP430, not sure about others) or as an alternative we use the tlsf based malloc implementation there. Adding support for tlsf can be easily done later in a follow-up though.
Michel, I fixed most of the comments above (still working on the others).
I will probably have to blacklist all Atmel samX devices, due to a conflicting symbol, unless anyone has better ideas on this regard.
On these platforms build currently fails and looks like this:
@danielinux very nice! Please go ahead and squash the fixing commits so there are only a few cleanly separated commits left, e.g. one adding the package, and one for each test app etc.
Re-tested everything on native nucleo-l476rg and samr21-xpro:
*expected due to memory constraints
Please just fix the small (nitpicky but quickly to do) doc/style things noted below. Feel free to directly ammend/squash and thats's it!