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 => 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 => 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 => 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 High IPCPhase Label1: 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 bandwidth Register file still accessed at high rate Cleverly moderated code still inflicts heat stroke Heat stroke does not monopolize resources 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, notentire pipeline => Avoid performance loss for normal threads • Access rate of culprit thread higher than others => 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 => 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 culprit’s fetch when temperature gets normal • to avoid starvation of culprit thread Can report repeat-offender to OS

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

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 => Continues to run malicious threads to find compatibility 2. Heat stroke can cause long solo-execution of threads => System utilization degraded to guarantee fairness 3. Cleverly designed code can fool Symbiotic OS Scheduler Test phase => behave normal, Run phase =>heat 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 => 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