Heat Stroke: Power-Density-Based Denial of Service in SMT

Jahangir Hasan Ankit Jalote T. N. Vijaykumar

School of Electrical & Computer Engineering,

Purdue University

Carla Brodley

Department of Computer Science,

Tufts University

Denial of Service (DOS) Attacks

Resource sharing prevalent in current systemsMalicious users can exploit the sharingDOS attacks maliciously hog shared resourceCan render the system practically inoperativeFor example1. Fork bomb2. TCP syn floodCan be detrimental to businesses and organizations

Must address DOS attacks to prevent financial loss

Vulnerability of SMT

Multiple threads share pipeline resources in SMT1. Register File2. Cache3. Fetch bandwidth=> Opportunity for DOS attacks

Previously-known attacks on SMT- Trace Cache flushing via self-modifying code [Micro02]

Are there other unaddressed vulnerabilities?

Heat Stroke: A Novel Attack in SMT

Repeatedly accessing pipeline resources create hot spotsMust stall/slow down to coolResource shared => all threads suffer

Heat Stroke exploits this vulnerabilityPersistently access shared resource at a high rateRepeated hot-spots cause repeated slowing/stallingSignificantly degrade performance of all other threads E.g., 1.2ms to heat, 12ms to cool => 90% slowdown

Must address this novel and detrimental attack

Previous Schemes not Applicable

Can heat stroke be solved by packaging?- Designed for avg. power, not local hot spots- Problem worsens with scaling

Can heat stroke be solved by architecture?- Slow down/stall entire pipeline (Clk, V Scaling)- They address occasional hot spots- But heat stroke is persistent and prolonged

Heat Stroke causes large degradation

Contributions

Identify Heat Stroke as a novel DOS attack in SMT- Does not exploit ICOUNT or monopolize resource- Purely a power-density problem

Propose Selective Sedation to address Heat Stroke- Identify culprit thread based on resource usage- Throttle only culprit thread- Allow other threads to continue execution

We successfully prevent Heat Stroke

Key Features of Selective Sedation

We do not solve the general power-density problem- Stall only the thread having power-density problem- Prevent it from affecting non-problematic threads

We do not separate malicious and non-malicious- Doing so would be hard- Must stall thread if it creates hot spot, malicious or not

- Therefore unnecessary to determine nature

Overview

IntroductionHeat Stroke ExamplesOur Solution to Heat StrokeMethodologyResultsConclusions

An Example of Heat StrokeLabel1:

add $1, $2, $3 br Label1

High-ILP program executes without stallsRepeatedly access register file at high rateCreate repeated hot spots at register fileHeat-up time short (1.2ms), cooling time long (12ms)

Degrades CPU utilization to 10%, but is it due to hogging fetch bandwidth or due to heat?

Moderated Example of Heat StrokeLabel1:

add $1, $2, $3 br 15*106 Label1

Label2: ld $4, addr1

(cache miss) … … … ld $4, addr9

(cache miss) br 3*103 Label2

Net ILP low => not hog fetch bandwidthRegister file still accessed at high rateCleverly moderated code still inflicts heat stroke

Heat stroke does not monopolize resources

High IPC

Phase

Low IPC Phase

Overview

IntroductionHeat Stroke ExamplesOur Solution to Heat StrokeMethodologyResultsConclusions

Selective Sedation

Solution based on two key observations

1. Need stall only culprit thread, not entire pipeline

=> Avoid performance loss for normal threads

2. Access rate of culprit thread higher than others

=> Easy to identify culprit

Two steps in Selective Sedation

1. Correctly and efficiently identify culprit thread

2. Selectively sedate only culprit thread

Timely Detection of Heat Stroke

Performance suffers due to long cooling time

Damage already done if hot spot gets created

Use temperature threshold just below emergency [HPCA01]

Detect Heat Stroke in timely manner

Launch Selective Sedation before actual hot spot

Identifying Culprit Thread

Flat average of access rate can be misleadingNeed to track recent historyWt. average counter for recent access-rate history

- Details in paper

When temperature threshold is exceeded=> Highest value counter indicates culprit thread

Selective Sedation

Stall fetch of only culprit threadRemaining threads continue to executeAllow hot resource to cool Resume culprit’s fetch when temperature gets normal- to avoid starvation of culprit thread

Can report repeat-offender to OS

