In December 2020, wolfSSL 4.6.0 featured initial support for building as a Linux kernel module, supplying the entire native wolfCrypt and wolfSSL APIs directly to other kernel modules.
Now, with our just-released milestone 5.0.0 release, we have extended that support with in-kernel FIPS 140-3, additional accelerated cryptography options on x86, and substantial improvements in stack usage.
Porting a library as large and complex as wolfSSL to the Linux kernel has been a multi-phase undertaking, guided by three key objectives:
- A build process that is completely turnkey on supported kernel lines, via configure –enable-linuxkm and –with-linux-source=/source/tree/top.
- A source tree that remains unified: the library and the kernel module are built from the same codebase, and differ only in various settings, and in kernel-specific glue logic.
- Module builds that use the Linux in-tree Kbuild toolchain, rather than a bespoke out-of-tree build system, to facilitate simultaneous and continuing support for a wide variety of old and new kernel releases.
The Linux kernel is not a POSIX target, and many facilities commonly available to libraries and applications are unavailable (e.g. stack red zones, the C library, thread-local storage) or severely restricted (e.g. stack depth and vectorized instructions). Additionally, each minor kernel version and hardware target has peculiarities that cannot be ignored.
In this presentation, we will chronicle some of the challenges we encountered porting wolfSSL to this unusual target, and the solutions we developed.
We will discuss:
- Refactors spanning the entire wolfSSL library to strictly control peak stack usage;
- New development and QA tools developed for the kernel module project, such as fine-grained cumulative stack depth instrumentation and error-checking vector register save/restore and asserts;
- Porting wolfcrypt_test to the kernel, for comprehensive validation of all cryptographic implementations;
- Automated translation of symbol visibility to kernel namespace export directives, leveraging ELF visibility tags;
- Extending the wolfSSL autotools configuration to set up a Kbuild configuration and seamlessly hand off control to Kbuild;
- New automated testing: continually testing module builds on the latest release (currently 5.15) and a substantial cross-section of LTS kernels (currently 3.16, 4.4, 4.9, 5.4, and 5.10);
- The challenges of maintaining squeaky-clean builds on kernels as old as 3.16 (2014) and as new as 5.15 (this week) from a single unified codebase that is directly and continually impacted by the engineering decisions of the Linux kernel developers;
- The challenge of FIPS 140-3 compliance in the Linux kernel: containerizing the FIPS module, stabilizing its hash, and refactoring thread-local storage requirements;
- An example application: wireGuard kernel module crypto rip&replace, and matching rip&replace of wireGuard user space software;
- The future: example applications that exercise in-kernel TLS negotiation, more x86 accelerations, acceleration on other architectures, etc.
Kernel Mode with wolfSSL Webinar
Nov 10, 10:00 AM PST
Register here: https://us02web.zoom.us/webinar/register/WN_afiL7xw9QI6Z83e5Vleldg
Email us at facts@wolfssl.com if you have any questions or comments.