New Year, New Milestones: What to Expect from the Zephyr Project in 2019

By | Blog

In this new blog post, Amy Occhialino, the Zephyr Project Governing Board Chair, shares a preview of what’s to come in 2019.

As we look forward into 2019, the Zephyr Governing board is excited about two major project milestones.  First, we will release our first Long Term Support (LTS) version in the first quarter.  This release will include new and enhanced features and will continue to solidify Zephyr’s presence as a viable long-term open source solution in the embedded real-time operating system market.

Secondly, the Zephyr project will be pursuing the Functional Safety (FuSa) certification of its core operating system.  This certification process will continue to grow Zephyr’s industrial solution applications and we will communicate FuSa milestones and features as they are developed and achieved over the course of 2019.

Here’s to a fantastic New Year!  We really appreciate all of the hard work and dedication from the Zephyr community that makes the project such a vibrant and growth-focused open source project.  Please continue to look to our new communication channels like Slack for further information on both our LTS release and FuSa activities.

To sign up for the Zephyr Project Slack Channel, click here:


Zephyr OS on display at CES

By | Blog

Now that the holidays are behind us, it’s time to get ready for the annual CES show in Las Vegas, Nevada! This year, Zephyr Project members NXP and Nordic Semiconductor will be on-site at the conference to show off their latest IoT innovations throughout the conference’s duration from January 8 to January 11. We invite attendees to stop by their booths (Nordic – booth 4459 at The Sands, Halls A-D and NXP – booth CP-18 in the Central Plaza) to experience interactive demos, meet with knowledgeable developers and learn more about their technology.

Nordic will be on-site to showcase several exciting demos including their Zephyr OS backed IoT devices based on their nRF91 Series. The devices have a Cortex-M33 with Trustzone, and can be utilized through the secure implementation of MCUBOOT.

The demo will be connected to Nordic’s cloud platform through cellular network and will display the position of the demo and log messages.

Additionally, Nordic will demo unique nRF9160 System-in-Package, bringing cellular IoT to any application, will make its show debut following global availability at the world’s leading consumer electronics show. In addition, the award-winning nRF52840 Bluetooth LE/Bluetooth 5 SoC will demonstrate concurrent protocol support. Other demonstrations include asset tracking, LTE-M gateways, and Thread sensors. To learn more, click here:

Zephyr member NXP will also be on-site to showcase how their IoT solutions impact a variety of industries including automotive, wearables, manufacturing/IIoT, retail, and AI.

An excerpt from the NXP blog shares some exciting demos being featured in their booth (CP-18 in the Central Plaza) as follows:

  • Smart Tour: Check out NXP’s “AI ML Life on the Edge” showcase.  Visitors can experience a guided tour and personalized demonstration of NXP edge computing solutions with technical consultants to explore the benefits of face and voice recognition, anomaly detection, lifecycle intelligence & security, and scalable edge technologies.
  • Smart Automotive: Experience a concept car that can separate its pod from the chassis to enable ultimate flexibility and uses, whether shared, owned or rented. Get a tour of breakthrough safe solutions across all vehicle domains – connectivity, driver replacement, in-vehicle experience, body and comfort, powertrain and vehicle dynamics connected through gateways and vehicle networks.
  • Smart Industry: See how edge computing solutions are reducing costly data transfer to the cloud for global supply chain systems. Learn how 5G access and real-time iMX processing is increasing throughput while making the factory floor smarter and safer.
  • Smart Home: Discover how purpose-built edge solutions connect modern homes to cloud-based services more efficiently than ever. From voice-controlled smart appliances to innovative hearables technology, NXP is increasing comfort, affordability, and convenience for smart home device makers and giving the industry something to talk about.
  • Smart Retail: NXP will unveil the “Smart Market,” a new, highly interactive and personalized shopping experience made possible through NXP’s broad portfolio and collaboration efforts with some of the biggest brand names including Kraft Heinz and Gevalia Coffee,The Coca-Cola Company, and Mammut and smart infrastructure partners like Stora Enso, Opticon, Decathlon, Kathrein Solutions,Ingenico and TPG Rewards. Together with its partners, NXP demonstrates how Smart Retail can go mainstream, and Smart Market visitors will have the opportunity to experience, first-hand, how high-tech retail is completely transforming the shopping experience of tomorrow with intelligent refrigerators, personalized signage, interactive branding and true self-checkout experiences.
  • Smart Audio:  Visit NXP’s smart audio demonstrations which include the latest in immersive sound, multi-assistant voice speakers, and 3D audio.

