Kumar R., Singhania A., Castner A., Kohler EProceedings of Design Automation Conference

Pages: 218 - 223 June 2007

112/04/13

Many embedded systems contain resource constrained microcontrollers where applications, operating system components and device drivers reside within a single address space with no form of memory protection. Programming errors in one application can easily corrupt the state of the operating system and other applications on the microcontroller. In this paper we propose a system that provides memory protection in tiny embedded processors. Our system consists of a software run-time working with minimal low-cost architectural extensions to the processor core that prevents corruption of state by buggy applications. We restrict memory accesses and control flow of applications to protection domains within the address space. The software run-time consists of a memory map: a flexible and efficient data structure that records ownership and layout information of the entire address space.

AbstractAbstract

- 2 -

Memory map checks are done for store instructions by hardware accelerators that significantly improve the performance of our system. We preserve control flow integrity by maintaining a safe stack that stores return addresses in a protected memory region. Cross domain function calls are redirected through a software based jump table. Enhancements to the microcontroller call and return instructions use the jump table to track the current active domain. We have implemented our scheme on a VHDL model of ATMEGA103 microcontroller. Our evaluations show that embedded applications can enjoy the benefits of memory protection with minimal impact on performance and a modest increase in the area of the microcontroller.

Abstract (cont.)Abstract (cont.)

- 3 -

Memory corruption on tiny embedded processor

What’s the ProblemWhat’s the Problem

- 4 -

Microcontroller Address Space

Single address space CPU Shared by apps., drivers and OS

Buggy applications can easily corrupt the state of OS and other applications

Memory ProtectionMemory Protection is an enabling technology for is an enabling technology for building robust embedded softwarebuilding robust embedded software

Memory is accessible to all SW modules via a single address spaceMemory is accessible to all SW modules via a single address space

Program1Program1

Program2Program2

Program3Program3

OSOS

MMU can provide protection domains However, No MMU in embedded micro-controllers

。MMU hardware requires lot of RAM。Increases area and power consumption 。Poor performance - High context switch overhead

Memory Protection Unit (MPU) Static partition of address space into segments However, not suited for complex embedded software (such as OS)

。Supports only two domains (user mode and supervisor mode) Protect the kernel from applications but not the applications

from another

Software-based Fault Isolation Run time checks to ensure all memory accesses reside within the segment

allocated to it The run time checks are introduced through compiler or binary rewrite

。However, Binary rewrite are quite error prone

Related WorkRelated Work

- 5 -

supervisor

user

P1P1

P2P2

P3P3

MPU

Memory protection suited for low-end microcontrollers Solve memory write Protectionmemory write Protection

。“store”, “call”, and “return” instructions

The proposed Memory Protection MethodThe proposed Memory Protection Method

- 6 -

Memory Map Table

HWextensio

n

Program1Program1

Program2Program2

Program3Program3

OSOS

Domain A

Domain B

Domain C

Domain D

Domain N

……

Domain A

Domain B

Domain C

Domain N

Memory Map Checker

Memory Map Checker

Control Flow Manager

Control Flow Manager

Jump TableSafe Stack

Software Routine

Hardware Software Hardware Software Co-Design approach Co-Design approach to memory to memory protectionprotection

Protection DomainProtection Domain

- 7 -

Domains - Logical partitions of address space Every software module stores its state in its own

protection domain Protect domain from corruption by other domains

Modules are restricted from writing to memory outside their domain through run-time checks

There is one single trusted domain in the system that is allowed to access all memory

Memory Map Data StructureMemory Map Data Structure

- 8 -

Fine-grained layout and ownership information

User Domain

Kernel Domain

Partition address space into blocks

Memory is allocated to domains as segments(Sets of contiguous blocks)

Store information for all blocks Encoded information for all block

Ownership – domain ID Layout - start of a logical segment

A domain could be allocated multiple segments

Efficiently encoded using 4 bits per block xxx0 - Start block of segment xxx1 - Later block of segment xxx is the 3-bit domain ID

Efficiently encoded using 4 bits per block xxx0 - Start block of segment xxx1 - Later block of segment xxx is the 3-bit domain ID

Back

Functional unit that validates store operations Programs can write only into their domainPrograms can write only into their domain Invoked before every write access

Memory Map CheckerMemory Map Checker

- 9 -

DATA_BUS

CPUCPUMemory Map

CheckerMemory Map

