Hybrid and scalable architecture for bit FLIP mitigation in dram

Abstract

Methods, systems, and apparatus for a computing device comprising: a group threshold filtering module, a probabilistic sampling filter, and a programmable processor, each of which can be configured by an external processor to perform a particular bit flip mitigation strategy.

Description

[0001] HYBRID AND SCALABLE ARCHITECTURE FOR BIT FLIP MITIGATION IN DRAM

[0002] BACKGROUND

[0003] This specification relates to mitigating attacks on computational devices that employ a dynamic random-access memory (DRAM). DRAM is a type of semiconductor memory widely used in electronic devices due to its simplicity and high density of memory cells. DRAM stores each bit of data in a separate memory cell, where each memory cell is a capacitor within an integrated circuit, relying on periodic refresh operations to maintain data integrity. As the memory cell representing a bit of data is accessed, the charge of the memory cell decreases.

[0004] DRAM is vulnerable to various security threats including a family of attacks known as ’Row Hammer" attacks, where frequent accesses of one or more memory’ rows can cause bit flips in adjacent rows due to electromagnetic crosstalk between rows. Researchers have demonstrated that a bit flip using a RowHammer attack can lead to unauthorized privilege escalation in a computer system.

[0005] SUMMARY

[0006] This specification describes systems and methods for implementing bit flip mitigation in dynamic random-access memory (DRAM) with a hybrid architecture that can protect against current attack strategies and which is adaptable to future attack strategies that have yet to be identified or developed. The hybrid architecture can include a hardware component and a programmable component. The hybrid architecture can include a set of configurable variables that determine the operation of the hardware components and executable instructions to be executed by the programmable component and updated to reflect new bit flip attack strategies.

[0007] The hybrid architecture can include a memory controller responsible for issuing memory accesses to the DRAM. A bit-flip mitigation subsystem can observe the memory accesses issued by the memory' controller and determine if a DRAM row is a potential aggressor row, where an aggressor row is a DRAM row that is accessed frequently enough to induce a bit flip in a nearby victim row.

[0008] The bit-flip mitigation subsystem includes two filtering modules that down-sample an incoming stream of memory accesses to reduce the data rate of memory accesses to be processed by' the programmable component. A group threshold filtering module counts memory' accesses within groups of rows, where a memory' access can pass the group threshold filtering module if the memory access corresponds to a row that belongs to a group of rows with a group counter above a particular count threshold. A probability sampling module processes the stream of memory' accesses and passes a memory' access according to a particular probability . This specification introduces the ability' for an external processor to configure the particular count threshold of the group threshold filtering module, the particular probability of the probability sampling module, and a control variable that determines a state of a multiplexer that can disable one of the two filtering modules.

[0009] A programmable processor can receive the outputs of one or both filtering modules and execute a memory access counting algorithm according to a set of instructions, where the set of instructions can be configured by the external processor in a secure way to adapt to new attack strategies. The programmable processor can issue instructions to refresh one or more DRAM rows that it determines to be an aggressor row or at risk of being victimized by an aggressor row.

[0010] Particular embodiments of the subject matter described in this specification can be implemented so as to realize one or more of the following advantages. A bit-flip mitigation subsystem with configurable filter parameters, a control variable that can determine which filters are active, and the ability' to update the particular instructions executed by the programmable processor allows for a scalable mitigation solution that can adapt to new threat vectors and bit flip attack strategies in existing devices in the field by a software or firmware update.

[0011] The details of one or more embodiments of the subject matter of this specification are set forth in the accompanying drawings and the description below-. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

[0012] BRIEF DESCRIPTION OF THE DRAWINGS

[0013] FIG. 1 is an overview of an example system implementation.

[0014] FIG. 2 is a detailed overview of an example system implementation.

[0015] FIG. 3 is an example dynamic random-access memory’ (DRAM) with multiple rows.

[0016] FIG. 4 is an overview of an example system implementation with a configurable multiplexer. FIG. 5 is an example process where memory accesses are processed by the example svstem.

[0017] Like reference numbers and designations in the various drawings indicate like elements.

[0018] DETAILED DESCRIPTION

[0019] This specification describes a system that performs bit flip mitigation in dynamic random-access memory (DRAM). As the density of memory cells in DRAM increases, the risk of bit flips as a malicious attack vector, also known as a RowHammer attack, has become greater. Electromagnetic interference between neighboring memory cells of a DRAM that are organized in rows, where each memory7cell holds a small amount of charge that indicates the value of the bit represented by the memory cell, can cause a memory cell to flip (i . e.. a bit flip) its value. A row of memory cells, each memory cell storing data, is a DRAM row. An unintentional or maliciously intentional bit flip in a first row of memory cells can occur if a second nearby row of memory7cells experiences a sequence of frequent switching activations. The bit flip effect as a result of frequent switching activations of a nearby row is considered to be both a reliability problem and a security threat, as RowHammer attacks have been used to successfully escalate privileges and take over a computer system.

