Secure HierarchyAware Cache Replacement Policy SHARP Defending Against

Secure Hierarchy-Aware Cache Replacement Policy (SHARP): Defending Against Cache-Based Side Channel Attacks Mengjia Yan, Bhargava Gopireddy, Thomas Shull, Josep Torrellas University of Illinois at Urbana-Champaign http: //iacoma. cs. uiuc. edu ISCA 2017

Shared Resources in Cloud • Shared hardware resources can leak information • Cache side-channel attacks: attacker observes a victim’s cache behavior – Can bypass software security policies – Leave no trace VM Isolation Victim VM Core L 1 Attacker VM Core L 1 Shared LLC Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 2

Sample Cache Side-Channel Attack: RSA Encryption Key for i = n− 1 down to 0 do r = sqr(r) …. . if ei == 1 then r = mul(r, b) …. end Probe addresses: Monitored by the spy to obtain information Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 4

Attack Illustration Victim L 1 Cache Spy L 1 Cache Set Shared L 2 Cache (Inclusive) Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 5

Attack Illustration Victim L 1 Cache Spy L 1 Cache Probe address Shared L 2 Cache (Inclusive) Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 6

Attack Illustration Victim L 1 Cache Spy L 1 Cache Probe address Evict Spy’s line Spy Access Inclusion Victim Hit Access Conflict Evict Wait Time Analyze Shared L 2 Cache (Inclusive) Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 7

Attack Illustration – Cont’d Victim L 1 Cache Spy L 1 Cache Probe address Spy’s line Spy Access Miss No Access Memory Access Shared L 2 Cache (Inclusive) Evict Secure Hierarchy-Aware Cache Replacement Policy (SHARP) Wait Time Analyze 8

Cache Side-Channel Attack Classification No Access Evict Wait Victim L 1 Cache Evict Analyze Evict Spy L 1 Cache Wait Time Analyze Eviction Strategies X • Conflict-based • Flush-based Inclusion Victim Evict clflush addr. X X Conflict Shared L 2 Cache Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 9

Contributions • Insight: Conflict-based attacks rely on “Inclusion Victims” • Introduce SHARP: – A shared cache replacement policy that defends against conflict-based attacks by preventing inclusion victims – A slightly modified “clflush” instruction to prevent flushbased attacks Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 11

SHARP: Preventing Inclusion Victims Step 1: Find a cache line in the set that is not present in any private cache Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 12

SHARP: Preventing Inclusion Victims Step 1: Find a cache line in the set that is not present in any private cache Victim L 1 Cache Spy L 1 Cache Probe address Spy’s line Line not in any private cache Inclusion victim from other core is prevented Shared L 2 Cache Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 13

SHARP: Prevention of Multi. Core Attack Step 1: Find a cache line in the set that is not present in any private cache Otherwise Step 2: Find a cache line in the set that is present only in the requesting core’s private cache Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 14

SHARP: Prevention - Multi. Core Attack Step 2: Find a cache line in the set that is present only in the requesting core’s private cache Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 15

SHARP: Prevention - Multi. Core Attack Step 2: Find a cache line in the set that is present only in the requesting core’s private cache Victim Spy 1 Spy 2 Evict Inclusion victim from other core is prevented Shared L 2 Cache Conflict Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 16

SHARP Summary Step 1: Find a cache line in the set that is not present in any private cache Otherwise Step 2: Find a cache line in the set that is present only in the requesting core’s private cache Otherwise Step 3: Randomly evict a line, increment alarm counter SHARP needs to know whether a line is present in private cache • Use presence bits in directory (Core Valid Bits) • Query, with a message, the private caches for information Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 17

Obtaining Private Cache Information: CVB • Using Core Valid Bits (CVB) only: – Step 1: Pick a line without any CVB set – Else Step 2: Pick a line with only the requester’s CVB set ✓ Readily available ✗ Conservative – Silent evictions from private cache do not update CVB Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 19

Obtaining Private Cache Information: Hybrid • Using combination of CVB and queries to private caches – Step 1: Pick a line without any CVB set – Else Step 2: Send queries to refresh CVB until a replacement candidate is found (all CVB bits zero, or only requester’s CVB set) ✓ Accurate ✗ Significant network overhead to send messages Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 20

Obtaining Private Cache Information: SHARP • Hybrid scheme with a limit on the query count – Step 1: Pick a line without any CVB set – Else Step 2: Send queries to refresh CVB for at most N lines. If candidate is not found, use current CVB for the rest (to pick a line present only in the requester’s cache) ✓ Accurate enough ✓ Low overhead Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 21

Experimental Setup • Marss. X 86 cycle-level full system simulator • 2 to 16 out of order cores – Private DL 1, IL 1, L 2 (32 KB, 256 KB) – Shared Inclusive L 3 cache (2 MB slice per core) – Baseline replacement policy: pseudo LRU Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 22

Security Evaluation: RSA Attack Baseline LRU: Access pattern of sqr, mul is clear for i = n− 1 down to 0 do r = sqr(r) …. . if ei == 1 then r = mul(r, b) …. end Secure Hierarchy-Aware Cache Replacement Policy (SHARP) Hit 23

Security Evaluation: RSA Attack Baseline LRU: Access pattern of sqr, mul is clear SHARP: No obvious access pattern of sqr, mul Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 24

L 3 Misses Per Kilo Instructions SHARP 2 1. 8 1. 6 1. 4 1. 2 1 0. 8 0. 6 0. 4 0. 2 0 Secure Hierarchy-Aware Cache Replacement Policy (SHARP) ag e er 4 Av x 2 6 ap t io ns ce sw ra yt ra e qm in fre m at e t an i flu id fe rre ce si m fa up de d ca nn ea ck tra bo dy ol e ck sc h bl a l “cvb” performs the worst s Normalized L 3 MPKI Inability to evict shared data Baseline CVB Hybrid causes cache thrashing 25

