Achieving Unbrickable Remote Firmware Updates on MCUs with a Microvisor Architecture

Achieving Unbrickable Remote Firmware Updates on MCUs with a Microvisor Architecture

For many years, microcontrollers have been a staple in various products, continuously revolutionizing their feature sets, reliability, and performance. Moore's Law has brought 16- and 32-bit processing to even the smallest and most affordable consumer products. The presence of larger memory and CPU power has allowed the use of real-time operating systems (RTOS) where previously developers had to rely on "bare metal" coding. However, as products have evolved to become connected devices in the context of IoT, it has revealed fundamental shortcomings in the traditional methods of software development for microcontrollers.

This article is the first in a series of articles covering a new IoT architecture that promises relief: a microvisor-based approach.

Consistent Device Reachability is Key in IoT Projects

Whereas an unconnected product might comprise 90% application code and 10% third-party code (and ongoing maintenance isn’t required as physical access would be required for any attack), connected products are often 20% application code and 80% third-party code, all of which has to be maintained to protect the user and manufacturer’s reputation.

Integrating and maintaining external components not only increases the lifetime costs of a product, but it also fails to provide any added value or differentiation in the market, being invisible to the end-users. This has led to a significant amount of resources, both in terms of time and money, being wasted on recreating connectivity solutions for every IoT product, rather than focusing on unique features or capabilities.

Additionally, the lack of relevant domain knowledge and the pressures of complexity, budgets, and schedules, leads to latent security issues that can compromise the security of the product in the future. To get relief from these burdens, many businesses resort to IoT platforms, as can be seen from a recent survey by Transforma Insights – and rightfully so.

Several key factors impact the viability of any IoT project – especially in the industrial sector: 

• Consistent device reachability: Maintaining reliable and consistent communication between connected devices and the cloud
• Trustworthy device-to-cloud security: Maintaining the integrity and confidentiality of connected devices at both hardware and application level
• Predictable end-to-end cost: Knowing the cost for long-term security upfront

The convenience of using a pre-built platform for IoT device management, to take care of security, the capability of OTA firmware updates, and device lifecycle management, is highly appreciated by many users. However, these platforms can also be quite restrictive in terms of developer flexibility, limiting choices in programming language, operating system, and development tools. While this level of control may be suitable for end-users who are new to hardware and firmware engineering, it can present a significant obstacle for experienced developers looking to integrate connectivity into their existing devices. Industry analyst Arnal Dayaratna, IDC, calls this requirement of openness out in a recent market note on edge application development, saying:

"Prioritize portability: Developing for the edge requires digital solutions to be fundamentally portable and compatible with a multitude of infrastructures."

~Arnal Dayaratna, IDC, "Developing for the Edge: Notes Toward a Definition of Edge Application Development", Published September 2022, ID US47198921

The microvisor approach to IoT platforms is promising alleviation. IoT platforms based on the microvisor architecture may offer the above-mentioned features of remote firmware updates and remote device lifecycle management, but without imposing a vendor’s choice of operating system or programming language. Furthermore, it can do so with increased levels of security, and offer entirely new IoT capabilities, such as live, line-by-line remote debugging of firmware. 

What is a Microvisor?

A microvisor is an IoT approach using hypervisors for microcontrollers, which enables reliable and secure remote operations, such as failsafe over-the-air firmware updates, on Internet-connected devices. 

Architecturally, a microvisor makes use of hardware separation within a microcontroller – such as the STM32U585 from ST – to divide it into two sections at boot time, e.g. by leveraging Arm® Trustzone®. 

TrustZone provides a cost-effective methodology to isolate security critical components in a system, by hardware-separating a rich operating system from a much smaller, secure operating system. Peripherals are assigned to either the microvisor zone or the customer application zone at boot time and the two sections run code independently of each other. This allows for complete security, and to be completely agnostic in terms of which operating system or programming language the application zone runs.

The microvisor element runs ‘alongside’ the application code on the same MCU but with different security privileges, thanks to the TrustZone split. The Microvisor wraps a layer of security and connectivity around the application code space.

A microvisor-based IoT platform does not impose any limitations on which OS or language must be used. It adapts to any approach in embedded development, whether it is 

• a custom bare-metal approach
• built on top of an “off the shelf” operating system, e.g., FreeRTOS or Azure RTOS
• using whatever programming language you choose

One of the key capabilities that a microvisor-based architecture allows is over-the-air (OTA) firmware updates, but in a way that does away with requiring 2 versions of the firmware on the device in case of failures. 

Guaranteeing Device Availability for Firmware Updates

The division of responsibilities in the microvisor architecture ensures reliable and consistent connectivity for IoT devices. The microvisor takes care of maintaining the IP stack, as well as the firmware and drivers for Wi-Fi and/or cellular modems. I.e. everything your device needs to get connected and stay connected. 

This means that even in the event of unexpected application failure, the device remains connected and reachable thanks to the microvisor component remaining connected and reachable. This includes all the components highlighted in the diagram.

The reliability of the connectivity, which eliminates the risk of "bricking" the device, opens up new opportunities for firmware development. This allows for decoupling the process of hardware manufacturing from the firmware development process. With the ability to perform frequent and reliable firmware updates, hardware manufacturers can produce devices even before the firmware has undergone complete testing. (It remains to be seen, however, if this level of agility, previously only seen in web and cloud development, will be adopted by device builders.)

As with any approach to FOTA (firmware updates over-the-air), saving bandwidth is critical, especially for cellular-connected devices that incur cost for data usage. The update service must be aware of the device’s current operational manifest, which defines what code/data should be stored in each defined memory area—either within on-die flash or in QSPI flash. Accordingly, when a new package is queued for FOTA, only areas which do not match would be deployed to the device.

A microvisor-based approach is no different, and the microvisor takes care of moving data required to apply an update from the cloud to a staging area in device QSPI storage, where it remains encrypted. Once the device has all the changed parts of the application stored safely in the staging area, it applies the upgrade in a fail-safe and restartable way, to ensure the upgrade appears atomic from the application’s point of view.

The application can be notified during the upgrade staging process, as it may want to indicate progress to an end user. Once the staging process is complete, the application is notified and can pick a convenient time to perform the upgrade. If required, the customer can force the upgrade to be applied at any time after staging; this may be used if the old code is behaving badly, for example.

How Can I Learn More About Microvisors?

If you’re interested in diving deeper into the microvisor architecture, consider reading the Twilio whitepaper “Architecture and Design Considerations for Modern IoT Infrastructure”, which is organized into two parts. 

Part I addresses a broader audience, such as IoT product managers, project managers, and engineering managers. It lays out a typical device-side IoT architecture and describes the traditional approach of implementation. It details the associated challenges and develops an argument for a different approach, now made possible through the hardware advancements described above.  

Part II addresses the experienced embedded engineer and explains Twilio’s thinking with regard to how the above-mentioned challenges can be effectively addressed with a new architecture. OR: