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

1
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
2
Denial of Service (DOS) Attacks

• Resource sharing prevalent in current systems
• Malicious users can exploit the sharing
• DOS attacks maliciously hog shared resource
• Can render the system practically inoperative
• For example
• Fork bomb
• TCP syn flood
• Can be detrimental to businesses and
  organizations
• Must address DOS attacks to prevent financial loss

3
Vulnerability of SMT

• Multiple threads share pipeline resources in SMT
• Register File
• Cache
• Fetch bandwidth
• gt Opportunity for DOS attacks
• Previously-known attacks on SMT
• Trace Cache flushing via self-modifying code
  Micro02
• Are there other unaddressed vulnerabilities?

4
Heat Stroke A Novel Attack in SMT

• Repeatedly accessing pipeline resources create
  hot spots
• Must stall/slow down to cool
• Resource shared gt all threads suffer
• Heat Stroke exploits this vulnerability
• Persistently access shared resource at a high
  rate
• Repeated hot-spots cause repeated
  slowing/stalling
• Significantly degrade performance of all other
  threads
• E.g., 1.2ms to heat, 12ms to cool gt 90 slowdown
  
• Must address this novel and detrimental attack

5
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

6
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

7
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

8
Overview

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

9
An Example of Heat Stroke

• Label1
• add 1, 2, 3
• br Label1
• High-ILP program executes without stalls
• Repeatedly access register file at high rate
• Create repeated hot spots at register file
• Heat-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?

10
Moderated Example of Heat Stroke

• Label1
• add 1, 2, 3
• br 15106 Label1
• Label2
• ld 4, addr1 (cache miss)
• ld 4, addr9 (cache miss)
• br 3103 Label2
• Net ILP low gt not hog fetch bandwidth
• Register file still accessed at high rate
• Cleverly moderated code still inflicts heat
  stroke
• Heat stroke does not monopolize resources

High IPC Phase
Low IPC Phase
11
Overview

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

12
Selective Sedation

• Solution based on two key observations
• Need stall only culprit thread, not entire
  pipeline
• gt Avoid performance loss for normal threads
• Access rate of culprit thread higher than others
• gt Easy to identify culprit
• Two steps in Selective Sedation
• Correctly and efficiently identify culprit thread
• Selectively sedate only culprit thread

13
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

14
Identifying Culprit Thread

• Flat average of access rate can be misleading
• Need to track recent history
• Wt. average counter for recent access-rate
  history
• - Details in paper
• When temperature threshold is exceeded
• gt Highest value counter indicates culprit thread

15
Selective Sedation

• Stall fetch of only culprit thread
• Remaining threads continue to execute
• Allow hot resource to cool
• Resume culprits fetch when temperature gets
  normal
• to avoid starvation of culprit thread
• Can report repeat-offender to OS

16
Experimental Methodology
Architectural Parameters Architectural Parameters Architectural Parameters
Issue 6, out-of-order 6, out-of-order
L1 64K 4-way, 2 cycle 64K 4-way, 2 cycle
L2 2M 8-way, 12-cycle 2M 8-way, 12-cycle
ROB 128 128
Power Density Parameters Power Density Parameters Power Density Parameters
Clock Clock 4 GHz
Heat Sink Heat Sink 0.8 K/W
Cooling time Cooling time 10 ms

• 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

17
Overview

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

18
Inflicting and Sedating Heat Stroke

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

19
Performance Impact of Heat Stroke and Selective
Sedation

• Our realistic heat sink is reasonable
• Heat stroke does not hog resources
• Heat stroke causes huge performance loss
• Selective Sedation restores performance

20
Effect of Sedation on Normal programs

• Selective Sedation has no adverse effect on
  normal programs

21
Overview

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

22
Conclusions

• Identified Heat Stroke as a novel DOS attack
• Proposed Selective Sedation to address Heat
  Stroke
• Identify 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

23
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
24
Symbiotic OS Scheduling solves heat stroke by
ensuring fairness ?

• Symbiotic OS Scheduling for SMT SIGMETRICS02
• 1. Assumes that degradation is due to
  incompatibility
• gt Continues to run malicious threads to find
  compatibility
• 2. Heat stroke can cause long solo-execution of
  threads
• gt System utilization degraded to guarantee
  fairness
• 3. Cleverly designed code can fool Symbiotic OS
  Scheduler
• Test phase gt behave normal, Run phase gtheat
  stroke
• Symbiotic scheduling does not solve heat stroke

25
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 gt system vulnerable
• Heat stroke must be addressed irrespective of
  other attacks

26
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

27
Variation Studies

• Effectiveness not sensitive to heat-sink or
  threshold precision