Efficient Embedded Memory Protection for Express Logic’s ThreadX® Real-Time Operating System (RTOS)

Overview

Embedded systems, like desktops and servers, are vulnerable to programming errors that can cause unintended behavior and even system failure. A bug in one program can overwrite data in another program or in the kernel, threatening the entire system.

Many techniques exist for protecting programs from the errant actions of other programs on the same system. In desktops and servers, this is effectively done through memory management hardware and a multiuser operating system that gives each user an independent virtual machine environment. This isolation effectively prevents direct access to the resources of other users or the operating system itself. But desktop and server approaches require more resources and may be impractical for an embedded system, which typically has demanding performance requirements and memory constraints.

This paper describes an approach that is designed to provide memory protection for embedded systems. “Embedded Memory Protection” (EMP) provides the benefits of memory protection without the typical overhead or complexity of desktop approaches.

Memory Protection Background

Traditionally, in desktop and server applications, memory protection has involved virtual memory and a process model programming environment. In a process model programming environment, each process has an independent virtual address range mapped to physical memory. This approach introduces overhead from complex bookkeeping of mapped page tables, additional memory for page tables, performance penalties for accesses outside of cached table entries, and performance penalties for copying data during transfers between processes. Because of this overhead, such memory protection approaches were limited to use in desktop and server systems which enjoy ample processor and memory capacity and no demanding real-time response requirements.

Embedded systems are vulnerable to program bugs in a similar manner, even though they are not multi-user oriented. Some embedded operating systems have employed process model memory protection schemes as an effective defense. Typically, such systems have ample memory and processor resources that can tolerate the inherent overhead of such an approach. Such resource-rich embedded systems are generally found in military, aerospace, and high-end telecommunications applications.

Process Model Memory Management

In a process model approach, each process is provided with a complete virtual address range which is mapped, page by page, to pages of physical memory. Physical addresses are constructed by appending the address offset within the page to the page address itself, resulting in a 32-bit address (in 32-bit architectures).

Each process can only reference addresses within its own virtual address range, preventing it from accessing any physical memory not explicitly mapped to its virtual address range. Mapped physical memory is able to be accessed according to the permissions for that page, as stored in the Memory Management Unit (MMU) by the operating system upon initialization.

Benefits of Process Model Memory Protection

A process model approach offers benefits to the developer by providing an independent virtual machine to each process.

• Each process gets an independent, complete 32-bit (or 64-bit on certain architectures) virtual address range that is mapped to physical memory one page at a time. This provides inherent protection of one process from unintentional access by another process.
• This also enables use of discontiguous physical memory pages to hold a process’s code and data, often convenient in dynamic-loading systems where memory fragmentation might otherwise block program loading and memory allocation.

Disadvantages of a Full Virtual-Memory Process Model

A virtual-memory process model architecture necessarily suffers from several operational disadvantages:

• Memory Overhead
  The kernel provides bookkeeping for all available memory pages and associated tables.
   
  • Table overhead: Typically, one set of tables is needed for each process with its own virtual address range. For complex applications, overhead per virtual address range can require up to several hundreds of kilobytes.
  • Bookkeeping overhead: Each page needs at least one record per virtual address range to indicate the physical address, virtual address, access permissions, owner, etc.
  • Kernel Overhead: The kernel must have additional code to load the virtual process and set up the virtual address related bookkeeping.
     
• Processing Overhead
  The kernel needs to do more processing for context switches and message passing.
   
  • Context switching is complicated by the need to reprogram the MMU at each process change.
  • When the MMU is reprogrammed, this invalidates internal MMU caches (Translation Lookaside Buffers, or TLBs) and the processor caches, causing overall system performance to suffer as a result of increased cache misses and cache line reloads.
  • Exception handling becomes complex, requiring one or more copies to pass information from a driver to the virtual address range of a process
  • Message Passing from one virtual address range to another involves at least two copies of the same data.
     
