System for Coarsegrained Memory Protection in Embedded Processors

1
System for Coarse-grained Memory Protection in
Embedded Processors

• Ram Kumar, Akhilesh Singhania,
• Andrew Castner, Eddie Kohler,
• Mani Srivastava
• University of California, Los Angeles

2
Memory Corruption

• Single address space CPU
• Shared by apps., drivers and OS
• Most bugs in deployed systems come from memory
  corruption
• Corrupted nodes trigger network-wide failures

Run-time Stack
Globals and Heap (Apps., drivers, OS) No
Protection
Microcontroller Address Space
Memory protection is an enabling technology for
building robust embedded software
3
Desired Protection Domains
Data RAM - Non contiguous partitions
Program FLASH - Contiguous partitions
Kernel
Driver
App. 1
App. 2

• Domains - Logical partitions of address space
• Module loaded into a single domain
• Protect domain from corruption by other domains

Create and enforce protection domains
4
MMU in Micro-Controllers

• MMU can provide protection domains
• No MMU in embedded micro-controllers
• MMU hardware requires lot of RAM
• Increases area and power consumption
• Poor performance - High context switch overhead
• Microcontroller Design Constraints
• Minimize Price, Power and Memory
• Real-time performance requirements

5
Software-based Approaches

• Software-based Fault Isolation (Sandbox)
• Inline checks validate memory accesses
• Modify code through compiler or binary rewrite
• Application Specific Virtual Machine
• Interpreted code is safe
• Domain specific extensions could be buggy
• Type-safe language
• Language semantics prevent illegal accesses
• Fine-grained memory protection
• Ccured - Retrofit C to make it type-safe

6
System Overview
Hardware Software Co-Design
Memory Map Checker Stack Bounds Checker (STORE)
Memory Map
Cross Domain Call Safe Stack (CALL RET)
Control Flow Manager
Domain Bounds Checker Stack Overflow Checker
Extensions Device Driver
Hardware Extensions
Software Components
Complexity
Efficiency
7
Design Goals

• Provide coarse-grained memory protection
• Protect OS from applications
• Protect applications from one another
• Targeted for resource constrained processors
• Low RAM and ROM usage
• Minimize area of protection logic
• Practical system
• Customizable hardware
• No modifications to instruction set architecture

8
Contributions

• Memory protection suited for low-end
  microcontrollers
• Memory Map
• Fine grained ownership and layout info.
• Enables protection without static partitioning of
  RAM
• Control Flow Manager
• Preserve control flow integrity
• Cross domain call, Safe Stack
• Stack Bounds - Prevent run-time stack corruption
• Designed and evaluated for AVR architecture
• Protection for the SOS operating system

9
Outline

• Introduction
• System Components
• Memory Map Manager
• Control Flow Manager
• Evaluation

10
Memory Map - Protection without static partitions
Fine-grained layout and ownership information
Partition address space into blocks
Allocate memory in segments (Set of contiguous
blocks)

• Store information for all blocks
• Encoded information per block
• Ownership - Kernel/User-ID
• Layout - Start of segment bit
• Block size is 8 bytes for Atmel AVR

User Domain
Kernel Domain
11
Using Memory map for protection

• Ownership information in memory map is current
• Only block owner can free/transfer ownership
• Trusted domain can access memory map API
• Store memory map in protected memory
• Easy to incorporate into existing systems
• Modify memory allocators - malloc, free
• Track function calls that pass memory across
  domains
• Changes to SOS Kernel 1
• Scheme is portable to other OSes and MCUs

12
Memmap Checker

• Enforces a protection model
• Write access to block granted only to owner
• Invoked before every write access
• Operations performed by checker
• Lookup memory map based on write address
• Verify current executing domain is block owner

13
Memory Map Controller
ST_INSTR
Fetch Decoder
Memory Map Controller
DATA RAM
CPU_ADDR
CPU_ADDR
CPU_WR_EN
CPU_WR_EN
CPU_STALL
DATA_BUS

• Functional unit that validates store operations
• Triggered by fetch decoder on a store instruction
• Compute memory map byte address for issued write
  address
• Retrieves memory map permission and validates
  stores
• Map maintained in protected RAM
• RAM access is bottleneck i.e. min. one cycle
  latency

14
MMC Store Operation
Cycle 1
Cycle 3
Cycle 2
Regular Mode
Protected Mode
15
Outline

• Introduction
• System Components
• Memory Map Manager
• Control Flow Manager
• Evaluation

16
Managing Control Flow

• System needs to manage control flow
• Prevent circumvention of run-time checks
• Track the currently active domain
• Enforced control flow restrictions
• Enter/Exit a domain through designated points
• Control flow restrictions can be statically
  verified
• Control flow can become corrupt at run-time
• Calls using corrupt function pointers
• Returns on corrupted stack
• Memory map cannot prevent such corruption

17
Cross Domain Call
Domain A call fooJT foo_ret
Domain B foo ret
Jump Table
fooJTjmp foo
Program Memory
18
Cross Domain Call Unit
From fetch_decoder on call instr.
jmp_tbl_base
jmp_tbl_bnd
call_addr
lt
lt
AND
CDC_EN

• Jump table setup by software
• Location configurable through UMPU registers
• Cross Domain Call State M/C
• Triggerred by CDC_EN
• Operation similar to software implementation
• Bottleneck is the push operation to safe stack

