1. © 2007 IBM Corporation WEST-2010 Practical and Secure PCM Memories via Online Attack Detection Moinuddin Qureshi Luis Lastras, Michele Franceschini, John Karidis IBM T. J. Watson Research Center, Yorktown Heights, NY

2. © 2007 IBM Corporation 2 Birthday Paradox Attack We thank Andre Seznec for pointing the Birthday Paradox Attack (BPA) vulnerability for Start-Gap In the paper, we first prove that for our RBSG scheme, BPA causes at-most 2x reduction in lifetime compared to Repeat Address Attack (RAA) Lifetime under attack : ~1-2 months Here we introduce an adaptive-RBSG scheme which extends the life to years under all analyzed attacks

3. © 2007 IBM Corporation 3 The Assumptions in Security Studies  No other application running except attack  Attack goes undetected for months/years  OS maintains mapping of pages for entire duration  Possible to write a line to memory at full speed Other things that can help:  Significant spare lines needed for PCM anyway  Legal actions for minimizing warranty fraud

4. © 2007 IBM Corporation 4 What we need … ParameterRBSGRandSwapIdeal.Req Lifetime for typical apps97%87.5%95+% Lifetime under attacksMonth(s)Year(s) Storage overhead~1.5KB25-256KBfew KB Latency overhead<10 cyc Write (performance) overhead1%12.5%<1% ComplexityLowHighLow Security: Lifetime under attacks should be in the range of years. Typical solution: Table based with RandSwap [Ben-Aroya et al.’06, Seznec’10] We would like to have security for free (or almost free)

5. © 2007 IBM Corporation 5 Key insight Table based methods make all applications pay high overhead to handle (infrequent) attacks: High overhead okay for attacks, not otherwise Wear leveling algorithms move lines at a particular rate. This rate determines: write overhead & robustness under attacks Trade-off: rate must be low to reduce overhead and high for robustness If we can identify attack-like patterns, then have slower rate for typical apps and faster for attacks: best of both worlds

6. © 2007 IBM Corporation 6 Our proposal: Adaptive Wear Leveling Wear Leveling Algorithm Online Attack Detector (OAD) WRITE.ADDR PCM Based Main Memory RateControl OAD controls the rate of movement based on properties of the memory write stream

7. © 2007 IBM Corporation 7 Outline  Introduction  Background on Start-Gap  Anatomy of Attacks  Practical Attack Detector  Adaptive Start-Gap  Summary and Discussions

8. © 2007 IBM Corporation 8 Start-Gap Wear Leveling Two registers (Start & Gap) + 1 line (GapLine) to support movement. Move GapLine every G writes to memory.  START A B C 0 1 2 3 4 PCMAddr = (Start+Addr); (PCMAddr >= Gap) PCMAddr++) D GAP  Storage overhead: less than 8 bytes (GapLine taken from spares) Write overhead: One extra write every G writes  1% (G=100) Randomized address space to avoid “hot region” and predictability

9. © 2007 IBM Corporation 9 Terminology Line Vulnerability Factor (LVF): N*G If (LVF > E) Repeated writes to a line causes line failure N= Number of Lines in Memory G= Gap Movement Interval (Writes per Gap movement) E= Endurance per each line LVF= Max writes to same address before line gets moved In general we want (LVF << E), say LVF=E/8 (not enough) Therefore, G= (E/8N), which means G=1/16 (if N=2E) But we want G>=100 to limit write overhead to less than 1%

10. © 2007 IBM Corporation 10 Effective LVF Intra Write Distance (d): Num writes between two writes to the same line But we write to several other lines between writes to same line For ELVF=E/8  G=(E.d)/(8N) Typically, d>>1K, which means G=128 easy for typical apps If (d>1), the line vulnerability factor reduces Effective LVF (d) = ELVF(d) = (N*G)/d

11. © 2007 IBM Corporation 11 Likelihood of Repeat Writes To show that d>>1K, we conducted the following experiment DRAM cache: 32MB, 8-way LRU, normal indexing Keep track of most recent “w” writes to memory Probability of hit in most recent “w” writes to memory Likelihood of hit in most recent 1K entries is less than one in a million

12. © 2007 IBM Corporation 12 Outline  Introduction  Background on Start-Gap  Anatomy of Attacks  Practical Attack Detector  Adaptive Start-Gap  Summary and Discussions

13. © 2007 IBM Corporation 13 Requirements for Attack For an attack to successfully cause failure, it must: 1.Write to a few lines (otherwise d>1K) 2.Repeatedly for at-least a few million times 3.At a fairly high write bandwidth We can exploit properties (1) and (2) for online attack detection.

14. © 2007 IBM Corporation 14 Canonical Form of Attacks SMA-like attacks are most challenging to detect Generalized RAA Stealth-Mode Attack

15. © 2007 IBM Corporation 15 Typical Apps vs. Attacks Easy to differentiate attacks by measuring hit rate of 1K entry window But too much hardware and power. Window searched on each access.

16. © 2007 IBM Corporation 16 Outline  Introduction  Background on Start-Gap  Anatomy of Attacks  Practical Attack Detector  Adaptive Start-Gap  Summary and Discussions

17. © 2007 IBM Corporation 17 Practical Attack Detector (PAD) We are interested in measuring hit rate of a relatively small window (1K) This can be approximated by a small stack and insert with prob “p” ADDRADDR + + HitCounter (16-bit) WriteCounter (16-bit) On each access, the stack is checked, WriteCounter incremented On a hit, the replacement info of entry is updated, HitCounter incremented On a miss, with a probability p, the insert the address in the stack When WriteCounter reaches max, hit rate is calculated, both counters halved We conservatively calculate the distance (d) = 1/hitrate

