Patent Application
20210389988
In order to run the foregoing code, it is necessary to have an evaluation copy of the SecureSMX RTOS. This is available for free download from ftp://ftp.smxrtos.com/pub1/patent_mpu345.zip. In addition, the IAR EWARM v8.20.1 development tools are needed. A free evaluation kit for these tools is available at www.iar.com. Also necessary is an ST Micro STM32746G-EVAL2 evaluation board to run the code. If this board is not available contact support@smxrtos.com for assistance in using another board.
Reference material for this application can be found in:
As embedded systems are drawn more into the Internet of Things (IoT), hacks and malware attacks are becoming increasingly frequent. Thus, security of embedded systems is becoming increasingly important. One tactic to improve security is to divide the software of an embedded system into many isolated partitions. Then if a hacker gains access to one partition he cannot access code or data in other partitions.
Most embedded systems use Micro Controller Units (MCUs), which have lower performance processors and much less memory than other computer systems such as servers, desktop computers, or even smart phones. For memory protection, MCUs normally provide Memory Protection Units (MPUs) rather than Memory Management Units (MMUs) as are found in more powerful processors. Because of this and due to the fact that all MCU embedded system code is linked into a single executable, achieving full partition isolation is much more difficult in these systems than it is in more powerful systems using MMUs.
Partition isolation is achieved in MCU systems by defining code and data regions which are unique to each partition. A region consists of contiguous memory with a memory starting address, a memory size, and memory attributes. The attributes supported depend upon the MPU, but typically include read/write, read only, and execute never. When a task in a partition starts running, regions for its partition are loaded into the MPU. The MPU insures that only memory in these regions can be accessed and only as permitted by each region's attributes. This is very effective at thwarting malware.
A large majority of MCU-based systems that are in use are based upon the Armv7 Cortex-M architecture. Unfortunately the MPU in this architecture is difficult to use. Hence, very little use has been made of it and development of algorithms and software to use it are practically non-existent. The recently released Armv8 Cortex-M architecture corrects some of the problems, but it is not in widespread use yet and it shares some limitations with the Armv7 architecture.
The standard method to create regions is to use compiler pragmas in the source code to define which code or data goes into which section. Then a linker command file defines which sections go into a linker block. To this are added region size and region alignment in the linker command file to produce a region block. MPUs covered by this invention may also have subregions and subregion disables, which permit a region block to more closely fit the actual size needed. Finally the linker command file defines where the blocks go in memory.
The most common MPU size is 8 slots. Unfortunately, this is often too few slots to hold enough regions for a running task such that the regions can be unique for the task. Even worse, some processors have MPUs with only 4 slots. As a consequence, it is often necessary to use regions that are common between tasks, or regions that span regions used by other tasks. Doing so results in tasks and partitions that are not fully isolated. This provides a hacker with a path from one partition to another, which reduces system security.
The subject matter of this invention is the introduction of methods to overcome MPU slot limitations and to use MPU slots more effectively. Three basic methods are included:
The following information describes a simple embodiment of the invention sufficient to explain how it works. The term “application” is understood to mean the software in an embedded device that performs the functions of that device.
If ok, address 102 is sent to Read/Write Memory 108, Read-Only Memory 109, and I/O Device 110 and any other memories or devices connected to address bus 105. Whichever of these devices recognizes the address then receives data from processor 101 via system data bus 107 or sends data to processor 101 via system data bus 107.
It should be apparent, to one skilled in the art, that other embodiments are possible, such as: multiple processors (either multiple cores on the same chip or multiple processors on different chips), multiple MPUs each connecting to the same or to different system buses, multiple system buses, and other types of memory.
For simplicity,
Every task has its own MPA, which governs the regions that it can access. MPU 301 slot 304 is dedicated for the task stack region (every task has its own stack), slot 305 is dedicated for multiple IO regions, and slots 306 to 309 are used for current task regions. The small numbers in MPA 302 slots 315 to 320 are the corresponding MPU 301 slot numbers. This is required by the Cortex v7M MPU and is not generally needed by other MPUs.
MPA 302 slots 312 thru 314 are auxiliary slots. Slots 312 and 313 contain IO expansion regions. Either IO1 region in slot 312 or IO2 region in slot 313 can be selected 303 and loaded into MPU 301 slot 305 and into MPA 302 slot 316, depending upon which IO region is needed at a particular place in the code of the current task. MPA 302 slot 314 contains a phantom region. It contains region pmsg, which is a subregion of one of the regions in MPU 301 slots 304 to 309. Hence, the current task can access it. This subregion is made available to other partitions as a region that they are allowed to access for the purpose of exchanging data. It is the basis for tunnel partitions discussed in a concurrent application by this author.
Hence, in this particular example, the current task is able to access three more regions than MPU 301 would normally permit. It should be apparent to one skilled in the art that the foregoing is just one example of regions for a particular task and that other tasks may have different regions that suit their requirements.
For simplicity,
As presented in the foregoing detailed descriptions, an MPU may be divided into static slots and active slots, if it has enough slots. The static slots are loaded during initialization and normally contain common regions and privileged regions used in pmode. The active slots correspond to the lower slots of the MPA from which the MPU is loaded when a new task starts or resumes. Thus the active slots contain regions specific to the current task, which is running. This structure improves performance and is appropriate for MPUs with a large number of slots, such as 16.
If the MPU has a moderate number of slots, such as 8, not only may there not be enough slots for static regions, there may not be enough slots for all active regions. As a consequence, it may be necessary to create larger regions or to share regions between partitions. Neither of these solutions is attractive because they reduce isolation between partitions and thus reduce system security. Unfortunately, the vast majority of MCUs in use have only 8-slot MPUs and some MCUs have only 4-slot MPUs. Hence, methods to employ more regions than available MPU slots are of great importance to achieve good security for MCU-based systems.
This invention adds auxiliary slots to a task's MPA. These can contain expansion regions and phantom regions that are specific to each task. Several expansion regions can share a single active MPU slot. When needed, the appropriate expansion region is loaded into the active MPU slot. Where in the code to place these region loads can be determined from Memory Management Faults (MMFs) when the task runs. Hence, neither redesign nor deep understanding of the code are necessary. Phantom regions are subregions of active regions. They are used to share data with other partitions and they do not require an active slot in the MPA of task of origin. This is the foundation for the tunnel portal presented in a concurrent application by this author.
An additional method of this invention to overcome insufficient MPU slots is to create a single partition template containing all regions needed by the partition code. These regions are based solely upon the code. The resulting template may be much larger than the available number of MPU slots. If so, special-purpose tasks are defined, each to execute a portion of the partition code, such that each task needs no more regions than there are MPU slots for it to use. These tasks are child tasks that are created by the main partition task, which becomes their parent task. A child task cannot do anything that its parent task cannot do, hence it is a proxy for the parent that is designed to reduce the regions needed by the parent.
Tasks are usually defined to perform certain functions, then writing the code follows. The unique idea here is that the partition code comes first, then the partition template that includes all regions needed by the code, then the tasks are defined to run the code such that the needed regions of each will fit into the MPU.