19
Domain Bounds Checker
PC
Domain Bounds Checker
BND_PANIC
CURR_DOM_ID

• Restrict control flow to address range of a
  domain
• Every domain occupies address range dom_lb,
  dom_ub
• Implemented as simple combinational logic in HW
• dom_lb lt PC lt dom_ub
• Domain bounds need to be initialized, stored and
  updated
• Initialized by loader or at link-time in static
  image
• Stored in Register array or RAM Area-Performance
  tradeoff
• Updated on cross domain calls

20
Stack Bounds
Stack Base
Caller Domain Stack Frame

• Single stack shared by all domains
• Bounds set during cross domain call
• Protection Model
• No writes beyond stack bound
• Prevent cross domain corruption
• Enforced by checker before all writes

Stack Bound
Callee Domain Stack Frame
Stack Ptr.
Run Time Stack
21
Outline

• Introduction
• System Components
• Memory Map Manager
• Control Flow Manager
• Evaluation

22
Micro-Benchmarks
23
Area Impact

• 64 increase in core area
• Measured using equivalent gates
• Core constitutes a small fraction of overall chip
  area
• Total area increase for ATMEGA103 4

24
Software Library Performance

• Overhead of setting / clearing memory map bits
• Free and Change_own have additional checks

25
Memory Usage

• Flexible data-structure - Tradeoff RAM for
  protection
• No. of domains
• Range of addresses protected
• Code memory usage increases by 15

26
Conclusion

• Hw-Sw Co-Desgin 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 manager
• Control flow manager
• Practical system with widespread applications
• Low resource utilization
• Minimal performance overhead
• Binary compatible with existing software and
  tool-chains
• Useful for embedded operating systems

27
Thank You !https//projects.nesl.ucla.edu/project
s/umpu

• NESL
• DAC
• June 2007

28
Memory Map Tradeoffs

• More protection domains ? More bits per block ?
  Larger memory map
• Smaller protected address range ? Smaller memory
  map
• Block size
• Larger block size ? Smaller memory map
• Larger block size ? Greater internal
  fragmentation
• Match block size to size of memory objects
• Mica2 - 8 bytes, Cyclops - 128 bytes

Memory map size for 8 Byte Blocks
29
Cross Domain Call Unit
Safe Stack
RET_ADDR
DATA RAM
SS_PTR
SSP_WR_EN
ltCROSS_DOMAIN_FRAMEgt
Fetch Decoder
Cross Domain Call Trigger
Cross Domain Call State M/C
CALL_INSTR
CDC_EN
CALL_ADDR
CALL_ADDR
CURR_DOM_ID
Domain Bounds Checker
PC
30
Application Overhead

• Install SOS on enhanced AVR
• Overhead measured using Modelsim simulator
• Overhead is significantly lower than SOS Software
  Sandbox

31
SOS Operating System
Static SOS Kernel
32
Safe Stack

• Extra stack maintained in protected memory
• Used for storing Harbor state information
• e.g. Return Address Protection
• Grows up in memory towards run-time stack

RUN-TIME STACK
SAFE STACK
HEAP and GLOBALS
Stacks grow towards one another
33
Return Address Protection
call foo foo_ret
foo ret
34
SOS Memory Layout
0x0200

• Static Kernel State
• Accessed only by kernel
• Heap
• Dynamically allocated
• Shared by kernel and applications
• Stack
• Shared by kernel and applications

Run-time Stack
Dynamically Allocated Heap
Static Kernel State
0x0000
35
Updating Memory Map
User
Kernel
Free

• Blocks Size on Mica2 - 8 bytes
• Efficiently encoded using 4 bits per block
• xxx0 - Start of segment block
• xxx1 - Later block of segment
• xxx is the 3-bit domain ID

36
Memmap API
memmap_set(Blk_ID, Num_blk, Dom_ID)

• Updates Memory Map
• Blk_ID ID of starting block in a segment
• Num_blk Number of blocks in a segment
• Dom_ID Domain ID of owner (e.g. USER / KERN)
• Returns owner of a given block
• Memory map API should be protected

Dom_ID memmap_get(Blk_ID)
37
Latency Sensitive Operations

• Isolate SOS serial stack - HDLC framing
• Constant Interrupt dispatch overhead - 23 clock
  cycles
• Rx interrupt incurs higher malloc overhead
• Regular SOS pre-allocates a message header pool
• SOS for UMPU performs in-line allocation

38
Address ? Memory Map Lookup
Address (bits 11-0)
Memmap Table
1
8
1 Byte has 2 memmap records
39
Memory Protection Unit (MPU)

• Low-cost hardware assisted protection
• Static partition of address space
• Base and Bound registers define partitions
• Max. of 8 partitions in a processor
• Access permissions defined for every region
• Memory access validated against permissions
• Simple Protection Features
• Supports only two domains
• Static partitioning of address space
• Limited control flow protection

40
Memory Map Overhead

• Overhead introduced in dynamic memory API
• Memory map needs to be updated
• Higher overheads of free and change_own
• Added checks to prevent illegal freeing or
  transfer
• Averaged over long simulation avg. allocation
  size 16 bytes
• Measured using Avrora for Mica2 platform