ICECS'06 1

Kyushu University Koji Inoue

Lock and Unlock: A Data Management Algorithm for A Security-Aware Cache

Koji InoueDepartment of Informatics,

Kyushu University

Japan Science and Technology Agency

ICECS'06 2

Kyushu University Koji Inoue

Background (1/2)

TrustedProgram

MaliciousProgram

Clock Gating

Signal Gating

DVS

Resizing

Drowsy Operation

Selective ActivationPipeliningSuperScalar

Branch Prediction

Value PredictionOn-chip

Cache

OOO Exe.

ILP TLP

MLP

ICECS'06 3

Kyushu University Koji Inoue

The Goal of This ResearchArchitectural Support for

SCache(improved data management)

PipeliningSuperScalar

Branch Prediction

Value PredictionOn-chip

Cache

OOO Exe.

ILP TLP

MLP

Clock Gating

Signal Gating

DVS

Resizing

Drowsy Operation

Selective Activation

ICECS'06 4

Kyushu University Koji Inoue

Outline Introduction Buffer-Overflow Attack Secure Cache Architecture

Overview Security Issue

Lock&Unlock Algorithm Evaluation

Security Strength Performance Overhead

Conclusions

ICECS'06 5

Kyushu University Koji Inoue

Buffer-Overflow Attack

Well-Known vulnerability Exploited by Blaster@2003 Caused by unexpected operations

writing an inordinately large amount of data into a buffer

This vulnerability exists in the C standard library (e.g. strcpy)

Lead to a stack smashing An attack code is inserted The return address is corrupted

Highjack the program execution control

R.B.Lee, D.K.Karig, J.P.McGregor, and Z.Shi, “Enlisting Hardware Architecture to Thwart Malicious Code Injection,” Proc. of the Int. Conf. on Security in Pervasive Computing, Mar. 2003.

0

10

20

30

40

50

60

CE

RT

Ad

viso

rie

s re

latin

gto

bu

ffer-

ove

rflo

w (

%)

1996 1997 1998 1999 2000 2001

year

Buffer Overflow

ICECS'06 6

Kyushu University Koji Inoue

Function Call/Return

int f ( ) { … g (s1); …}

int g ( char *s1) { char buf [10]; … strcpy(buf, s1); …}

Programcode

1. Start f( )2. Call g( )3. Execute strcpy( )4. Return to f( )

ICECS'06 7

Kyushu University Koji Inoue

Function Call/Return

int f ( ) { … g (s1); …}

int g ( char *s1) { char buf [10]; … strcpy(buf, s1); …}

Programcode

Programcode

1. Start f( )2. Call g( )3. Execute strcpy( )4. Return to f( )

StackGrowth

s1Return

AddressSaved FP

Local Variablebuf

FP

SP

Higher Addr.

Lower Addr.

The Next PCof Call g( )

ICECS'06 8

Kyushu University Koji Inoue

Function Call/Return

int f ( ) { … g (s1); …}

int g ( char *s1) { char buf [10]; … strcpy(buf, s1); …}

Programcode

1. Start f( )2. Call g( )3. Execute strcpy( )4. Return to f( )

Local Variablebuf

StackGrowth

s1Return

AddressSaved FP

FP

SP

Higher Addr.

Lower Addr.

The Next PCof Call g( )

String

ICECS'06 9

Kyushu University Koji Inoue

Function Call/Return

int f ( ) { … g (s1); …}

int g ( char *s1) { char buf [10]; … strcpy(buf, s1); …}

Programcode

1. Start f( )2. Call g( )3. Execute strcpy( )4. Return to f( )

StackGrowth

s1Return

AddressSaved FP

Local Variablebuf

FP

SP

Higher Addr.

Lower Addr.

The Next PCof Call g( )

String

ICECS'06 10

Kyushu University Koji Inoue

Function Call/Return

int f ( ) { … g (s1); …}

int g ( char *s1) { char buf [10]; … strcpy(buf, s1); …}

Programcode

1. Start f( )2. Call g( )3. Execute strcpy( )4. Return to f( )

StackGrowth

s1Return

AddressSaved FP

Local Variablebuf

FP

SP

Higher Addr.

Lower Addr.

The Next PCof Call g( )

String

ICECS'06 11

Kyushu University Koji Inoue

Stack Smashing

int f ( ) { … g (s1); …}

int g ( char *s1) { char buf [10]; … strcpy(buf, s1); …}

Programcode

1. Start f( )2. Call g( )3. Execute strcpy( )4. Return to f( )

StackGrowth

s1Return

AddressSaved FP

Local Variablebuf

FP

SP

Higher Addr.

Lower Addr.

The Next PCof Call g( )

String

StackGrowth

s1Return

AddressSaved FP

Local Variablebuf

FP

SP

Higher Addr.

Lower Addr.

The Next PCof Call g( )

ICECS'06 12

Kyushu University Koji Inoue

Stack Smashing

int f ( ) { … g (s1); …}

int g ( char *s1) { char buf [10]; … strcpy(buf, s1); …}

Programcode

1. Start f( )2. Call g( )3. Execute strcpy( )4. Return to f( )

StackGrowth

s1Return

AddressSaved FP

Local Variablebuf

FP

SP

Higher Addr.

Lower Addr.

The Next PCof Call g( )

StackGrowth

s1Return

AddressSaved FP

Local Variablebuf

FP

SP

Higher Addr.

Lower Addr.

The Next PCof Call g( )

StringAttackCode

To theAttack Code

