CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the priority of U.S. provisional application 62/801,039 filed on Feb. 4, 2019. It is incorporated by reference in its entirety.

PROGRAM LISTINGS

mpu.c contains region get and make functions.

mpu.h provides macros necessary to define MPU regions and Memory Protection Arrays (MPAs)

xblk.c contains protected block get, make, and release functions.

xmsg.c contains protected message send and receive functions.

xtask.c contains task create function with protected stack.

tmpu.c provides demo code showing how to use protected blocks, messages, and stacks.

The foregoing contain most of the code related to the inventive material herein. However, many small code segments are spread throughout the SMX RTOS, which hosts this code. In order to run the code it is necessary to have an evaluation copy of the SMX RTOS and its board support code. This is available for free download from ftp://ftp.smxrtos.com/publ/patent_mpu2.zip. In addition, the JAR 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 the board is no longer available contact support@smxrtos.com for assistance in using a newer board.

BACKGROUND

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 for security is to divide the software of an embedded system into many isolated regions. Then if a hacker gains access to one region he cannot access code or data in other regions, as is the case if regions are not isolated from each other.

Most embedded systems use Micro Controller Units (MCUs), which have lower performance processors and much less memory than other 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 larger processors. Because of this and due to the fact that all embedded system code is normally linked into a single executable achieving 100% partition isolation is much more difficult in embedded systems than it is in larger 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 starting memory address, a memory size, and memory attributes. Attributes supported depend upon the MPU, but typically are 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 memory in these regions can be accessed and only as permitted by each region's attributes. For example, there might be a code region (read-only and execute) from location 0×200000 of size 0x4000 and there might be a data region (read/write, execute never) from location 0×10000000 of size 0x1000. Attempted accesses outside of MPU regions or with the wrong attributes (e.g. attempt to execute data) result in termination of task operation and transfer of control to the operating system. This is very effective at blocking malware in order to minimize damage by it.

Security also requires that an MCU have a privileged mode where system software runs and the MPU can be changed and an unprivileged mode where application and middleware partitions run. Switching from unprivileged mode to privileged mode usually can only be accomplished by triggering an exception, which causes privileged code to run and thus a hacker in an unprivileged partition cannot change the MPU. Needless to say privileged code is designed to be very difficult to hack and is strongly protected.

The standard method to create regions is to use compiler pragmas to define which code or data goes into a named section. Then a linker command file defines which sections go into blocks and the size, alignment, and sequence of the blocks. Finally the linker command file defines where the blocks go in memory. Then code defines blocks as regions, which meet the requirements of the MPU (e.g. some MPUs require sections to be powers of 2 in size). For some MPUs subregions must also be defined for blocks. For the purpose of discussion, herein, these are called static regions. The term static is used because regions defined this way cannot be changed after the software is compiled and linked. A previous patent application (Moore, application Ser. No. 15/863,913) discussed methods to define and utilize static regions

SUMMARY OF THE INVENTION

The subject matter of this invention is the introduction of dynamic regions which are defined in the code and do not require linker commands. Hence they are generated in a more automatic manner, which frees the programmer of significant details. This can enable dramatic reduction in programming time and in programming errors.

Also dynamic regions are very important to support conditional and run-time dependent code and data. For example, certain code may be included or not, depending upon product options, installation variables, or run-time variations. Another example is that a buffer size may need to be determined at run time because it depends upon available memory. These kinds of requirements are difficult to handle with linker commands.

The inventive material introduced herein covers the following kinds of dynamic regions:1. Dynamic template regions.2. Permanent task stack regions.3. Temporary task stack regions.4. Protected blocks.5. Protected messages.

In addition the use of protected messages to securely transfer data between isolated regions is introduced.

The preferred embodiment of the inventive material herein is illustrated inFIG. 1. It consists of one processor, one memory protection unit (MPU), one or more read/write memories, one or more read-only memories and one or more I/O devices or peripherals all connected via a single system bus. 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 read/write memory only or other types of memory. In addition, the preferred embodiment of the inventive material herein uses the ARM Cortex-M architecture including its MPU. It should be apparent to one skilled in the art that embodiments using other processor and MPU architectures are also supported.

