memory protection in resource constrained sensor nodes ram kumar rengaswamy ([email protected]) ph.d....

Memory Protection in Resource Constrained

Sensor NodesRam Kumar Rengaswamy

([email protected])Ph.D. Defense

10/20/06 PhD Defense

2

Memory Corruption in Mote-class Sensor Nodes

Run-time Stack

Sensor Node Address Space

Globals and Heap

(Apps., drivers, OS)

No Protection

Single address space CPU

Shared by apps., drivers and OS

Many bugs in deployed systems come from memory corruption

Corrupted nodes trigger network-wide failures


3

Programming errors cause Corruption

Motes are difficult to program

Error in “well-tested” sampling module in SOShdr_size = SOS_CALL(s->get_hdr_size, proto);s->smsg = (SurgeMsg*)(pkt + hdr_size);s->smsg->type = SURGE_TYPE_SENSORREADING;

Return value is not being checked• SOS_CALL fails in some conditions, returns -1• Error code used as offset into a buffer, causes corruption

Protection mechanisms prevent such corruptionMemory protection is required forbuilding robust sensor software


4

Desired Protection Domains

Kernel

Driver

App. 1

App. 2

Data RAM - Non contiguous partitions

Domains - Logical partitions of address space

Module loaded into a single domain Protect domain from corruption by other domains

Program FLASH - Contiguous partitions

Harbor - Create and enforce protection domains


5

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

Core MMU Cache

Area (mm2) 0.13u

mW/MHz

ARM7-TDMI No No 0.25 0.1

ARM720T Yes 8 Kb 2.40 (~10x) 0.2 (~2x)


6

Software-based Fault Isolation

Coarse-grained protection; check all memory accesses

Checks in-lined by binary rewriter; separately verified

Challenge - Ensure checks are not circumvented

Sandboxing [wahbe92SFI]• Designed for RISC architectures• Static partitioning of virtual address space• Dedicated sandbox registers ensure checks are not skipped

XFI [xfi06osdi]• Control Flow Integrity using static analysis and run-time checks

t-kernel [gu06tkernel]• Naturalization - Rewrite binary on mote to make it safe• Virtual memory for heap accesses for protection

X


7

Challenge - Fault Isolation on Mote

SFI partitions virtual address space• Leverage large address space due to MMU• 4 GB per process on x86

Static, continuous, and large domains• Checks have low overhead• Minimal state maintenance per domain

Static partitioning is impractical in motes• Limited address space - No MMU• Severely limited physical memory• Wastage through internal fragmentation

Kernel Ext. #1

Static Kernel

Kernel Ext. #2


8

Software-based Approaches

Application Specific Virtual Machine• Interpreted code is safe and efficient• High-level VM instructions are not type-safe• [levis05active] [balani06dvm]

Type Safe Languages• Fine grained protection• Non-type safe extensions for low level code• Compiler output difficult to verify• [titzer06virgil], [necula02ccured]

Static Analysis for Resource Management• Exchange heap ownership tracking in Singularity [sing06lang]

• Dynamic memory ownership tracking in SOS [roy07lighthouse]


9

Harbor Design Goals Fault Isolation as building block for protection• Sandbox for ASVM instructions• Static analysis for performance enhancement

Motivation of Harbor• Memory protection in SOS operating system

Provide coarse-grained memory protection• Protect OS from applications• Protect applications from one another

Targeted for resource constrained systems• Low RAM usage• Minimal performance overhead

Amenable to software and hardware implementations


10

Thesis Contributions Designed Harbor Memory Protection

• Primitives suited for mote-class sensor nodes

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 [wahbe92sfi], Safe Stack [xfi06osdi]• Stack Bounds - Prevent run-time stack corruption

Designed and evaluated two systems based on Harbor• Software-based memory protection for SOS• Hardware-enhanced memory protection unit for AVR


11

Outline

Introduction

Harbor Primitives• Memory Map

Sandbox for SOS Modules UMPU Conclusion


12

Memory Map - Protection without static partitions

Fine-grained layout and ownership information

Store information for all blocks

Encoded information per block• Ownership - Kernel/User-ID• Layout - Start of segment bit

