51 research outputs found

    PThammer: Cross-User-Kernel-Boundary Rowhammer through Implicit Accesses

    Full text link
    Rowhammer is a hardware vulnerability in DRAM memory, where repeated access to memory can induce bit flips in neighboring memory locations. Being a hardware vulnerability, rowhammer bypasses all of the system memory protection, allowing adversaries to compromise the integrity and confidentiality of data. Rowhammer attacks have shown to enable privilege escalation, sandbox escape, and cryptographic key disclosures. Recently, several proposals suggest exploiting the spatial proximity between the accessed memory location and the location of the bit flip for a defense against rowhammer. These all aim to deny the attacker's permission to access memory locations near sensitive data. In this paper, we question the core assumption underlying these defenses. We present PThammer, a confused-deputy attack that causes accesses to memory locations that the attacker is not allowed to access. Specifically, PThammer exploits the address translation process of modern processors, inducing the processor to generate frequent accesses to protected memory locations. We implement PThammer, demonstrating that it is a viable attack, resulting in a system compromise (e.g., kernel privilege escalation). We further evaluate the effectiveness of proposed software-only defenses showing that PThammer can overcome those.Comment: Preprint of the work accepted at the International Symposium on Microarchitecture (MICRO) 2020. arXiv admin note: text overlap with arXiv:1912.0307

    ํƒ€์ž„ ์œˆ๋„์šฐ ์นด์šดํ„ฐ๋ฅผ ํ™œ์šฉํ•œ ๋กœ์šฐ ํ•ด๋จธ๋ง ๋ฐฉ์ง€ ๋ฐ ์ฃผ๊ธฐ์–ต์žฅ์น˜ ์„ฑ๋Šฅ ํ–ฅ์ƒ

    Get PDF
    ํ•™์œ„๋…ผ๋ฌธ (๋ฐ•์‚ฌ) -- ์„œ์šธ๋Œ€ํ•™๊ต ๋Œ€ํ•™์› : ์œตํ•ฉ๊ณผํ•™๊ธฐ์ˆ ๋Œ€ํ•™์› ์œตํ•ฉ๊ณผํ•™๋ถ€(์ง€๋Šฅํ˜•์œตํ•ฉ์‹œ์Šคํ…œ์ „๊ณต), 2020. 8. ์•ˆ์ •ํ˜ธ.Computer systems using DRAM are exposed to row-hammer (RH) attacks, which can flip data in a DRAM row without directly accessing a row but by frequently activating its adjacent ones. There have been a number of proposals to prevent RH, including both probabilistic and deterministic solutions. However, the probabilistic solutions provide protection with no capability to detect attacks and have a non-zero probability for missing protection. Otherwise, counter-based deterministic solutions either incur large area overhead or suffer from noticeable performance drop on adversarial memory access patterns. To overcome these challenges, we propose a new counter-based RH prevention solution named Time Window Counter (TWiCe) based row refresh, which accurately detects potential RH attacks only using a small number of counters with a minimal performance impact. We first make a key observation that the number of rows that can cause RH is limited by the maximum values of row activation frequency and DRAM cell retention time. We calculate the maximum number of required counter entries per DRAM bank, with which TWiCe prevents RH with a strong deterministic guarantee. TWiCe incurs no performance overhead on normal DRAM operations and less than 0.7% area and energy overheads over contemporary DRAM devices. Our evaluation shows that TWiCe makes no more than 0.006% of additional DRAM row activations for adversarial memory access patterns, including RH attack scenarios. To reduce the area and energy overhead further, we propose the threshold adjusted rank-level TWiCe. We first introduce pseudo-associative TWiCe (pa-TWiCe) that can search for hundreds of TWiCe table entries energy-efficiently. In addition, by exploiting pa-TWiCe structure, we propose rank-level TWiCe that reduces the number of required entries further by managing the table entries at a rank-level. We also adjust the thresholds of TWiCe to reduce the number of entries without the increase of false-positive detection on general workloads. Finally, we propose extend TWiCe as a hot-page detector to improve main-memory performance. TWiCe table contains the row addresses that have been frequently activated recently, and they are likely to be activated again due to temporal locality in memory accesses. We show how the hot-page detection in TWiCe can be combined with a DRAM page swap methodology to reduce the DRAM latency for the hot pages. Also, our evaluation shows that low-latency DRAM using TWiCe achieves up to 12.2% IPC improvement over a baseline DDR4 device for a multi-threaded workload.DRAM์„ ์ฃผ๊ธฐ์–ต์žฅ์น˜๋กœ ์‚ฌ์šฉํ•˜๋Š” ์ปดํ“จํ„ฐ ์‹œ์Šคํ…œ์€ ๋กœ์šฐ ํ•ด๋จธ๋ง ๊ณต๊ฒฉ์— ๋…ธ์ถœ๋œ๋‹ค. ๋กœ์šฐ ํ•ด๋จธ๋ง์€ ์ธ์ ‘ DRAM ๋กœ์šฐ๋ฅผ ์ž์ฃผ activationํ•จ์œผ๋กœ์จ ํŠน์ • DRAM ๋กœ์šฐ ๋ฐ์ดํ„ฐ์— ์ง์ ‘ ์ ‘๊ทผํ•˜์ง€ ์•Š๊ณ ์„œ๋„ ๋ฐ์ดํ„ฐ๋ฅผ ๋’ค์ง‘์„ ์ˆ˜ ์žˆ๋Š” ํ˜„์ƒ์„ ๋งํ•œ๋‹ค. ์ด๋Ÿฌํ•œ ๋กœ์šฐ ํ•ด๋จธ๋ง ํ˜„์ƒ์„ ๋ฐฉ์ง€ํ•˜๊ธฐ ์œ„ํ•ด ์—ฌ๋Ÿฌ๊ฐ€์ง€ ํ™•๋ฅ ์ ์ธ ๋ฐฉ์ง€ ๊ธฐ๋ฒ•๊ณผ ๊ฒฐ์ •๋ก ์  ๋ฐฉ์ง€ ๊ธฐ๋ฒ•๋“ค์ด ์—ฐ๊ตฌ๋˜์–ด ์™”๋‹ค. ๊ทธ๋Ÿฌ๋‚˜, ํ™•๋ฅ ์ ์ธ ๋ฐฉ์ง€ ๊ธฐ๋ฒ•์€ ๊ณต๊ฒฉ ์ž์ฒด๋ฅผ ํƒ์ง€ํ•  ์ˆ˜ ์—†๊ณ , ๋ฐฉ์ง€์— ์‹คํŒจํ•  ํ™•๋ฅ ์ด 0์ด ์•„๋‹ˆ๋ผ๋Š” ํ•œ๊ณ„๊ฐ€ ์žˆ๋‹ค. ๋˜ํ•œ ๊ธฐ์กด์˜ ์นด์šดํ„ฐ๋ฅผ ํ™œ์šฉํ•œ ๊ฒฐ์ •๋ก ์  ๋ฐฉ์ง€ ๊ธฐ๋ฒ•๋“ค์€ ํฐ ์นฉ ๋ฉด์  ๋น„์šฉ์„ ๋ฐœ์ƒ์‹œํ‚ค๊ฑฐ๋‚˜ ํŠน์ • ๋ฉ”๋ชจ๋ฆฌ ์ ‘๊ทผ ํŒจํ„ด์—์„œ ํ˜„์ €ํ•œ ์„ฑ๋Šฅ ํ•˜๋ฝ์„ ์•ผ๊ธฐํ•œ๋‹ค๋Š” ๋‹จ์ ์ด ์žˆ๋‹ค. ์ด๋Ÿฌํ•œ ๋ฌธ์ œ๋ฅผ ํ•ด๊ฒฐํ•˜๊ธฐ ์œ„ํ•ด, ์šฐ๋ฆฌ๋Š” TWiCe (Time Window Counter based row refresh)๋ผ๋Š” ์ƒˆ๋กœ์šด ์นด์šดํ„ฐ ๊ธฐ๋ฐ˜ ๊ฒฐ์ •๋ก ์  ๋ฐฉ์ง€ ๊ธฐ๋ฒ•์„ ์ œ์•ˆํ•œ๋‹ค. TWiCe๋Š” ์ ์€ ์ˆ˜์˜ ์นด์šดํ„ฐ๋ฅผ ํ™œ์šฉํ•˜์—ฌ ๋กœ์šฐ ํ•ด๋จธ๋ง ๊ณต๊ฒฉ์„ ์ •ํ™•ํ•˜๊ฒŒ ํƒ์ง€ํ•˜๋ฉด์„œ๋„ ์„ฑ๋Šฅ์— ์•…์˜ํ–ฅ์„ ์ตœ์†Œํ™”ํ•˜๋Š” ๋ฐฉ๋ฒ•์ด๋‹ค. ์šฐ๋ฆฌ๋Š” DRAM ํƒ€์ด๋ฐ ํŒŒ๋ผ๋ฏธํ„ฐ์— ์˜ํ•ด ๋กœ์šฐ activation ๋นˆ๋„๊ฐ€ ์ œํ•œ๋˜๊ณ  DRAM ์…€์ด ์ฃผ๊ธฐ์ ์œผ๋กœ ๋ฆฌํ”„๋ ˆ์‹œ ๋˜๊ธฐ ๋•Œ๋ฌธ์— ๋กœ์šฐ ํ•ด๋จธ๋ง์„ ์•ผ๊ธฐํ•  ์ˆ˜ ์žˆ๋Š” DRAM ๋กœ์šฐ์˜ ์ˆ˜๊ฐ€ ํ•œ์ •๋œ๋‹ค๋Š” ์‚ฌ์‹ค์— ์ฃผ๋ชฉํ•˜์˜€๋‹ค. ์ด๋กœ๋ถ€ํ„ฐ ์šฐ๋ฆฌ๋Š” TWiCe๊ฐ€ ํ™•์‹คํ•œ ๊ฒฐ์ •๋ก ์  ๋ฐฉ์ง€๋ฅผ ๋ณด์žฅํ•  ๊ฒฝ์šฐ ํ•„์š”ํ•œ DRAM ๋ฑ…ํฌ ๋‹น ํ•„์š”ํ•œ ์นด์šดํ„ฐ ์ˆ˜์˜ ์ตœ๋Œ€๊ฐ’์„ ๊ตฌํ•˜์˜€๋‹ค. TWiCe๋Š” ์ผ๋ฐ˜์ ์ธ DRAM ๋™์ž‘ ๊ณผ์ •์—์„œ๋Š” ์„ฑ๋Šฅ์— ์•„๋ฌด๋Ÿฐ ์˜ํ–ฅ์„ ๋ฏธ์น˜์ง€ ์•Š์œผ๋ฉฐ, ํ˜„๋Œ€ DRAM ๋””๋ฐ”์ด์Šค์—์„œ 0.7% ์ดํ•˜์˜ ์นฉ ๋ฉด์  ์ฆ๊ฐ€ ๋ฐ ์—๋„ˆ์ง€ ์ฆ๊ฐ€๋งŒ์„ ํ•„์š”๋กœ ํ•œ๋‹ค. ์šฐ๋ฆฌ๊ฐ€ ์ง„ํ–‰ํ•œ ํ‰๊ฐ€์—์„œ TWiCe๋Š” ๋กœ์šฐ ํ•ด๋จธ๋ง ๊ณต๊ฒฉ ์‹œ๋‚˜๋ฆฌ์˜ค๋ฅผ ํฌํ•จํ•œ ์—ฌ๋Ÿฌ๊ฐ€์ง€ ๋ฉ”๋ชจ๋ฆฌ ์ ‘๊ทผ ํŒจํ„ด์—์„œ 0.006% ์ดํ•˜์˜ ์ถ”๊ฐ€์ ์ธ DRAM activation์„ ์š”๊ตฌํ•˜์˜€๋‹ค. ๋˜ํ•œ TWiCe์˜ ์นฉ ๋ฉด์  ๋ฐ ์—๋„ˆ์ง€ ๋น„์šฉ์„ ๋”์šฑ ์ค„์ด๊ธฐ ์œ„ํ•˜์—ฌ, ์šฐ๋ฆฌ๋Š” threshold๊ฐ€ ์กฐ์ •๋œ ๋žญํฌ ๋‹จ์œ„ TWiCe๋ฅผ ์ œ์•ˆํ•œ๋‹ค. ๋จผ์ €, ์ˆ˜๋ฐฑ๊ฐœ๊ฐ€ ๋„˜๋Š” TWiCe ํ…Œ์ด๋ธ” ํ•ญ๋ชฉ ๊ฒ€์ƒ‰์„ ์—๋„ˆ์ง€ ํšจ์œจ์ ์œผ๋กœ ์ˆ˜ํ–‰ํ•  ์ˆ˜ ์žˆ๋Š” pa-TWiCe (pseudo-associatvie TWiCe)๋ฅผ ์ œ์•ˆํ•˜์˜€๋‹ค. ๊ทธ๋ฆฌ๊ณ , ํ…Œ์ด๋ธ” ํ•ญ๋ชฉ์„ ๋žญํฌ ๋‹จ์œ„๋กœ ๊ด€๋ฆฌํ•˜์—ฌ ํ•„์š”ํ•œ ํ…Œ์ด๋ธ” ํ•ญ๋ชฉ์˜ ์ˆ˜๋ฅผ ๋”์šฑ ์ค„์ธ ๋žญํฌ ๋‹จ์œ„ TWiCe๋ฅผ ์ œ์•ˆํ•˜์˜€๋‹ค. ๋˜ํ•œ, ์šฐ๋ฆฌ๋Š” TWiCe์˜ threshold ๊ฐ’์„ ์กฐ์ ˆํ•จ์œผ๋กœ์จ ์ผ๋ฐ˜์ ์ธ ์›Œํฌ๋กœ๋“œ ์ƒ์—์„œ ๊ฑฐ์ง“ ์–‘์„ฑ(false-positive) ํƒ์ง€๋ฅผ ์ฆ๊ฐ€์‹œํ‚ค์ง€ ์•Š๋Š” ์„ ์—์„œ TWiCe์˜ ํ…Œ์ด๋ธ” ํ•ญ๋ชฉ ์ˆ˜๋ฅผ ๋”์šฑ ์ค„์˜€๋‹ค. ๋งˆ์ง€๋ง‰์œผ๋กœ, ์šฐ๋ฆฌ๋Š” ์ปดํ“จํ„ฐ ์‹œ์Šคํ…œ์˜ ์ฃผ๊ธฐ์–ต์žฅ์น˜ ์„ฑ๋Šฅ ํ–ฅ์ƒ์„ ์œ„ํ•ด TWiCe๋ฅผ hot-page ๊ฐ์ง€๊ธฐ๋กœ ์‚ฌ์šฉํ•˜๋Š” ๊ฒƒ์„ ์ œ์•ˆํ•œ๋‹ค. ๋ฉ”๋ชจ๋ฆฌ ์ ‘๊ทผ์˜ ์‹œ๊ฐ„์  ์ง€์—ญ์„ฑ์— ์˜ํ•ด ์ตœ๊ทผ ์ž์ฃผ activation๋œ DRAM ๋กœ์šฐ๋“ค์€ ๋‹ค์‹œ activation๋  ํ™•๋ฅ ์ด ๋†’๊ณ , TWiCe๋Š” ์ตœ๊ทผ ์ž์ฃผ activation๋œ DRAM ๋กœ์šฐ์— ๋Œ€ํ•œ ์ •๋ณด๋ฅผ ๊ฐ€์ง€๊ณ  ์žˆ๋‹ค. ์ด๋Ÿฌํ•œ ์‚ฌ์‹ค์— ๊ธฐ๋ฐ˜ํ•˜์—ฌ, ์šฐ๋ฆฌ๋Š” hot-page์— ๋Œ€ํ•œ DRAM ์ ‘๊ทผ ์ง€์—ฐ์‹œ๊ฐ„์„ ์ค„์ด๋Š” DRAM ํŽ˜์ด์ง€ ์Šค์™‘(swap) ๊ธฐ๋ฒ•๋“ค์— TWiCe๋ฅผ ์ ์šฉํ•˜๋Š” ๋ฐฉ๋ฒ•์„ ๋ณด์ธ๋‹ค. ์šฐ๋ฆฌ๊ฐ€ ์ˆ˜ํ–‰ํ•œ ํ‰๊ฐ€์—์„œ TWiCe๋ฅผ ์‚ฌ์šฉํ•œ ์ €์ง€์—ฐ์‹œ๊ฐ„ DRAM์€ ๋ฉ€ํ‹ฐ ์“ฐ๋ ˆ๋”ฉ ์›Œํฌ๋กœ๋“œ๋“ค์—์„œ ๊ธฐ์กด DDR4 ๋””๋ฐ”์ด์Šค ๋Œ€๋น„ IPC๋ฅผ ์ตœ๋Œ€ 12.2% ์ฆ๊ฐ€์‹œ์ผฐ๋‹ค.Introduction 1 1.1 Time Window Counter Based Row Refresh to Prevent Row-hammering 2 1.2 Optimizing Time Window Counter 6 1.3 Using Time Window Counters to Improve Main Memory Performance 8 1.4 Outline 10 Background of DRAM and Row-hammering 11 2.1 DRAM Device Organization 12 2.2 Sparing DRAM Rows to Combat Reliability Challenges 13 2.3 Main Memory Subsystem Organization and Operation 14 2.4 Row-hammering (RH) 18 2.5 Previous RH Prevention Solutions 20 2.6 Limitations of the Previous RH Solutions 21 TWiCe: Time Window Counter based RH Prevention 26 3.1 TWiCe: Time Window Counter 26 3.2 Proof of RH Prevention 30 3.3 Counter Table Size 33 3.4 Architecting TWiCe 35 3.4.1 Location of TWiCe Table 35 3.4.2 Augmenting DRAM Interface with a New Adjacent Row Refresh (ARR) Command 37 3.5 Analysis 40 3.6 Evaluation 42 Optimizing TWiCe to Reduce Implementation Cost 47 4.1 Pseudo-associative TWiCe 47 4.2 Rank-level TWiCe 50 4.3 Adjusting Threshold to Reduce Table Size 55 4.4 Analysis 57 4.5 Evaluation 59 Augmenting TWiCe for Hot-page Detection 62 5.1 Necessity of Counters for Detecting Hot Pages 62 5.2 Previous Studies on Migration for Asymmetric Low-latency DRAM 64 5.3 Extending TWiCe for Dynamic Hot-page Detection 67 5.4 Additional Components and Methodology 70 5.5 Analysis and Evaluation 73 5.5.1 Overhead Analysis 73 5.5.2 Evaluation 75 Conclusion 82 6.1 Future work 84 Bibliography 85 ๊ตญ๋ฌธ์ดˆ๋ก 94Docto

    TRRespass: Exploiting the Many Sides of Target Row Refresh

    Full text link
    After a plethora of high-profile RowHammer attacks, CPU and DRAM vendors scrambled to deliver what was meant to be the definitive hardware solution against the RowHammer problem: Target Row Refresh (TRR). A common belief among practitioners is that, for the latest generation of DDR4 systems that are protected by TRR, RowHammer is no longer an issue in practice. However, in reality, very little is known about TRR. In this paper, we demystify the inner workings of TRR and debunk its security guarantees. We show that what is advertised as a single mitigation mechanism is actually a series of different solutions coalesced under the umbrella term TRR. We inspect and disclose, via a deep analysis, different existing TRR solutions and demonstrate that modern implementations operate entirely inside DRAM chips. Despite the difficulties of analyzing in-DRAM mitigations, we describe novel techniques for gaining insights into the operation of these mitigation mechanisms. These insights allow us to build TRRespass, a scalable black-box RowHammer fuzzer. TRRespass shows that even the latest generation DDR4 chips with in-DRAM TRR, immune to all known RowHammer attacks, are often still vulnerable to new TRR-aware variants of RowHammer that we develop. In particular, TRRespass finds that, on modern DDR4 modules, RowHammer is still possible when many aggressor rows are used (as many as 19 in some cases), with a method we generally refer to as Many-sided RowHammer. Overall, our analysis shows that 13 out of the 42 modules from all three major DRAM vendors are vulnerable to our TRR-aware RowHammer access patterns, and thus one can still mount existing state-of-the-art RowHammer attacks. In addition to DDR4, we also experiment with LPDDR4 chips and show that they are susceptible to RowHammer bit flips too. Our results provide concrete evidence that the pursuit of better RowHammer mitigations must continue.Comment: 16 pages, 16 figures, in proceedings IEEE S&P 202

    DRAM Bender: An Extensible and Versatile FPGA-based Infrastructure to Easily Test State-of-the-art DRAM Chips

    Full text link
    To understand and improve DRAM performance, reliability, security and energy efficiency, prior works study characteristics of commodity DRAM chips. Unfortunately, state-of-the-art open source infrastructures capable of conducting such studies are obsolete, poorly supported, or difficult to use, or their inflexibility limit the types of studies they can conduct. We propose DRAM Bender, a new FPGA-based infrastructure that enables experimental studies on state-of-the-art DRAM chips. DRAM Bender offers three key features at the same time. First, DRAM Bender enables directly interfacing with a DRAM chip through its low-level interface. This allows users to issue DRAM commands in arbitrary order and with finer-grained time intervals compared to other open source infrastructures. Second, DRAM Bender exposes easy-to-use C++ and Python programming interfaces, allowing users to quickly and easily develop different types of DRAM experiments. Third, DRAM Bender is easily extensible. The modular design of DRAM Bender allows extending it to (i) support existing and emerging DRAM interfaces, and (ii) run on new commercial or custom FPGA boards with little effort. To demonstrate that DRAM Bender is a versatile infrastructure, we conduct three case studies, two of which lead to new observations about the DRAM RowHammer vulnerability. In particular, we show that data patterns supported by DRAM Bender uncovers a larger set of bit-flips on a victim row compared to the data patterns commonly used by prior work. We demonstrate the extensibility of DRAM Bender by implementing it on five different FPGAs with DDR4 and DDR3 support. DRAM Bender is freely and openly available at https://github.com/CMU-SAFARI/DRAM-Bender.Comment: To appear in TCAD 202
    • โ€ฆ
    corecore