All Your Questions about Twilio Microvisor

All Your Questions about Twilio Microvisor

In January, we hosted our first webinar of the year, together with our friends at STMicroelectronics. While the topic of “Unbrickable Remote Firmware Updates for Highly Secure MCUs” might sound niche to some, it turned out to be the most successful webinar in the over 7-year history of Twilio IoT. With more than 1000 registrations and an attendance rate of 37%+, we got over 120 new sign-ups for the Twilio Microvisor Beta Program (and you can still sign up too!)

Hardware is hard, but hardware is also cool. The concept of IoT is seeing a renaissance and opportunities abound, as more and more people realize that the real problems of the world are physical in nature. The idea of getting device connectivity from a company that has been running connectivity solutions for many years makes sense, of course, and the appeal of the promise of unbrickable firmware updates over the air is not hard to understand – bricking, i.e. rendering a device useless like a brick through a firmware update mishap, can be a costly accident in some scenarios. Many of you wrote to us about the need for more reliability in remote firmware management, and we’re glad that our Microvisor architecture, powered by Arm TrustZone, can fill that void.

You asked a total of 80 (!) questions during the webinar. Wow!

We couldn’t address them all live, so here is a write-up of the key questions that reached us, grouped by category. If you haven’t heard of Twilio Microvisor but got curious now, start by reading What is a Microvisor?

On secure remote live debugging and firmware OTA

Is live remote debugging like online testing in PLC, or via ST-Link?

The Twilio Microvisor capability of secure remote live debugging means GDB debugging of your device entirely remotely, single-stepping your code in a debugger of your choice over a cellular or Wi-Fi connection. Think of it as the exact same experience you get over a JTAG cable, but now served over the remote connection to a device that could be anywhere in the world.

We do this by tunneling the GDB debug protocol from your local development PC or MAC all the way to the edge device itself wherever it is in the world. The Twilio CLI tool and the Microvisor plugin enable you to run a local GDB server on your development PC that you can hook up to your own toolchain / integrated debug experience. This local server connects through the Twilio Microvisor service directly to the edge device that you want to debug. This connection is transparently routed over a cellular connection (e.g. powered by Twilio Super SIM), via Wi-Fi, or Ethernet to your embedded device.

This enables you to access all of the capabilities of your debugger (command line or GUI-based) that you will need in order to figure out what went wrong with your application. The initial release of Microvisor’s remote debugging functionality supports the majority of the commands provided by GDB. Further commands are expected to be added as Microvisor progresses through its Beta phases. Find details in our documentation.

How does the microcontroller establish an end-to-end encrypted connection with the debugger, and how is interception prevented?

The secure remote debugging link is fully end-to-end encrypted and ensures only you have access to your devices. On top of this, having access to secure remote debugging means that the local debug ports can be physically disabled on the edge device itself, meaning that your device is even more secure in the field. This level of security is one extra way that you can protect your code running on your device.

Is live debugging through GDB feasible for production firmware? What is the memory cost of enabling the feature?

Yes. We route the GDB protocol directly to the GDB debug hardware internally to the U5 device - in this way, it doesn’t require any more RAM to work, even in a production device. I.e. you can debug your actual production firmware on a device if you want to.

Can you debug a device that has challenging 2-way communication, for example a Class-A LoRaWAN device

The Microvisor itself communicates via Cellular, Wi-Fi, or Ethernet to the Microvisor service and your back end application. We are not currently planning on implementing the Microvisor interface over a LoRaWAN radio. That said, because you have the ability to run whatever you want on the application side of the device, you can attach a LoRa radio here and use Microvisor and its communication just for OTA updates. We are already working with multiple LoRa use cases where this architecture is being considered.

When pushing firmware updates OTA, does it have to be a complete package or do you support delta updates as well?

The Microvisor upgrade protocol supports partial upgrades (e.g. of the firmware, application, filesystem components). You can upgrade just the pieces that have changed, and in turn minimize the over-the-air data / bandwidth / power consumption / cost etc., required for the OTA upgrade itself. See here for details on applications and bundles.

On supported environments, footprint, and integration

Which MCU(s) does Twilio Microvisor support today, and what are the hardware requirements to run Microvisor?

Today, we support the STM32U585 family of ICs. The microvisor architecture itself can run on any Cortex-M processor with Arm TrustZone. As for the Twilio Microvisor product, we are considering support for other Arm M33 MCUs. If you have a specific use case that requires a specific MCU, please contact us at microvisor@twilio.com and we will take a look.

Do you need to use the Twilio Electric Imp hardware, or can it be used on custom proprietary hardware?

The Microvisor implementation is different from the Electric Imp products that Twilio also offers. In the case of Microvisor, you will design and build your own hardware based on the Microvisor hardware requirements. The only requirements for Microvisor are the STM32U585, and either a modem, or the comms co-processor. All other hardware choices are entirely up to you.

Can the Microvisor be installed on something larger? Does STMicroelectronics produce something with more flash or would you need to do multiple updates to push larger updates?

