Detecting and mitigating memory attacks

Abstract

The present disclosure relates to systems and methods implemented on a memory controller for detecting and mitigating memory attacks (e.g., raking attacks). For example, a memory controller may track activation of a row address within memory hardware (e.g., a DRAM device), and determine whether a pattern of activation indicates a row hammer attack. This is determined using a count pattern for the corresponding memory sub-library. In the event that a possible row hammer attack is detected, the memory controller may activate a sampling mode (rather than a count mode) for a particular sub-library to identify which row addresses should be refreshed on the memory hardware. Implementations described herein provide an alternative to low computational cost that can accurately detect and mitigate ramming attacks as compared to strict detection mechanisms that require access to a large number of computing resources.

Description

Background Art

[0001] Recent years have seen an increase in the use of computing devices (e.g., mobile devices, personal computers, server devices, cloud computing systems) for receiving, storing, editing, transmitting, processing, or otherwise utilizing digital data for various processing applications and services. Indeed, it is now common for individuals and businesses to adopt cloud computing architectures and computing resources on various computing devices. As the demand for memory resources grows, memory resources continue to expand in availability and complexity across various computing platforms.

[0002] In some memory systems, many security exploits have been used to take advantage of unintended and / or undesired side effects in dynamic random access memory (DRAM) hardware. For example, some malicious actors have found ways to damage data in memory cells by using row hammer attacks. These attacks typically involve activating one or more memory rows multiple times in rapid succession to cause charge from nearby memory cells to leak and ultimately damage the data on them. Furthermore, as DRAM manufacturing processes continue to shrink, row hammer attacks have the potential to affect a larger number of memory cells.

[0003] Detecting and mitigating row hammer attacks presents significant challenges to memory systems. For example, conventional approaches often involve expending significant processing resources (e.g., memory hardware) to accurately identify specific aggressor rows (i.e., rows with high activation rates) or victim rows (i.e., rows under attack). Alternatively, where conventional systems do not dedicate significant hardware resources to identifying and preventing row hammer attacks, these systems may easily become overwhelmed, particularly where the hardware is operated outside of normal operating conditions or accessed in unusual ways.

[0004] These and other problems exist in connection with detecting and mitigating memory attacks, and in particular with respect to detecting and mitigating row hammer attacks. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 An example computing device environment is shown that includes a memory system having a memory controller including a row hammer detection system implemented thereon.

[0006] Figure 2 An example implementation of access count records showing the recording of counts of corresponding row addresses across multiple memory sub-banks is shown.

[0007] Figure 3An example access count table for a memory sub-bank represented within an access count record is shown in accordance with one or more embodiments.

[0008] Figure 4 A series of example actions for determining whether a possible attacker row exists for a given memory subset is shown.

[0009] Figure 5 A series of example actions are shown for activating and implementing a sampling mode based on determining that a given memory sub-bank is in a possible attacker row.

[0010] Fig. 6A An example refresh command record is shown showing a count of refresh commands generated and issued by a memory controller over a predetermined period of time.

[0011] Figure 6B A series of example actions are shown for determining whether to issue a refresh command based on information from a refresh command record.

[0012] Figure 7 A series of actions for detecting and mitigating a row hammer attack in a memory system is shown in accordance with one or more embodiments.

[0013] Figure 8 Some components that may be included in a computer system are shown. DETAILED DESCRIPTION

[0014] The present disclosure generally relates to detecting and mitigating memory attacks (e.g., row hammer attacks) on memory systems. For example, one or more embodiments described herein relate to features and functions implemented by a memory controller to track (e.g., read) activations of memory addresses (e.g., row addresses) within memory hardware (e.g., dynamic random access memory (DRAM)) and determine whether a pattern of accesses indicates a row hammer attack.

[0015] As will be discussed in further detail herein, the memory controller may implement an access count mode that involves tracking a count of instances in which a particular memory row address is activated over a period of time, and predicting whether a row hammer attack is occurring for a given memory sub-bank based on the tracked counts. Upon determining that a row hammer attack may be occurring (e.g., based on certain counts exceeding a threshold), the memory controller may activate a sampling mode for the memory sub-bank in which a random number is compared to a sampling threshold to determine whether a particular row address is reported as an attacker row address involved in a row hammer attack.

[0016] As an illustrative example, the present disclosure describes a row hammer detection and mitigation system (or simply "row hammer detection system" as used herein) for detecting and mitigating row hammer attacks on one or more memory rows of a dynamic random access memory (DRAM) device. In one or more embodiments, the row hammer detection system may maintain an access count table for a memory sub-bank (e.g., each of a plurality of sub-banks), the access count table including a plurality of access counts for memory addresses (e.g., row addresses) of the memory sub-bank, and a spillover count indicating access counts for one or more memory addresses that are not represented by a plurality of access counts for the corresponding memory addresses. As used herein, an access count may refer to an activation count, or more specifically, to a row activation count for a corresponding row of a memory. Thus, while one or more embodiments described herein specifically relate to access counts, it will be understood that this may specifically refer to a row activation count or a count of row activations for a given row address.

[0017] The row hammer detection system can consider the values ​​from the access count table to determine (e.g., predict) that a row hammer attack is occurring (or may occur) and take appropriate action. For example, in one or more embodiments described herein, the row hammer detection system can determine that an overflow count from the access count table exceeds a threshold count, and activate a sampling mode for a memory sub-bank based on the overflow count exceeding the threshold. As will be discussed in further detail below, the row hammer detection system can activate the sampling mode by generating (multiple) random numbers and determining whether the (multiple) random numbers fall within a sampling threshold. In the event that the (multiple) random numbers fall within a predetermined threshold, the row hammer detection system can report the memory row address as a possible attacker row in a row hammer attack. Additional details will be discussed below in conjunction with various examples.

[0018] The present disclosure includes many practical applications that provide benefits and / or solve problems associated with detecting and mitigating rowhammer attacks occurring on memory sub-banks of memory hardware. Examples of some of these applications and benefits are discussed below.

[0019] For example, by switching between access counting mode (or simply "counting mode") and sampling mode, the row hammer detection system can provide a low computational cost alternative to maintaining expensive and robust activation records for one or more memory banks. In fact, where conventional approaches typically involve maintaining extensive records of access instances for one or more entire memory banks to ensure that a specific instance of a row hammer attack is detected, the row hammer detection system uses a hybrid scheme to switch between counting mode and sampling mode to predict that a row hammer attack may be occurring and allow the row hammer detection system to identify the location of the attack within an acceptable amount of time.

