To Partition Or Not To Partition

For Secure IoT Devices

Most embedded systems that are connected to the Internet, also known as things or devices, are based upon microcontrollers having moderate performance and small to moderate memories. The software or firmware in these devices typically runs on minimal RTOSs with no security protection. All software in such systems is linked into a single executable. If a hacker breaks in anywhere, he has access everywhere.

The low-hanging fruit of phishing and weak passwords is rapidly disappearing. As a consequence, hackers will be switching to exploiting the vulnerabilities (of which hundreds have been identified) in Internet-connected devices, in order to gain access to the large, ransom-rich systems that incorporate them. This and the recent Presidential NO SECURITY = NO SALE executive order and potential C-Suite and company liability risks, make it imperative for OEMs to start producing secure IoT devices and secure embedded devices.

Software vulnerabilities can be fixed. However fixing them, without partitioning, is a bit of a futile effort. First, a hacker needs only one overlooked vulnerability to break into a device. Second, new vulnerabilities are being found frequently, so fixing them is a never-ending battle. And the battlefield is not level. Developers are expected to develop useful products within time and cost constraints. How much time do they have for security concerns? A hacker has no time nor cost constraints and he needs to find only one vulnerability in order to get inside a device and to exploit it. Hence hackers have the advantage. Therefore developers need better methods and tools to create secure IoT devices and secure embedded devices.

The following figure illustrates the basic concepts of partitioning:

The pmode barrier is enforced by the processor. Software cannot penetrate it, except via an exception. The umode[1] partitions above this barrier typically contain third party SOUP, network stacks, other middleware, and drivers. These are typically the most vulnerable to attack from the outside world. Below the barrier are pmode[2] partitions containing mission-critical software, system software (e.g. RTOS), security software, and secret data such as encryption keys that are stored in the Vault. In systems with fully isolated partitions, if a hacker breaks into one partition, he cannot access code or data in other partitions. The barrier is especially high for umode partitions.

This basic concept of identifying what is vulnerable and what is most important to protect is, in itself, a step toward better IoT device security. Then, rational decisions can be made concerning how to apportion resources. For resource-constrained projects, not wasting development resources is crucial, if secure IoT devices are to be developed on time and on budget. What is needed to do this are the tools to partition off the vulnerable code, which may not be fixable, in order to protect the valuable code and data.

SecureSMX® is our next generation, secure RTOS, which enables users to create partitions that are fully isolated from each other. This level of isolation is not easy to do in microcontroller systems since all software is linked into a single executable. To accomplish full partition isolation, SecureSMX provides the following, necessary capabilities:

  • Robust pmode/umode processor control.
  • Efficient, flexible, task-based Memory Protection Unit (MPU) control.
  • Software Interrupt (SWI) API for system services (e.g. SemSignal()) from umode.
  • Multi-heap support that allows partitions to have their own heaps, if needed.
  • Partition portals to transfer data and commands between isolated partitions.
  • Utilities to help partition software.

The objective of SecureSMX is to give developers the weapons to level the battlefield with hackers. It is not practical to expect developers to create perfectly secure code throughout an entire project in a limited time, if ever. There are actually many advantages to partitioning that support faster project development. There is a learning curve, but once down this curve, the payback is the ability to create secure IoT devices within practical time and cost limits.

For more information, please visit www.smxrtos.com/securesmx. Keywords: Secure IoT devices, Secure Embedded devices, Secure RTOS, SecureSMX


[1] umode = unprivileged or user mode.

[2] pmode = privileged or protected mode.

More Blogs

Copyright © 2021 Micro Digital, Inc. All rights reserved.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s