ELC/OpenIoT NXP Demo

By | Blog

In October, thousands of people met in Edinburgh, Scotland for the Embedded Linux Conference Europe and OpenIoT 2018. During the conference, attendees saw 12 Zephyr technical presentations, participated in a full-day hackathon and stopped by the Zephyr Project booth to see demos and speak with member representatives and community members. The event proved to be a fantastic opportunity to learn about the diverse and innovative ways ZephyrOS is being used by members. In an effort to share some of the highlights of this event with the larger community, we’ll be posting demos, videos and resources throughout the winter. Thank you to NXP and Stanislav Poboril for starting this series with a closer look at their demo.

Software Defined Peripherals- Zephyr Used to Offload Real-Time Tasks from Linux

This demonstration demonstrates the offloading of the real-time task from Linux using Zephyr and RPMsg. For the purpose of this example, the UDOO Neo board with an NXP i.MX 6SoloX heterogeneous multicore SoC was chosen. Linux is running on the ARM Cortex-A9 core. The Linux deployment consists of a kernel module which creates one or more virtual devices /dev/ttySoftX to read and write data to the M4 core. The ARM Cortex-M4 core runs Zephyr for the execution of a real-time task, in this case  emulation of the UART protocol using GPIO pins. RPMsg is used for communication between the two systems.

Internally, RPMsg uses a Messaging Unit block and shared memory on the platform. On the Arm Cortex-M4 core, Zephyr waits for the configuration message from Linux on an RPMsg endpoint. Then it configures the emulation of UART using GPIO pins. It starts two cooperative threads – to transmit and to receive data. The transmit thread reads data received from Linux, decodes it into the form of UART pin changes which are enqueued to a buffer. The buffer is consumed from a timer callback, which toggles respective GPIO output pin(s). The timer callback also reads the input GPIO pin(s) states and places them into the receive buffer. This is read by the receive thread, which decodes it into bytes and sends it to the Arm Cortex-A9 using RPMsg.

The source code and description for the demo can be found here:

MCUboot Security Part 1

By | Blog

Zephyr Project member David Brown, a Senior Engineer with Linaro Ltd.,  shares the best practices for security in this blog post, which first ran on Brownian Motion

This is the first in what I hope to be a series of posts about the MCUboot bootloader from a security perspective. Please note that although I work in security, I am by no means a cryptographer. I appreciate any feedback on any and all flaws in my analysis.

The MCUboot project

The MCUboot Project is a secure bootloader for 32-bit MCUs. The goal of MCUboot is to define a common infrastructure for the bootloader, system flash layout on microcontroller systems, and to provide a secure bootloader that enables easy software upgrade.

The essential problem that MCUboot seeks to solve is how to allow firmware updates, while still maintaining some kind of integrity and control over what firmware can be run on the device. The easiest way to prevent unauthorized firmware from running on a device is to configure the flash to be immutable. Unfortunately, this prevents potential security updates (as well as functionality improvements). MCUboot solves this by itself being a small amount of code that can be placed in an immutable section of flash. It then can verify the main code before allowing it to execute, as well as control updates to that code.