[0020] In addition, the row hammer detection system can track activations at the sub-bank level, rather than tracking access counts for the entire memory system or the entire memory bank. This smaller-scale tracking approach allows the row hammer detection system to maintain access counts using smaller count tables maintained for the corresponding memory sub-banks. Tracking and detecting row hammer attacks at the sub-bank level allows the row hammer detection system to activate its sampling mode when the associated sub-bank is overloaded, while allowing the counting mode to be used to monitor other sub-banks. In addition, features of the system described herein reduce the associativity of the tables from potentially thousands to a smaller number (e.g., 16, 32), while reducing the total number of counters (e.g., by a factor of 20 or 30). This reduced associativity additionally enables the system described herein to meet performance requirements of storage controllers, which is difficult or impossible with conventional approaches.

[0021] As described above, and as will be discussed in further detail below, one or more embodiments described herein relate to the implementation of a hybrid scheme in which a memory controller switches between a counting mode and a sampling mode when detecting a potential row hammer attack. This hybrid approach enables the memory controller to maintain an access count table without consuming or occupying a large amount of memory resources required by conventional approaches. For example, where conventional approaches that rely exclusively on a heavy-hitting counting mode require 10 megabytes (MB) of static random access memory (SRAM) to reliably detect a row hammer attack instance, the approach described herein involves a smaller scale of SRAM resources to track access counts across multiple memory sub-banks. In fact, the features of the row hammer detection system regarding the implementation of a hybrid detection scheme at the sub-bank level can reduce the amount of SRAM required to detect and mitigate row hammer attacks for memory banks of similar size to 1 / 100 or 1 / 1000 of that of conventional approaches. In fact, as described above, implementing the hybrid scheme described herein can reduce the number of counters by 20 times, 30 times, or more, compared to conventional approaches.

[0022] In addition, features of the row hammer detection system reduce computational and hardware overhead on the storage controller while still maintaining an extremely low probability of missing a row hammer attack. For example, by identifying specific memory sub-banks that may be affected by a row hammer attack, and then selectively activating a sampling mode for the memory sub-banks, the row hammer detection system can implement the sampling mode on a sub-bank level without disrupting the operation of other sub-banks of the memory hardware. This allows the row hammer detection system to implement the sampling mode on a smaller portion of the memory hardware using a sampling threshold that is almost guaranteed to find and prevent a row hammer attack before causing data corruption on nearby memory cells.

[0023] Additionally, as will be discussed in further detail below, one or more embodiments described herein include features and capabilities that allow for detection and mitigation of row hammer attacks without requiring memory hardware to be shared or making all hardware and topology information available to the memory controller. For example, by identifying specific rows of memory (and / or blast radius) that are predicted to be attacker rows in a row hammer attack, the row hammer detection system can issue a command to the memory hardware that allows the memory hardware to take steps locally and mitigate the identified row hammer attack. As described above, this command can be issued without requiring the hardware to share certain information with the memory controller that the hardware vendor wishes to avoid sharing. Additionally, this allows the row hammer detection system to be implemented on memory controllers across a variety of hardware architectures to detect and mitigate a variety of memory attacks across different computing devices.

[0024] As indicated in the foregoing discussion, the present disclosure utilizes various terms to describe the features and advantages of the systems herein. Additional details are now provided regarding the meaning of some example terms.

[0025] For example, a "computing device" may refer to a computing node, a server node, a host device, or any electronic device having memory hardware (or accessible memory hardware) thereon. In one or more embodiments described herein, a computing device may refer to a server device on a network of connected network devices (e.g., a cloud computing system). Alternatively, a computing device may refer to a mobile or non-mobile device, such as a laptop, desktop, phone, tablet, or other device that can access the memory resources of one or more memory devices. Figure 8 Additional details regarding some general features and functions of computing devices are discussed.

[0026] As used herein, "memory hardware" or "memory resource(s)" may refer to accessible memory across one or more computing devices. For example, memory hardware may refer to a local memory storage device having memory blocks accessible to an application or operating system on a computing device. Memory hardware may refer to memory managed by one or more integrated memory controllers (or simply "memory controllers"), which are co-located on a memory system or otherwise implemented on a computing device. A memory device may refer to any memory resource managed by a memory controller, including local, external, remote, or pooled memory accessible to one or more computing devices. In fact, memory hardware may refer to any memory device managed by a memory controller.

[0027] Memory hardware may refer to memory resources of various memory types. For example, in one or more embodiments described herein, a memory device may refer to a dynamic access memory (DRAM), a static random access memory (SRAM), a flash memory, or other non-persistent memory source. In one or more embodiments, a memory system includes a dual in-line memory module (DIMM) device (or other device type) that provides accessible memory sources. In one or more embodiments, a memory device may include multiple memory banks that provide partial memory resources to various applications or processes.

[0028] As used herein, a "memory bank" may refer to a memory unit on memory hardware. For example, a memory bank may refer to a logical partition of memory divided across multiple chips on a memory system. In one or more specific examples described herein, a memory bank refers to one of a plurality of similarly sized memory banks representing corresponding portions of memory hardware. For example, in one or more embodiments, the memory hardware includes sixty-four (64) memory banks, each memory bank including eight (8) sub-banks. As used herein, a memory sub-bank may refer to a portion (e.g., a subset) of memory resources from a corresponding memory bank. It should be understood that while one or more embodiments are described herein in conjunction with memory hardware having a specific number (e.g., 64) of memory banks, and each memory bank includes eight memory sub-banks, other implementations may include any number of memory banks, wherein one or more of the memory banks include a variable number of multiple memory sub-banks. It should also be understood that a memory bank and a corresponding memory sub-bank may refer to memory resources of various different sizes.

[0029] As will be discussed below in conjunction with examples, a memory controller can track counts of row activations (e.g., memory activations) across multiple memory sub-banks. In one or more embodiments, the memory controller can perform this tracking of access counts while operating in a counting mode. As used herein, "counting mode" refers to an operating mode of the memory controller relative to a corresponding memory sub-bank in which the memory controller tracks counts of row activations of the memory sub-bank. For example, as will be discussed below, a row hammer detection system can maintain an access count table that includes multiple counts of corresponding memory addresses (e.g., memory row addresses). The access count table can additionally include an overflow count.

[0030] In one or more embodiments, the row hammer detection system may cause the memory controller to switch to a sampling mode or otherwise activate a sampling mode. As used herein, "sampling mode" refers to an operating mode of the memory controller relative to a corresponding memory sub-bank in which the memory controller generates a random number for an activated row and compares the random number to a sampling threshold. Based on the comparison, the memory controller may report an address / row by generating and issuing a refresh command that indicates a memory address as a predicted attacker row for a row hammer attack. After resolving the row hammer attack, the memory controller may return to sampling mode for the corresponding memory sub-bank.