• Programming Complexity
  Setup and programming is more complex in a process model system.
   
  • The programmer may need to define processes and reassign resources apart from actual application development
  • Applications may have to communicate through special channels since other process memory is not directly addressable
  • Interrupt service routines may not be able to pass information to application processes directly, requiring a second level of interrupt processing
     
• Debugging Overhead
  Debugger integration becomes more demanding and complex, limiting user choice of tools.
  • Special debugging requirements exist, involving debugger support by the kernel to be able to handle breakpoints in virtual addresses not directly mapped to corresponding physical addresses. The debugger and kernel must be tightly integrated, with changes in one mandating changes to the other.
  • JTAG bandwidth can be too limited to pass all system information (i.e., multiple, dynamic virtual memory page tables) to the debugger, requiring availability of system control through Ethernet or a serial port, which in turn demands extra hardware and drivers to be available in support of specific platforms.

The Cost of Virtual Memory

While process model virtual memory systems deliver added security for embedded applications, they also increase overhead in memory consumption and processor performance, and programming complexity is greater for the developer. This introduces certain costs for the benefits of this approach:

• More Expensive Processor. Since a sacrifice in performance might prevent an embedded system from performing its intended tasks, the cost of a process model approach can include the need for a more powerful, more expensive processor to make up for the increased overhead.
• Additional Memory. Enough memory must be provided for an embedded system to perform its intended functions. With the increased need for memory resources, the cost of a process model approach may require additional memory with the attendant increase in package size and power consumption that results.
• Longer Development Time. Development time is directly related to the ease with which programmers can produce correct code. Process model architectures generally require more complex programming approaches, costing additional development time and delaying time to market.

These costs might be tolerable in a large military or telecommunications system where ample memory and fast, expensive processors are common, or where cost is not an overriding concern. But, in a typical cost-sensitive embedded system where memory and processor speed are tight, such drawbacks may prove prohibitive.

As a result, most embedded applications have opted to live without the benefits of MMU support. With Express Logic’s new EMP memory protection technology, now there is a way to enjoy the benefits of memory protection in an embedded system without significant additional cost in performance overhead, increased memory size, or added programming complexity.

A New Approach

Express Logic’s new Embedded Memory Protection (EMP) product delivers memory protection for embedded applications while retaining the small size, ease of use, and high efficiency of the ThreadX® real-time operating system (RTOS). EMP offers protection of user threads and the kernel from inadvertent overwrites caused by bugs in application code—one of the most common reasons why embedded developers consider using memory protection. EMP meets this objective in a straightforward, efficient manner appropriate for resource-constrained embedded systems.

EMP enables developers to place boundaries around critical data structures, critical threads, and the kernel, preventing unintended access. Much like the way watertight compartments protect a ship from being flooded by a single break in its hull, EMP prevents bugs in a thread from causing unintended actions outside of that thread, containing the malfunction and “keeping the ship afloat” until an orderly recovery can be performed.

This approach also automatically identifies certain bugs during development, since any attempt to cross these boundaries activates a processor trap and the offending instruction is identified by an error handler routine. This response streamlines test and validation, speeding time to market.

EMP still plays a role in the field, after the system has been deployed, by protecting it against latent bugs that escaped testing. Rather than allowing such bugs to bring down the entire system, they are automatically trapped and reported to the system, keeping them from causing further damage to application resources or the kernel.

How It Works

EMP maps kernel and application memory address ranges directly to physical memory. Each virtual page address is mapped to the identical physical page address. No provision for demand-paging is needed since embedded systems rarely, if ever, employ the mass storage required for such operation. EMP provides threads with a simple API to services that set MMU protection registers to permit or prevent access to designated data areas and to activate or deactivate those protections.

• Page protection. Access to each mapped page is specified as
  • Read-Only
  • Read/Write
  • No Access