We support an external QSPI flash on the STM32U585 for additional code and data storage. See here for details. The whole filesystem can be upgraded and included in the Microvisor OTA update. There is a total application bundle size limit of 64MB. See also here for further details.

Do you have any plans to support Linux-based apps?

Not currently, no. While the microvisor architecture (using the Arm TrustZone in order to separate connectivity from the firmware itself) could run on an application processor which itself could run Linux or even Android, this is not currently supported by the Twilio Microvisor product. We are focussing initially on the MCU class of devices, typically those with an Arm M33 core with TrustZone – starting with the STM32U585.

Does the Microvisor “take over” the entirety of the TrustZone or can user applications put code alongside the Microvisor in the TrustZone? If the latter, how do we prevent application code from corrupting the Microvisor?

Yes, the Microvisor does take over the TrustZone and the user can not put applications alongside the Microvisor. We intend to support additional features in the TrustZone implementation and expose them via the Microvisor system calls. If you have a use case that requires a specific piece of TrustZone code, then please do contact us at microvisor@twilio.com and we will take a look.

What is the device-side footprint of Microvisor in terms of flash/RAM?

The STM32U585 MCU contains 2MB of internal flash. This is partitioned by Microvisor during the boot sequence such that the upper 1MB are reserved for Microvisor and the remaining 1MB are provided for the application.

Microvisor owns the MCU’s BKPSRAM (2KB) and the top half (256KB) of SRAM3 (512KB total). The lower 256KB of SRAM3, and all of SRAM1 (192KB), SRAM2 (64KB), and SRAM4 (16KB), is available to the application.

Find more information here.

Are all the pins of the STM32U585 Microvisor dev board exposed, or just the GPIO pins?

All except the small handful reserved for Microvisor - see here for details. All of the remaining IO is available for use directly, natively from your firmware (in the application space).

Can Microvisor-powered devices connect to a cloud of our choice?

Yes. The application pane is under your complete control. You can integrate with AWS, Microsoft, Google, or any other cloud / hosted / on-premise offering of your choice.

What does the “going through Twilio” path mean for say connecting to Azure IoT Central? Would this mean the sample X-CUBE-AZURE using X-CUBE-CELLULAR for the U5 is not required?

Correct. Microvisor takes care of all of the connectivity components that your device requires, in order to get online and stay online. This includes the modem firmware, the device drivers, and the IP stack running on the device.

This means that connection to Azure IoT Central is now a simple matter of authentication, and MQTT for which we provide example code and simple Microvisor system calls.

One of the big benefits of a Microvisor approach is that you no longer have to worry about, support, and maintain all of those connectivity components, as these are taken care of by Twilio Microvisor. You get to focus on your application and business case, and leave it to Twilio to take care of all of the boring but necessary components.

On security

What mechanisms are available for secure remote attestation of the device/microvisor/firmware?

Each Microvisor device reports the layout and contents of the flash as a series of individual layers / components. Each layer is separately signed for secure attestation purposes. This ensures that only devices belonging to you can run only code belonging to you.

Are the hardware private keys owned by STMicroelectronics, or are there options to have custom provision of HW private keys?

Each Microvisor device is individually identified and keyed. Customers can deploy public keys to the device & service at time of manufacture and sign any or all parts of the manifest with the corresponding private keys. This process allows the service to verify that a manifest should be accepted by a device – rejecting deployments by a bad actor with service access early in the process.

With your support for write protection, do you imply that the root file system is read-only?

No, the application / firmware file system (e.g., the FreeRTOS file system if you use FreeRTOS as your operating system) is read/write.

On connectivity

Which cellular modem hardware, Wi-Fi hardware, and Ethernet hardware does Microvisor support? Is it easy to add any not yet supported?

Microvisor initially supports the Quectel EG21-G LTE Cat 1 cellular module for mobile connections to the Internet, which has global band support. Microvisor will reserve this module’s networking functionality, and the application must establish cellular Internet communications via Microvisor system calls.

The application will have full access to the EG21-G for GNSS (GPS, GLONASS, BeiDou/Compass, Galileo, and QZSS) operations.

When your application uses the same connectivity interface/hardware as Microvisor, how do you handle that?

Microvisor will reserve this module’s networking functionality, and the application must establish cellular Internet communications via Microvisor system calls.

For cellular connectivity, does Twilio mandate the use of Twilio Super SIM, or does Microvisor also support other SIMs?

We do not mandate the use of Super SIM with Microvisor. While a Super SIM is included in all our Nucleo dev boards enabling you to get up and running straight away, any other SIM that is supported by our supported modem(s) (see above) should be capable of working with Microvisor. Please contact us at microvisor@twilio.com and we will assist with integrating the new SIM provider as an option.

Is there support for a local gateway? i.e., can one device have cellular, while others connect via Bluetooth / Wi-Fi through the gateway, while maintaining the full functionality?

Today, each Microvisor device makes its own connection directly (over Wi-Fi, Ethernet, or Cellular transports). We are considering extending the Microvisor capability to work on devices that are connected via a Microvisor gateway. I.e., devices that are connected to the gateway over Bluetooth / Bluetooth Low Energy, or possibly Wi-Fi.

