The Internet of Things (IoT) and security have been mainstays in technology headlines over the past month, and really for more than a year now. Distributed, botnets, and ransomware are now common in the vocabulary of embedded and IoT engineers of all types, so it is fitting that the major announcement to come out of last week’s ARM TechCon addressed them.
Well, really the “announcement” was a series of smaller, related announcements, but they all started with the unveiling of the Cortex-M23 and Cortex-M33 processor cores, the first commercially available ARM IP to implement the. The two cores are comparable in performance and power consumption to the Cortex-M0+ and Cortex-M3/4, respectively, though ARM officials report that the -M33 will deliver a 20 percent efficiency gain over its predecessors as well as increased floating-point performance.
But the main features of both processors lie in their security architecture, which is centered around TrustZone technology that was previously only available on Cortex-A-class application processors. For those unfamiliar, TrustZone operates around the concept of a Trusted Execution Environment (TEE) that has been implemented using a software layer in Cortex-A devices that prevents non-secure (or potentially non-secure) code from running in protected memory regions alongside critical code (Figure 1). In the case of the –M23 and –M33, however, core logic is used to partition the secure and non-secure worlds, reducing transactional instruction latency to as little as one or two clock cycles and removing the memory and resource overhead of the software-based “secure monitor.” As a result, a root of trust can be established on even the smallest of IoT edge nodes using TrustZone, and the jointly-announcedcan extend that functionality with features such as persistent secret storage, rollback prevention, software validation, True Random Number Generation, encryption, and authentication, which are implemented through a combination of hardware, software, and tools.
In addition, the new –M-class processors are available with an optional memory protection unit (MPU) capable of safeguarding up to 32 memory regions (16 secure, 16 non-secure). The MPU can also be reprogrammed by an operating system (OS) on the fly in multi-tasking environments so that memory permissions change with the context of a system (Figure 2). Therefore, one application may have access to data, resources, and peripherals that another does not, enabling task isolation that works in tandem with TrustZone to increase overall security.
Both the –M23 and –M33 are backwards compatible with previous ARMv7-M processors, and ARM representatives noted that they expect to see the two new processors deployed in conjunction for designs looking to balance power consumption and performance. In order to distribute the security provided by the new cores throughout an entire system architecture, ARM also extended its CoreLink Interconnect with two new offerings: the CoreLink SIE 200 that implements IP blocks on top of the AMBA 5 AHB5 bus protocol to disseminate TrustZone technology throughout system on chips (SoCs) based on Cortex-M (Figure 3); and the CoreLink SSE 200 subsystem that packages CoreLink SIE 200 IP, a Cortex-M33 core, the mbed OS, optional TrustZone CryptoCell and wireless Cordio Bluetooth Low Energy (BLE) or 802.15.4 technologies, and all the necessary infrastructure to accelerate SoC design cycles.
A while back I wrote about, including the integration of a real-time kernel (RTOS) and merging of the mbed 2.0 “Classic” and mbed 3.0 “Eventing OS” development lines. Last week at TechCon, ARM officially announced perhaps the worst-kept secret in embedded, mbed Cloud.
I say “worst-kept secret” because for me, and many others in the industry, the mbed Cloud was a foregone conclusion once ARM released mbed Device Connector/Server at last year’s show. That said, the end-to-end strategy of mbed is the right one, and logical as tech companies attempt to bring IT and OT together for IoT. ARM has a stake in IoT from the silicon IP level, in device software with the mbed OS, and now at the network services layer through the device management capabilities that make up mbed Cloud (Figure 4):
- mbed Cloud Connect: Allows users to add or decommission devices with any cloud using the standards-based Open Mobile Alliance (OMA) Lightweight Machine-to-Machine (LWM2M) model and CoAP.
- mbed Cloud Provision: Provides provisioning tools that facilitate the trusted injection of software/firmware assets into devices, as well as policy provisioning across cloud applications.
- mbed Cloud Update: For network-wide software and firmware updates.
- mbed Cloud Client: The management portion of the platform that is compatible with multiple OSs and application clouds.
The mbed Cloud portal isas version 1.0 won’t be publicly available until Q1 2017, but hopefully the cloud/datacenter infrastructure expertise that resides in will come in handy should the platform hit any speed bumps as it is rolled out.
Another area ARM could perhaps use SoftBank’s assistance is in the revenue model behind mbed Cloud, which is positioned as a software-as-a-service (SaaS) offering that departs from the company’s tradition of IP licensing. One concern is mbed Cloud’s “” – capabilities that to-date haven’t specified.
Of course, ARM needs to generate income from mbed somewhere, so selling IP that is optimized for the mbed OS which in turn provides benefits when used in conjunction with the mbed Cloud (where ARM will generate recurring services revenue) makes sense. However, this does mean that the success of the mbed Cloud SaaS model is somewhat contingent on the success and adoption of the mbed OS, which places an onus on the mbed OS team to deliver and maintain a commercially viable solution. OSs in general and RTOSs in particular take time to reach critical mass, and while ARM quotes a global community of 200,000 mbed OS 5 developers and more than 1 million device builds per month, users are likely to be less forgiving the more they start taking mbed-based solutions to market, especially given the current security climate.
Meanwhile, OS vendors like Express Logic, Green Hills, Mentor Graphics, Micrium, MontaVista, and Wind River were out in force at the show…
Continuing education for engineers
Another announcement that officially occurred the week before ARM TechCon but warrants mention is the launch of ARM Education Media, a subscription-based, self-service digital education hub designed by ARM and supported by its ecosystem partners that offers continuing education coursework and e-learning materials for professional engineers, students, and generally anyone who is interested in IoT/embedded computing.
The ARM Education Media platform spawned out of the realization that most engineers learn using technology that is already out of date when they’re in school, only to be faced with the reality of annual or quarterly technology turnover once they enter the workforce (8051, anyone?). Khaled Benkrid, a University of Cambridge lecturer with a PhD in Computer Science and ARM’s Director of Education and Research Enablement, said that this has resulted in a growing skills gap in engineering where students are learning from “materials based on 20-30-year-old technology” and that “industry needs to play a role in this as content creators with content that keeps pace with technological changes … because the gap exists in the workplace itself.”
Today, Education Media consists of four online courses focused on embedded system design and programming that are supported by ARM partner development kits available from:
- “Efficient Embedded Systems Design and Programming” covers interrupts, memory mapping, interfaces, etc., and uses the (ARM Cortex-M4-based with floating-point capability) as a reference platform.
- “Rapid Embedded Systems Design and Programming” teaches students how to build embedded systems using high-level APIs, promotes code reuse, and uses the mbed OS running on the (based on ARM Cortex-M0+) as an example.
- The “Internet of Things” course goes into detail on how to build a “Thing,” create mobile apps, and connect the device to hubs and the cloud.
- “Digital Signal Processing” focuses on the concepts behind DSP programming for 32-bit systems, and relies on the (ARM Cortex-M4-based with built-in audio codec) as a baseline.
These initial courses include lab videos, quizzes, lecture courses, and slides that cover both theory and practice, and are the first four on a roadmap that will expand with eight more classes:
- RTOS and MCU programming
- SoC design with Cortex-M0 cores prototyped via FPGA
- Advanced SoC design with Cortex-A cores
- Linux development including kernel design and custom peripherals
- Online/mobile gaming app development in the context of smartphone resources
- Mechatronics, robotics, motor control, and sensing
- Co-processor design based on a specific instruction set architecture (ISA)
- Very-large-scale-integration (VLSI) design, from concept to foundry
The Education Media program is based on a four-year revamp cycle to prevent curriculum from becoming stale, and considers industry technology trends (such as 64-bit processors) as well as requests from users and academia in its development. The platform’s interface includes community forums that facilitate peer-to-peer interaction as well as access to moderators, and those curious can get initially acquainted with the platform at.
Final thoughts on education and security
A final observation on education and security came during a Q&A with ARM CTO Mike Muller last Tuesday in which he responded to a question about security in light of the recent DDoS attack on DYN domain name system (DNS) servers. Muller stated that, going forward, everyone has a stake in security – from IP vendors through OEMs to end users. He equated the problem to that of pollution, where everyone suffers from indifference but benefits from proactive measures like recycling.
Just before the session ended I challenged him on this, because, in my opinion, end users in the consumer world don’t know, care, or have much of an incentive to take even the simplest of IoT security measures, such as changing default passwords – the mindset here is plug ‘n’ play, set ‘n’ forget. In the commercial and industrial sectors organizations have a vested interest in committing the time and resources to secure their networks and systems, but unless individuals are faced with immediate and moderately severe cyber consequences (think home security rather than the inconvenience of downed websites), I find it hard to believe they will expend the energy to prevent armies of botnets from repeatedly resurfacing. To me the burden of responsibility for security falls to original equipment manufacturers (OEMs) and their suppliers, who have both financial motivations for keeping the Internet protected, as well as legal reasons because they will undoubtedly become the initial targets of lawsuits when they inevitably start to fly.
The differences in opinion on this topic between Muller, myself, and others I spoke to at the show reveal that we are facing a digital age learning curve, one that impacts us not only as an industry, but as a society as a whole.
I welcome your thoughts in the comments section.