There is a lot of frustration by security experts and legislators, with device OEMs not implementing security measures. Apparently, many OEMs balk at the ongoing effort and expense to create and manage a security team to verify and fix problem reports and to communicate their actions according to the requirements of various security agencies. On their side, OEMs probably prefer a one and done approach to security. I think that I have a solution for this conflict. It is not a perfect solution, but it is a half-step in the right direction.
The solution is partitioning. We have found that it is possible to achieve strong isolation between software partitions for the Arm Cortex-M architecture with memory protection units. It is possible to do this without excessive memory waste or processor overhead for both the v7M and v8M architectures.
Tasks in one partition cannot access resources in another partition. They must go through portals. Tasks in client partitions send protected messages, pmsgs, to the portals of servers. pmsgs contain commands and data, which servers interpret and send back results via the same portals. pmsgs contain client privilege levels to permit applications to implement least-privilege operations on, for example, file accesses.
As such, partition portals are the only thing known about one partition by other partitions. Internal data and code is hidden. This allows partitions to be individually stopped and rebooted to recover from malicious attacks. Down the road they also could be individually updated.
The Cortex-M architecture provides a very strong barrier between unprivileged mode (umode) and privileged mode (pmode). We call this the pmode barrier. It can be penetrated from umode only by exceptions, the principal one being the SVC exception, which is used for system calls from umode.
Vulnerable code is put into isolated umode partitions, and mission-critical code is put into pmode partitions where it runs largely unchanged, yet is protected by the pmode barrier and by partition isolation.
A hacker gaining access to a umode partition is sand-boxed – he can go no further. In addition, limitations on runtime, object access, interrupts, and IO are placed upon umode partitions to block the hacker from doing system damage from within a partition that he has penetrated.
This architecture protects equally against zero-days as against unpatched known vulnerabilities. It also supports development and support siloing to protect against insider threats.
The two sides seem about to go to war. I wonder if this half step might be preferable. It is entirely possible that partitioned devices can perform their main functions and guard private data, while under attack. It is also possible that ancillary functions can recover from attacks. We have proven that this approach is feasible and that it works. It would at least give consumers and other users more protection than they have now.
The above diagram illustrates the principles of Cortex-M partitioning. It shows how a vulnerable network stack and its Ethernet driver are isolated from the rest of the system in a umode partition. The apparent penetration of the pmode barrier by the tunnel portal is only virtual – the path is actually via the SVC exception.
For more information on partitioning, check out our free ebook Achieving Device Security.
Ralph Moore — President and SecureSMX Architect https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYyv-PrT9gXjY9cNq91mFsc59ytFkfIVTvW8TGih5P8J44Q0UHuB0ta8Mw18OzN76ChhSAN23KJRYBxRth1V_n4fpRZGZA1Je-wowrKu7BSAEmkIJjW68JHLag_pP9-4fDDdv02ciili-NoU9dt9g-nWQQxjEHseLtUClZ1_q0eFX2ZkEXstELRSuoEAQ/s100-rw-e365/ra.png
