IoT Device Designers Get Help from ARMv8-M Cores

Someone once said that IoT devices live in the wild. They must be able to withstand any number of attacks, whether they be communication, physical or software based attacks. The threats are real and the consequences can range from simple irritants to life threatening situations.

It’s because of these threats that IoT device designers are now blessed with the chance to show off their design skills by creating devices that can safely be deployed, used and updated while they live in the wild. I attended a webinar this week hosted by ARM entitled, ‘Security Principles for ARM TrustZone for ARMv8-M’. ARM does a really nice job of educating designers about their products and this webinar was no exception to the rule. The webinar gave a very nice overview of how ARM is helping IoT device designers meet the challenges of keeping their devices safe in the wild.

This webinar is one of many that can be found on ARM’s developer community web site and it primarily focused on how the ARMv8-M architecture helps designers guard against software-based attacks. At the center of ARM’s solution is their TrustZone technology. TrustZone has been around for quite some time but it takes on a different incarnation when used with the newer M33 and M23 cores.

The M33 is essentially the same as a M3 or M4 except for two very noticeable differences. The first difference is that the M33 adds a co-processor interface that can be used for management of multiple sensors envisioned to be needed in an IoT system. The second difference is that there is no longer a dedicated hardware block for TrustZone. Instead, every block within the M33 has been restructured to natively handle TrustZone functionality and capabilities. The core is taking on the full responsibility of TrustZone protection. TrustZone wise the same is true for the M23 which is functionally equivalent to the M0/M0+ ultra-low power cores but again, all of the functions have been re-engineered to handle TrustZone natively.

So what does that imply? In the new architecture, there are literally two parallel execution environments for the processor. One environment is secure, the other is non-secure. There is a new hardware block that is called the security attribution unit (SAU). The SAU is responsible for partitioning and managing all memory (instruction addresses and data) into one of these two buckets. As the processor executes, each address (of instructions or data) to be fetched has its security attribute checked. Those marked as secure are checked to make sure they are indeed in the secure address space and are being used by secure code. These instructions run in the secure execution environment. Those not so marked are checked that they are in the non-secure space and their instructions are run through the non-secure execution environment.

Each environment also has its own set of registers throughout the system and these registers are managed by the SAU. The system boots first into the secure area and once the system is reset it then runs code in the non-secure space for application boot up. The system also allows for secure vs non-secure interrupts and includes additional instructions that can be used by the software designers to check address validity in one environment vs the other. ARM has added additional instructions to the ACLE (ARM C language extensions) that enables software engineers to proactively check for things like buffers that are trying to cross secure/non-secure boundaries. This latter feature enables software designers to easily protect their code against a common attack surface known as buffer overruns.

Memory and device configuration can be controlled in one of three ways. They can be hard wired at synthesis time before manufacturing, they can be programmatically changed through code in secure memory or they can be dynamically changed by the system stack using TrustZone security protocols and Root of Trust encryption using the IDAU (implementation defined attribution unit) interface. In fact, the system configuration can literally be a combination of all three of these methods.

The new architecture also support legacy systems by overlaying two more modes (Trusted and Un-Trusted) on top of the ARMv7-M privileged and non-privileged modes. The CPU handles transitions between these modes automatically based on the attribution mappings that have been set. The new cores can also handle cross-domain function calls including calls from non-secure code that want to use the services of code in the secure section. The good news for software developers is that this is handled automatically by the new architecture through the addition of a Secure Gateway instruction call. The SG call tells the system that code from the non-secure side is asking for services from the secure code side. The hardware takes care of pushing secure registers onto the stack and zeroing out the registers before running tasks for the non-secure side. This ensures that non-secure code does not get a peek into the secure side’s memory. Once the service has completed its secure side work the hardware again automatically pop’s the secure side register values for continuation of work that was going on in the secure side before the non-secure call came in.

This last scenario is essentially a good example of what ARM is trying to achieve in general with the M33/M23 architecture. They are providing a system-wide approach to security that is highly configurable and yet easy to secure.

The main idea being to keep the existing software development paradigm in place for application developers while making it as easy as possible for the IoT system designers to be able to secure their IoT devices in the wild.

See also:
ARM Developer Community
Webinar recording
ARM TrustZone