[0031] Additional details regarding example features and functionality of the hammer detection system will now be provided in relation to the illustrative diagrams depicting example implementations. Specifically, Figure 1 An example implementation of a computing device 102 is shown having an operating system 104 thereon. The computing device 102 may refer to any of the various computing devices discussed above. Additionally, the operating system 104 may refer to a system for managing software and hardware on the computing device 102. In addition to conventional features of conventional operation, one or more embodiments of the operating system 104 may facilitate switching between a memory controller operating in a counting mode or a sampling mode. Further details regarding switching a memory controller between operating modes will be discussed below.

[0032] like Figure 1 As further shown, the computing device(s) 102 include a memory system 106. The memory system includes a memory controller 108 and memory hardware 120. In addition to the features that will be discussed in conjunction with detecting and mitigating row hammer attacks, the memory controller 108 can generally control the flow of data into and out of the memory hardware 120. For example, the memory controller 108 can manage read and write operations to the memory hardware 120. The memory controller 108 can also track and manage data associated with reads and writes to the memory hardware 120. The memory controller 108 can also implement error detection and correction features with respect to memory resources on the memory hardware 120.

[0033] As described above, and as will be discussed in further detail below, the memory controller 108 may provide features related to detecting and mitigating row hammer attacks on the memory hardware 120. For example, Figure 1 As shown, the memory controller 108 includes a hammer detection system 110. As will be discussed in further detail below, the hammer detection system 110 can implement features and functions related to detecting and mitigating hammer attacks. As described above, the hammer detection system 110 can implement various operating modes in detecting and mitigating hammer attacks.

[0034] like Figure 1 As shown, the row hammer detection system 110 may include a counting mode manager 112. The counting mode manager 112 may implement a counting mode in which a count of addresses (e.g., row addresses) is maintained in an access count table of a plurality of memory sub-banks on the memory hardware 120. Specifically, the counting mode manager 112 may determine an estimated count of a plurality of row addresses of a corresponding memory sub-bank, and determine whether a particular sub-bank is overwhelmed by a potential row hammer attack based on the estimated activation count and the corresponding overflow account number. Additional details related to the counting mode will be discussed in detail below.

[0035] like Figure 1 As further shown, the row hammer detection system 110 may include a sampling pattern manager 114. The sampling pattern manager 114 may implement a sampling pattern for one or more memory sub-banks that may become overwhelmed when maintaining access counts within corresponding access count tables. In particular, upon detecting a potential row hammer attack for an address (e.g., a row address) of an associated memory sub-bank, the sampling pattern manager 114 may apply a sampling pattern in which a random number is generated for each memory row access and the random number is compared to a sampling threshold. Based on the comparison, the sampling pattern manager 114 may estimate that a row hammer attack is occurring at the associated memory address and generate a refresh command to send to the memory hardware 120. Additional details regarding the sampling pattern are discussed in detail below.

[0036] like Figure 1 As shown, the row hammer detection system 110 may include a plurality of sub-bank count tables 116. The sub-bank count tables 116 may include records of memory addresses (e.g., row addresses) for associated time periods and corresponding row activation accounts. The sub-bank count tables 116 may additionally include overflow counts for each corresponding sub-bank. As will be discussed in further detail below, the row hammer detection system 110 (e.g., the count pattern manager 112) may consider the counts of the corresponding row addresses in conjunction with the overflow counts to determine whether an address from a particular sub-bank has an attacker memory address (e.g., an attacker row) that is part of a row hammer attack.

[0037] like Figure 1As shown, the row hammer detection system 110 may additionally include a plurality of refresh command tables 118. As described above, upon detecting a row hammer attack and identifying a possible attacker row, the row hammer detection system 110 may submit a refresh command to the memory hardware 120 that enables the memory hardware to mitigate the row hammer attack. In one or more embodiments described herein, the row hammer detection system 110 may additionally maintain a record of refresh commands provided to the memory hardware 120. Such a refresh command table 118 may be used to limit the number of refresh commands executed on a corresponding row address of the memory hardware 120. This enables the row hammer detection system 110 to comply with hardware specifications while avoiding scenarios where refresh commands may interrupt normal operation of the memory controller 108 and the memory hardware 120.

[0038] As mentioned above, the memory system 106 includes memory hardware 120 that provides memory resources to any of the various applications managed by the operating system 104. As described above, the memory controller 108 may provide access to and control of the flow of data between the operating system 104 and the memory hardware 120. Figure 1 As shown, the memory hardware 120 may include a plurality of memory banks 122 , each memory bank including a plurality of memory sub-banks 124 .

[0039] Although one or more embodiments described herein refer to an implementation of the memory hardware 120 including a particular number of memory banks 122 and corresponding sub-banks 124, it should be understood that the memory hardware 120 may include any number of memory banks and associated sub-banks. As described above, a memory bank may refer to a logical partition of memory resources from the memory hardware 120, wherein a memory sub-bank refers to a subset of the memory resources of a corresponding memory bank. In one or more embodiments described herein, the memory hardware 120 includes sixty-four memory banks, each with a set of eight associated memory sub-banks. These memory banks and associated sub-banks may represent resources of similar size, or alternatively, these memory banks and associated sub-banks may be of different sizes within the memory hardware 120.

[0040] Although Figure 1Example implementations of a computing device 102 are shown in accordance with one or more embodiments, but it should be understood that other implementations described herein may be implemented on different environments of computing device(s). For example, in one or more embodiments, the computing device(s) 102 may include multiple memory systems (e.g., pooled memory systems) implemented on different memory devices that are accessible by one or more applications or virtual machines hosted by the computing device(s). In one or more embodiments, the environment may include multiple computing devices that may access memory resources on a single memory system. In each implementation, the memory hardware 120 may be managed by a corresponding memory controller 108 having a hammer detection system 110 implemented thereon.

[0041] As described above, the row hammer detection system 110 (eg, the counting mode manager 112 ) may implement a counting mode to track activation counts of corresponding memory sub-banks 124 from a plurality of memory banks 122 on the memory hardware 120 . Figure 2 An example implementation is shown that illustrates an access count record 202 within which access counts for row addresses on the memory hardware 120 are maintained.

[0042] like Figure 2 As shown, the access count record 202 includes an entry record, which includes a row address and a corresponding activation count. For example, the access count record 202 includes a plurality of entry columns 204a-n, which include M rows. As will be discussed in further detail below, each row of a different column is associated with a corresponding memory sub-bank. In addition, each entry column in the plurality of entry columns 204a-n corresponds to a parallel channel of a memory structure within the memory controller 108.

[0043] For example, in one or more embodiments, the number of entry columns 204a-n is based on a number of parallel channels capable of reading all address values ​​(e.g., all 16 address values) in parallel. In one or more embodiments described herein, the access count record 202 is maintained within a static random access memory (SRAM) structure having sixteen parallel access points (e.g., sixteen parallel channels). In one or more embodiments, the size of the access count table is determined based on the parallel capabilities of the SRAM structure. Thus, while one or more embodiments describe a row with sixteen entries representing estimated activation counts for corresponding memory subbanks, other implementations may have fewer or additional entries based on an SRAM structure with additional parallel channels.

[0044] like Figure 2As shown, a plurality of entry columns 204a-n include columns of memory addresses 206a-n and corresponding access counts 208a-n. For example, a first entry column 204a may include a first set of addresses 206a and a corresponding first set of access counts 208a. The first set of addresses 206a may include row addresses from different sub-banks and associated access counts 208b, which indicate an estimated activation count for the corresponding row addresses. Similarly, a second access column 204b may include a second set of addresses 206b and a corresponding second set of access counts 208b. The access columns 204a-n may include any number of addresses and corresponding access counts, up to an Nth set of addresses 206n and a corresponding Nth set of access counts 208n.

[0045] In addition to the addresses 206a-n and the corresponding access counts 208a-n, the access count record 202 may include an overflow column 210 that indicates an overflow count for each row of the access count record 202 corresponding to the corresponding memory sub-bank. For example, the first row of the access count record 202 may include a first overflow count, the second row of the access count record 202 may include a second overflow count, and so on. As described above, in the case where the memory hardware 120 includes sixty-four memory banks and each memory bank includes eight memory sub-banks, the access count record 202 may include five hundred and twelve rows, each row representing a corresponding memory sub-bank. It will also be noted that each entry of the corresponding sub-bank is associated with a different entry column 204a-n accessible via different parallel channels of the memory controller hardware. This parallelism allows for rapid access and updating of the corresponding entry within the access count record 202.

[0046] Figure 2 Additionally shown is an example row activation command 201 according to one or more embodiments. In the example shown, the row activation command 201 includes a row address 203 and a sub-bank identifier 205. The row activation command 201 is sent by the memory controller 108 when accessing a row. In the example shown, the sub-bank identifier 205 corresponds to the three least significant bits of the row activation command 201, and the least significant bits are used to identify the corresponding sub-bank. As described above, each row of the access count record 202 corresponds to a sub-bank. Therefore, the three least significant bits can be used to identify a specific row of the access count record 202. Then, when updating one or more entries in the corresponding row of the access count record 202, the row address 203 can be evaluated and considered. Figure 3 An example access count table for a corresponding sub-bank is shown to discuss additional information regarding which entry to update or increment the overflow count.

[0047] As mentioned above, Figure 2As shown, each row of the access count record 202 refers to the access count table of the associated memory sub-bank. In addition, as discussed above, upon receiving the row activation command 201, the row hammer detection system 110 can update the corresponding row of the access count record 202 (e.g., based on the sub-bank identifier 205 included in the row activation command 202). To further illustrate the process for updating a row from the access count record 202, additional information will be discussed in conjunction with an example row 212 of the access count record 202 corresponding to the first sub-bank represented in the access count record 202. As an example, in Figure 3 An example row 212 of entries is further shown in the example access count table shown.

[0048] Figure 3 2 shows an example access count table 302 according to one or more embodiments described herein. As described above, the access count table 302 can refer to an example row (e.g., the example row 212) from the access count record 202. Specifically, the access count table 302 can include multiple entries, each entry corresponding to a respective channel of an associated row from the access count record. Thus, as Figure 3 As shown, the access count table 302 may include a first row (including addresses and counts of the first row from the first channel (channel 0)), a second row (including addresses and counts of the first row from the second channel (channel 1)), and so on, until the Nth entry (including addresses and counts of the first row from the Nth channel (channel N)).

[0049] like Figure 3 As shown, the access count table 302 may include a plurality of entries, the entries including a first column address 304 and a second column count 306. In addition, the access count table 302 may include an overflow entry 308 indicating an overflow count of the access count table 302.

[0050] Although Figure 3 An example access count table 302 is shown including a table with sixteen entries and an overflow count, but the access count table 302 may include any number of entries to track estimates of access counts associated with corresponding addresses. In the example shown, the number of entries in the access count table 302 may correspond to the number of parallel channels from the SRAM structure on the memory controller 120. In other implementations, the access count table 302 may include additional or fewer entries based on the hardware specifications of the memory controller 120 (e.g., the size of the SRAM structure).

[0051] It will also be noted that the counts of the corresponding addresses represent estimated counts of the associated addresses. For example, because the number of entries that the access count table 302 may include is much less than the number of row addresses of the corresponding sub-bank, when an activation command (e.g., activation command 201) is detected, the access count table 302 may dump certain addresses from the access count table 302. Figure 4 Additional details discussing how to update the access count table 302 are provided in greater detail.

[0052] Specifically, Figure 4 A series of example actions 400 for updating corresponding entries of a corresponding access count table are shown. More specifically, Figure 4 An example implementation is shown in which the row hammer detection system 110 maintains access counts for the corresponding memory sub-bank when in counting mode. In one or more embodiments, the row hammer detection system 110 enables the counting mode for each memory sub-bank by default. The row hammer detection system 110 can implement a series of actions 400 for each row activation command received when in counting mode.

[0053] like Figure 4 As shown, the row hammer detection system 110 may perform an act 402 of detecting activation of a next address. For example, in one or more embodiments, the row hammer detection system 110 may receive, detect, or otherwise identify a row activation command indicating a sub-bank and an associated address (e.g., a row address). In one or more embodiments, the row hammer detection system 110 may identify a particular access table (e.g., the access count table 302) to be updated (e.g., a particular row of the access count record 202) based on a sub-bank identifier included in the row activation command.

[0054] Upon detecting activation of the next address, the row hammer detection system 110 may first perform an action 404 of determining whether an address in the memory sub-bank is available within the associated access table. For example, the row hammer detection system 110 may compare the address portion of the row activation command to a set of addresses in the first column of the access count table and determine whether one of the addresses matches the address from the row activation command. In the event that the address matches an existing address within the access count table (e.g., "yes" at action 404), the row hammer detection system 110 may perform an action 410 of incrementing a count of row entries (of matching addresses). In other words, the row hammer detection system 110 may increment an estimated count of matching addresses within the access count table. Figure 4 As shown, after incrementing the count of the row entry, the row hammer detection system 110 may return to perform action 402 regarding the next row activation.

[0055] Alternatively, in the event that the hammer detection system 110 determines that the address does not match an existing address in the access count table (e.g., "No" at action 404), the hammer detection system 100 may perform additional steps related to updating the access count table. Figure 4 As shown, the row hammer detection system 110 can perform an action 406, which determines whether any count within a table entry of the access count table is equal to the overflow count. More specifically, the row hammer detection system 110 can query the counts of the table, and if any count of the corresponding address is equal to the overflow count, the row hammer detection system 110 can perform an action 408, which inserts the address of the detected row activation into the address field of the corresponding entry (or one of the address fields with a count that matches the overflow count). The row hammer detection system 110 can then proceed to perform an action 410 of incrementing the count of the new row entry. Figure 4 As shown, after incrementing the count of the row entry, the row hammer detection system 110 may return to perform action 402 regarding the next row activation.