[0020] To mitigate the risk of unintended bit flips in a DRAM, a hybrid architecture that includes a hardware component and a programmable component can be used. The ability to update logic executed by the programmable component in the field allows for the system to adapt to new bit flip attack patterns as they are discovered.

[0021] FIG. 1 is an overview of an example system that can implement bit flip mitigation with a hybrid architecture that includes a programmable component and a hardware component. The system is an example of a system that can detect if a row of memory cells in a DRAM 100 is an aggressor row. where an aggressor row is a row of memory cells that experiences repeated memory accesses in an effort to induce a bit flip in a neighboring row, and to proactively refresh the appropriate row s of the DRAM 100. In some implementations, the appropriate rows to refresh are the rows physically adjacent to the aggressor row.

[0022] A memory controller 102 can control memory accesses to the DRAM 100, where accesses can include an activate, read, precharge, and refresh commands among others. The activate command can be used to open (or activate) a row- in the DRAM 100 for access. The read command can be used to read data from a specific column in the row7selected by the activate command. The precharge command can be used to close the row that was previously opened by the activate command. The refresh command can be used to restore the charge in one or more rows of the DRAM 100, preventing data loss due to charge leakage. The memory controller 102 can issue a refresh command to a row if the row is suspected to be a victim row, i.e., the victim of an aggressor row that is experiencing frequent activate commands. For example, by repeatedly activating a row, the charge contained in one or more memory cells of the row can decrease. By refreshing the row before a bit flip occurs, the full charge is restored to the level before the repeated activations began. In general, a memory access begins with an activate command. The row-attack mitigation subsystem 100 analyzes a stream of memory accesses, which is equivalent to analyzing a stream of activate commands issued by the memory' controller 102 to the DRAM 100.

[0023] A row-attack mitigation subsystem 110 can monitor memory accesses issued by the memory controller 102 to the DRAM 100 and decide if an intervention is necessary to ensure reliability' and security' in the data stored in the DRAM 100. The row-attack mitigation subsystem 110 can be communicatively coupled to the memory controller 102. In some implementations, the row-attack mitigation subsystem 110 can snoop on the communication between the memory controller 102 and the DRAM 100, where the information does not flow from the memory' controller 102 to the DRAM 100 through the row-attack mitigation subsystem 110, but the row-attack mitigation subsystem 110 can receive a copy of the memory accesses issued by the memory controller 102. The row-attack mitigation subsystem 110 can process the memory accesses in the context of other recent memory accesses and determine which rows are being frequently accessed to continuously monitor the degree to which each row in the DRAM 100 is at risk of being victimized by an aggressor row.

[0024] The row-attack mitigation subsystem 110 includes a group threshold filtering module 112. The group threshold filtering module 112 can process the memory accesses from the communication channel that can include memory accesses sent from the memory' controller 102 to the DRAM 100. The row-attack mitigation subsystem 110 can configure the group threshold filtering module 112 to count memory accesses for groups of rows of the DRAM 100 and to generate a group number for each group of rows, where the group number is incremented each time a memory access corresponding to a row in the corresponding group of rows is processed by the module 112. A memory access corresponding to a row in a group of rows passes the group threshold filtering module 112 if the corresponding group number exceeds a count threshold within a particular time window.

[0025] The objective of the group threshold filtering module 112 is to identify the memory’ accesses sent by the memory' controller 102 to the DRAM 100 that target a group of rows in the DRAM 100 that causes a group number to exceed a threshold within the particular time window. In some implementations, with each memory access processed by the group threshold filtering module 112, the group number corresponding to the memory access can be read from a memory module that holds the group number for each group within the particular time window. The group threshold filtering module 112 can increment the group number in the memory module with each observed memory access. If the incremented group number exceeds a count threshold, all subsequent memory accesses pass the filtering processes performed by the group threshold filter module 112. In some implementations, the group counters are reset at the end of the particular time window that corresponds to the time window upon which each DRAM row is refreshed, where the time window is specific to the particular DRAM 100.

[0026] The row-attack mitigation subsystem 110 includes a probabilistic sampling module 114. In some implementations, an observed memory access between the memory' controller 102 and the DRAM 100 can pass a filter applied by the probabilistic sampling module 114 if the output of a random number generator is below a particular value. In other words, the rowattack mitigation subsystem 110 can configure the probabilistic sampling module 114 to select a particular row within a group to be refreshed with a particular probability'. In some implementations, the probabilistic sampling module 114 can pass one in every' sixteen, thirty - two, or sixty-four memory accesses that are processed by the module 114, where the specific probability is configurable by an external application processor, as described in relation to FIG. 2.

[0027] Both the group threshold filtering module 112 and the probabilistic sampling module 114 select a subset of observed memory accesses issued by the memory' controller 112 to the DRAM 100 to analyze. By randomly refreshing rows of the DRAM 100, as performed by the probabilistic sampling module 114, the likelihood of an aggressor row victimizing an adjacent row decreases since the likelihood of each row being refreshed within the particular time window is non-zero. By counting the number of memory' accesses issued to multiple groups of rows by the memory controller 102. the group threshold filtering module 112 can detect abnormal activity without tracking memory accesses issued to every row in the DRAM.