Block size is 8 bytes for Mica2

User Domain

Kernel Domain

Partition address space into blocks

Allocate memory in segments(Set of contiguous blocks)


13

Using Memory map for protection

1. Ownership information in memory map is current

2. Only block owner can free/transfer ownership

3. Trusted domain can access memory map API

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


14

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


15

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

Addr. Range

0B - 4096B

256B - 3072B

2 Domains 128 B (~3%)

88 B (~2%)

4 Domains 256 B (~6%)

176 B (~4%)

Memory map size for 8 Byte Blocks


16

Outline

Introduction

Harbor Primitives• Control Flow Manager



17

Managing Control Flow Harbor 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


18

Program Memory

Domain Acall fooJTfoo_ret:

Domain B

foo:…

ret

Register exported functionfooJT:jmp foo

Cross Domain Call

Jump Table

Cross Domain Call Stub

Verify call into jump table Compute callee domain ID Determine return address

Verify call into jump table Compute callee domain ID Determine return address


19

Stack Bounds

Run Time Stack

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

Stack Bound

Stack Base

CallerDomainStackFrame

CalleeDomainStackFrame


20

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-TIMESTACK

SAFESTACK

HEAPand

GLOBALS

Stacks grow towards one another


21

Return Address Protection

call foofoo_ret:

foo:…

ret

foo_ret foo_ret

RUN-TIMESTACK

SAFESTACK

func_entry_stub:

Copy to safe stack

foo_ret foo_ret

RUN-TIMESTACK

SAFESTACK

func_exit_stub:

Restore from safe stack


22

Outline

Introduction Harbor Primitives



23

SOS Sandbox System Overview

BinaryRe-WriterBinary

Re-WriterSandboxBinary

Raw Binary

MemoryMap

MemoryMap

ControlFlow Mgr.ControlFlow Mgr.

Memory Safe Binary

BinaryVerifierBinaryVerifier

Desktop

Sensor Node


24

System Design Choices

Binary Re-writer• Independent of programming language, compilers

• Binary output is easier to decode and verify

Only verifier implementation needs to be correct

Verification at every node• No need to trust the source of a binary• Safety ensured by properties of the binary• Do not need secure code dissemination protocols


25

Binary Re-Writerst Z, Rsrcst Z, Rsrc push X

push R0movw X, Zmov R0, Rsrccall memmap_checkerpop R0pop X

push Xpush R0movw X, Zmov R0, Rsrccall memmap_checkerpop R0pop X

Sandbox stores and computed control flow• Sequence is re-entrant, works in presence of interrupts• Push/Pop removed by using dedicated registers

Insert calls to run-time checks• Checks located in trusted domain• Inlining increases module size

Preserve original control flow e.g. branch targets etc.


26

Verifier Operation Single in-order pass through instruction stream• Process one basic block at a time

• Constant state maintained

For each basic block, the verifier ensures• Stores are sandboxed

• Computed control flow instructions are checked

• Static jump/call/branch targets lie within domain bounds

• Disallow certain instructions - SPM etc.


27

Multi-Word Instructions Multi-word instructions pose a problem for verifier

• st <addr>, call <addr>

Cannot detect jumps into the middle of an instruction• <addr> could be decoded as a store instruction• Such store instructions can circumvent checks

Re-writer inserts special marker symbols

Ensure all control transfers to the start of basic block

Special marker symbol is decoded as NOP• Cannot be a valid instruction in the ISA• No valid immediate argument can equal the marker symbol• Unique symbol present at start of basic blocks only


28

Comparison with t-kernel

Harbor t-kernelWeak Isolation Memory writes Limited control flow restriction

Strong isolation Memory writes Stronger restrictions e.g. infinite loops

Multi-domain protection

Single application support only

Rewrite on PCVerify on Mote

Rewrite on MoteRequires external flash

No virtual memoryVirtual memory for heap accessesOverheads of both systems are comparable


29

Outline

Introduction Harbor Primitives

Sandbox for SOS Modules•Evaluation

UMPU Conclusion


30

Sandbox Evaluation Sandbox feasible on mote-class sensors

• Modest resource usage• Minimal overhead for typical sensor workloads