[0056] Returning to act 406, in which the row hammer detection system 110 determines that there is no table entry equal to the overflow count, the row hammer detection system 110 may perform an act 412 of incrementing the overflow count. As is apparent from the illustrated series of acts 400, the overflow count should generally be the lowest count (or equal to the lowest count) of any entry within the access table. Furthermore, it should be noted that one of the entries (e.g., the address count or the overflow count) should be incremented with each row activation. Furthermore, while an entry within the access count table may be replaced with any address of the corresponding sub-bank (e.g., as indicated by act 408), it will be appreciated that the specific count of the corresponding address within the access count table reflects an upper limit estimate of the address represented within the access count table at any time. Thus, while the access count does not necessarily reflect the exact number of activations for a particular row address, the access count does represent an upper limit estimate for the corresponding row address.

[0057] like Figure 4 As shown, the row hammer detection system 110 may perform an action 414, which determines whether the overflow count of the access count table is greater than (or equal to) the threshold count. In the event that the overflow count does not exceed the threshold count, the row hammer detection system 110 may return to perform an action 402 regarding the next row activation. Conversely, in the event that the overflow count is greater than (or equal to) the threshold count, the row hammer detection system 110 may perform an action 416 of activating the sampling mode. Additional information related to implementing the sampling mode is discussed below.

[0058] It should be noted that the overflow count may be considered as a metric for determining whether the counting method is becoming overwhelmed due to a potential row hammer attack. In one or more embodiments, an overflow count being equal to or above a threshold count may not mean that a row hammer attack has necessarily occurred, but rather that a row hammer attack may be occurring (or expected to occur) based on abnormal read or write behavior that the counting mode is not fully equipped to handle. This may be caused by a row hammer attack, or alternatively, may also be caused by other read and / or write behavior with respect to row addresses of a particular sub-bank.

[0059] Although Figure 4 4. Although not shown, it is understood that the series of actions 400 may be performed relative to a certain time interval. For example, in one or more embodiments, the access count table may be periodically cleared, which may include resetting the access count and the overflow count to zero. The hammer detection system 110 may determine the specific time interval based on the specifications of the memory hardware 120 and / or the hardware (e.g., SRAM structure) of the memory controller 108.

[0060] Although the clearing interval may vary from system to system, in one or more embodiments described herein, the row hammer detection system 110 relies on the specifications or generation of the DRAM hardware to reset the counts of the access count table for each refresh window (e.g., 32 milliseconds in DDR5, 64 milliseconds in DDR4). In one or more implementations, the row hammer detection system 110 resets the access counts of the associated memory sub-bank based on determining that the row hammer detection device 110 is in the counting mode of the corresponding sub-bank after a predetermined time interval has passed. Therefore, in one or more examples described herein, after 32 milliseconds have passed without the overflow count hitting or exceeding the threshold and triggering the activation of the sampling mode, as described above in conjunction with Figure 4 As discussed, the row hammer detection system 110 may assume that the associated storage sub-bank is not currently experiencing a row hammer attack, and reset the count and continue tracking the count. In one or more embodiments, the row hammer detection system 110 uses a counter invalidation register (CIR) on the memory controller 108 to clear the counter of the access count table.

[0061] Furthermore, it should be understood that the access counters may not be cleared at the same time for each sub-bank. For example, the intervals between different sub-banks may be staggered. Some sub-banks may have different intervals than other sub-banks. Furthermore, as described above, in the event that the hammer detection system 110 has activated the sampling mode for a given sub-bank, the hammer detection system 110 may not reset the count for the associated sub-bank at the end of the predetermined interval. In one or more implementations, the hammer detection system 110 may wait to receive a specific instruction (e.g., from the memory hardware 120 or the operating system 104) to switch back to the counting mode for the memory sub-bank.

[0062] Figure 5 1 shows a series of example actions 500 that the hammer detection system 110 may implement in response to detecting a trigger condition associated with switching from the counting mode to the sampling mode. For example, the hammer detection system 110 may implement a series of actions 500 for a particular sub-bank based on detecting that the overflow count equals or exceeds a threshold value within a given time interval (e.g., Figure 4 shown).

[0063] like Figure 5 As shown, the row hammer detection system 110 can perform an action 510 of activating a sampling mode. In one or more embodiments, activating the sampling mode involves determining one or more thresholds and parameters associated with implementing the sampling mode. For example, the row hammer detection system 110 can define a sampling threshold that can be compared to a random number. In one or more embodiments, the sampling threshold is determined based on a maximum activation count (MAC) that the memory hardware 120 is configured to tolerate before a binary bit value changes due to a row hammer attack. For example, as mentioned above, a MAC can refer to a metric that measures the number of activations that a row can maintain until a binary bit in an adjacent row (or within a certain blast radius) flips (e.g., from 0 to 1 or from 1 to 0).

[0064] As described above, the sampling threshold may vary based on the specifications of the memory hardware 120 and / or the memory controller 108. As further mentioned above, the MAC value may be considered when determining a particular threshold and the probability that a given random number will fall within the sampling threshold. In one or more embodiments, the threshold is set to MAC / 4.4 based on the assumption that a row hammer attack can affect up to four rows. Other implementations may determine slightly different thresholds based on similar (or different) considerations specific to the memory hardware 120. As described above, the MAC value may vary from device to device. Nevertheless, despite the variable MAC value, sampling threshold, and sampling probability register value, it will be understood that one or more embodiments described herein may achieve a row hammer failure rate of less than 1e-10 over a five-year lifespan of the memory hardware 120.

[0065] In addition to setting the sampling threshold, the hammer detection system 110 may activate the sampling mode by setting the always sampling register (ASR) to an "on" value. Figure 4 and Figure 5 Although not explicitly shown in FIG. 1 , in one or more embodiments, the hammer detection system 110 may first check the ASR bit to determine whether the hammer detection system 110 is based on a counting mode (e.g., Figure 4 ) to perform actions, or, alternatively, according to a sampling mode (e.g., as Figure 5) to perform an action. Thus, where the row hammer detection system 110 can be configured to check the ASR bit in response to each detected row activation, the ASR bit can act as a signal or trigger to implement one of the corresponding operating modes (i.e., counting mode or sampling mode). Thus, in this example, setting the ASR value to "on" will trigger the sampling mode for each subsequently detected activated row until the row hammer detection system 110 receives an instruction to re-enable the counting mode.