[0028] In some implementations, the group threshold filtering module 112 can process the memory accesses before the probabilistic sampling module 114. In some other implementations, the probabilistic sampling module 114 can process the memory accesses before the group threshold filtering module 112. The cumulative effect of both modules is a down-sampling of the incoming stream of memory accesses.

[0029] The row-attack mitigation subsystem 110 includes a programmable processor 1 16 that can execute software, firmware, or both. The programmable processor 116 can be configured to receive outputs from the group threshold filtering module 112 and / or the probabilistic sampling module 110 and to execute instructions that cause the programmable processor 116 to perform one or more different row-attack detection processes and to provide refresh commands to the memory controller when a row-attack is detected, i.e., a victim row is identified. The memory controller 102 can issue memory accesses to the DRAM 100 at a frequency faster than software can process (i.e., 1GHz). Because of this, the group threshold filtering module 112 and the probabilistic sampling module 114 are designed as hardware implementations that can process high frequency data rates. The effect of the two filtering modules is a down-sampling, or a low pass filtering, of the incoming stream of observed memory7accesses. The down-sampled stream of memory' accesses that pass one or more of the filtering modules, the filtering modules being the group threshold filtering module 112 and probabilistic sampling module 1 14, can be processed by the programmable processor 1 16. In some implementations, the programmable processor 116 can be configured to receive memory' accesses from either or both of the filtering modules (112 and 114). In some implementations, the programmable processor 116 can perform frequent element detection (i.e., detect rows of the DRAM 100 that are frequently accessed which may indicate the presence of an aggressor row) or other sophisticated counting algorithms, as further described in relation to FIG. 2. The specific detection algorithm executed by the programmable processor 116 to identify a potential aggressor row' can be updated externally to adapt to new- threats and new strategies of RowHammer attacks.

[0030] The row-attack mitigation subsystem 110 can include a direct refresh management command issuer (DRFM command issuer 118). The DRFM command issuer 118 receives refresh commands from the programmable processor 116, w here the refresh command includes the rows of the DRAM 100 should be refreshed. In some cases, the programmable processor 116 can instruct the DRFM command issuer 118 to refresh a row in the DRAM 100 due to a probabilistic determination. In some other cases, the programmable processor 116 can instruct the DRFM command issuer 118 to refresh a row in the DRAM 100 because the row- belongs to group with a group number that exceeds the count threshold for the group. In some other cases, the row can belong to a group with a group number that exceeds the count threshold as well as being probabilistically selected to be refreshed. The DRFM command issuer 118 can send a corresponding instruction to the memory controller 102, where the memory controller can send a refresh command to an appropriate row of the DRAM 100.

[0031] FIG. 2 is a detailed overview of an example system that can implement bit flip mitigation with a row-attack mitigation subsystem 200 that includes a programmable component and a hardware component. The system is an example of a system that can detect if a row of memory’ cells in a DRAM (i.e.. DRAM 100) is an aggressor row, where an aggressor row is a row of memory cells that experiences a switching activation repeatedly in an effort to induce a bit flip in a neighboring row, and to refresh the appropriate rows of the DRAM.

[0032] In some implementations, a processor 201 (i.e., a central processing unit (CPU)) can communicate with the row-attack mitigation subsystem 200 to configure one or more components. The processor 201 can communicate with the row-attack mitigation subsystem

[0033] 200 over a secure channel, i.e., through a firewall 250. The processor 201 can send configuration variables to be stored in a control and status register (CSR 214), where the variables can determine threshold values and determine if specific components of the rowattack mitigation subsystem 200 are enabled. In addition, the processor 201 can load firmware that is run by a programmable component of the row-attack mitigation subsystem 200. In some implementations, a programmable processor 208 can load and execute instructions stored in an instruction memory (IMEM 216), where the instructions in the IMEM 216 are loaded from the processor 201. The programmable processor 208 can receive the instructions over a fabric interconnect 212, where the fabric interconnect 212 is a network of communication channels that connects the programmable processor 208 and the processor

[0034] 201 with memory' devices, where the memory devices store programmable instructions (i.e., firmware stored in IMEM 216), configuration variables (i.e., in CSR 214), and counters (i.e., in DMEM 218).

[0035] In general, as described in relation to the remaining components of FIG. 2, the ability’ to adaptively store configuration values in CSR 214 and executable instructions in IMEM 216 as loaded by the processor 201, the row-attack mitigation subsystem 200 is able to adapt to new threat vectors and new attack approaches as they are discovered.

[0036] The row-attack mitigation subsystem 200 is configured to analyze a sequence of memory’ accesses between a memory’ controller 202 and a DRAM (i.e., DRAM 100). A DDR PHY Control Interface (DCI interface 204) allows the row-attack mitigation subsystem 200 to observe the memory accesses. The sequence of memory accesses sent from the memory controller 202 to the DRAM is analyzed by the components of the row-attack mitigation subsystem 200 to determine if a proactive refresh of one or more DRAM rows within a particular time window is necessary to mitigate against the risk of unintended bit flips in the one or more DRAM rows. In some implementations, the particular time window is the refresh time interval, where the refresh time interval is a pre-determined and DRAM-specific interval upon which each row of the DRAM is refreshed.

