ARM hopes to make chips in the Internet of Things a little more secure – by adding its TrustZone defenses to its microcontroller blueprints. In effect, ARM is adding some extra hurdles for hackers to leap in order to exploit programming bugs in gadgets' firmware.

What the heck is TrustZone?

TrustZone is usually found in ARM's application processor designs – your smartphone's system-on-chip, for example. It's been around since the early 2000s, though, first appearing in the ARMv6 ARM11 family well before the smartmobe boom.

It works by splitting the device into two domains: a secure domain and a non-secure domain. Typically, your bells-and-whistles operating system with its huge attack surface and vulnerabilities (cough, Android) runs in the non-secure domain, and the secure domain runs stuff that needs safeguarding: code-signing cryptography and fingerprint sensor drivers, say.

TrustZone acts as a barrier between the two worlds, allowing the non-secure and secure realms to talk to each other, but never allowing the non-secure side to tamper with the secure half – allowing the non-secure zone to trust that the secure zone hasn't been infiltrated to do anything malicious to the system.

This technology isn't hacker-proof, not by a long shot: the sort of bugs that turn into security holes in operating systems can crop up in the code running in the secure domains. If there is a buffer overflow or an integer overflow vulnerability in the secure zone's code, it can be exploited from the non-secure side to infiltrate the protected realm.

ARM's TrustZone is only as secure as the software running in the safeguarded world – and smartphone firmware developers have managed to turn out some pretty insecure code.

For its microcontroller implementation of the technology, ARM has added some hardware-level defenses against any crap code that ends up in devices. ARM hopes its microcontroller designs end up in plenty of Internet of Things gadgets, so hardwiring extra protections into the mechanism is welcome.

Welcome to ARMv8-M

ARM's new microcontroller architecture is called ARMv8-M, which is not to be confused with ARMv8-A. ARMv8-M is a 32-bit design with TrustZone features and a few other bits and pieces. ARMv8-A is the 64-bit architecture used in high-end handhelds and server chips.

ARMv8-M is optimized for high-speed switching between the secure and non-secure states, with banked stack pointers and interrupt control registers, and a new instruction marking out functions the non-secure side is allowed to call in secured space. Devices start in secure mode, allowing it to initialize the hardware and check the integrity of the code running in non-secure mode. Then it switches to the non-secure zone, and away it goes, handling function calls from the insecure world as required.

Here's a summary of how ARM explained ARMv8-M to us.

Don't confuse ARMv8-M with ARMv8-A: the former is a 32-bit architecture for microcontrollers – chips that run software for a very specific purpose

Here's the minimum you can do with a top-end microcontroller that uses an ARMv8-M core – this is the baseline specification

This is the mainline specification, which builds on the baseline spec to build a fully featured micrcontroller core

The architecture doesn't have a standard memory management unit (MMU) that provides virtual memory via paging. Instead it has a memory protection unit (MPU) which can mark regions of RAM as accessible and non-accessible. ARMv8-M is more flexible with the size of its regions – which look like x86-style segments. The previous architecture only allowed regions to be built out of fixed blocks.

ARMv8-M looks pretty standard to ARM-savvy programmers. It also provides separate stacks and stack limit pointers for the secure and non-secure worlds, and automatically switches between the two, minimizing bugs in code by moving this job into the hardware. Interrupt control registers are also banked between the secure and non-secure worlds so the protected zones can guarantee they'll always receive interrupts they rely on.

Memory addresses can be marked as accessible to the secure or non-secure zones, preventing non-secure code from accessing secure areas. This protection extends beyond RAM to flash storage and memory-mapped peripherals

Now here's an interesting part: the SG instruction. Entry points into the secure zone from the insecure realm must start with this particular machine code instruction. That tells the processor this is a legit function call. If non-secure code tries to call a function in the secure area that isn't marked with an SG instruction, an exception is raised

Finally, a technology preview of mbed – ARM's operating system for the Internet of Things that is still in development – is now available. Work on the software was announced this time last year, and released as a beta in September. ®