1 Reply by douzzer

(4 replies, posted in wolfSSL)

Our current technique for getting Wireguard to consume the crypto implementations in libwolfssl.ko is a patched Wireguard kernel module.

Recipe:

Clone the fork at https://github.com/douzzer/wolf-wireguard-kernel  -- you'll need the branch named "wolfcryptified", which is the default branch for this fork.

Build libwolfssl.ko using 

./configure --enable-linuxkm --enable-xchacha --enable-poly1305 --enable-curve25519

at a bare minimum.  You can just use --enable-all-crypto to assure you get everything you could possible need crypto-wise, and it's wise to use --enable-cryptonly to disable the TLS/DTLS layer from the module (it's irrelevant to Wireguard obviously).

Then at the top of the patched Wireguard source tree:

make WOLFCRYPT=1 KERNELRELEASE="the-kernel-release" KERNELDIR="the-kernel-source-tree-top" WOLFSSL_ROOT="the-wolfssl-top"

The kernel release is something like "6.12.3-gentoo" or, if you're testing on the ragged edge, "6.13-rc1".

We test this nightly, on the latest release and mainline kernels, and have for several years, so it should just-work for you.

Note that if you are currently building the in-tree Wireguard module statically linked into your kernel ('Y' in .config) rather than as a dynamically loaded module ('M'), then you'll need to rebuild the kernel with in-tree Wireguard either 'M' or 'N' to avoid a conflict between the out-of-tree and in-tree implementation.

Go to forum: wolfSSL

2 Reply by douzzer

(2 replies, posted in wolfSSL)

We've put up a candidate fix for the problem you reported.  See https://github.com/wolfSSL/wolfssl/pull/7652

The fix is quite simple, and doesn't require anything specific to ARMCC.

Edit: this fix is now merged, so you can just clone/pull master to get it.

Go to forum: wolfSSL

3 Reply by douzzer

(3 replies, posted in wolfSSL)

Oh dear, yes that example is a sticky wicket.  The config file that failed out on you (`examples/Linux-LWIP/echo-config.json`) hasn't been updated in well over a year, and has a couple clauses in it that were deprecated in release v0.6.0-preview-6.  I'm fixing that config file for the next release, at least.

I believe the only changes that are absolutely needed, btw, are changing `"default-policy-static"` to `"default-policy"`, and similarly `"default-event-static"` to `"default-event"`, in the `"default-policies"` section.

But even if you get it to load successfully, it won't quite work right, because the demo is just using libpcap to generate the raw input packets to lwIP.  This allows you to exercise and explore the traffic evaluation dynamics of wolfSentry, which is particularly useful with `WOLFSENTRY_DEBUG_LWIP` and/or `DEBUG_ROUTE_LOOKUP` defined in the build.

But it doesn't allow actual filtration, because libpcap is just tapping the packet flow, not intercepting it.  The Linux kernel (and its in-tree IP stack) still receives the traffic unfiltered.  Worse yet, it still generates the regular replies to it, like ICMP echo reply and TCP unreachable-reset.  With wolfSentry configured to generate its own replies, the client sees double replies.  E.g. "DUP" ping replies.  And in fact, lwIP and Linux can disagree on what to do, e.g. lwIP accepting a connection, but Linux resetting it.  It's a mess.

We should probably remove this (2 year old) example because of these glitches, but it has proven useful for internal development+testing at least.

In `examples-notification-demo` there's an example that actually works right as-is, though it doesn't demo the lwIP integration.

Some time soon we'll be adding an updated turnkey lwIP-RTOS example, but for now you could do worse than just review the new documentation in `doc/freertos-lwip-app.md`.

Go to forum: wolfSSL

4 Reply by douzzer

(3 replies, posted in wolfSSL)

Hi @lemonicesprite!

The first thing to do is git clone the wolfSentry repository (https://github.com/wolfSSL/wolfsentry), then "make test" on a Linux or similar host, to start learning your way around.

And you've picked a good time to kick the tires -- we've just merged detailed documentation for the configuration JSON syntax.

The port to NuttX should be super-easy, because NuttX has POSIX implementations for all of the intrinsics that wolfSentry depends on.  In particular it has pthreads and semaphore APIs that cover everything needed, so on first look I think you should be able to do a straight POSIX build of the library.

And that's something to point out early -- wolfSentry is a library that your application calls into.  So your initial goal is just to pass the right values to make for the cross compilation, to get the library to build.  Have a look at the "ifdef RUNTIME" section of the Makefile, and the freertos-arm32-build-test recipe in Makefile.analyzers, to see some setup examples.

The only substantive obstacle I see is that NuttX uses the uIP stack, and we currently only have lwIP stack integration ready to go.  So that integration work would be needed, to get full functionality.  You can have a look at lwip/LWIP_PACKET_FILTER_API.patch to get a sense of the changes needed for full integration.  If uIP already has hooks in it for packet filtering, it will be fairly easy to port to it, but if not, it will be hard like lwIP.

Go to forum: wolfSSL