[0037] The sequence of memory accesses sent from the memory controller 202, as observed over the DCI interface 204, can be processed by a group threshold filtering module 220. As described in relation to FIG. 1, the group threshold filtering module 220 can count memory accesses for groups of rows of the DRAM and generate a group number for each group of rows, where the group number is incremented each time a memory access corresponding to a row in the corresponding group of rows is processed by the module 220 within a particular time window. The objective of the group threshold filtering module 220 is to identify the memory accesses sent by the memory controller 202 to the DRAM that target a group of rows in the DRAM that causes a group number to exceed a threshold within the particular time window.

[0038] The group threshold filtering module 220 can include a group counter mapping module 224, where the group counter mapping module 224 maps each memory access from the DCI interface 204 to a group counter using a scheme similar to the physical address-to- DRAM address mapping in memory devices. In some implementations, a 22-bit activate command corresponding to a memory access is mapped to a partition ID and a partition row. The partition ID is a 5 -bit value, where each of the 5-bits is calculated through an XOR- Reduction between the 22-bit activate command and a 22-bit programmable hash register. The partition row is a 9-bit value, where each of the 9-bits are extracted from the 22-bit activate command based on a programmable mask register.

[0039] In some implementations, the group counter mapping module 224 can map each memory corresponding to a row of the DRAM to a corresponding group of rows. The rows contained in each group of rows is unique to a particular instance of the row-attack mitigation subsystem. In some implementations, the particular instance is associated with a unique subsystem (i.e., a first group of rows associated with a first subsystem, and a second group of rows associated with a second subsystem) or a reboot of a particular subsystem (i.e., a first group of rows associated with a subsystem and a second group of rows associated with the subsy stem after a reboot). For example, the row identified by an index 67 may correspond to a group index identified by a group index 4 on a first device. The row identified by an index 67 may correspond to a group index identified by a group index of 9 on a second device. Similarly, the row identified by an index 67 may correspond to a group index identified by a group index of 2 on the first device after the first device is rebooted. The randomness configured into the group counter mapping module 224 decreases the likelihood that an attacker can reverse engineer the group counter mapping 224 mechanism to port a RowHammer attack strategy across devices.

[0040] The group threshold filtering module 220 can include a group threshold filter 226 that can process an output of the group counter mapping module 224 along with a group counter threshold 222 and a set of group counters stored in a group counters static random-access memory (SRAM 229). The processor 201 can configure the group counter threshold 222 and stored it in the CSR 214. A corresponding group counter stored in the group counters SRAM 229 is incremented each time a memory access is observed for a row in a corresponding group of rows in the DRAM. If a group counter for a corresponding group of rows in the DRAM exceeds the group counter threshold 222, the memory7access can pass the group threshold filtering module 220 to be processed by a subsequent component of the row-attack mitigation subsystem 200.

[0041] In some implementations, the set of group counters can be stored in a dedicated group counters SRAM 229, where each group counter is an 11 -bit value that is addressed based on a partition ID and a partition row of the DRAM. In some other implementations, each group counter is a different size based on a threshold requirement of the group threshold filtering module 220. The group counters represent a number of memory7accesses that correspond to a group of rows in the DRAM. In some implementations, each group counter is cleared after each refresh time interval, where the refresh time interval is specific to the corresponding DRAM.

[0042] In some implementations, a mechanism for clearing the group counters, where the group counters are stored in the group counters SRAM 229, can be determined by logic stored in a group counter clearing logic SRAM 228. In some implementations, memory accesses can be missed during the time the group counters are being set to zero after each refresh time interval. Alternative strategies other than simply zeroing the values of each group counter stored in the group counters SRAM 229 avoid the possibility of missed memory accesses during the clearing process. For example, the group threshold filter module 220 can implement an alternating banks mechanism. The alternating banks mechanism includes two copies of the group counters SRAM 229. In this case, the system can overlap the clearing of a first group counters SRAM while a second group counters SRAM continues normal operation. When the refresh period completes, the system can begin to use the group counters corresponding to the first group counters SRAM. Other strategic mechanisms to clear the group counters SRAM 229 without imparting downtime on the system of risking the effects of missed memory accesses are possible and can be stored in the group counter clearing logic SRAM 228.

[0043] If a memory access passes the group threshold filtering module 220, the memory access can be processed by a probabilistic sampling filter 230. In some implementations, the probabilistic sampling filter 230 can be implemented before the group threshold filtering module 220, as the operations performed by each module are independent. In addition, a multiplexer (MUX 206) can receive the output of the group threshold filtering module 220 to allow one or both filter modules (the group threshold filtering module 220 and the probabilistic sampling filter 230) to be considered. The processor 201 can configure the MUX 206 configuration and represent the configuration with a value stored in the CSR 214. The processor 201 can configure the MUX 206 to consider the effect of one or both filter modules.