Checker RAMRAMCPU_ADDRCPU_WR_ENCPU_STALL

MMC_ADDRMMC_WR_EN

ST_INSTR

Triggered on a store instruction Operations performed by the checker

Lookup memory map for issued write address Retrieve permission from memory map and validates stores

。Verify current executing domain is block owner

Assuming block size of 8 bytes, the nine significant bits of the address represent the block number

Permissions are packed into a byte If the encoded information is stored in four bits, then each byte would contain information of two

contiguous blocks Last bit of the block number Last bit of the block number represents the block offset of the permission

The remaining bits index into the memory map tale

Address Address Memory Map Lookup Memory Map Lookup

- 10 -

Address (bits 11-0)

Memory Map Table

1 Byte has 2 memory map records

8

1

Block Number (bits 11-3) Byte Offset (bits 2-0)mem_map_base

Assume block size of 8 bytesAssume block size of 8 bytes

Memory Map Offset (bits 11-4)

In cycle 2 First, it stalls the processor execution and take control of the address bus to memory Perform address translation address translation to lookup memory map for issued write address Read memory map table to retrieve the permission

In cycle 3 Retrieve permission from memory map, and compare the ownership

information to the current executing domain ID If check is successful, then MMC issues a write operation to data memory

Operations Performed by Memory Map Operations Performed by Memory Map Checker (MMC)Checker (MMC)

- 11 -

CPU_WR_ADDR

MMC_RD_ADDR

CLK

CPU_ADDR

CPU_WR_EN

MMC_ADDR

MMC_WR_EN

CPU_STALL

Cycle 1 Cycle 3Cycle 2

Regular Mode

Protected Mode

The software library manages all the memory available Ensure memory map accurately reflects current ownership and

layout。The library provides “malloc”, “free” and “change_own” calls that

automatically update the memory map data structure Only permit block owner to free/change its ownership

。To enforce this condition, the software library reads the current active domain ID

Set up the memory map memory map to be located in a protected regionlocated in a protected region。This prevents corruption of the memory map data structure

Initialize the MMC with the proper block size, number of protection domains and the range of protected address space

Memory Map Software LibraryMemory Map Software Library

- 12 -

Back

Control flow can become corrupt at run-time EX: Returns on corrupted stack (return addresses are stored in stack) Memory map can’t prevent such internal memory corruption

。Programming errors can cause a module to corrupt its own state

Control flow manager ensures that control can never flow out of a domain, except Via calls to functions exported by other domains Via returns to calls from other domains

The current executing domain also needs to be tracked Required by the memory map checker to validate write accesses

Control Flow ManagerControl Flow Manager

- 13 -

Preserve control flow integrity through the Preserve control flow integrity through the safe stack safe stack that stores return addressesthat stores return addresses

Each domain has its own jump table in flash memory that contains The set of functions exported by each domain

The jump table can’t be corrupted Due to modules are not allowed to write to flash memory

Each entry in the jump table is an instruction jump to a valid exported function

Re-directed through jump table Re-directed through jump table to functions exported by a domain

Cross Domain LinkingCross Domain Linking

- 14 -

Program Memory

Domain Acall fooJT

Domain Bfoo:…ret

fooJT: jmp foofooJT: jmp fooDomain B Jump Table

Cross Domain Call Verify call into jump table Compute callee domain ID

Jump exceptionJump exceptionJump exceptionJump exception

Jump table of all domains are stored at fixed location in flash memory This simplifies the verifying of the target address of a call

A valid target address has to reside in the jump table

The ID of the called domain can be easily determined First, computing the address offset from the base address of the jump table Then, dividing it by the size of the jump table

The cross domain call state machine Push the current domain ID into stackPush the current domain ID into stack, during cross domain call Restore the previous domain ID and transfer control back to the caller’s

domain, during cross domain return

Domain TrackingDomain Tracking

- 15 -

jmp_tbl_base_addressjmp_tbl_base_address jmp_tbl_upper_boundjmp_tbl_upper_boundcall_addrcall_addr

<=<= <<

ANDAND

Single stack shared by all domains Protection Model

Prevent corruption of stack belonging to a domain by any module belonging to a different domain

Bounds set during cross domain call Processor copies the current stack current stack

pointerpointer into a stack_boundstack_bound register

Enforced by MMC before all writes No writes beyond stack bound

Run-Time Stack ProtectionRun-Time Stack Protection

- 16 -