[0066] As described above, in one or more embodiments, the sampling mode is activated for a particular memory sub-bank. In fact, in one or more examples described herein, the decision to switch between the counting mode and the sampling mode will be performed on a sub-bank-by-sub-bank basis. Thus, in the case where the sampling mode is activated for a first sub-bank, the row hammer detection system 110 can continue to maintain access counts for other memory sub-banks of the same memory bank (and other memory banks) while implementing the sampling mode for the first memory sub-bank. In one or more embodiments, the row hammer detection system 110 can simultaneously execute the sampling mode on multiple sub-banks while implementing the counting mode on other (multiple) memory sub-banks.

[0067] When the sampling mode is activated and the relevant parameters, sampling thresholds, and other values ​​are set, the row hammer detection system 110 can perform an action 520 of detecting activation of the next address. For example, similar to one or more embodiments described above, the row hammer detection system 110 can identify an activation command including a corresponding address and a sub-bank identifier. As discussed above, the row hammer detection system 110 can identify the relevant sub-bank based on the sub-bank identifier from the activation command.

[0068] like Figure 5 As shown, the hammer detection system 110 may perform an act of generating a random number 530. In one or more embodiments, the hammer detection system 110 generates the random number using a linear feedback shift register (LFSR) (or other more robust mechanism) on the memory controller 108. As described above, when the sampling mode is activated and various thresholds and parameters of the sampling mode are determined, a range of potential random numbers may be determined.

[0069] As further shown, the hammer detection system 110 can perform an action 540 of determining whether the random number is within a sampling threshold. As described above, the sampling threshold can be determined when the sampling mode is activated. In at least one example described herein, the random number is compared to a sampling probability register (SPR) value. The implementation of the source of randomness can determine the specific value of the sampling threshold (e.g., how large the SPR value needs to be).

[0070] As described above, the specific value(s) and threshold of the SPR may be determined based on the hardware specifications of the memory controller 108 and the acceptable probability that a given row hammer attack may not be mitigated before causing data corruption. In particular, the sampling threshold(s) may be determined to achieve a failure rate equal to or below a threshold. In one or more embodiments described herein, the sampling threshold may be determined based on a maximum activation count (MAC) metric that measures the number of activations that a row can maintain until bits in an adjacent row (or nearby) begin to flip. The MAC value may represent the minimum number of records of activations of a given row that cause bits in a nearby row (e.g., an adjacent row) to flip. In one or more embodiments described herein, the MAC value may refer to approximately 1000. However, other memory hardware 120 may have different MAC values, which will result in different sampling thresholds (e.g., as indicated in the table above).

[0071] like Figure 5 As shown, in the case where the random number is not within the sampling threshold, the row hammer detection system 110 can return to act 520 and detect the activation of the next row address. In this case, the row hammer detection system 110 may not issue a refresh command for the given row address. Conversely, in the case where the row hammer detection system 110 determines that the random number is within the sampling threshold, the row hammer detection system 110 can perform act 550 of generating a refresh command.

[0072] A refresh command may include any command sent from the memory controller 108 to the memory hardware 120 to facilitate refreshing one or more rows of memory corresponding to a suspected row hammer attack. For example, in one or more embodiments, the refresh command includes a command indicating a specific row or range of rows and instructions that enable the memory hardware 120 to locally execute the refresh command on the specific row of memory. In one or more embodiments, the refresh command is a directed refresh management (DRFM) command with a hardware specific scheme (e.g., a double data rate (DDR) scheme such as DDR5) in which the memory controller reports the identity of the aggressor row and requests the memory hardware 120 (e.g., DRAM devices) to refresh all victims affected by a given aggressor row.

[0073] In one or more embodiments, the refresh command includes an indication of a blast radius. For example, the row hammer detection system 110 may generate and issue a refresh command that indicates a row suspected of being an aggressor row, and a blast radius that defines a predetermined number of rows (e.g., two rows) at a threshold distance from the aggressor row. The blast radius may indicate the aggressor row and the row(s) on either side of the aggressor row within the threshold distance as row addresses that should be refreshed in response to the refresh command. In one or more embodiments, the row hammer detection system 110 simply identifies the aggressor row and the associated blast radius (or the blast radius is determined locally by the memory hardware 120). Alternatively, the row hammer detection system 110 may simply send a refresh command (e.g., a DRFM command) for each affected row, including the aggressor row and one or more rows on each side of the aggressor row (e.g., depending on the blast radius).

[0074] As mentioned above, in one or more embodiments, the row hammer detection system 110 can limit the number of refresh commands issued in a given time period. For example, in one or more embodiments, the row hammer detection system 110 can be limited to issuing a limited number of commands for each memory bank in a given time interval. In one or more embodiments described herein, the row hammer detection system 110 can be limited to issuing a single refresh command every 7.8 microseconds.

[0075] To prevent the hammer detection system 110 from violating this limitation of the memory system 106, the hammer detection system 110 may track the refresh commands issued within a predetermined interval (e.g., a 7.8 microsecond interval) to ensure that the hammer detection system 110 does not issue more than a threshold number of commands (for a particular memory bank) within the predetermined interval. In one or more embodiments, the hammer detection system 110 may only issue one refresh command for a given memory bank within the predetermined interval. The predetermined number of commands and the predetermined interval may be known or determined based on the specifications of the memory hardware 120.

[0076] Fig. 6A An example refresh command table 602 is shown according to one or more embodiments. Similar to the example access count record 202 discussed above, the refresh command table 602 can be maintained on a memory structure (e.g., an SRAM structure) on the memory controller 108. For example, Fig. 6A In the example shown, the row hammer detection system 110 can maintain an SRAM structure with multiple parallel channels 604a-n (e.g., thirty-two channels), each channel including M entries (e.g., sixty-four entries). By maintaining or otherwise utilizing thirty-two parallel channels, the row hammer detection system 110 can ensure that there is almost always an empty entry in the refresh command table 602 where the address of the corresponding refresh command can be placed. Fig. 6A As shown, the row hammer detection system 110 may place the address within the corresponding entry based on the received refresh command 606 , which includes the indicated aggressor address (eg, an aggressor row address).

[0077] Figure 6B 602 to ensure that the row hammer detection system 110 does not exceed a threshold number of refresh commands for a given memory bank within a predetermined time interval. As mentioned above, the row hammer detection system 110 may refresh the values ​​from the refresh command table 602 at a predetermined interval (e.g., a refresh interval). For example, in executing Figure 6B Before or after the illustrated series of actions 650 , the row hammer detection system 110 may determine whether a refresh interval has elapsed, and if so, clear all values ​​from the refresh command table 602 .

[0078] like Figure 6B As shown, the hammer detection system 110 may perform an action 652 of detecting a refresh command. As described above, this may be based on the hammer detection system 110 implementing a sampling pattern with respect to the memory sub-bank and generating a refresh command based on a comparison of a random number and a sampling threshold. Figure 6B In the example shown, the hammer detection system 110 may perform the series of actions 650 before issuing a refresh command. For example, the hammer detection system 110 may perform the series of actions 650 after generating a refresh command, but before issuing the refresh command.