[0044] In some implementations, the probabilistic sampling filter 230 can include a probabilistic sampler 232 that processes the incoming memory access along with a programmable probability threshold 236 and a linear feedback shift register (LFSR 238). The probability7threshold 236 can be configured such that if the probabilistic sampler 232 generates a number below the probability threshold 236, the memory access passes the probabilistic sampling filter 230. With each memory access processed by the probabilistic sampling filter 230, the probabilistic sampler 232 implements a random number generator (RNG) mechanism to generate a random number. In some implementations, the RNG mechanism can be implemented as an 8-bit LFSR, where the LFSR can allow probabilistic sampling at rates at granularity of 0.00392, allowing the programmable processor to fine tune the probabilistic sampling filter 230 to achieve a desired degree of filtering. The 8-bit LFSR 238 includes 8 stages, where each stage can store one bit. Therefore, each entry of the LFSR 238 can represent 256 different states, resulting in the granularity of 1 / 255 (0.00392). In some implementations, the processor 201 can configure the programmable probability threshold 236 and a seed value for RNG mechanism in the CSR 214.

[0045] If a memory access passes the probabilistic sampling filter 230, the memory access can be processed by the MUX 206, where the MUX 206 is configured according to a value stored in the CSR 214 and set by the processor 201, along with the output of the group threshold filtering module 220. The programmable processor 208 can process the output of the MUX 206. In some implementations, the programmable processor 208 is a CPU that loads and runs the executable instructions stored in IMEM 216, where the processor 201 loads the instructions into the IMEM 216. The programmable processor 208 receives a down-sampled stream of memoi accesses from the MUX 206, where the stream of memory accesses observed through the DCI interface 204 is down-sampled by the group threshold filtering module 220 and / or the probabilistic sampling filter 230.

[0046] In some implementations, the programmable processor 208 can execute a set of instructions stored in IMEM 216, where the processor 201 loads the set of instructions corresponding to a row-attack detection process at boot time, to determine if a memory access received from the MUX 206 should trigger a row refresh in the DRAM due to a suspected bit flip attack in the corresponding row. The row-attack detection process can include various memory access tracking algorithms including Counter-based Adaptive Tree (CAT), Modified Counter-based Adaptive Tree (CAT-TWO), and other related counting algorithms. The counting algorithms can store related counters in the DMEM 218. The output of each counting algorithm is a determination of whether a refresh command should be issued to a DRFM command issuer 240, where a direct refresh management (DRFM) command instructs the memory' controller 202 to issue a refresh command to the corresponding DRAM row. In general, the row-attack detection process can be a variation of one or more common most-frequent-element counting algorithms.

[0047] The row-attack mitigation subsystem 200 includes a lookup table module 210, where the lookup table module 210 receives the output of the counting algorithm executed by the programmable processor 208. The lookup table module 210 includes one or more lookup tables, where each lookup table operates as a cache memory’ and includes the DRFM commands issued by the DRFM command issuer 240 within the particular time interval (i.e., the refresh time interval corresponding to the DRAM). If the counting algorithm executed by the programmable processor 208 determines a particular row should be refreshed, but the row7was previously refreshed within the particular time window, the DRFM command is not issued. The number of issued DRFM commands should be minimized to avoid DRAM downtime, because each DRFM command results in stalled memory access requests to the DRAM.

[0048] The DRFM command issuer 240 receives requests to refresh DRAM rows that have not been refreshed in the particular time window as confirmed by a miss in the lookup table query7. The refresh requests are loaded into a per-bank DRFM queue 242. The per-bank DRFM queue 242 stores the DRFM commands to be sent to the memory controller 202, where a separate queue is configured for each bank of the DRAM. In some implementations, the DRAM can include multiple banks, where a bank is a two-dimensional section of memory cells of the DRAM, and each bank can have one simultaneously activated row. In some implementations, a DRFM issue manager 244 can notify the memory controller 202 that a DRFM command is to be issued by writing the details of the DRFM command (i.e., DRAM row and bank) to an appropriate CSR. where the memory controller 202 has access to the appropriate CSR. Upon receiving notification that a DRFM command should be issued, the memory7controller can issue the DRFM command to the DRAM to refresh the corresponding row of memory cells based on a blast radius, where the blast radius corresponds to a predicted number of affected rows.

[0049] FIG. 3 is an overview of an example DRAM 300, where the DRAM 300 includes multiple rows (i.e., DRAM row 302) of memory' cells. In some implementations, each cell holds an amount of charge that indicates the value of the bit represented by the cell. Over time, the charge of the cell leaks, requiring a frequent refresh of the charge in each DRAM cell at a refresh time interval. In some implementations, the refresh time interval is 32 milliseconds (ms), where the refresh time interval is specific to a particular DRAM device.