Run Time Stack

CallerDomain

StackFrame

CallerDomain

StackFrame

CalleeDomain

StackFrame

CalleeDomain

StackFrame

Stack Ptr.

Stack_Bound

Stack Base

Prevent cross domain corruption of stack Prevent cross domain corruption of stack

In spite of the stack are protected from corruption from modules in other domains However, programming errors can cause a module to corrupt

its own stack

Therefore, maintain an extra stack in protected memory To store return addresses in a separate stack that resides in a

different protection domain

Setup safe stack at the end of all global data and make it grows up toward run-time stack

Safe StackSafe Stack

- 17 -

RUN-TIMESTACK

RUN-TIMESTACK

SAFESTACKSAFE

STACK

HEAPand

GLOBALS

HEAPand

GLOBALS

Safe Stack and Run-Time Stack approach one another

Performance Overhead (CPU Cycles) Introduced Performance Overhead (CPU Cycles) Introduced by the Memory Protection Mechanismby the Memory Protection Mechanism

- 18 -

Compare with software based approach through binary rewrite

Superior performance of run-time

checks in HW

High overhead of software based memory map checker Due to require bit shift operations to translate write address to memory map

lookup Cross domain call and return have an overhead of five cycles

Due to push “current domain ID”, “stack bound” and “return address” to stack 。 Information of five bytes needed to push to stack, and one byte can be written every cycle

Restoring the values read from stack Saving and restoring return addresses doesn’t introduced added overhead

Due to simply redirect the store of the return address to safe stack when processor pushes the return address to the run-time stack

Unit: CPU Cycles

Overhead introduced in memory map software library Due to memory map needs to be updated during allocation,

free and transfer of memory Higher overheads of free and change_own calls

Due to additional checks to prevent illegal freeing or ownership transfer of memory by non-owners

Performance Overhead (CPU Cycles) of Software Performance Overhead (CPU Cycles) of Software Library Introduced by the Protection MechanismLibrary Introduced by the Protection Mechanism

- 19 -

Compare overhead of memory allocation routines in the presence and absence of the protection

mechanism

Unit: CPU Cycles

Code and Data Memory Usage of the Code and Data Memory Usage of the Software LibrarySoftware Library

- 20 -

Memory map size is 256 bytes for multi-domain protection This represents an overhead of 6.25% (256 bytes / 4KB)

Flexible data-structure - Tradeoff RAM for protection Size of memory map required can be reduced

。By modifying portion of address space that required memory map for protection

The total code memory usage of the software library 3674 bytes , an overhead of 2.8% (3674 bytes / 128KB)

Most of the additions to the core area are in the memory map decoder That support arbitrary bit-shift in a single cycle

。We can eliminate this overhead for fixed block size and number of protection domains

32% overall increase in the core area This represents a modest increase in the overall chip area

。As core occupies only a small fraction of the overall area

Hardware Overhead of the Memory Protection Hardware Overhead of the Memory Protection Mechanism Mechanism

- 21 -

HW/SW co-design approach for memory protection Enabling technology for reliable embedded software systems Combine flexibility of software with efficiency of hardware

Building blocks for memory protection Memory map checker Control flow manager

Practical system with widespread applications Low resource utilization Minimal performance overhead Binary compatible with existing software and tool-chains

。The software library provides a standard programming interface。Doesn’t modify the instruction set architecture of the processor

ConclusionsConclusions

- 22 -

Memory protection suited for low-end microcontrollers Doesn’t static partition of address space

。Rely on a memory map data structure Record ownership ownership and layoutlayout info. of the entire address space

Doesn’t rewrite binary to introduce run time checks。Enhance the “store”, “call”, and “return” instructions to perform run time

checks in hardware Hardware Software Co-Design approach Hardware Software Co-Design approach to memory protection

The proposed Memory Protection MethodThe proposed Memory Protection Method

- 23 -

Memory Map Checker(STORE instruction extension)Memory Map Checker

(STORE instruction extension)

Hardware ExtensionsSoftware Routine

Memory MapMemory Map

Domain Tracker(CALL instruction extension)

Domain Tracker(CALL instruction extension)

Domain Tracker(RETURN instruction extension)

Domain Tracker(RETURN instruction extension)

Jump TableJump Table

Safe StackSafe Stack

Low cost architecture extension and software Low cost architecture extension and software library work together to isolate from anotherlibrary work together to isolate from another