MCUboot is configurable, and these configuration choices affect the security promises that MCUboot is able to make.

  • CONFIG_BOOT_SIGNATURE_TYPE_RSA and CONFIG_BOOT_SIGNATURE_TYPE_ECDSA_P256control the type of digital signature MCUboot uses to verify the image. It is possible to define neither of these, and it will only ensure that there is a SHA256 hash present. With neither signature algorithm, the image is not protected against intentional tampering, but merely acts as a checksum, to prevent a corrupted image from booting.
  • CONFIG_BOOT_VALIDATE_SLOT0 controls whether MCUboot validates the signature of the booted image on every boot (or just when upgrading). This can be disabled to make the boot process slightly faster, at the cost of no longer verifying a path of trust to the running image.
  • CONFIG_BOOT_UPGRADE_ONLY controls how upgrades are performed. If this is unset, MCUboot uses a (complex) swapping algorithm to exchange the new upgrade image with the old image. This will allow an easy revert if the system determines that the image will not boot. If this is enabled, the new image will overwrite the old image, and if it doesn’t boot, there is no fallback image.

From a security perspective, I will assume that one of the signature options is set, and that SLOT0 is validated. In a future post, I will discuss the upgrade only option, and demonstrate why neither of these is a good solution, from a security perspective. It will offer a suggestion for how to better handle reverts.

System Model

MCUboot assumes that it is running on a small 32-bit microcontroller where the code executes directly out of flash (eXecute In Place, or XIP). Although support for non-XIP targets is desirable, it has not been implemented at the time of writing.

MCUboot divides flash into several regions. We will refer to them as B for the bootloader area, P for the primary region, U for the upgrade region, and S for the scratch region. There are constraints on the layout and sizes of these partitions which are not relevant to our analysis here. We make the following assumptions of this flash memory:

  • The flash memory is internal to the MCU itself. External flash memory is easier for a malicious party to modify.
  • The B region can be permanently marked as immutable. Some MCUs will still allow a full-chip erase, which would allow a determined party to replace the entire firmware with their own.
  • The code at B is the first configurable code that the MCU will run. The MCU may have internal boot code, however if it can be configured to support some type of recovery process, this must be permanently disabled (to prevent arbitrary code from running).
  • JTAG and SWD debugging ports will be disabled in production devices. Limited debugging can be permitted as long as the B region cannot be tampered with.

Image format

MCUboot (the code in B) verifies the image in P before running it. This image begins with a small header Hd, the executable image itself, Ex, and a set of metadata after the image, M1M2, etc. The format of the payload then looks like (Hd||Ex||M1||M2||…).

Each piece of metadata is in tag-length-value format, with the following tags:

  • IMAGE_TLV_SHA256: The associated data is the SHA256 hash of (Hd||Ex). This tag is required in all configurations.
  • IMAGE_TLV_KEYHASH: The associated data is the SHA256 hash of a public key. This is used to indicate what public key a following signature uses.
  • IMAGE_TLV_RSA2048_PSS: A digital signature made with RSA-2048 PKCS v2.1 PSS. The signature is made with the same hash as IMAGE_TLV_SHA256.
  • IMAGE_TLV_ECDSA224: A digital signature of the hash made with ECDSA using the NIST P-224 curve.
  • IMAGE_TLV_ECDSA256: A digital signature of the hash made with ECDSA using the NIST P-256 curve.

If MCUBOOT has been configured to support one of the signature types, then at the following tags must be present: IMAGE_TLV_SHA256IMAGE_TLV_KEYHASH, and one signature that matches the signature type compiled into the code. There can be more than one pair of keyhash and signature pairs present, and the bootloader will ignore any that it doesn’t understand.

MCUboot will reject the image if the metadata does not meet these requirements.

Boot process

Upon booting, MCUboot examines PU, and S to determine its internal state. If it detects it was in the middle of an operation, it will try to continue that operation. If U is valid, and is marked to indicate an upgrade, it will begin the upgrade process. This will either copy U onto P entirely, or use a swap algorithm using S to exchange the contents of P and U (depending on configuration).

If P contains a valid image, MCUboot will transfer control to the execution address of this image (indicated in a CPU specific manner; for Arm, the address and initial stack pointer are at the beginning of Ex).

If none of this is true, MCUboot will stop to prevent malicious code from running.

Stay tuned for more:

  • Security implications of not verifying SLOT0.
  • Security implications of not using a digital signature.
  • Deeper dive into “swap”, its complexities, and some discussion of an easier idea.

For more blogs from David, visit his personal webpage here.