[0050] In some implementations, a sequence of frequent activations of one or more DRAM rows are executed within the refresh time interval between DRAM refreshes. For example, frequent activations within the refresh time interval on DRAM row 67 306 and DRAM row 69 310 can cause a bit flip due to electromagnetic interference on DRAM row 68 308. In this example, DRAM row 67 306 and DRAM row 69 310 are aggressor rows, where they are repeatedly activated within the refresh time interval. The DRAM row 68 308 is the victim row, where a bit flip can occur due to frequent activations of nearby DRAM rows. In addition, other rows can be considered victim rows. For example, DRAM row 66 and DRAM row 70 (not illustrated in FIG. 3) can be victim rows, as they are also adjacent to the aggressor rows DRAM row 67 306 and DRAM row 69 310.

[0051] FIG. 4 is an overview of an example system that can implement bit flip mitigation with a hybrid architecture that includes a programmable component and a hardware component, where the programmable component can configure which filtering methods are applied to observed DRAM memory' accesses.

[0052] In some implementations, a bit flip mitigation system can observe DRAM memory accesses from a memory controller over a DDR PHY Control Interface (DCI interface 400). The memory accesses observed over the DCI interface 400 are processed by a group threshold filtering module 402 and a probabilistic sampling module 404.

[0053] As described in relation to FIG. 1, the group threshold filtering module 402 can count memory accesses for groups of rows of the DRAM and generate a group number for each group of rows, where the group number is incremented each time a memory access corresponding to a row in the corresponding group of rows is processed within a particular time window. The objective of the group threshold filtering module 402 is to identify the memory accesses sent by the memory controller to the DRAM over the DCI interface 400 that target a group of rows in the DRAM that causes a group number to exceed a threshold within the particular time window.

[0054] As described in relation to FIG. 1, the probabilistic sampling module 404 can select pass a particular memoi ' access with a particular probability. In other words, if the probabilistic sampling module 404 is the only method implemented, DRAM rows are randomly selected to be refreshed without any additional insight into DRAM memory' accesses to mitigate the possibility of bit flips.

[0055] In some implementations, the system can configure a multiplexer (MUX 406) to implement one or both of the group threshold filtering module 402 and probabilistic sampling module 404. The programmable component can configure the MUX 406 to use both modules or one module. The output of the MUX 406 is a filtered sequence of memory accesses, as observed over the DCI interface 400 and filtered by a programmable combination of the group threshold filtering module 402 and the probabilistic sampling module 404.

[0056] A processor 408 can receive the output of the MUX 406 and implement logic to determine if a DRAM row should be refreshed within the particular refresh time interval. If the processor 408 determines a row should be proactively refreshed, the processor 408 can direct a DRFM command issuer 410 to issue a row refresh command to a memory controller 412. The memory controller 412 can issue the row refresh command to the DRAM that will proactively refresh the row' before the refresh time interval elapses.

[0057] FIG. 5 is a flow diagram of an example process that determines if a memory access targets a row corresponding to a detected row attack. The process includes operations performed by components of a row-attack mitigation subsystem (i.e., the row-attack mitigation subsystem as described in relation to FIG. 2), where the row-attack mitigation subsystem can include a group threshold filtering module, a probabilistic sampling module, and a programmable processor. For convenience, the process will be described as being performed by an appropriate hardware component or programmable component configured to operate in accordance with this specification.

[0058] The group threshold filtering module counts (502) memory accesses for groups of rows to generate a corresponding group number, where the memory accesses are observed through a communication interface that receives copies of the memory7commands issued by a memory controller to a DRAM. The row-attack mitigation subsystem is communicatively coupled to the memory controller. In some implementations, the communication interface is a DDR PHY Control Interface (DCI) interface. Each memoiy7access can pass the group threshold filtering module if the DRAM row corresponding to the memory7access belongs to a group or rows with a group number that exceeds a count threshold within a particular time window.

[0059] In some implementations, the particular time window is set by the particular DRAM device, as the memory cells of a DRAM device are periodically refreshed to account for charge leakage in the memory cells.

[0060] In some implementations, the set of rows that make up each particular group of rows changes with every hardware boot and differs between different devices. The variability of a mapping between row number and corresponding group results makes it harder for an attacker to determine a scalable attack mechanism that can operate across devices and across device boots.

[0061] In some implementations, the group threshold filtering module is implemented in hardware. In addition, in some implementations, the count threshold can be configured by an external processor and stored in a memory7device located in the row-attack mitigation subsystem.

[0062] The probabilistic sampling module passes (504) each memory access based on a particular probability7. In other w ords, the probabilistic sampling module can process a stream of memory' accesses to output a down sampled version of the stream of memory accesses, where the down sampled stream is a random sampling of the input stream. In some implementations, the probabilistic sampling module is implemented in hardw are. In addition, in some implementations, the particular sampling probability can be configured by an external processor and stored in a memory7device located in the row-attack mitigation subsystem. For example, the probabilistic sampling module can pass memory' accesses based on a particular probability of 1 / 8, 1 / 16, 1 / 32, 1 / 64, or 1 / 128.

