PROCESSOR SUPPORT FOR SOFTWARE-LEVEL CONTAINMENT OF ROW HAMMER ATTACKS

A method and apparatus for mitigating row hammer attacks is provided. A row hammer alert is generated by a component of a memory architecture controlling operation of a memory device. The component may be a memory controller, coherency logic, or data fabric. The component obtains a physical address of an aggressor row that caused the alert and obtains an identifier of an execution context corresponding to the physical address. The component generates an error message for a processing device, the error message including the identifier of the execution context. The processing device retrieves the error message when performing a context switch. The processing device then generates an event received by the operating system. The operating system then takes action to reduce row hammer by the execution context, such as ending, restarting, or throttling the execution context.

FIELD OF THE INVENTION

The present invention relates to mitigating data corruption due to row hammer attacks.

BACKGROUND

In order to achieve ever greater storage densities, memory cells of every type have become smaller and are packed closer together. Many types of memories will place many layers of memory cells on a single chip. The downside of these developments is that the conductive paths for writing to and reading from each cell have also become smaller and more tightly packed with one another and the memory cells. This creates opportunities for electrical interference in which asserting signals on the control lines for addressed memory cells may cause an unintended change in state in non-addressed memory cells. The decreasing size of the memory cells has made them even more susceptible to this problem.

Malicious actors have exploited this vulnerability to implement “row hammer” attacks in which one or more rows of memory cells are repeatedly written to or read from in a manner that will intentionally change the values stored in one or more other rows of memory cells.

Dynamic random-access memory (DRAM) is particularly susceptible to such attacks. Nonetheless, DRAM is used in many applications due to its quick access times. In DRAM, each memory cell includes a capacitor that is charged to write a binary 1 to that cell. To read the cell, the capacitor is allowed to discharge onto a sense line. The capacitors are susceptible to leakage and therefore DRAM must be refreshed periodically by reading and rewriting data stored therein. Some approaches to mitigating row hammer attacks include increasing the refresh rate for affected memory cells. However, such approaches may be overwhelmed and also impose a performance penalty.

There is therefore a need for more effective ways for mitigating row hammer attacks.

DETAILED DESCRIPTION

OVERVIEW

A row hammer alert is generated by a component of a memory architecture controlling operation of the memory device. The component obtains a physical address of an aggressor row that caused the alert and obtains an identifier of an execution context corresponding to the physical address. The component generates an error message for a processing device, the error message including the identifier of the execution context. The processing device retrieves the error message when performing a context switch and then generates an event received by the operating system. The operating system then takes action(s) to reduce row hammer by the execution context, such as ending, restarting, or throttling the execution context. This technical solution provides the benefits of enabling the operating system to mitigate row hammer attacks rather than relying exclusively on the memory architecture.

Memory Architecture

The approach described herein for mitigating row hammer attacks is used in a memory architecture100ofFIG.1including some or all of the depicted components, or additional components. The depicted memory architecture is one example architecture. Any memory architecture known in the art may also incorporate logic for implementing the row hammer mitigation approach described herein.

The memory architecture includes a plurality of memory modules102. The memory modules102each include two- or three-dimensional arrays of memory cells, each memory cell having the capacity to store and output one or more bits of data. Each memory module102may further include circuits enabling row and column inputs to be translated to a physical location within each memory module102so that data may be written to or read from the physical location.

The memory modules102may be implemented as single in-line memory modules (SIMM), dual in-line memory modules (DIMM), or other form factor. The memory modules102include memory cells implemented as dynamic random-access memory (DRAM), static random-access memory, or other volatile memory. In some implementations, the memory modules include non-volatile memory cells, such as NAND flash memory cells.

A bank of two or more memory modules102is each coupled to a memory controller104. The memory controller104performs such functions as translating addresses into a module index (i.e., identifier of a particular memory module102), row index, and possibly a column index. The memory controller104asserts control lines to invoke reading data from or writing data to a particular address. In the case of memory modules102implemented as DRAM, the memory controller104performs refreshing of data stored in the memory modules102.

According to an implementation, the memory controller104is further configured to detect row hammer attacks and, in response, generate a row hammer alert. For example, logic within the memory controller104includes logic tracking the frequency that each row of each memory module102is written to and/or read from. An algorithm implemented by the memory controller104may determine whether a pattern of writing to and reading from a potential aggressor row is likely to cause modification of other non-addressed rows of the memory module102including the aggressor row. The implementation of the algorithm varies depending upon a particular implementation and may be dependent on the properties of the memory cells making up each memory module102. In particular, the frequency of writes and/or reads to the aggressor row that is likely to cause changes to non-addressed rows decreases as the size of the memory cells decreases and packing density of the memory cells increases.

The memory controller104is further configured with logic for mitigating row hammer attacks, such as by increasing the refresh rate for one or more of the memory modules102coupled thereto. According to an implementation, the memory controller104is configured to generate the row hammer alert in response to a row hammer attack exceeding the mitigation capacity of the memory controller104, whereas row hammer attacks that are successfully mitigated by the memory controller104will not result in generating a row hammer alert.