Code Memory Usage• Blank SOS kernel compiled for Mica2 platform• Compiler: avr-gcc -Os• Jump table = 2 KB• Checkers + Memory Map API ~ 4 KB

Raw Code Size (2 domains) (8 domains)

41796 B +6146 B

+14.7% +6228 B

+14.9%


31

Data Memory Usage

9.5%5.1% 5.8%3.4%

Flexible data-structure - Tradeoff RAM for protection

Memory map RAM usage: 70 - 256 Bytes Additional constant overhead: 28 bytes


32

Code Size of Sandbox Modules

Significant increase in code size: 30% - 65%

Rewriting store by long sequence to call checker

Overhead can be reduced by dedicated registers

Static analysis can eliminate redundant checks


33

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

API Normal

Protected

Increase

malloc 363 622 82%

free 138 446 238%

change_own 55 270 418%


34

Run-Time Checkers Overhead

OPERATION CYCLESmemmap_checker 65+14 (40x)cross_domain_call 65+12 (19x)cross_domain_ret 28+4 (8x)func_entry_stub 38+8func_exit_stub 38+4

Incur high overhead, despite implementation in assembly

Checks occur in critical path, impact application performance


35

CPU Intensive Benchmarks

FFT - Fixed point operation on 64 samples Outlier - Distance based threshold on 4 samples Buffer Writer - Averaged over buffer size (16 -

96) bytes Worst case work-load for Harbor

• 100% CPU utilization in executing benchmarks• Checks introduced in critical path, directly

impact performance


36

Sandbox versus Virtual Machine

Virtual machines provide fine-memory protection

Average interpretation overhead 115 [ASVM]

Interpretation overhead significantly higher than sandboxing

Sandboxing VM slows it down by factor of 2.6• VM provides fine-grained protection to scripts• Harbor provides coarse protection to system running VM


37

Data Collector Application

Experiment Setup• 3-hop linear network simulated in Avrora• Simulation executed for 30 minutes• Tree Routing and Surge modules inserted into network

• Data pkts. transmitted every 4 seconds• Control packets transmitted every 20 seconds

1.7% increase in relative CPU utilization• Absolute increase in CPU - 8.41% to 8.56% • 164 run-time checks introduced• Checks executed ~20000 times


38

SOS Sandbox Conclusions

Sandboxing is feasible on mote-class sensors

Memory map is flexible; tune to protection needs

Low performance impact for typical workloads• Run-time checks have high overhead• Sandbox has lower overhead than virtual machine

Building block for enhanced protection schemes


39

SOS Sandbox Future Work

Verifier design tradeoff• Static analysis eliminates redundant checks

• Improve overall system performance• Increase complexity of verifier, infeasible on mote

Incorporate network into the system• Trusted code sources within the network• Sandbox on Micro-servers or Backend• Secure code dissemination to mote cluster


40

Outline

Introduction Harbor Primitives Sandbox for SOS Modules

UMPU Conclusion


41

UMPU Design Goals Exploit hardware to improve Harbor’s performance

Provide coarse-grained memory protection

Targeted for resource constrained processors• Low RAM and ROM usage• Minimize area of protection logic

Practical system• No modifications to processor instructions• Customizable - Soft IP Core, Configuration Registers


42

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


43

UMPU Overview

Memory Map CheckerStack Bounds Checker

(STORE)

Memory Map CheckerStack Bounds Checker

(STORE)

Cross Domain CallSafe Stack

(CALL & RET)

Cross Domain CallSafe Stack(CALL & RET)

Domain Bounds CheckerStack Overflow CheckerDomain Bounds CheckerStack Overflow Checker

Hardware ExtensionsSoftware Components

Memory Map APIMemory Map API

Cross Domain LinkingCross Domain Linking

UMPU Device DriverUMPU Device Driver

Hardware Software Co-Design

Complexity Efficiency


44

Memory Map Controller

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

FetchDecoderFetch

DecoderMemory MapControllerMemory MapController

DATARAMDATARAM

CPU_ADDRCPU_WR_ENCPU_STALL

CPU_ADDRCPU_WR_EN

DATA_BUS

ST_INSTR


45

CPU_WR_ADDR