[0063] The programmable processor receives (506) outputs from the group threshold filtering module and the probabilistic sampling module. In some implementations, the outputs from the two modules can first pass through a configurable multiplexer, where the multiplexer can pass the stream of memory accesses that are processed by one or both of the group threshold filtering module and probabilistic sampling module. In some implementations, the programmable processor is a central processing unit (CPU).

[0064] The programmable processor executes (508) instructions to perform a row-attack detection process. The row-attack detection process can include the Counter-based Adaptive Tree (CAT), Modified Counter-based Adaptive Tree (CAT-TWO), and other related algorithms. The specific counting process executed by the programmable processor can be configured by an external processor, where the corresponding instructions can be stored in an instruction memory' located in the row-attack mitigation subsystem. The ability to update the instructions executed by the programmable processor enables the row-attack mitigation subsystem to adapt to new ty pes of attack strategies.

[0065] The programmable processor provides ( 10) refresh commands to the memory controller when a row-attack is detected, where the memory' controller is responsible for controlling memory accesses to the DRAM. In some implementations, the programmable processor can first provide the refresh commands to a direct refresh management command issuer, where the direct refresh management command issuer manages the refresh commands with corresponding buffers to manage the flow of refresh commands to the memory' controller.

[0066] Embodiments of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them.

[0067] The term “data processing apparatus” refers to data processing hardware and encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can also be, or further include, special purpose logic circuitry', e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). The apparatus can optionally include, in addition to hardware, code that creates an execution environment for computer programs, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0068] In addition to the embodiments described above, the following embodiments are also innovative: Embodiment 1 is a system comprising: a dynamic random-access memory (DRAM) having a plurality of rows: a memory controller configured to control memory accesses to the DRAM; and a row-attack mitigation subsystem communicatively coupled to the memory controller and comprising: a group threshold filtering module configured to count memory accesses for groups of rows of the DRAM and to generate a group number, wherein the module passes any memory access corresponding to a row in a group of rows that has a group number that exceeds a count threshold within a particular time window, a probabilistic sampling module configured to pass a particular memory access with a particular probability, and a programmable processor configured to receive outputs from the group threshold filtering module and the probabilistic sampling module and to execute instructions that cause the programmable processor to perform a plurality of different row-attack detection processes and to provide refresh commands to the memory controller when a rowattack is detected.

[0069] Embodiment 2 is the system of embodiment 1 , wherein a multiplexer is configured to receive an output from the group threshold filtering module and an output from the probabilistic sampling module and to pass one or both of the outputs to the programmable processor.

[0070] Embodiment 3 is the system of any one of embodiments 1 -2, wherein the group threshold filtering module is configured to count memory7accesses for groups of rows of the DRAM, each group of rows including a subset of rows that is unique to a particular instance of the row-attack mitigation subsystem, the particular instance associated with a unique subsystem or a reboot of a particular subsystem.

[0071] Embodiment 4 is the system of any one of embodiments 1-3, wherein the count threshold of the group threshold filtering module is configurable.

[0072] Embodiment 5 is the system of any one of embodiments 1-4, wherein the particular probability of the probabilistic sampling module, the particular probability determining the probability of passing a particular memory' access, is configurable.

[0073] Embodiment 6 is the system of any one of embodiments 1-5, wherein the group number is set to zero at the beginning of each time window, the time window determined by the particular DRAM. Embodiment 7 is the system of any one of embodiments 1-6, wherein the instructions that cause the programmable processor to perform a plurality of different row-attack detection processes are updated to adapt to new types of attack strategies by an external processor and stored in an instruction memory .

[0074] Embodiment 8 is the system of any one of embodiments 1-7, wherein the memory controller issues a refresh command to the DRAM to a particular row, the particular row determined by the programmable processor.

[0075] Embodiment 9 is the system of any one of embodiments 1-8, wherein the refresh commands issued by the programmable processor to the memory controller are managed by a direct refresh management command issuer.

[0076] Embodiment 10 is a method comprising: counting memory accesses for groups of rows of a dynamic random-access memory (DRAM) to generate a group number via a group threshold filtering module, wherein a memory7access passes the group threshold filtering module if the group number exceeds a count threshold within a particular time window; passing a particular memory access with a particular probability with a probabilistic sampling module; receiving outputs from the group threshold filtering module and the probabilistic sampling module to a programmable processor; executing instructions in the programmable processor to perform a plurality’ of different row-attack detection processes; and providing refresh commands from the programmable processor to a memory’ controller when a row-attack is detected.

[0077] Embodiment 11 is the method of embodiment 10, wherein a multiplexer is configured to receive an output from the group threshold filtering module and an output from the probabilistic sampling module and to pass one or both of the outputs to the programmable processor.

[0078] Embodiment 12 is the method of any one of embodiments 10-11, wherein the group threshold filtering module is configured to count memory accesses for groups of rows of the DRAM, each group of rows including a subset of rows that is unique to a particular instance of the row-attack mitigation subsystem, the particular instance associated with a unique subsy stem or a reboot of a particular subsystem.