One or more memory controllers104for one or more banks of memory modules102are coupled to coherency logic106. The coherency logic106implements a coherency slave with respect to processors108that are connected to the memory architecture100. Each processor108includes a cache110, such as a level 1 (L1), level 2 (L2) and/or level 3 (L3) shared cache, although the L2 cache may also be shared. The coherency logic106performs tasks in response to requests from the processors108and/or cache controllers for caches110coupled to the processors108. For example, the coherency logic106is instructed to read data from one of the memory modules102by way of the appropriate memory controller104and write it to the cache110of a processor108in response to a cache miss for that cache110. The coherency logic106also writes data from the cache110to one of the memory modules102by way of the appropriate memory controller104in response to an instruction to flush one or more rows of the cache110.

In some implementations, a data fabric112is used such as the SCALABLE DATA FABRIC (SDF) from ADVANCED MICRO DEVICES (AMD). The data fabric112provides a data plane through which a plurality of components can each communicate with one another, such as processors108, persistent storage devices, data buses, peripherals, graphics processing units (GPU), and the like. In such implementations, the processors108are connected to the memory controllers104and/or coherency logic106by way of the data fabric112.

Each processor108is a central processing unit (CPU), graphics processing unit (GPU), or other type of processor. The processors108may be different processing cores of a multi-core processor. Each processor108is configured to read instructions from the memory module102and execute them in sequence. The processors perform any of the functions of a CPU as known in the art. The row hammer mitigation approach described herein operates in conjunction with one or more registers114storing data describing a current executing context, such as a process or thread. According to an implementation, the processor108further includes registers or memory implementing an error log116to which one or more components of the memory architecture100write data.

In some implementations, the memory controller104implements a port118. The port defines input and or output lines by which the processor108and memory controller104exchange information in addition to commands, data to be written, and addresses to which data is to be written to or read from. The port118is, for example, used by the processor108to provide an execution context identifier (e.g., thread identifier) associated with a memory command input by the processor108to the memory controller104. Example commands include, without limitation, a write command, a read command, and a command to allocate a block of memory to the execution context and to return a start address of the block of memory to the processor108. The memory controller104stores an association between an address or block of addresses and the execution context identifier received from the processor108. The memory controller104uses the port118to communicate information to the processor108, such as error notifications. A row hammer alert according to the mitigation approach described herein and according to an implementation, is transmitted by the memory controller104to the processor108using the port118.

In some implementations, coherency logic106and the data fabric112likewise implement ports120,122, respectively. The processor108may additionally or alternatively transmit the execution context associated with a command to one or both of ports120,122as described above with respect to the port118. The processor108may additionally or alternatively receive error notifications from one or both of ports120,122as described above with respect to the port118. For example, error notifications from a memory controller104are passed up to the coherency logic106and/or data fabric112, which then forward the error notifications to the processor108.

Inasmuch as there are multiple processors108, each processor108is connected to any of the ports118,120,122that are implemented and be independently addressable. For example, for an execution context identifier received from a particular processor108, error notifications referencing that execution context identifier may be transmitted to that processor108. Error notifications transmitted from a port118,120, and/or122may be written to the error log116of the processor108to which the notifications are transmitted.

Memory Controller Logic for Detecting Row Hammer Attacks

FIG.2depicts a method200performed by the memory controller104in response to detection of a row hammer event. As used herein “row hammer event” refers to a pattern of reads and/or writes to an aggressor row of a memory module102that is predefined as being a row hammer event according to the logic of the memory controller104. Which pattern or patterns are identified as row hammer attacks may be determined by testing of memory modules having the same type as the memory module102. For example, patterns of reads and/or writes are tested to determine which have an unacceptable probability of causing modification of non-addressed rows, e.g., greater than a predefined probability threshold. For some types of memory modules102, normal patterns of reads and/or writes from legitimate software, as opposed to viruses or malware, match a predefined pattern and are still interpreted as row hammer events in order to hinder unintentional modification of non-addressed rows.

According to an implementation, the method200includes receiving202a row hammer alert and a physical address of an aggressor row. The physical address may be in the form of module index of a memory module102and a row index of the aggressor row. The physical address may also be an address from which the module and row index of the aggressor row were translated.

In response to receiving202the row hammer alert, the method200includes retrieving204the execution context identifier corresponding to the physical address. As noted above, in some implementations commands from a processor108are accompanied by an associated execution context received through the port118. Accordingly, this execution context may be retrieved204from a stored mapping between execution context identifiers and corresponding addresses. Where the execution context identifiers are associated with blocks of addresses, the memory controller104may include logic for determining which block of addresses includes the address of the aggressor row and obtaining the execution context identifier associated with that block of addresses.

According to an implementation, the method200further includes creating206an error log entry116in the processor108Where there are multiple processors108, the processor108in which the error log entry is created is the processor that requested allocation of the aggressor row or block of addresses including the aggressor row. In other implementations, notification of the row hammer alert is provided to the processor108by other means, such as in the form of a machine check exception (MCE), interrupt request (IRQ). For example, the memory controller104and its corresponding memory modules102may be an error reporting entity according to the memory check architecture (MCA). In some implementations, the processor retrieves the execution context identifier from the memory controller104in response to the row hammer alert