MMC_RD_ADDRCLK

CPU_ADDR

CPU_WR_EN

MMC_ADDR

MMC_WR_EN

CPU_STALL

MMC Store OperationCycle 1

Cycle 3

Cycle 2

Regular Mode

Protected Mode


46

Cross Domain Call Unit

FetchDecoderFetch

DecoderCross DomainCall TriggerCross DomainCall Trigger

Cross DomainCall State

M/C


M/CCALL_ADDRCALL_INSTR

CALL_ADDRCDC_EN

DomainBoundsChecker

DomainBoundsChecker

PC

CURR_DOM_ID

Safe StackSafe Stack

RET_ADDR

<CROSS_DOMAIN_FRAME>

DATARAMDATARAM

SS_PTRSSP_WR_EN


47

Cross Domain Call Unit

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

jmp_tbl_basejmp_tbl_base jmp_tbl_bndjmp_tbl_bndcall_addrcall_addr

<= <

AND

From fetch_decoder on call instr.

CDC_EN


48

Domain Bounds Checker

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 <= PC <= 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

DomainBoundsChecker

DomainBoundsChecker

PC

CURR_DOM_IDBND_PANIC


49

UMPU Micro-Benchmarks

Instruction AVR UMPU SWStore 2 3 79

Cross Domain Call

4 9+4 77

Cross Domain Return

4 9 32

Interrupt Dispatch

4 5+13 -

Interrupt Return

4 5+9 -

Save Return Addr.

4 4 46

Restore Return Addr.

4 4 42


50

UMPU Logic Area

Synthesized microcontroller using Xilinx tools• Design targeted towards Vertex2 FPGA• 64% increase in area of core• Measured in terms of equivalent logic gates

Spec sensor node [Jason Hill]• Identical processing core• Chip Area = 6.25 mm2

• Core Area = 0.39 mm2 (Utilization = 6.3%)• UMPU Enhanced Core = 0.64 mm2(Utilization = 10.3%)• Area utilization of the core increases by 4%• Packed without changing die size• 10x increase in chip area with the addition of MMU


51

UMPU Application Overhead

Install SOS on UMPU enhanced AVR Overhead measured using Modelsim simulator UMPU overhead is significantly lower than SOS Sandbox


52

UMPU Conclusion Hw-Sw Co-Desgin for Memory Protection

• Combine SW flexibility with HW efficiency

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

• Useful for embedded operating systems


53

UMPU Future Work Recovery from corrupted software

UMPU supports exception mechanism

Non-maskable highest priority interrupt

Records system state during panic


54

Outline

Introduction Harbor Primitives Sandbox for SOS Modules UMPU

Conclusion


55

Conclusion Memory Protection

• Enabling technology for reliable software systems• Memory protection introduced in 60’s in mainframes• Page-based protection introduced in desktop in 80’s

• Embedded design constraints motivate new techniques

Explored fault-isolation on micro-controllers• Protection primitives for limited address space• Flexible design: Tradeoff protection for resources

• Building block for more advanced techniques

Thank You !https://projects.nesl.ucla.edu/projects/sos-2x/

https://projects.nesl.ucla.edu/projects/umpu/Ram Kumar

PhD DefenseApril 4th, 2007

https://projects.nesl.ucla.edu/projects/sos-2x/

https://projects.nesl.ucla.edu/projects/sos-2x/

https://projects.nesl.ucla.edu/projects/umpu/

https://projects.nesl.ucla.edu/projects/umpu/


57

References [Wahbe92SFI] Robert Wahbe, Steven Lucco, Thomas E. Anderson and Susan L Graham.

Efficient software-based fault isolation. In SOSP 92 [small97misfit] Christopher Small. MiSFIT: A tool for constructing safe extensible C++

systems. In Proc. 3rd USENIX Conference on Object-Oriented Technologies, 1997 [witchel02mmp] Emmett Witchel, Josh Cates, and Krset Asanovic. Mondriaan Memory

Protection. In ASPLOS 2002. [necula02ccured] George C. Necula, Scott McPeak, and Westley Weimer. Ccured: Type-saef

