A Run-Time Memory Protection Methodology Udaya Seshua, Nagaraju Bussa*, Bart Vermeulen NXP Semiconductors, *Philips Research 12 th Asian and South Pacific Design Automation Conference 2007 January 25, 2007, Yokohama, Japan
Agenda • Introduction • Motivation • Debugging Run-Time Memory Corruption • Prior Work • Proposed Debug Methodology – Hardware Design – Software Design • Experimental Results • Conclusion Udaya Seshua, “A Run-Time Memory Protection Methodology”, 12 th Asian and South Pacific Design Automation Conference 2007, January 25 th , 2007 2
Introduction • System chips are becoming more and more complex – More transistors per mm 2 , customer requirements, embedded processors & SW, mixed processes... # Transistors per die Code Size Evolution of High End TV Software 100M 100000 10B 64000 TV ROM size CPU 32000 1B Memory 12000 10M Frequency 100M 4096 3000 2048 10M 1024 1M 512 1M 256 100k 100k 64 32 10K 16 10k 8 1k 4 2 1k 1 1970 1975 1980 1985 1990 1995 2000 2005 2010 1978 1982 1986 1990 1994 1998 2002 2006 2009 source: Intel, ITRS roadmap source Rob van Ommering, PRLE Informatica Colloquium, October 2005 Udaya Seshua, “A Run-Time Memory Protection Methodology”, 12 th Asian and South Pacific Design Automation Conference 2007, January 25 th , 2007 3
Introduction Effort as % of Project Time • Extensive pre-silicon verification – Formal Verification Design Verification – Simulation 53% 47% – Timing Verification – Emulation – DRC, LVS … source: Collet International Research Inc. • No guarantee that all HW and SW errors Industry Silicon Spins are removed before silicon 100% ASSP ASIC 90% – Too many use cases 80% – Mandatory trade-off between amount 70% 60% of detail and speed 50% 40% 30% • Debugging embedded software on 20% prototype silicon is a necessity 10% 0% – Find remaining SW and HW errors 1 2 3 4 5 or above source: Numetrics Management Systems, Inc. Udaya Seshua, “A Run-Time Memory Protection Methodology”, 12 th Asian and South Pacific Design Automation Conference 2007, January 25 th , 2007 4
Motivation • In any application nearly 70% of code deals with memory transfers • Memory-related bugs are among the most prevalent and difficult to catch – particularly in applications written in an unsafe language such as C/C++ • In an embedded system, a single memory access error can cause an application to behave unpredictably or even a delayed crash • A good debug infrastructure capable of locating memory-related bugs quickly is key to reducing the effort spent on software debug Udaya Seshua, “A Run-Time Memory Protection Methodology”, 12 th Asian and South Pacific Design Automation Conference 2007, January 25 th , 2007 5
Debugging Run-Time Memory Corruption • A single incorrect memory access can crash an application and/or threaten its security Processor Processor 2. Access data referenced by pointer 1. Fetch Pointer Value Memory 0x1234 Data 0x1234 Udaya Seshua, “A Run-Time Memory Protection Methodology”, 12 th Asian and South Pacific Design Automation Conference 2007, January 25 th , 2007 6
Debugging Run-Time Memory Corruption • A single incorrect memory access can crash an application and/or threaten its security Processor Processor 2. Access unintended data referenced by corrupted pointer 1. Fetch Pointer Value Memory 0x1234 Data Unintended 0x1340 Data 0x1234 0x1340 Corrupted Pointer caused by bug or security breach • How do we detect these errors efficiently at run-time? Udaya Seshua, “A Run-Time Memory Protection Methodology”, 12 th Asian and South Pacific Design Automation Conference 2007, January 25 th , 2007 7
Prior Work • Mostly software-only methods (“Purify, xGCC and the like”) – High performance penalty (5-10x not uncommon) – Not acceptable in real-time, embedded systems • Available HW support often used on ad-hoc basis – a Memory Management Unit – a Processor data breakpoint • “Whatever is available can and will be used!” – Even if it wasn’t designed for this purpose • Results in long and unpredictable debug times – Slipping deadlines, market and possibly customer loss Udaya Seshua, “A Run-Time Memory Protection Methodology”, 12 th Asian and South Pacific Design Automation Conference 2007, January 25 th , 2007 8
Proposed Debug Methodology • Structured Integrated Hardware/Software Approach – Monitor memory accesses of an application • Flag invalid accesses for QoS, security or debug – Perform frequently recurring tasks in hardware • Compare memory addresses with valid regions – Keep configurability in software for flexibility • Configure valid regions • Make optimal trade-off between – Hardware cost, i.e. silicon area – Software cost, i.e. performance drop Udaya Seshua, “A Run-Time Memory Protection Methodology”, 12 th Asian and South Pacific Design Automation Conference 2007, January 25 th , 2007 9
Proposed Debug Methodology Run-Time Memory Protection Architecture rpu_id=1; rpu_id=1; main() main() { { rpus_initialize(0); rpus_initialize(0); func1(); func1(); func2(); func2(); } } func1() func1() { main() { id = rpu_id++; { main() id = rpu_id++; func1(); { p = malloc(127); func2(); func1(); p = malloc(127); rpus_heap_enable(127,p); } func2(); rpus_heap_enable(127,p); } int a[10]; func1() int a[10]; rpus_stack_enable(10,a,id); { func1() rpus_stack_enable(10,a,id); p = malloc(127); { int b[10]; int a[10]; p = malloc(127); int b[10]; rpus_stack_enable(10,b,id); int b[10]; int a[10]; rpus_stack_enable(10,b,id); free(p); int b[10]; free(p); a[10]=0; free(p); free(p); } a[10]=0; rpus_heap_disable(p); } rpus_heap_disable(p); rpus_check_access(a+10); func2() rpus_check_access(a+10); { func2() a[10]=0; int a[10]; { a[10]=0; rpus_stack_disable(id); int b[10]; int a[10]; rpus_stack_disable(id); } int b[10]; } } } func2() func2() { { id = rpu_id++; id = rpu_id++; int a[10]; int a[10]; rpus_stack_enable(10,a,id); rpus_stack_enable(10,a,id); Int b[10]; Int b[10]; rpus_stack_enable(10,b,id); rpus_stack_enable(10,b,id); rpus_stack_disable(id); rpus_stack_disable(id); } Peripheral Peripheral } Peripheral Peripheral • • • Processor Processor 1 N 1 N bus (e.g. AXI) Region Region memory access Memory Memory Protection Protection violation detected Interface Interface Module Module signal debugger SW Udaya Seshua, “A Run-Time Memory Protection Methodology”, 12 th Asian and South Pacific Design Automation Conference 2007, January 25 th , 2007 10
Proposed Debug Methodology RPM Hardware Architecture RPU controller heap RPU 1 data_in • • • address heap RPU N data_out heap_in Bus stack_fallback_n Adapter or rpu_mode stack RPU 1 read rpu_data • • • write stack RPU M stack_in Udaya Seshua, “A Run-Time Memory Protection Methodology”, 12 th Asian and South Pacific Design Automation Conference 2007, January 25 th , 2007 11
Proposed Debug Methodology Heap RPU Hardware Block Diagram cascade_in data base size clk mode sub control A<B? or cascade_out Udaya Seshua, “A Run-Time Memory Protection Methodology”, 12 th Asian and South Pacific Design Automation Conference 2007, January 25 th , 2007 12
Recommend
More recommend