Experimental Methodology

- Extend Wattch to include Hot-Spot and SMT

- Base case stops pipeline upon a hot spot

- All simulations run for 500 million cycles

- Use a history of 0.5 million cycles for identifying culprit

Architectural Parameters

Issue 6, out-of-order

L1 64K 4-way, 2 cycle

L2 2M 8-way, 12-cycle

ROB 128

Power Density Parameters

Clock 4 GHz

Heat Sink 0.8 K/W

Cooling time 10 ms

Overview

- Introduction- Heat Stroke Examples- Our Solution to Heat Stroke- Methodology- Results- Conclusions

Inflicting and Sedating Heat Stroke

Heat stroke causes repeated hot spots Selective Sedation drastically contains hot spots

0

2

4

6

8

10

appl

ueo

n

equa

ke gcc

mes

a

sixtra

ck vpr

Nu

mb

er o

f E

mer

gen

cies

Single SPEC SPEC and Heat-Stroke SPEC and Sedation

Performance Impact of Heat Stroke and Selective Sedation

Our realistic heat sink is reasonableHeat stroke does not hog resourcesHeat stroke causes huge performance lossSelective Sedation restores performance

0

0.5

1

1.5

2

2.5

3

3.5

4

appl

ueo

n

equa

ke gcc

mes

a

sixtra

ck vpr

IPC

of

SP

EC

pro

gra

m o

nly

SPEC - ideal heat-sink

SPEC - real heat-sink

SPEC+ Heat Stroke - ideal sink

SPEC + Heat Stroke - real sink

SPEC + sedation - real sink

Effect of Sedation on Normal programs

Selective Sedation has no adverse effect on normal programs

0

0.5

11.5

2

2.5

3

applu

+equ

ake

eon+

equak

e

equa

ke+e

quak

e

gcc+

equak

e

mes

a+equ

ake

sixtra

ck+eq

uake

vpr+

equa

ke

Co

mb

ined

IP

C o

f S

PE

C a

nd

Eq

uak

e Without Sedation With Sedation

Overview

IntroductionHeat-Stroke ExamplesOur Solution to Heat StrokeMethodologyResultsConclusions

Conclusions

Identified Heat Stroke as a novel DOS attackProposed Selective Sedation to address Heat StrokeIdentify and stall culprit thread, not entire pipeline

Our results show that selective sedation:- Effectively prevents Heat Stroke- Is robust across heat-sink and threshold variations- Has no adverse effect on normal programs

We identified and solved a novel DOS attack in SMT

Heat Stroke: Power-Density-Based Denial of Service in SMT

Jahangir Hasan Ankit Jalote T. N. Vijaykumar

School of Electrical & Computer Engineering,

Purdue University

Carla Brodley

Department of Computer Science,

Tufts University

Symbiotic OS Scheduling solves heat stroke by ensuring fairness ?

Symbiotic OS Scheduling for SMT [SIGMETRICS02]:1. Assumes that degradation is due to incompatibility=> Continues to run malicious threads to find compatibility2. Heat stroke can cause long solo-execution of threads=> System utilization degraded to guarantee fairness3. Cleverly designed code can fool Symbiotic OS Scheduler Test phase => behave normal, Run phase =>heat stroke

Symbiotic scheduling does not solve heat stroke

Once remote machine is accessed, other DOS attacks more severe than

heat stroke are possible ?

Systems are patched for known DOS attack methods- Important to address every DOS attack method- Heat stroke unaddressed => system vulnerable

Heat stroke must be addressed irrespective of other attacks

Selective sedation is unfair to non-malicious high-resource-usage thread?

Non-malicious high-resource-usage thread:- Performance is inherently power-density limited- Any scheme must throttle such thread

Selective sedation does nothing to worsen its performance

Selective sedation is not unfair

Variation Studies

Effectiveness not sensitive to heat-sink or threshold precision

Results for aggressive Heat-Sink

00.5

11.5

22.5

33.5

4

applu eo

n

equa

ke gcc

mes

a

sixtra

ck vpr

SPEC CPU 2000

IPC

fo

r S

PE

C p

rog

ram

o

nly

Single SPEC ideal sink

Single SPEC realisticsink

SPEC and Variant2 idealsink

SPEC and Variant 2realistic sink

SPEC and Variant 2 withsedation