retrofitting of legacy code. In POPL 2002. [levis05active] Phil Levis, David Gay and David Culler. Active Sensor Networks. In

NSDI 2005 [regehr06utos] John Regehr, Nathan Cooprider, Will Archer, and Eric Eide. Memory

safety and untrusted extensions for TinyOS. Univ. of Utah Tech. Report 2006 [mccamant06pittsfield] Stephen McCamant and Greg Morrisett. Evaluating SFI for CISC

architecture. In USENIX symposium 2006. [balani06dvm] Rahul Balani, Ram Kumar, Simon Han, Ilias Tsigokannis, and Mani

Srivastva. Multi-level Software Reconfiguration for Sensor Networks. In EMSOFT 2006. [gu06tkernel] Lin Gu and John A Stankovic. t-kernel: Providing reliable OS support to

wireless sensor networks. In Sensys 2006 [xfi06osdi] Ulfar Erlingsson, Martin Abadi, Michael Vrable, Michai Budiu, and George C

Necula. XFI: Software guards for system address spaces. In OSDI 2006 [divya06ccured] Divya Arora, Anand Raghunathan and Niraj K Jha. Architectural support

for safe software execution on embedded processors. In CODES+ISSS 2006 [titzer06virgil] Ben L. Titzer. Virgil: Objects on the head of a pin. In OOPSLA 2006. [sing06lang] Manuel Fahndrich, Mark Aiken, Chris Hawblitzel, Orion Hodson, Galen Hunt,

James R Larus, and Steven Levi. Language support for fast and reliable message-based communication in Singularity OS. In Eurosys 2006

[roy07lighthouse] Roy Shea, Shan Markstrum, Todd Millstein, Rupak Majumdar, and Mani Srivastava. Static Checking for Dynamic Resource Management in Sensor Network Systems.


58

Core Name RAM ROM FMAX $100 Units

MMU Core

AT91SAM7S128+AT29BV010A

8K Non+

128K

33 8.84 +

1.7

None ARM7TDMI

AT91RM9200 16K 128K 180 14.43

Yes AT91

ATMEGA128 4K 128K 16 8.75 None AVR

ATMEGA1281 8K 128K 16 8.75 None AVR

ML67Q500x 32K 256K 60 ?? None ARM7TDMI

iMOTE2 32M 32M 416 299 Yes PXA271

MicaZ 4K 128K 8 125 No AVR

Price for Protection


59

Reliable Sensor Networks

Reliability is a broad and challenging goal

Data Integrity• How do we trust data from our sensors ?

Network Integrity• How to make network resilient to failures ?

System Integrity• How to develop robust software for sensors ?


60

Memory Protection in Desktops

HW based protection designed since early 60’s

Intel iAPX 432 introduced in 1975• Sophisticated architectural support for protection

Page-based protection• Intel 80386 introduced it in 1985• Ubiquitous in the desktop world today

What about the embedded processors ?


61

SOS Operating System

Tree RoutingModule

Tree RoutingModule

Data CollectorApplication

Data CollectorApplication

PhotosensorModule

PhotosensorModule

DynamicallyLoaded modules

DynamicMemoryDynamicMemory

MessageSchedulerMessage

SchedulerDynamicLinker

DynamicLinker

KernelComponents

SensorManagerSensor

ManagerMessaging

I/OMessaging

I/OSystemTimerSystemTimer

SOSServices

RadioRadio I2CI2C ADCADCDeviceDrivers

Static SOS Kernel


62

SOS Memory Layout

Static Kernel State• Accessed only by kernel

Heap• Dynamically allocated• Shared by kernel and applications

Stack• Shared by kernel and applications

Run-time Stack

Static Kernel State

Dynamically

Allocated

Heap

0x0200

0x0000


63

Updating Memory Map

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

User

Kernel

pA = malloc(KERN, 16);

pB = malloc(USER, 30);

mem_chown(pA, USER);Free


64

Memmap API

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

memmap_set(Blk_ID, Num_blk, Dom_ID)

Dom_ID = memmap_get(Blk_ID)


65

Address Memory Map Lookup

Address (bits 11-0)

Memmap Table

1 Byte has 2 memmap records

81

