The wolfBoot recipes in the meta-wolfssl (https://github.com/wolfSSL/meta-wolfssl) Yocto layer can now build wolfCrypt from a wolfSSL source tree you supply. Set `WOLFBOOT_WOLFSSL_SRC = “/path/to/wolfssl”` in `local.conf` and that tree is used in place of the copy the recipe would otherwise fetch into `lib/wolfssl`. The wolfSSL entry drops out of `SRC_URI` entirely, so nothing is downloaded. Both `wolfboot_git.bb` and `wolfboot-keytools-native_git.bb` read the variable, which keeps the tools that sign your firmware images on the same wolfCrypt as the bootloader that verifies them. Use of the local wolfCrypt source code gives better version alignment across the build. Without setting WOLFBOOT_WOLFSSL_SRC applications link `libwolfssl` from the `wolfssl` recipe, and wolfBoot compiles its own wolfCrypt, the two are pinned separately, so an image containing both can be carrying two wolfSSL versions that drift further apart every time one pin is bumped without the other. Pointing both at one tree removes the duplicate download and the second crypto code base along with it.
Note that this reuses wolfSSL *sources*, not the target `libwolfssl.so`, since wolfBoot compiles wolfCrypt itself into a bare metal image with no libc to link against. The recipe copies your tree into `${WORKDIR}` first, because wolfBoot writes object files alongside the wolfCrypt sources, skips any prebuilt host objects it finds there, and fingerprints the tree into its task hashes so that editing a source file triggers a rebuild instead of handing you a stale `wolfboot.elf` out of sstate.
The meta-wolfssl layer also now ships a recipe for [wolfHSM](https://www.wolfssl.com/products/wolfhsm/), wolfSSL’s hardware security module framework. wolfHSM gives you a client/server protocol for offloading key storage and crypto operations to a secure processor or enclave, plus platform ports supplying the transport, flash, time and lock primitives. The recipe stages sources and headers rather than building a library, because wolfHSM is configured by the application that uses it. `wh_settings.h` includes your `wolfhsm_cfg.h`, which selects the transport, the NVM backend, buffer sizes and whether crypto is compiled in at all, so two consumers with different configs do not share an ABI. Consumers add `DEPENDS += “wolfhsm”` and compile `src/*.c` plus one `port/*/` directory from `${STAGING_DATADIR}/wolfhsm`, either directly or by including the `wolfhsm.mk` fragment staged next to the sources. Only the `posix` port is staged by default. Add others with `WOLFHSM_PORTS = “posix infineon”`. Everything lands in `wolfhsm-dev`, since wolfHSM source is a build input and is not in a target rootfs.
Both changes are in the `meta-wolfssl` layer, under `recipes-wolfssl/wolfboot/` and `recipes-wolfssl/wolfhsm/`, each with a README covering the details. If you have questions about wolfBoot, wolfHSM, or the Yocto recipes, contact us at facts@wolfssl.com.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now