The memory controller104is described above as performing the method200. In other implementations, another component of the memory architecture100performs some or all of the steps of the method200. For example, the coherency logic106performs the method200by communicating with the processor108by means of the port120. The data fabric112performs the method200by communication with the processor108be means of the port122. In some implementations, the memory controller104includes logic for identifying row hammer events and, in response, transmits an alert to one or both of the coherency logic106and data fabric112. Either of the coherency logic106and data fabric112then creates an entry in the error log116in response to the row hammer alert. In other implementations, either of the coherency logic106and data fabric112include logic for detecting row hammer events and creating entries in the error log106.

Mitigation Approach in Response to Row Hammer Alerts

FIG.3depicts components of a computing device for mitigating row hammer attacks, such as in response to alerts received in accordance with the method200. According to an implementation, the execution contexts executed by the processor108are threads300that are part of a process302that may include a plurality of threads300. The process302may execute an application, network service, daemon, operating system service, or any executable that may be executed on a computing device. Launching and managing of the process302is performed by an operating system304. Examples of the operating system304include WINDOWS, LINUX, MACOS, or the like. The operating system304provides functions for interfacing with the components of a computing device, standard libraries for use by processes302, and executables for launching and managing processes302in response to user inputs, schedules, or predefined events. The operating system304may execute within a virtual machine that may itself be managed by a virtual machine manager (VMM). In the following description, the mitigation approach is described as being performed by the operating system304but may be performed in a like manner by a virtual machine or VMM.

The processor108generates an event306in response to an entry in the error log116that is created in response to row hammer alert. The event306includes one or more status bits308,310. For example, status bit308indicates that the event indicates a recoverable error. Status bit310indicates that the event has been delivered to the execution context that was executing when the recoverable error occurred. The event306is provided by the processor108to the execution context, e.g., thread300, for processing. For example, the processor108checks the error log116as part of performing a context switch away from an execution context and, in response to an entry in the error log116, creates the event306.

The thread300may be executing a workload312when the row hammer alert occurred. The workload312may be executable code for performing a task delegated to the thread300. In response to the event306, the operating system304may cause the thread300to restart performing the workload312.

According to an implementation, the process302has one or more quality of service (QoS) parameters314. The QoS parameters314specify resources allocated to the process302and include a processor time parameter defining an amount of processing cycles allocated for execution of the process302by the one or more processors108. The QoS parameters314specifies a number of memory commands that may be submitted by the process302within a given time window. For example, a process302is allocated a fraction of available memory commands executable by the memory architecture100, e.g., on average over the time window, X percent of memory commands executed by the memory architecture100may be permitted to be from the process302.

In response to receiving the event306from the processor108for the process302, the operating system304adjusts the QoS parameters314of the process302to one or both of reduce the amount of processing cycles or memory commands allocated to the process302. As one example, the value of X is reduced, such as X=0.5*X. In this manner, the ability of the process302to cause row hammer attacks will be reduced.

FIG.4depicts a method400executed by the processor108to mitigate row hammer attacks. The method400may include initiating402a context switch. For example, execution of instructions of a currently executed thread300may be stopped. The method400may include, as part of performing the context switch, reading404the error log116. In response to an entry in the error log116indicating a row hammer alert, the processor108may retrieve406the execution context identifier from the entry, which may or may not be the same as the identifier of the thread300that was stopped at step402.

The method400may include creating408an event306associated with the execution context identifier and setting410one or more bits of the event. As noted above, a bit308may be set to indicate that the event indicates a recoverable error and a bit310may be set to indicate that the recoverable error was delivered to the execution context in which the recoverable error occurred.

As noted above, some patterns of reads and/or writes may create a risk of row hammer but in fact be from a legitimate process302. Accordingly, specifying that the error is recoverable may suppress ending of the process302by the operating system304and may further suppress rebooting of a computing device executing the process302.

The processor108may then complete412the context switch. Completing412the context switch may include copying the contents of context registers114to any of the memory modules102or to the cache110. Completing412the context switch may include loading values defining a different execution context into the context registers114from the cache110or any of the memory modules102and commencing execution of instructions of the different execution context. Any of the actions performed as part of performing a context switch may be performed before or after steps404-410. For example, in some implementations, at least stopping execution of the current execution context is performed at step402and at least starting execution of the different execution context is not performed until step412. Other steps performed as part of the context switch may be performed before or after steps404-410.

According to an implementation, in response to the event created at step408, the operating system304alters operation of the thread300and/or process302in order to mitigate subsequent row hammer attacks by the process302. This action may be selected from the following options:

3. Restart the workload312of the thread300.

According to an implementation, the mitigation action is performed as part of the context switch performed prior to starting execution of the different execution context. The operating system304tracks row hammer alerts received over time for the process302and escalates each time a row hammer alert is received. For example, for a first row hammer alert, a first level of throttling is performed. For a second row hammer alert, a second, greater, level of throttling is performed. For a third row hammer alert, the process302is ended and the executable being executed by the process302is flagged as having excessive row hammer risk. The executable may be malware that needs to be removed or as a legitimate application that will need to be modified to prevent row hammer events.