Why Zephyr?

When the Zephyr project was announced in February, many members of the Linux community seemed to find it puzzling. Although Zephyr is hosted by the Linux Foundation, it is an entirely separate operating system that incorporates no Linux code. It also targets small hardware devices—from Arduinos to ARM system-on-chips (SoCs)—even though there are several other open-source OS projects (including Linux for many ARM SoCs) that also address that device class. At the 2016 Embedded Linux Conference in San Diego, the Zephyr team was on hand to make the case for why the new project is necessary and, hopefully, interesting to developers.

OSes of Things

Intel's Anas Nashif presented an overview of Zephyr in his talk, describing both its background within Intel and its capabilities. The bottom-line goal of the project is to provide an open-source, realtime operating system (RTOS) for "sub-Linux devices." Beyond that, however, Intel looked at the existing RTOS offerings on the market and found them lacking in several respects. First, many of them focus only on one architecture, which limits their appeal.

Second, many of them are "roll your own" projects developed for research or maintained by a single person. That seems to correlate with a lack of security work, which is a serious drawback. In addition, some of these smaller RTOS projects use peculiar software licenses, which also inhibits their adoption within the open-source community. Finally, many of the existing projects are too limited in functionality to serve as a general-purpose OS for Internet of Things (IoT) devices, which Intel sees as the primary use case for Zephyr.

Put all of those factors together, and one has the Zephyr product brief: an open-source RTOS that supports multiple architectures, has a broad contributor base, and offers "more than just a scheduler"—specifically, good networking support and a real security framework. Intel happened to acquire the rights to Wind River's microcontroller RTOS, decided it could be developed into a good fit, and set about to clean up the code and prepare it for release. That RTOS is now the open-source Zephyr, although it also serves as the core of Wind River's "Rocket" RTOS product. Intel is currently leading the development effort.

By building on the existing Wind River code base, Nashif said, Zephyr can start with a battle-tested code base used for more than a decade in real-world conditions. Expanding the original code involved several key steps. First, it was restructured to be more modular. At compile time, developers can include or exclude whichever subsystems they need in order to fit the hardware. The hardware in question includes what he called "the very lowest end of the sub-Linux device spectrum", "where the cost of the silicon is minimal." He showed a slide listing the initial hardware products on which Zephyr runs, which includes the Arduino 101 and Intel Quark D2000 at the low end, and goes all the way up to the second-generation Intel Galileo at the high end. But, he added, the Galileo is a development platform only; it is fully capable of running Linux, so he expected no one would use it for a real Zephyr deployment.

Second, the Zephyr team added networking. It wrote a Bluetooth Low Energy (BLE) implementation from scratch, and ported the IP stack from the open-source Contiki RTOS. IPv6 is supported, include the low-energy 6LoWPAN. The project is still looking at other network stacks; Near-Field Communication (NFC) is likely; ZigBee and WiFi are also possibilities if there is demand.

The third addition to the code base was a cryptographic library based on TinyCrypt. In a separate session, security developer Constanza Heath described TinyCrypt's set of random-number generation (RNG), cipher, and key-exchange primitives, as well as Zephyr's general approach to security. A Zephyr image runs only a single application, which is statically linked in at compile time. There is a single address space and no loadable kernel modules are supported, which reduces the attack surface considerably. In brief, she said, with a single, statically linked process running, if there is malicious code running on your Zephyr hardware, then it was there at compile time. The project thus skips some other security features that larger OSes include to protect against security exploits, though she said the team is still looking into adding some protections like address-space randomization. For most security features, the question at hand is the security-versus-size trade-off.

Features

When it comes to size, Zephyr can run comfortably in 8KB of RAM, and can even run in a minimum of 2KB of RAM, although Nashif said that at that size it provides nothing but a "Hello World" demo. The Zephyr kernel can be configured in either one of two modes. The smallest is "nanokernel" mode, which provides a basic multi-threaded execution environment, inter-thread synchronization services (including semaphores and mutexes), message queues, and interrupt services. Nanokernel mode is expected to be used for the smallest and cheapest devices, he said, such as environmental sensors, which need to do little processing beyond gathering and sending data.

A step up from nanokernel mode is microkernel mode, which offers a superset of nanokernel mode's features, including more sophisticated message queuing, additional memory allocation services, preemptive tasks, and round-robin time slicing. This mode is expected to be used on slightly larger IoT nodes, such as sensor hubs that may need to process and format data collected from sensors before forwarding it on to a remote server. Nashif pointed out that networking was available in both nanokernel and microkernel mode, although configuring a nanokernel build for the full IP networking stack could potentially make it hard to fit Zephyr into a sub-10KB RAM device.

Nashif noted Zephyr also makes use of some tooling from Linux. Configuration is done using the Linux kernel's kconfig, and Zephyr builds are done using kbuild. But the similarities stop with those tools, he said—a Zephyr image is configured and built for a single application. "We're just trying to learn from Linux, not to be Linux." The project offers a software development kit (SDK) that supports five compilers and provides tools for flashing images onto devices and for debugging. In addition to running on Linux, Windows, and Mac OS X, the SDK can run in Docker containers.

Intel sees Zephyr as a strategic investment, Nashif said. It saw gaps in the RTOS market, particularly where IoT devices are concerned, and took the opportunity to try building a project to fill the gap. It hopes to win over the community, and hopes to work with other open-source projects wherever possible. Nashif added that he knows the IoT space is a crowded one; he has seen two new IoT OSes announced since Zephyr was released, and does not expect that trend to slow down.

Whoever establishes dominance in the IoT market will have to overcome quite a bit of competition, both proprietary and open source. It is quite early in Zephyr's lifespan, even though the code base has a longer history through its days at Wind River. Wherever it goes from here, it will be interesting to watch.

[The author would like to thank the Linux Foundation for travel assistance to attend ELC 2016.]