[0079] like Figure 6B As further shown, the hammer detection system 110 may identify the address included in the refresh command and perform an action 654 of looking up the address in the refresh command table 602. Figure 6B As shown, the row hammer detection system 110 may perform action 656 , which determines whether the address from the refresh command is included in the refresh command table 602 .

[0080] In the event that the address is not in the table, the row hammer detection system 110 can perform an act 658 of issuing a refresh command. Alternatively, in the event that the address is in the table (i.e., a refresh command for the memory address was issued within a predetermined time interval), the row hammer detection system 110 can perform an act 660 of discarding the command. In one or more embodiments, the row hammer detection system 110 can quietly discard the command knowing that a refresh command has recently been issued for the same address, and trusting that a row hammer attack will not cause the binary bits of the corresponding row to be corrupted in such a short period of time. Furthermore, dropping the command in this case will prevent the row hammer detection system 110 from issuing refresh commands for the associated memory bank multiple times within a predetermined time interval, thereby violating the specifications of the memory hardware 120. Figure 6BAs shown, after performing each of acts 658 and 660, the row hammer detection system 110 may return to act 652 and detect the next refresh command.

[0081] Now go to Figure 7 , which illustrates an example flow chart including a series of actions for detecting and mitigating a suspected row hammer attack on a row address of memory hardware (e.g., a DRAM device). Figure 7 Actions according to one or more embodiments are shown, but alternative embodiments may omit, add, reorder, and / or modify Figure 7 Any action shown in . Figure 7 The actions of may be performed as part of a method. Alternatively, a non-transitory computer-readable medium may include instructions that, when executed by one or more processors, cause a computing device (e.g., a server device) to perform Figure 7 In a further embodiment, the system may perform Figure 7 action.

[0082] Figure 7 A series of actions 700 are shown for detecting and mitigating a suspected row hammer attack on a row address of memory hardware (e.g., a DRAM device). In one or more embodiments, the series of actions 700 are implemented by a memory controller to detect and mitigate a row hammer attack on one or more memory rows of a DRAM device. Figure 7 As shown, the series of actions 700 includes an action 710 of maintaining an access count table for a memory sub-bank, the access count table including access counts and overflow counts for row addresses. In one or more implementations, action 710 involves maintaining an access count table for a memory sub-bank, the access count table including a plurality of access counts indicating estimated activation counts of associated memory row addresses within the memory sub-bank, and an overflow count based on memory row accesses to at least one memory row address not included in the access count table.

[0083] As further shown, series of acts 700 may include act 720 of detecting that the overflow count is greater than or equal to a threshold count. In one or more embodiments, act 720 involves detecting whether the overflow count is greater than or equal to a threshold count associated with a prediction of a possible aggressor row from a memory sub-bank.

[0084] As further shown, the series of acts 700 may include an act of activating a sampling mode based on determining whether the random number falls within a sampling threshold 730. In one or more embodiments, act 730 involves activating a sampling mode of the memory sub-bank by generating a random number and determining whether the random number falls within the sampling threshold based on detecting that the overflow count is greater than or equal to the threshold count.

[0085] As further shown, series of acts 700 may include act 740 of reporting a memory address as an aggressor address based on the random number falling within a sampling threshold. In one or more embodiments, act 740 involves reporting a memory row address as an aggressor address based on whether the random number falls within the sampling threshold.

[0086] In one or more embodiments, the series of actions 700 includes maintaining a plurality of access count tables for a plurality of memory sub-banks including a memory sub-bank, the plurality of memory sub-banks corresponding to memory banks of a DRAM device. In one or more embodiments, activating a sampling mode for a memory sub-bank includes selectively activating the sampling mode while continuing to maintain an additional access count table in the plurality of access count tables for other sub-banks in the plurality of memory sub-banks.

[0087] In one or more embodiments, maintaining the access count table includes detecting activation of a first memory row address on the memory sub-bank, determining that the first memory row address is not included in the access count table, and incrementing an overflow count based on determining that the first memory row address is not included in the access count table. In one or more embodiments, incrementing the overflow count causes the overflow count to be greater than or equal to a threshold count. In one or more embodiments, the series of actions 700 includes periodically clearing the access count table at predetermined time intervals.

[0088] In one or more embodiments, activating the sampling mode includes determining a sampling threshold based on a maximum activation count (MAC) determined for the DRAM device. In one or more embodiments, determining whether the random number falls within the sampling threshold includes determining whether the random number is less than the sampling threshold. In one or more embodiments, the probability that the random number falls within the sampling threshold decreases as the MAC determined for the DRAM device increases.

[0089] In one or more embodiments, reporting the memory row address as an aggressor address includes reporting a blast radius of two or more address rows to the DRAM device. In one or more embodiments, reporting the memory row address as an aggressor address includes issuing a refresh command that causes the DRAM device to refresh the address row of the aggressor address and one or more additional address rows adjacent to the address row. In one or more embodiments, the access count table is maintained in an SRAM structure on a memory controller coupled to the DRAM device.

[0090] Figure 8 Certain components are shown that may be included within computer system 800. One or more computer systems 800 may be used to implement the various devices, components, and systems described herein.

[0091] The computer system 800 includes a processor 801. The processor 801 may be a general-purpose single-chip or multi-chip microprocessor (e.g., an Advanced RISC (Reduced Instruction Set Computer) Machine (ARM)), a special-purpose microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, etc. The processor 801 may be referred to as a central processing unit (CPU). Figure 8 Only a single processor 801 is shown in the computer system 800 , but in an alternative configuration, a combination of processors (eg, an ARM and DSP) could be used.

[0092] The computer system 800 also includes a memory 803 in electronic communication with the processor 801. The memory 803 can be any electronic component capable of storing electronic information. For example, the memory 803 can be implemented as a random access memory (RAM), a read-only memory (ROM), a magnetic disk storage medium, an optical storage medium, a flash memory device in a RAM, an onboard memory included in a processor, an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM) memory, a register, etc., including combinations thereof.

[0093] Instructions 805 and data 807 may be stored in memory 803. Instructions 805 may be executed by processor 801 to implement some or all of the functionality disclosed herein. Executing instructions 805 may involve using data 807 stored in memory 803. Any of the various examples of modules and components described herein may be implemented in part or in whole as instructions 805 stored in memory 803 and executed by processor 801. Any of the various examples of data described herein may be data 807 stored in memory 803 and used during execution of instructions 805 by processor 801.

[0094] The computer system 800 may also include one or more communication interfaces 809 for communicating with other electronic devices. The communication interface(s) 809 may be based on wired communication technology, wireless communication technology, or both. Some examples of the communication interface 809 include a universal serial bus (USB), an Ethernet adapter, a wireless adapter operating according to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless communication protocol, Wireless communication adapter, and infrared (IR) communication port.