• Thread Protection. On creation, each thread can set its own boundaries to protect it from accessing or overwriting memory outside those boundaries. By setting protection boundaries around each thread, the developer ensures that such threads cannot unintentionally overwrite other threads’ memory or the kernel. This protection effectively eliminates some of the most difficult bugs to find.
• Flexibility. EMP enables “trusted” threads to be introduced with permission to read/write anywhere, as can the kernel. Since all threads begin as trusted, no programming action is required to leave them as such. Trusted threads may be used for efficient inter-thread data transfer and communication, avoiding the copy step required in many traditional process model architectures.
• Ease of Use. EMP requires only a handful of API calls. Very little code is added to provide EMP services, keeping ThreadX small enough to satisfy the demanding memory requirements often found in embedded systems. In fact, EMP can be removed from an application upon deployment, enabling the manufacturer to recover even the small amount of memory it requires.

How EMP Differs From Other Protection Approaches

Right from square one, Express Logic takes an antithetical approach, believing that protection should only be used when needed. Express Logic leaves protection off by default, so developers can choose when protection is needed. Most protected systems protect everything, and the developer must perform some action(s) to turn protection off when it gets in the way.

EMP offers the developer advantages in performance efficiency and programming simplicity compared to other approaches to memory protection:

• Programming Simplicity
  EMP offers programming simplicity and operational efficiency by using a simple API and only a handful of service calls. When contrasted to the multiple address ranges of most virtual memory approaches, this is far, far simpler and much more appropriate for embedded use.
  
  To illustrate, let’s see how one call sets up everything:
  
  tx_protect_initialize(*table,table_size,*memory,memory_size,*error_handler);
  
  Each thread can set its protection as follows:
  
  tx_protect_memory(*thread,*memory,memory_size,protect_type,pagetable,pagetable_size);
   
• Efficient Performance
  Because EMP employs a single logical=physical address space, there is no overhead introduced at context switch time. Page translation is achieved completely in hardware, within the address-generation stage of the processor pipeline.
  
  Also, because of the single, unified address range, messages can be sent from one thread to another without the need to copy the data, as is required when multiple virtual address ranges are used. Zero-copy data transfers are performed at all times, further increasing efficiency.

Advantages and Benefits of EMP

Express Logic’s new EMP offers advantages over a process model approach to the developer seeking memory protection in an embedded system:

• EMP is more appropriate for the job
  • Designed from the ground-up for embedded applications, not adapted from a desktop or multi-user approach
• EMP has lower overhead
  • Minimal bookkeeping overhead because logical addresses map directly to physical addresses
  • Minimal memory overhead because the number of tables is reduced to 1 page table per thread
  • Minimal execution/context switching overhead amounts to turning on and off the MMU (3 instructions)
  • Kernel runs with MMU disabled (trusted), maintaining a zero-copy API
• EMP is easier to use
  • Easy to program, with a simple API and few restrictions on program operation
  • No special loader support necessary
  • Independent of the debugger or toolchain
• EMP is optional
  • Existing applications can run as is or add protection as desired
  • More user control over the level of protection

By using Express Logic’s new EMP for ThreadX in development of an embedded system, developers will enjoy increased system reliability and faster time to market, without sacrificing performance or memory footprint. EMP’s ease of use makes it ideal for existing ThreadX users as well as for developers new to the use of commercial RTOSes. Small, fast, and easy-to-use – all good reasons to consider Express Logic’s ThreadX RTOS with EMP for successful embedded system product development.

About Express Logic

Headquartered in San Diego, CA, Express Logic offers the most advanced run-time solution for deeply embedded applications, including the popular ThreadX RTOS, the high-performance TCP/IP stack NetX™, and the embedded MS-DOS file system FileX™. All products from Express Logic include full source-code and have no run-time royalties. For more information about Express Logic solutions, please visit www.expresslogic.com, call 1-888-THREADX, or email inquires to sales@expresslogic.com.

ThreadX is a registered trademark of Express Logic, Inc. EMP, NetX, FileX, CANX, preemption-threshold, picokernel, UDP fast path technology, are trademarks of Express Logic, Inc. All other brands or product names are the property of their respective holders.