A System for Coarse Grained Memory Protection in Tiny Embedded Processors

1
A System for Coarse Grained Memory Protection in
Tiny Embedded Processors

• Kumar R., Singhania A., Castner A., Kohler E
• Proceedings of Design Automation Conference
• Pages 218 - 223
• June 2007

2
Abstract

• 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.

3
Abstract (cont.)

• 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.

4
Whats the Problem

• Memory corruption on tiny embedded processor

• Single address space CPU
• Shared by apps., drivers and OS
• Buggy applications can easily corrupt the state
  of OS and other applications

Program1
Program2
Memory is accessible to all SW modules via a
single address space
Program3
OS
Microcontroller Address Space

• Memory Protection is an enabling technology for
  building robust embedded software

5
Related Work

• 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

MPU
P1
user
P2
P3
supervisor
6
The proposed Memory Protection Method

• Memory protection suited for low-end
  microcontrollers
• Solve memory write Protection
• store, call, and return instructions

HW extension
Program1
Domain A
Domain B
Program2
Domain B
Domain C
Program3
Domain C
Domain D
OS

Domain N
Domain N
Memory Map Checker

• Hardware Software Co-Design approach to memory
  protection

Memory Map Table
Software Routine
Jump Table
Control Flow Manager
Safe Stack
7
Protection Domain

• 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

8
Memory Map Data Structure
Fine-grained layout and ownership information
Partition address space into blocks
Memory is allocated to domains as segments (Sets
of contiguous blocks)
A domain could be allocated multiple segments

• Store information for all blocks
• Encoded information for all block
• Ownership domain ID
• Layout - start of a logical segment

User Domain
Kernel Domain

• 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
9
Memory Map Checker

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

DATA_BUS

• 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

10
Address ? Memory Map Lookup
Address (bits 11-0)
Assume block size of 8 bytes
Block Number (bits 11-3)
Byte Offset (bits 2-0)
mem_map_base
Memory Map Offset (bits 11-4)
8
1
Memory Map Table
1 Byte has 2 memory map records

• 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 represents the block
  offset of the permission
• The remaining bits index into the memory map tale

11
Operations Performed by Memory Map Checker (MMC)
Cycle 1
Cycle 3
Cycle 2
CPU_WR_ADDR
MMC_RD_ADDR
Regular Mode
Protected Mode

• In cycle 2
• First, it stalls the processor execution and take
  control of the address bus to memory
• Perform 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

12
Memory Map Software Library

• 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 to be located 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

Back
13
Control Flow Manager

• Control flow can become corrupt at run-time
• EX Returns on corrupted stack (return addresses
  are stored in stack)
• Memory map cant 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

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

14
Cross Domain Linking

• Each domain has its own jump table in flash
  memory that contains
• The set of functions exported by each domain
• The jump table cant 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 to functions
  exported by a domain

Cross Domain Call
Domain A call fooJT

• Verify call into jump table
• Compute callee domain ID

Domain B Jump Table
Domain B foo ret
fooJT jmp foo
Jump exception
Program Memory
Jump exception
15
Domain Tracking

• 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 stack, during
  cross domain call
• Restore the previous domain ID and transfer
  control back to the callers domain, during cross
  domain return

jmp_tbl_base_address
jmp_tbl_upper_bound
call_addr
lt
lt
AND
16
Run-Time Stack Protection

• 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 pointer into a
  stack_bound register
• Enforced by MMC before all writes
• No writes beyond stack bound

Stack Ptr.
Callee Domain Stack Frame
Stack_Bound
Caller Domain Stack Frame
Stack Base
Run Time Stack

• Prevent cross domain corruption of stack

17
Safe 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

RUN-TIME STACK
SAFE STACK
HEAP and GLOBALS
Safe Stack and Run-Time Stack approach one another
18
Performance Overhead (CPU Cycles) Introduced by
the Memory Protection Mechanism
Superior performance of run-time checks in HW
Unit CPU Cycles
Compare with software based approach through
binary rewrite

• 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 doesnt
  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

19
Performance Overhead (CPU Cycles) of Software
Library Introduced by the Protection Mechanism
Unit CPU Cycles
Compare overhead of memory allocation routines in
the presence and absence of the protection
mechanism

• 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

20
Code and Data Memory Usage of the Software Library

• 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)

21
Hardware Overhead of the Memory Protection
Mechanism

• 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

22
Conclusions

• 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
• Doesnt modify the instruction set architecture
  of the processor

23
The proposed Memory Protection Method

• Memory protection suited for low-end
  microcontrollers
• Doesnt static partition of address space
• Rely on a memory map data structure
• Record ownership and layout info. of the entire
  address space
• Doesnt 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 to memory
  protection

Memory Map Checker (STORE instruction extension)
Memory Map
Domain Tracker (CALL instruction extension)
Jump Table
Domain Tracker (RETURN instruction extension)
Safe Stack
Hardware Extensions
Software Routine

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