18. © 2007 IBM Corporation 18 Effectiveness of PAD PAD can monitor different window sizes, depending on the insert probability (p) We assume a 16-entry stack with p=1/256 PAD can accurately estimate the distance (d) for SMA

19. © 2007 IBM Corporation 19 Characteristics of PAD 1.Programmable and accurate for distances within window 2.Low detection latency (32K writes) 3.Pardons infrequent hits in window (must hit several times) 4.Decaying effect on hit rate  attack not easily forgotten 5.Handles multiple attacks  reports worst-case d 6.Low hardware cost (68 bytes) and non-intrusive PAD is off the critical path, distance calculation every 32K writes

20. © 2007 IBM Corporation 20 Outline  Introduction  Background on Start-Gap  Anatomy of Attacks  Practical Attack Detector  Adaptive Start-Gap  Summary and Discussions

21. © 2007 IBM Corporation 21 Adaptive Start-Gap Key insight: Make Gap Movement Interval (G) a function of distance (d) To ensure < E/8 writes occur to a given line before the line is moved: G = For typical apps, d>>1K, which means G=128 For repeat address attack (RAA), d=1, which means G=1/16 if (N=2E) Slow (but not a problem, as it is an attack, not using the cache) But useful writes reduced to less than 1/16.

22. © 2007 IBM Corporation 22 Adaptive Region-Based Start-Gap Key insight: Divide memory into regions (num regions = num banks) With “r” banks, number of lines in each bank becomes N/r Therefore, to ensure < E/8 writes occur before the line is moved: G = Thus, even under RAA, one line moves every demand write Each bank has its own start-gap and attack detection circuit (68 bytes) Total storage overhead of aRBSG: 16*(4+4+68) = 1216 bytes For N=2E and r=16 G =

23. © 2007 IBM Corporation 23 Results for GRAA Generalized Repeat Address Attack (GRAA) on n lines. N=2 26, E=2 25, Banks=Regions=16, TimeToWriteOneLine=1 µ second Lifetime remains constant at 4 years. Useful writes from 50% to 98%

24. © 2007 IBM Corporation 24 Handling BPA Effectiveness of BPA bounded by “Buckets and Balls” problem Assume attacker knows which line maps to which bank ELVF of E/8 not enough, need ELVF of E/64 for ~50% demand writes 8 months Number of buckets (B)=4M

25. © 2007 IBM Corporation 25 Extensions for Handling BPA With ELVF=E/64, 37% of demand writes + 37% “extra” writes. Lifetime: 74% of 4 years (~3 years) [Without any spare lines] G = G 8 Move gap 8 times faster to ensure ELVF of E/64 Avoid 8x write overhead: Under attack ensure >= 8 demand entries in WRQ before writing. This ensure d min = 8. Worst-case overhead: one “extra” write per demand write

26. © 2007 IBM Corporation 26 Generalized SMA: “Fooling” the detector SMA tries to trick PAD by hiding 1 attack line in random writes SMA is easy to detect but GSMA much harder to detect. k small enough that attack line does not enter PAD (k<1/p) n large enough that PAD forgets about the line if inserted (n>NumEntries/p) For our setup k 256*16  n> 4096 < Avg. Detection Period > Avg. Retention Period

27. © 2007 IBM Corporation 27 Lifetime under GSMA k={1,2,4,8,16,32,64,128,256} x n={1K,2K,4K,8K,16K,32K,64K,128K} If distance calc off by 8x this means ELVF of E/8 instead of E/64 If attack was at full speed: Lifetime of 8 months GSMA inherently slow (8K/128  64x slow): Lifetime ~2.2 years For the worst-case attack under LRU, distance calc. off by 8x

28. © 2007 IBM Corporation 28 Comparison ParameterRBSGRandSwapIdeal.ReqaRBSG Lifetime for typical apps97%87.5%95+%97% Lifetime under attacksMonth(s)Year(s) Storage overhead~1.5KB25-256KBfew KB<1.3KB Latency overhead<10 cyc Write (perf.) overhead1%12.5%<1% ComplexityLowHighLow Possible to get security for free … Well, almost free

29. © 2007 IBM Corporation 29 Outline  Introduction  Background on Start-Gap  Anatomy of Attacks  Practical Attack Detector  Adaptive Start-Gap  Summary and Discussions

30. © 2007 IBM Corporation 30 Summary  Security: We want lifetime in range of year(s) under attacks  We propose to decouple: attack detection and corrective actions  We propose simple and accurate attack detector (68 bytes)  We propose Adaptive RBSG that keeps write overhead for typical apps to < 1% and provides years of lifetime under attacks  Attack detection can be used for other corrective actions: slow down service, inform OS, swap page, inform sys admin  Attack detection also applicable to other wear leveling algorithms  Beta version: Work in progress (other attacks, theoretical analysis)

31. © 2007 IBM Corporation 31  Pagemode can be supported securely as well by: Randomizing at page granularity Having a GAP-PAGE instead of a GAP-LINE Rotating lines within page using a static randomizer: F(start,addr)  Make it harder for attacker to devise attacks. For example, randomize the index of DRAM cache This will also prevent typical apps showing attack-like patterns Other Extensions (not evaluated yet) Last Level Cache Rand InvRand ToMemory Addr