HARP: Practically and Effectively Identifying Uncorrectable Errors in Memory Chips That Use On-Die Error-Correcting Codes

Abstract

Aggressive storage density scaling in modern main memories causes increasing error rates that are addressed using error-mitigation techniques. State-of-the-art techniques for addressing high error rates identify and repair bits that are at risk of error from within the memory controller. Unfortunately, modern main memory chips internally use on-die error correcting codes (on-die ECC) that obfuscate the memory controller's view of errors, complicating the process of identifying at-risk bits (i.e., error profiling).To understand the problems that on-die ECC causes for error profiling, we analytically study how on-die ECC changes the way that memory errors appear outside of the memory chip (e.g., to the memory controller). We show that on-die ECC introduces statistical dependence between errors in different bit positions, raising three key challenges for practical and effective error profiling: on-die ECC (1) exponentially increases the number of at-risk bits the profiler must identify; (2) makes individual at-risk bits more difficult to identify; and (3) interferes with commonly-used memory data patterns that are designed to make at-risk bits easier to identify.To address the three challenges, we introduce Hybrid Active-Reactive Profiling (HARP), a new error profiling algorithm that rapidly achieves full coverage of at-risk bits based on two key insights. First, errors that on-die ECC fails to correct have two sources:(1) direct errors from raw bit errors in the data portion of the ECC word and (2) indirect errors that on-die ECC introduces when facing uncorrectable errors. Second, the maximum number of indirect errors that can occur concurrently is limited to the correction capability of on-die ECC. HARP's key idea is to first identify all bits at risk of direct errors using existing profiling techniques with the help of small modifications to the on-die ECC mechanism. Then, a secondary ECC within the memory controller with correction capability equal to or greater than that of on-die ECC can safely identify bits at-risk of indirect errors, if and when they fail.We evaluate HARP in simulation relative to two state-of-the-art baseline error profiling algorithms. We show that HARP achieves full coverage of all at-risk bits faster (e.g., 99th-percentile coverage 20.6%/36.4%/52.9%/62.1% faster, on average, given 2/3/4/5 raw bit errors per ECC word) than the baseline algorithms, which sometimes fail to achieve full coverage. We perform a case study of how each

A Deeper Look into RowHammer’s Sensitivities: Experimental Analysis of Real DRAM Chips and Implications on Future Attacks and Defenses

“…Fourth, we test DRAM modules that do not implement error correction codes (ECC) [12,21,36,41,67,124]. Doing so ensures that neither on-die [46,104,[113][114][115] nor rank-level [21,67] ECC can alter the RowHammer bit flips we observe and analyze. Fifth, we prevent known on-DRAM-die RowHammer defenses (i.e., TRR [52,55,84,93]) from working by not issuing refresh commands throughout our tests [27,71].…”

“…15 and 16 on spatial variation of HC first across subarrays can be leveraged to reduce the time required to profile a given DRAM module's RowHammer vulnerability characteristics. This is an important challenge because profiling a DRAM module's RowHammer characteristics requires analyzing several environmental conditions and attack properties (e.g., data pattern, access pattern, and temperature), requiring time-consuming tests that lead to long profiling times [20,27,71,72,78,110,111,113,166]. According to our Obsvs.…”

A Case for Transparent Reliability in DRAM Systems

“…To exacerbate the problem of identifying a de nitive error model, DRAM manufacturers are starting to incorporate two on-die error-mitigation mechanisms that correct a limited number of errors from within the DRAM chip itself: (1) on-die ECC [28,54,95,[254][255][256][257][258] for improving reliability and yield and (2) target row refresh [100,160,222,239] for partially mitigating the RowHammer vulnerability. Prior works on ECC [27,30,54,95,101,258,259,296,[320][321][322][323][324] and RowHammer [92,100,160,226] show that both on-die ECC and TRR change how errors appear outside of the DRAM chip, thereby changing the DRAM error model seen by the memory controller (and therefore, to the rest of the system). Unfortunately, both mechanisms are opaque to the memory controller and are considered trade secrets that DRAM manufacturers will not ofcially disclose [22,23,92,93,95,226,258,298].…”

“…Prior works propose two practical ways of identifying retentionweak cells: (1) active pro ling, which uses comprehensive tests to search for error-prone cells o ine [77-79, 127, 129, 135], and (2) reactive pro ling, which constantly monitors memory to identify errors as they manifest during runtime, e.g., ECC scrubbing [56,61,82]. Both approaches require the pro ler to understand the worst-case behavior of data-retention errors for a given DRAM chip [79,127]: an active pro ler must use the worst-case conditions to maximize the proportion of retention-weak cells it identi es during pro ling [78] and a reactive pro ler must be provisioned to identify (and possibly also mitigate) the worst-case error pa ern(s) that might be observed at runtime, e.g., to choose an appropriate ECC detection and correction capability [127,226,324].…”

Uncovering In-DRAM RowHammer Protection Mechanisms:A New Methodology, Custom RowHammer Patterns, and Implications

“…Further, we find that 1) over 99.9% of the DRAM rows are vulnerable (i.e., have at least one bit flip) to the new access patterns and 2) the new access patterns cause up to 9.4 million bit flips per DRAM bank. The large number of RowHammer bit flips caused by our specialized access patterns has significant implications for systems protected by Error Correction Codes (ECC) [47,92,93,95]. Our analysis shows that the U-TRR-discovered access patterns can cause up to 7 bit flips at arbitrary locations in one 8-byte dataword, suggesting that typical ECC schemes capable of correcting one error/symbol and detecting two errors/symbols (e.g., SECDED ECC [10,37,43,60,61,79,87,118] and Chipkill [2,20,86]) cannot provide sufficient protection against RowHammer even in the presence of TRR mechanisms.…”