[0079] Embodiment 13 is the method of any’ one of embodiments 10-12, wherein the count threshold of the group threshold filtering module is configurable. Embodiment 14 is the method of any one of embodiments 10-13, wherein the particular probability of the probabilistic sampling module, the particular probability determining the probability of passing a particular memory access, is configurable.

[0080] Embodiment 15 is the method of any one of embodiments 10-14, wherein the group number is set to zero at the beginning of each time window, the time window determined by the particular DRAM.

[0081] Embodiment 16 is the method of any one of embodiments 10-15. wherein the instructions that cause the programmable processor to perform a plurality of different rowattack detection processes are updated to adapt to new types of attack strategies by an external processor and stored in an instruction memory.

[0082] Embodiment 17 is the method of any one of embodiments 10-16, wherein the memory controller issues a refresh command to the DRAM to a particular row, the particular row determined by the programmable processor.

[0083] Embodiment 18 is the method of any one of embodiments 10-17, wherein the refresh commands issued by the programmable processor to the memory controller are managed by a direct refresh management command issuer.

[0084] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or on the scope of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially be claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0085] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0086] Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.

[0087] What is claimed is:

Claims

CLAIMS1. A system comprising: a dynamic random-access memory (DRAM) having a plurality of rows; a memory controller configured to control memory accesses to the DRAM; and a row-attack mitigation subsystem communicatively coupled to the memory controller and comprising: a group threshold filtering module configured to count memory accesses for groups of rows of the DRAM and to generate a group number, wherein the module passes any memory access corresponding to a row in a group of rows that has a group number that exceeds a count threshold within a particular time window, a probabilistic sampling module configured to pass a particular memory access with a particular probability, and a programmable processor configured to receive outputs from the group threshold filtering module and the probabilistic sampling module and to execute instructions that cause the programmable processor to perform a plurality of different row -attack detection processes and to provide refresh commands to the memory controller when a rowattack is detected.

2. The system of claim 1, wherein a multiplexer is configured to receive an output from the group threshold filtering module and an output from the probabilistic sampling module and to pass one or both of the outputs to the programmable processor.

3. The system of any of claims 1-2, wherein the group threshold filtering module is configured to count memory accesses for groups of rows of the DRAM, each group of rows including a subset of rows that is unique to a particular instance of the row-attack mitigation subsystem, the particular instance associated with a unique subsystem or a reboot of a particular subsystem.

4. The system of any one of claims 1-3, wherein the count threshold of the group threshold filtering module is configurable.

5. The system of any one of claims 1-4, wherein the particular probability of the probabilistic sampling module, the particular probability determining the probability of passing a particular memory access, is configurable.

6. The system of any one of claims 1-5, wherein the group number is set to zero at the beginning of each time window, the time window determined by the particular DRAM.

7. The system of any one of claims 1-6, wherein the instructions that cause the programmable processor to perform a pl urality of different row-attack detection processes are updated to adapt to new types of attack strategies by an external processor and stored in an instruction memory.

8. The system of any one of claims 1-7, wherein the memory' controller issues a refresh command to the DRAM to a particular row, the particular row determined by the programmable processor.

9. The system of any one of claims 1-8, wherein the refresh commands issued by the programmable processor to the memory' controller are managed by a direct refresh management command issuer.

10. A method comprising: counting memory' accesses for groups of rows of a dynamic random-access memory' (DRAM) to generate a group number via a group threshold filtering module, wherein a memory access passes the group threshold filtering module if the group number exceeds a count threshold within a particular time window; passing a particular memory access with a particular probability7with a probabilistic sampling module; receiving outputs from the group threshold filtering module and the probabilistic sampling module to a programmable processor; executing instructions in the programmable processor to perform a plurality7of different row-attack detection processes; and providing refresh commands from the programmable processor to a memory controller when a row-attack is detected.

11. The method of claim 10, wherein a multiplexer is configured to receive an output from the group threshold filtering module and an output from the probabilistic sampling module and to pass one or both of the outputs to the programmable processor.

12. The method of any of claims 10-11, wherein the group threshold fdtering module is configured to count memory accesses for groups of rows of the DRAM, each group of rows including a subset of rows that is unique to a particular instance of the row-attack mitigation subsystem, the particular instance associated with a unique subsystem or a reboot of a particular subsystem.

13. The method of any one of claims 10-12, wherein the count threshold of the group threshold filtering module is configurable.

14. The method of any one of claims 10-13, wherein the particular probability of the probabilistic sampling module, the particular probability determining the probability of passing a particular memory access, is configurable.

15. The method of any one of claims 10-14, wherein the group number is set to zero at the beginning of each time window, the time window determined by the particular DRAM.

16. The method of any one of claims 10-15, wherein the instructions that cause the programmable processor to perform a plurality of different row -attack detection processes are updated to adapt to new types of attack strategies by an external processor and stored in an instruction memory.

17. The method of any one of claims 10-16, wherein the memory controller issues a refresh command to the DRAM to a particular row , the particular row' determined by the programmable processor.

18. The method of any one of claims 10-17, wherein the refresh commands issued by the programmable processor to the memory controller are managed by a direct refresh management command issuer.

Images