Products       Learn       Buy       Support       Company
 
  Home > Products > SecureSMX
   
 
  SecureSMX®  Next Generation RTOS

for ARM Cortex-M Memory Protection Unit


The current practice for developing secure software is to patch problems as they are exposed by breaches. By then sensitive data has already been stolen, or damage has already been done. With luck only white hat hackers are finding the vulnerabilities, but even then, code must be endlessly patched. It will never converge to perfection because new exploits will continue to be found.

The current thinking for improving this process is to teach engineers to write better, more secure code from the start. This undoubtedly will help, but it won't solve the problem.

Arm's Platform Security Architecture (PSA) promotes dividing code into isolated partitions. This way a hacker is limited to damaging only the partition that was breached. Furthermore, code improvement can focus scarce programmer talent on the most critical partitions. We agree with Arm's approach and have spent the last few years implementing it.

We are pleased to announce SecureSMX®, our next generation RTOS, which solves the security problem for microcontroller-based embedded systems. Isolated partitions limit hacker invasions so they cannot reach sensitive data, keys, passwords, and other vital information, nor access code or I/O in other partitions. The main embedded software can be run in a single privileged partition, with little modification. Vulnerable software such as network stacks, drivers, SOUP, etc. can be moved into unprivileged partitions, which are wholly isolated from the main embedded software and from each other.

In order to accomplish full isolation between partitions, SecureSMX provides the following:

  • Effective privileged mode (pmode)/unprivileged mode (umode) processor control.
  • Efficient, flexible task-based Memory Protection Unit (MPU) control.
  • Software Interrupt (SWI) API for system services.
  • Multi-heap support.
  • Partition portals.

Normally, embedded applications run entirely in pmode when they are first ported to SecureSMX, since this requires only minor modifications to be made to them. Then vulnerable and untrusted code is moved into isolated umode partitions in order to protect the main software from hacking and malware. SecureSMX provides the necessary tools to accomplish this with moderate effort.

SecureSMX currently supports MCUs based upon the Cortex-v7M and Cortex-v8M architectures. These account for a large proportion of microcontroller units (MCUs) in use today. Several methods are provided to gain efficient memory usage, despite problems caused by the v7M MPU region size and alignment requirements. Security and structuring improvements made to current v7M systems can be carried over to new v8M systems. Since partitioning fosters modularity, this can result in considerable labor savings, as well as strong security for new things.


 
Solutions



Is Your Thing in Danger?



The Cortex-M architecture accounts for a large proportion of microcontroller units (MCUs) in use today, and these have powerful security features, such as Memory Protection Units (MPUs). Yet, these are used only sparingly, if at all, in most embedded systems, despite the pressing need for better security. Why is this? It seems that the embedded system industry has made a collective judgement that the Cortex-M security features are either too difficult to use or not effective and that they waste too much memory and processor time.

However, we have found that through careful, innovative design techniques, embedded system software can be divided into isolated partitions that provide strong security against hacker invasions. Furthermore, this can be done with only moderate memory and performance losses on the order of 10% — well worth the security gained. However, new tools and methodologies are necessary if reasonable development schedules are to be met, because there are many difficult obstacles to be overcome. It is for this reason that we have developed SecureSMX, our next generation RTOS.

Read More



Where's the Gold?



Many Things are embedded systems to which networking has recently been added. As such, hackers coming in via the Hacker's Highway (aka the Internet) can overcome the weak defenses of such systems and gain access to critical information such as encryption keys. As a consequence, entire networks can become compromised all the way into the Cloud.

There is a solution to prevent hackers from easily breaking in to your system and stealing your gold and jewels. The following is a simple, step-by-step approach to protect your new Thing using SecureSMX, our next generation RTOS.

Read More



What's in Your SOUP?



SOUP (Software of Unknown Pedigree) is frequently incorporated into embedded system projects due to schedule pressure, lack of in-house expertise, or for other reasons, and it ends up in the final product. If you got unlucky, the code has few comments, objects are poorly named, the logic is convoluted, and the code is full of easily-hackable flaws. No one on your team has time to understand it, let alone fix it. If you picked the code, you may feel like you are in the soup. Maybe it is time to find another job, such as in a grocery store. But WAIT! There is a solution.

Read More



FreeRTOS Security? Not to Worry



It is now possible to greatly increase the security of FreeRTOS projects by porting them to SecureSMX using FRPort, a free product of Micro Digital. SecureSMX facilitates dividing an application into isolated partitions, which provides strong protection against hacking since a hacker can only access code and data within the partition that was entered. In this solution paper, we discuss the porting process and how SecureSMX security features are much stronger than those of FreeRTOS and SAFERTOS. FRPort also makes the large suite of SMX middleware products and drivers available to FreeRTOS projects.

Read More



Moving Uptown to Umode



pmode partitions may be just as effective as umode partitions for reliability; however, umode partitions are much better for security for the following reasons: the hardware enforced pmode barrier prevents umode access to pmode data and code; the MPU cannot be turned off nor altered from umode; and the Background Region (BR) is ineffective in umode. These combine to form a very strong barrier for a hacker who has penetrated a umode partition. Thus umode is "uptown".

Read More



More Solution Papers are coming. Sign up below to be notified.



Technical Papers



Achieving Full MCU Partition Isolation

Part 1: Fundamentals

To me, achieving full partition isolation is the Holy Grail of microcontroller unit (MCU) system security, because there is very little a hacker can do from inside of a partition that is fully isolated from the rest of the system. Achieving full isolation between processes using memory management units (MMUs) is relatively easy but requires power-hungry processors to achieve acceptable process switching times, and it is not appropriate at the task-level, anyway. Achieving full partition isolation for MCUs using memory protection units (MPUs) is possible, but comes with a high level of difficulty.

Read More  (embedded.com)

Part 2: MPU Management

In this part we get into the details of MPU management, including the relationship between Task Control Blocks (TCBs), Memory Protection Arrays (MPAs), and MPA templates. Note that an MPA template might apply to a single MPA and task or it might be shared between tasks and their MPAs. Normally, in the latter case, the tasks would be in the same partition. There is also a default MPA that does not require a template. It is used when no MPA has been created for a task. In the sections that follow we will discuss how to define templates.

Read More  (embedded.com)

Part 3: Heaps

In this part we cover the need for multiple heaps and the heap features that are useful in partitioned embedded systems. The right heap is important for achieving full MCU partition isolation. Multi-heap support becomes necessary because using a common heap between partitions breaks partition isolation. A hacker can wreck a common heap and bring all partitions using it down or possibly invade them through it.

Read More  (embedded.com)



More Technical Papers are coming. Sign up below to be notified.






  SecureSMX User's Guide Peek (Excerpts)

For more information, please register or email sales@smxrtos.com.
Indicate your interest in SecureSMX. Full documentation will be supplied under NDA to qualified prospects.

Solution Papers





SMX Products

eheap

Kernel Special Features

Why Use an RTOS?

     back to top
 
  Register for More Info
 
  Sign Up for News
 



       eheap  Embedded Heap


 
Home       Sitemap       Contact