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 systems Malicious users can exploit the sharing DOS attacks maliciously hog shared resource Can render the system practically inoperative For example 1.Fork bomb 2.TCP syn flood Can be detrimental to businesses and organizations Must address DOS attacks to prevent financial loss

Vulnerability of SMT Multiple threads share pipeline resources in SMT 1.Register File 2.Cache 3.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 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

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 Introduction Heat Stroke Examples Our Solution to Heat Stroke Methodology Results Conclusions

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?

Moderated Example of Heat Stroke Label1: add $1, $2, $3 br 15*10 6 Label1 Label2: ld $4, addr1 (cache miss) … … … ld $4, addr9 (cache miss) br 3*10 3 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 High IPC Phase Low IPC Phase

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

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

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

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 Issue6, out-of-order L164K 4-way, 2 cycle L22M 8-way, 12-cycle ROB128 Power Density Parameters Clock4 GHz Heat Sink0.8 K/W Cooling time10 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

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

Effect of Sedation on Normal programs Selective Sedation has no adverse effect on normal programs

Overview Introduction Heat-Stroke Examples Our Solution to Heat Stroke Methodology Results 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

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

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