Does this work with industrial ethernet protocols, like PROFINET or EtherNet/IP?

We support Ethernet as a transport via the same co-processor that is used for Wi-Fi, Bluetooth, and Bluetooth Low Energy. You can test this Ethernet transport today on the Nucleo development board. We do not support PROFINET or EtherNet/IP today.

The products I develop are operating within WirelessHART networks. How might Twilio Microvisor help with networks such as WirelessHART, that are closed and typically operated by conservative customers very concerned with management of change?

While the microvisor architecture is indeed designed for highly reliable and highly secure remote firmware management, we are currently not planning to support network types outside of the common ones of Wi-Fi, Cellular, and Ethernet.

On maintenance of Microvisor itself

Does Twilio handle maintenance and updates to the microvisor itself? If so, when is this scheduled?

Yes, Twilio handles the upgrades of the Microvisor component itself. This includes upgrading the Microvisor code, the device drivers and IP stack, and the firmware on the co-processor and modem. i.e., everything that your device needs to remain secure, and connected. These updates are scheduled and you will be notified when they are due to take place.

What guarantees are there for ongoing, reliable, security audits of the Microvisor source/implementation?

We contract an external penetration test of both the Microvisor hardware and Microvisor cloud components and can share the summary of the results under NDA. In addition to this, we are looking towards meeting some IoT specific security certifications. Our whitepaper on the Microvisor architecture provides some details as to the security approach that Microvisor takes.

What prevents the microvisor from being bricked while it is being updated?

The microvisor component is upgraded in an atomic operation (much like the application component). It is extensively tested before release, and the release process is staged such that many devices will have been upgraded and tested before your devices receive the upgrade. This upgrade process is based on the same approach that we use with the proven Twilio Electric Imp platform that has already delivered 10s of millions of firmware updates and never ever bricked a single device.

To conserve power can the hypervisor itself go into a low power mode until the user application needs attention?

Yes, the microvisor implementation is a low power architecture and it manages the low power modes / states of the device, ensuring the lowest possible power consumption can be achieved whatever radio you are using for connectivity. Your application / firmware gets to control the connection schedule, and Microvisor makes sure that the device is in the lowest possible power consumption state. It is possible to create a Microvisor-based device that will operate for multiple years of operation from a single set of primary cells.

On pricing and support

Should this solution be discontinued by Twilio, what kind of support / handover can we expect on the existing products?

Don’t worry, the great thing about the Microvisor approach is that there is no tie-in to Twilio, or at least not in the same way as there is with probably all other IoT platforms that exist today. We fully support migrating away from a Microvisor architecture if that’s the direction that you want to take.

Because the application and firmware is entirely in your hands, all of this code continues to work in a world where you now implement the connectivity components. i.e., if you want to recompile your application and firmware image so that it supports the connectivity components directly and removes Microvisor from the path, then you can do this. One final update from Microvisor to push this image to your device, and you are up and running.

What sort of licensing/pricing models do you offer?

We offer a per device / per month licensing model where you only pay for devices that connect in a given month. For business cases looking for a CapEx style model, we can also offer a one-time fee option for the lifetime of your device. Please reach out to us for further details.

Miscellaneous

Does Microvisor support precision timing and offer high performance NIC capability?

Microvisor provides Ethernet and Wi-Fi connectivity via a co-processor connected to the STM32U585 - see here for more details. In this way, the network performance of both interfaces is only limited by the performance of the ESP32, the host interface, and the Microvisor stack itself. The performance of both connectivity interfaces is suitable for a wide range of IoT applications and we intend to characterize this performance in the future.

Who is responsible for maintaining date time on the system?

The Microvisor itself takes ownership of the RTC (Real-Time Clock) and works with the Microvisor cloud service to maintain accuracy.

Tell us about anticipated parts shortages for these MCUs and mitigation strategies.

Great news! Because the STM32U585 is on 40nm technology node, it has been far less impacted by the global supply chain shortage than those on other older fabrication technologies. The STM32U585 is not on allocation and is available now on standard ST lead times for orders placed today.

Can this platform be used in a class III medical device? Do you have the appropriate documentation for the platform to be validated?

At the moment, we do not have the documentation / certifications that enable Microvisor to be used as a Class III medical device. This may be something that we look to do in the future but is not currently a priority.

How is the microvisor approach different from digital twins?

A microvisor is a technology that provides secure and reliable remote operations for connected microcontrollers, by using hardware separation, e.g. through the Arm TrustZone. A microvisor-based IoT architecture allows for features such as failsafe (“unbrickable”) over-the-air firmware updates and live remote debugging, and does not impose any limitations on the operating system or programming language used in the device.

On the other hand, digital twin is the concept of virtual replicas of physical assets that are used to monitor and control these assets. Digital twins use data from IoT devices to create a digital representation of the physical asset, which can then be used to simulate, analyze, and optimize the performance of the asset.

So while a microvisor enables reliable connectivity and updatability for connected assets, digital twins are a way to utilize the data collected from these devices to gain insights and make informed decisions about the physical assets.