Discussion: Integrations into the Yocto and Zephyr projects.

[L-series]

Following a discussion with @mkannwischer regarding the roadmap for the projects, it was brought up that a increased level of visibility within communities of consumers of mlkem/mldsa working on embedded devices would be desirable.

Currently, the two defacto tools for developping custom embedded linux and RTOS solutions are the Yocto Project as well as the Zephyr Project, both of which are projects of the Linux Foundation. @hanno-becker I'm opening this issue to discuss the possibility/desirability of integrating mlkem/dsa into the two former ecosystems.

In the case of Yocto, one would write a bitbake recipe (essentially a file which describes how to build the library - similar to a nix derivation, and is consumed by yocto when producing a linux image). Such a recipe would most likely live in one of the core meta-layers (repository containing many recipes) of the project itself. I propose something like https://github.com/openembedded/meta-openembedded/tree/master/meta-oe/recipes-crypto (MbedTLS and other similar libraries reside here).

In the case of Zephyr, one would write a module for the zephyr kernel and it would live in https://github.com/zephyrproject-rtos/zephyr/tree/main/modules.

If this is something which is of interest, I can begin with the implementations. Please let me know your thoughts!

[hanno-becker]

@L-series I'd love that. If you have bandwidth to explore integrations into Yocto and/or Zephyr, that would be fantastic.

I was recently contacted by Angelo Tsanaktsidis from Zephyr (?) who indicated interest in this as well. I pointed him to this thread.

[mkannwischer]

Thanks @L-series! That sounds great! Indeed making mlkem/mldsa-native more accessible and integrated into other software is one of our main goals for this year. Integrations Yocto and Zephyr would be perfectly aligned with that and I'm happy to support in case any problems occur.

Feel free to start with a prototype and ask us for a review!

I'm not familiar with Yocto and Zephyr, so please excuse that I'll have a lot of trivial questions:

• How does versioning work in Yocto and Zephyr? Is it similar to nix that the recipe/module pins to a specific version (and that can potentially be overwritten by the user)? In that case we would have to update regularly (for that having more releases as discussed in Discussion: Release schedule #1519 may be quite useful as we could pin to semantic versions rather than git commits). Is there a mechanism for automatically updating recipes when upstream publishes a new release or is this handled by a maintainer? If you need to specify maintainers, please add me (and maybe @hanno-becker if he wants) there as well.
• Do Yocto and Zephyr come with their own CI that we can rely on for testing new versions? It would be good if we can run at least functional tests and ideally ACVP tests as a part of that.

@dstebila, I remember liboqs also has a Zephyr integrations and tests in the liboqs CI. Do you mind tagging the people driving that here, please? Maybe they have something to add to the discussion.

[L-series]

Lovely, I'll start working on an implementation shortly and will keep you both updated on my progress.

Regarding your questions @mkannwischer :

* How does versioning work in Yocto and Zephyr? Is it similar to nix that the recipe/module pins to a specific version (and that can potentially be overwritten by the user)? In that case we would have to update regularly (for that having more releases as discussed in [Discussion: Release schedule #1519](https://github.com/pq-code-package/mlkem-native/issues/1519) may be quite useful as we could pin to semantic versions rather than git commits). Is there a mechanism for automatically updating recipes when upstream publishes a new release or is this handled by a maintainer? If you need to specify maintainers, please add me (and maybe [@hanno-becker](https://github.com/hanno-becker) if he wants) there as well.

Recipes in Yocto are similar to nix packages in the sense that yes, it pins the library to a specific version (you specify the branch and SRCREV (commit hash) in the recipe). In terms of updates and maintenance, once the recipe has been upstreamed, it falls under the maintenance of the main layer maintainer. however most of the time the updates to the recipe usually come from whoever upstreamed it (or community members if it hasn't been updated in a while). Regarding a mechanism to update the recipe, there isn't really any automatic way of doing it. Yocto has a developer tool called the AUH (automatic upgrade helper) which can be ran and automatically bumps the package version if the build succeeds, however im not sure if this is actually implemented in their CI. I suppose one would have to manually make these updates to the upstream recipe whenever they see fit (say every major release of mlkem/dsa).

In the case of zephyr I currently see two ways of doing this. The first would be to take the approach of liboqs and maintain a port within the mlkem/mldsa libraries themselves. This includes a kconfig snippet, a West manifest and sensible default configs for the embedded setting. The second would be to try and upstream this port - this involves having a clone of the libraries be tracked in zephyr project (eg. hostap: https://github.com/zephyrproject-rtos/hostap).

* Do Yocto and Zephyr come with their own CI that we can rely on for testing new versions? It would be good if we can run at least functional tests and ideally ACVP tests as a part of that.

Both projects have their respective CI. For Yocto I'm not certain how it works, for Zephyr there seem to be various CI actions which we could rely upon.

[atsana01]

Hi all,

Thanks @hanno-becker for pointing me here, happy to join the discussion.

I’ve worked with PQC libraries on Zephyr and have some experience with the integration challenges (RNG backend hooks, memory constraints on MCU-class devices, and Kconfig/CMake build integration). I’d be glad to help with testing and feedback once @L-series has a prototype, particularly around tight RAM scenarios.
Regarding @mkannwischer’s question about CI: Zephyr’s CI includes Twister (their test framework) which can run functional tests across multiple boards/QEMU targets. For ACVP you’d likely need a separate setup, but functional tests via Twister should be straightforward.

Happy to collaborate where useful, feel free to tag me on any Zephyr-specific questions.