Written by Carles Cufí, TSC member and Open Source software engineer at Nordic Semiconductor
For the last 3 months, we’ve been busy working on the next release – Zephyr 2.3.0. More than 200 conttributors have added over 3200 commits to the codebase, in one of our busiest, most feature-packed and secure releases yet.
Looking back at the tenets that underpin the project, security has always been a fundamental objective of Zephyr. A recent report by security firm NCC Group analyzed security vulnerabilities that were found in the Zephyr codebase and reported to Zephyr’s security team before disclosing the actual report. All the critical and high vulnerabilities found were fixed before the end of the release cycle, and thus the 2.3.0 release contains no know security issues. In keeping with the spirit of open source collaborative development and full transparency, Zephyr now includes a vulnerabilities web page that lists all disclosed, public security issues and the patches that fixed them.This is on top of Zephyr’s comprehensive and detailed security policies, which are also publicly available.
Another milestone for the project is the addition of integration with the Trusted Firmware M open source Trusted Execution Environment framework, which implements Arm’s Platform Security Architecture specification. Zephyr has long included support for Arm’s TrustZone hardware, including being able to target the secure side of the firmware, but by adding integration with the standard Trusted Firmware M project, it now also offers the option to combine TF-M and Zephyr to create a PSA-certified solution.
Another highlight of the release has to do with Zephyr’s extensive use of the devicetree standard to describe the hardware it runs on. The RTOS has used this format for several years, but this release overhauls the mechanism by which drivers and applications can retrieve the information present in the devicetree source files that are processed as inputs.
A powerful new static, macro-based API gives developers the ability to query any information they might require of the nodes and properties that the devicetree source files contain. The new API will be further extended in future releases to allow for even more complex operations that, until now, were only available in systems that compile the devicetree source into a binary blob, such as hierarchical queries and unique device identifiers. All of the in-tree devicetree users have been ported to the new API, leading to a substantial improvement in readability, clarity and structure to drivers and other subsystems.
Digital Signal Processing is also of major importance in some applications that Zephyr supports. Until this release, Zephyr users that compiled the RTOS for Arm-based platforms were required to add and integrate Arm’s complete DSP extension library manually, leading to code duplication, complexity and bugs. This release introduces the mainline integration of CMSIS-DSP into the Zephyr distribution, simplifying enormously the task of Zephyr users who want to benefit from this solid and mature Digital Signal Processing framework. Not only has the actual framework been integrated, but also the comprehensive suite of tests, so that we can make sure that the functionality works correctly on all supported platforms. Users themselves can make use of these tests to verify that the port to their custom board functions properly when enabling the DSP library.
The kernel has long presented a simple but established format for timeout parameters. This has served the project well for many years, but it was time to overhaul it in order to be able to later introduce advanced features such as clock source selection, high-precision (including 64-bit) timeouts and even absolute timeout values, which are critical for certain subsystems that need to track time with high precision based on external events, such as radio activity of some sort. The new timeout API encapsulates the parameter into an opaque structure, making for a smooth transition for Zephyr users while at the same time ensuring that the solution is future-proof.
Additional features include:
- A new CMake package system that reduces the need for the use of environment variables, one of the biggest hurdles when setting up Zephyr for the first time
- Support for Advertising Extensions in the Bluetooth Low Energy Host, which enables devices to broadcast data and establish connections at long-range
- A new heap allocator which is substantially more flexible and performant than the existing mem pool one
To top all of the above, more than 900 GitHub issues were closed during this release cycle, including Enhancements, Feature Requests and, of course, hundreds of bugs. Check out the full release notes for a complete list of issues and benefits.
As always we’d like to extend our gratitude to all of the contributors that have made this release possible, no matter whether they are company-sponsored or volunteers contributing their own free time. Zephyr is only made possible by them, and we are thrilled to see the community grow and become even more involved in the future of the project.
Join Us
We invite you to try out Zephyr 2.3.0. You can find our Getting started Guide here. If you are interested in contributing to the Zephyr Project please see our Contributor Guide. Join the conversation or ask questions on our Mailing List.