Block Number (bits 11-3) Block Offset (bits 2-0)9 bits


66

Optimizing Memmap Checker

Minimize performance overhead of checks

Address Memory Map Lookup• Requires multiple complex bit-shift operations• Micro-controllers support single bit-shift operations

• Use FLASH based look-up table• 4x Speed up - From 32 to 8 clock cycles

Overhead of a software check - 89 cycles


67

Control Flow Manager Overview

Cross Domain Call• Enforce control flow restrictions• Track current domain ID

Stack Bounds• Prevents stack corruption across domains• Enables safe sharing of single stack

Safe Stack• Separate stack in protected memory• Stores cross domain call frames, Return Addresses


68

Cross Domain Call Frame

Return Address #AStack Bound #ADomain #A

Safe Stack

Return Address #BStack Bound #BDomain #B

Return Address #CStack Bound #CDomain #C

Cross domain calls can be chained

Calls frames stored in a stack

Current state in top frame

Push during call

Pop during return

Protected from corruption

Frame size is 5 bytes


69

Cross Domain Return

Program Memory

call foo

foo:…

ret

•Verify return address•Restore previous frame•Return

•Verify return address•Restore previous frame•Return

Cross Domain Return Stub


70

Control Flow Checkers

Checkers enforce the control flow restrictions• Control flow cannot enter or exit a domain arbitrarily• Only cross domain calls can cause a domain change

Static control flow instructions verified at load time• CALL <addr>, JMP <addr>, BRANCH, RCALL etc.

retret jmp ret_checkerjmp ret_checkerReturn Instruction

icallicall call icall_checkercall icall_checkerIn-Direct Call Instruction


71

Memory Map

Checker

Memory Map

Checker

ProcessorFetch

Decoder

ProcessorFetch

Decoder


Domain TrackerDomain Tracker

Bus ArbiterBus

Arbiter

Call

Call/Ret

Store Stall Processor

Update Domain ID to MMC

Update Domain IDDATASRAMDATASRAM

UMPU Extensions


72

UMPU Initialization

UMPU configurable using registers• Registers are protected and read-only• Block size, size of memory map records

Trusted Domain• Special domain not subject to any checks

• Boot into trusted domain on reset• Initializes and updates protected registers

• Maintains and updates memory map


73

Control Flow Controller

FetchDecoderFetch

DecoderCross DomainCall TriggerCross DomainCall Trigger


M/C


M/CCALL_ADDRCALL_INSTR

CALL_ADDRCDC_EN

DomainBoundsChecker

DomainBoundsChecker

PC

CURR_DOM_ID


RET_ADDR

<CROSS_DOMAIN_FRAME>

DATARAMDATARAM

SS_PTRSSP_WR_EN

Set of functional units that enforce control flow restrictions


74

Interrupt Controller

Asynchronous change to current domain

All interrupts originate in trusted domain• Verifier scans interrupt table during boot-up• Controller changes state to trusted domain

ISR uses cross domain calls

Design alternative with better performance• Register interrupts with a domain• Incurs memory overhead to maintain extra state


75

UMPU Exception Controller

Run-time checkers generate panic signals

Controller generates interrupt on panic• UMPU exception has highest priority• Interrupt is non-maskable

Controller stores state information• Panic condition, program counter etc.• Aids development of exception routines


76

Other Harbor Primitives

Safe Stack• Protected safe stack pointer register

Run-Time Stack Protection• Stack bounds setup during cross domain calls

• Stack overflow protection in hardware

Return Address Protection• Preserve control flow integrity within domain


77

UMPU Area Breakup

Domain bounds checker occupies most area• Register array stores domain bounds• Improved performance of cross domain calls

Complex hardware based state machines• Memory map controller• Cross Domain Call Unit


78

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


79

Robust Sensor Network Systems

Emergency Response

Building Automation

Asset Tracking

WSN Applications• Demand high availability

• Support multiple users

Current SW technology inadequate for long term deployments

memory protection in resource constrained sensor nodes ram kumar rengaswamy ([email protected]) ph.d....

Documents

corruption memory protection

protection domains slide

defense slide

phd defense

protection x slide

safe virtual memory

memory accesses checks

static kernel kernel