[0095] The computer system 800 may also include one or more input devices 811 and one or more output devices 813. Some examples of input devices 811 include keyboards, mice, microphones, remote control devices, buttons, joysticks, trackballs, touchpads, and light pens. Some examples of output devices 813 include speakers and printers. One specific type of output device that is typically included in the computer system 800 is a display device 815. The display device 815 used with the embodiments disclosed herein may utilize any suitable image projection technology, such as a liquid crystal display (LCD), a light emitting diode (LED), gas plasma, electroluminescence, and the like. A display controller 817 may also be provided for converting data 807 stored in the memory 803 into text, graphics, and / or moving images (as appropriate) shown on the display device 815.

[0096] The various components of the computer system 800 may be coupled together by one or more buses, which may include a power bus, a control signal bus, a status signal bus, a data bus, etc. For clarity, the various buses are referred to in Figure 8 Shown in FIG. 8 is bus system 819 .

[0097] Unless specifically described as being implemented in a particular manner, the techniques described herein may be implemented in hardware, software, firmware, or any combination thereof. Any features described as modules, components, etc. may also be implemented together in an integrated logic device, or individually as discrete but interoperable logic devices. If implemented in software, these techniques may be implemented at least in part by a non-transient processor-readable storage medium that includes instructions that, when at least one processor executes the instructions, perform one or more of the methods described herein. Instructions may be organized into routines, programs, objects, components, data structures, etc. that may perform specific tasks and / or implement specific data types, and may be combined or distributed as desired in various embodiments.

[0098] Computer-readable media can be any available media that can be accessed by a general or special purpose computer system. A computer-readable medium that stores computer-executable instructions is a non-transient computer-readable storage medium (device). A computer-readable medium that carries computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the present disclosure may include at least two distinct computer-readable media: a non-transient computer-readable storage medium (device) and a transmission medium.

[0099] As used herein, non-transitory computer-readable storage media (devices) may include RAM, ROM, EEPROM, CD-ROM, solid-state drives (“SSD”) (e.g., RAM-based), flash memory, phase change memory (“PCM”), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code means in the form of computer-executable instructions or data structures and that can be accessed by a general or special purpose computer.

[0100] Without departing from the scope of the claims, the steps and / or actions of the methods described herein may be interchanged with each other. In other words, unless the proper operation of the described method requires a specific order of steps or actions, the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims.

[0101] The term "determining" includes a wide variety of actions, and thus, "determining" may include calculating, computing, processing, deriving, investigating, searching (e.g., searching in a table, database, or other data structure), ascertaining, etc. Furthermore, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. Furthermore, "determining" may include solving, selecting, choosing, establishing, etc.

[0102] The terms "comprising," "including," and "having" are intended to be inclusive and mean that there may be additional elements in addition to the listed elements. Furthermore, it should be understood that reference to "one embodiment" or "an embodiment" of the present disclosure is not intended to be interpreted to exclude the existence of additional embodiments that also include the described features. For example, any element or feature associated with the embodiments described herein may be combined with any element or feature of any other embodiment described herein, where compatible.

[0103] Without departing from the spirit or features of the present disclosure, the present disclosure may be embodied in other specific forms. The described embodiments should be considered illustrative rather than restrictive. Therefore, the scope of the present disclosure is indicated by the appended claims rather than by the above description. Changes within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A method implemented by a memory controller for detecting and mitigating a row hammer attack on one or more memory rows of a dynamic random access memory (DRAM) device, the method comprising: maintaining an access count table for a memory sub-bank, the access count table comprising a plurality of access counts indicating estimated activation counts for associated memory row addresses within the memory sub-bank and an overflow count, the overflow count being based on memory row accesses for at least one memory row address not included in the access count table; detecting that the overflow count is greater than or equal to a threshold count, the threshold count associated with a prediction of a possible aggressor row from the memory sub-bank; based on detecting that the overflow count is greater than or equal to the threshold count, activating a sampling mode for the memory sub-bank by generating a random number and determining whether the random number falls within a sampling threshold; as well as Based on whether the random number falls within the sampling threshold, a memory row address is reported as an attacker address.

2. The method according to claim 1, further comprising: A plurality of access count tables are maintained for a plurality of memory sub-banks including the memory sub-bank, the plurality of memory sub-banks corresponding to memory banks of the DRAM device.

3. The method of claim 2, wherein activating the sampling mode for the memory sub-bank comprises: The sampling mode is selectively activated while continuing to maintain additional ones of the plurality of access count tables for other ones of the plurality of memory sub-banks.

4. The method according to any one of claims 1 to 3, wherein maintaining the access count table comprises: detecting activation of a first memory row address on the memory sub-bank; determining that the first memory row address is not included in the access count table; as well as The overflow count is incremented based on a determination that the first memory row address is not included within the access count table. The method of claim 4 , wherein incrementing the overflow count causes the overflow count to be greater than or equal to the threshold count.

6. The method according to any one of claims 1 to 5, further comprising periodically clearing the access count table at predetermined time intervals.

7. The method of any one of claims 1-6, wherein activating the sampling mode comprises determining the sampling threshold based on a maximum activation count MAC determined for the DRAM device, wherein determining whether the random number falls within the sampling threshold comprises determining whether the random number is less than the sampling threshold. 8 . The method of claim 7 , wherein a probability that the random number falls within the sampling threshold decreases as the MAC determined for the DRAM device increases.

9. The method of any one of claims 1-8, wherein reporting the memory row address as an attacker address comprises reporting a blast radius of two or more address rows to the DRAM device.

10. The method of any one of claims 1-9, wherein reporting the memory row address as an aggressor address comprises issuing a refresh command that causes the DRAM device to refresh an address row of the aggressor address and one or more additional address rows adjacent to the address row.

11. The method of any one of claims 1-10, wherein the access count table is maintained in an SRAM structure on a memory controller coupled to the DRAM device.

12. The method according to any one of claims 1 to 11, further comprising: maintaining a record of report commands issued by the memory controller; as well as The memory row address is reported based on the memory row address not included in the record of the report command when each value of the record of the report command is cleared at a predetermined time interval, and the predetermined time interval is determined based on the hardware specification of the DRAM device.

13. A system comprising: A dynamic random access memory (DRAM) device, the DRAM device comprising a plurality of memory banks, each of the plurality of memory banks comprising a plurality of memory sub-banks; as well as A memory controller coupled to the DRAM device, the memory controller being configured to implement the method according to any one of claims 1-12.

14. A memory controller, the memory controller being configured to implement the method according to any one of claims 1-12.

15. The memory controller of claim 14, wherein the plurality of memory sub-banks correspond to memory banks of a dynamic random access memory (DRAM) device coupled to the memory controller.

Images