Execution Time CVB Hybrid Average execution time SHARP increase ≈ 1% 1. 2 1 0. 8 0. 6 0. 4 0. 2 Secure Hierarchy-Aware Cache Replacement Policy (SHARP) ag e er 4 Av x 2 6 ap t io ns ce sw ra yt ra e qm in fre m at e t an i flu id fe rre ce si m fa up de d ca nn ea ck tra bo dy ch ol e ck s bl a l 0 s Normalized Execution Time Modest slowdown of 6% due Baseline to large working set 26

More in the Paper • Prevention of flush-based attacks • Detailed evaluation – Mixes of SPEC workloads – Scalability to 8, 16 cores – Threshold Alarm Analysis • Handling of related attacks, defenses • Insights into the scheme, corner cases Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 27

Conclusion • Insight: Conflict-based attacks rely on “Inclusion Victims” • Presented SHARP: – Shared cache replacement policy that defends against conflictbased attacks by preventing inclusion victims – Slightly modified “clflush” instruction to prevent flush-based attacks ü Prevents all known cache-based side channel attacks ü Minimal performance loss ü No programmer intervention ü Minor hardware modifications Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 28

Secure Hierarchy-Aware Cache Replacement Policy (SHARP): Defending Against Cache-Based Side Channel Attacks Mengjia Yan, Bhargava Gopireddy, Thomas Shull, Josep Torrellas University of Illinois at Urbana-Champaign http: //iacoma. cs. uiuc. edu ISCA 2017

Backup

Preventing Flush-Based Attacks • “clflush” instruction – Invalidates an address from all levels of the cache hierarchy – Can be used at all privilege levels on any address • Used to handle inconsistent memory states – Memory-mapped IO – Self modifying code Write-able • Attacker exploits “clflush” through page sharing of Read-Only – Shared library SHARP: Allow “clflush” only if the thread has Copy-On-Write – Page de-duplication write access to the address Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 31

• • Starvation Threshold for alarms Pathological cases How does it apply to other replacement policies ? – Performance will still be better ? Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 32

Performance Evaluation on SPEC Benchmarks Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 33

Performance Evaluation on Scalability • Mixes of SPEC applications on 8 -core setup Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 34

Performance Evaluation on Scalability • PARSEC applications on 16 -core setup Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 35

Alarm Anlysis • An attacker thread will increment its counter at least 100, 000 times in 1 billion cycles • It is safe to use 2, 000 as threshold in SHARP 4 Alarms per 1 billion cycles in benign workloads Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 36

Compare to Related Works • Conflict-based attack – Cache partition High performance overhead – Software assisted cache - Require code modification locking - Difficult to precisely determine addresses to protect • Flush-based attack – Disable “clflush” in user space Secure Hierarchy-Aware Cache Replacement Policy (SHARP) Legacy issues 37

Performance Evaluation on PARSEC Benchmark “cvb” performs the worst Inability to evict shared data causes cache thrashing, thus higher MKPI Reducing inclusion victims lowers MPKI Secure Hierarchy-Aware Cache Replacement Policy (SHARP) Average MPKI increase is low 38

Performance Evaluation on PARSEC Benchmark Modest slowdown of 6% due to large working set. Secure Hierarchy-Aware Cache Replacement Policy (SHARP) Average execution time increase ≈ 1% 39

Experiment Setup • Marss. X 86 cycle-level full system simulator Parameters for the simulated system Evaluated configurations Parameter Value Config. Line Replacement Policy in L 3 Multicore 2 -16 cores at 2. 5 GHz baseline Pseudo-LRU replacement. Core 4 -issue, out-of-order, 128 -entry ROB cvb Use CVBs in both step 1 and 2 Private L 1 I-Cache/D-Cache 32 KB, 64 B line, 4 -way Access latency: 1 cycle query CVBs in step 1 & queries in step 2 SHARPX Private L 2 Cache 256 KB, 64 B line, 8 -way, Access latency: 5 cycles after L 1 CVBs in step 1. In step 2, limit the max number of queries to X, where X = 1, 2, 3 or 4. Query from L 3 to L 2 3 cycles network latency each way Shared L 3 Cache 2 MB bank per core, 64 B line, 16 -way, Access latency: 10 cycles after L 2 Coherence Protocol MESI DRAM Access latency: 50 ms after L 3 Operating System 64 -bit version of Ubuntu 10. 4 Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 40

SHARP: New Cache Replacement for Security • Prevents an attacker thread from creating “Inclusion Victims” Cache 0 - Victim Cache 1 - Spy ü Prevents all known cachebased side channel attacks ü Minimal performance loss Conflict ü No programmer intervention Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 42

Attacks on Inclusive Hierarchical Caches • Cache based side channel attacks rely on “Inclusion Victims” Evict Cache 0 - Victim Cache 1 - Spy Shared address Spy’s line Conflict Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 43

SHARP: New Cache Replacement for Security • Prevents an attacker thread from creating “Inclusion Victims” Cache 0 - Victim Cache 1 - Spy Prevents cache-based side channel attacks minimal performance penalty Conflict Secure Hierarchy-Aware Cache Replacement Policy (SHARP) 44

Sample Attack – RSA Encryption Key Square and multiply based exponentiation • Input : base b, modulo m, exponent e = (en− 1. . . e 0 )2 Output: be mod m r=1 for i = n− 1 down to 0 do r = sqr(r) r = mod(r, m) if ei == 1 then r = mul(r, b) r = mod(r, m) end return r Secure Hierarchy-Aware Cache Replacement Policy (SHARP) Probe addresses used by spy 45