Insert the attack code!Corrupt the return address!

ICECS'06 13

Kyushu University Koji Inoue

Stack Smashing

int f ( ) { … g (s1); …}

int g ( char *s1) { char buf [10]; … strcpy(buf, s1); …}

Programcode

1. Start f( )2. Call g( )3. Execute strcpy( )4. Return to f( )

StackGrowth

s1Return

AddressSaved FP

Local Variablebuf

FP

SP

Higher Addr.

Lower Addr.

The Next PCof Call g( )

StackGrowth

s1Return

AddressSaved FP

Local Variablebuf

FP

SP

Higher Addr.

Lower Addr.

The Next PCof Call g( )

StringAttackCode

To theAttack Code

Insert the attack code!Corrupt the return address!Hijack the program execution!

ICECS'06 14

Kyushu University Koji Inoue

Outline Introduction Buffer-Overflow Attack Secure Cache Architecture

Overview Security Issue

Lock&Unlock Algorithm Evaluation

Experimental Set-Up Security Strength Performance Overhead

Conclusions

ICECS'06 15

Kyushu University Koji Inoue

Protect return-address (RA) values in the cache! Generate one or more “Replicas” on each RA store Compare the original RA with a replica on the RA load If they are not the same, we know that the popped RA has been corrupted!

ML RL RL

way0 way1 way2 way3tag

data(line)

Data (Ret. Addr.) Load (pop)

Replica-MUX

Safe?

replica replica

Read-MUX

masterTag Match && R-flag

Tag Match&& no R-flag

HIT?

Word-DataMatch

Ref. Addr.Index

TagOffset

Store (push)Data (Ret. Addr.)

RL: Replica LineML: Master Line

R-flag

Secure Cache Architecture

ICECS'06 16

Kyushu University Koji Inoue

Security Issue The replica lines are also evicted from

the cache Miss the opportunity to check the RA

value if no replica lines reside in the cache

So… Good for many applications (w/ high cache-

hit rates) Bad for memory intensive applications (w/

high cache-miss rates)

ICECS'06 17

Kyushu University Koji Inoue

Outline Introduction Buffer-Overflow Attack Secure Cache Architecture

Overview Security Issue

Lock&Unlock Algorithm Evaluation

Security Strength Performance Overhead

Conclusions

ICECS'06 18

Kyushu University Koji Inoue

Lock and Invalidate Approach

Prohibit the eviction of replica lines until they are loaded later! (Lock)

Invalidate the loaded replicas to release the cache resource (Invalidate)

Pros. Effective use of cache resource

Cons. Squashed return-address loads

prematurely invalidate the replica lines

ICECS'06 19

Kyushu University Koji Inoue

Lock & Unlock Approach

Prohibit the eviction of replica lines until they are loaded later! (Lock)

Keep the replicas in the cache until they are evicted due to the replacement policy! (Unlock)

Pros. Avoid premature replica-line invalidation

Cons. Waste cache resource

ICECS'06 20

Kyushu University Koji Inoue

Outline Introduction Buffer-Overflow Attack Secure Cache Architecture

Overview Security Issue

Lock&Unlock Algorithm Evaluation

Security Strength Performance Overhead

Conclusions

ICECS'06 21

Kyushu University Koji Inoue

Experimental Set-Up Processor Simulator

SimpleScalar3.0 4-way OOO Superscalar 4-way 16KB L1 D-Cache

SCache Model LRU1-L&I: Lock & Invalidate (w/ LRU replica placement) LRU1-L&U: Lock & Unlock (w/ LRU replica placement) MRU1-L&U: Lock & Unlock (w/ MRU replica placement)

Benchmark Programs SPEC2000

7 integer programs, 4 fp programs Small input

ICECS'06 22

Kyushu University Koji Inoue

Vulnerability

0.0%

5.0%

10.0%

15.0%

20.0%

25.0%

164.g

zip

175.v

pr

176.g

cc

181.m

cf

197.p

arse

r

255.v

orte

x

256.b

zip2

177.m

esa

179.a

rt

183.e

quak

e

188.a

mmp

Vuln

era

bili

ty

Benchmark Programs

LRU1-L&ILRU1-L&UMRU1-L&U

(Nv-rald / Nrald) * 100 Total #of issued

RA loadInsecure issued

RA load

ICECS'06 23

Kyushu University Koji Inoue

Performance Overhead

0.0%0.1%0.2%0.3%0.4%0.5%0.6%0.7%0.8%0.9%1.0%

164.g

zip

175.v

pr

176.g

cc

181.m

cf

197.p

arser

255.v

ortex

256.b

zip2

177.m

esa

179.a

rt

183.e

quak

e

188.a

mmp

Perf

orm

ance

Overh

ead

Benchmark Programs

LRU1-L&ILRU1-L&UMRU1-L&U

ICECS'06 24

Kyushu University Koji Inoue

Outline Introduction Buffer-Overflow Attack Secure Cache Architecture

Overview Security Issue

Lock&Unlock Algorithm Evaluation

Security Strength Performance Overhead

Conclusions

ICECS'06 25

Kyushu University Koji Inoue

Summary Architectural support for run-time buffer-overflow detection New data management algorithms

Lock and Invalidation Inefficient for some benchmark programs

Max. :23% vulnerability Performance overhead is less than 0.9%

Lock and Unlock Very efficient for all benchmark programs

Max. :2.5% vulnerability (average<0.8%) Performance overhead is less than 0.3%

Future Work Integrate to a secure micorprocessor platform

Conclusions