Memory poisoning with hints

A method and system for storing hints in poisoned data of a computer system memory includes receiving poisoned data in a component of the system; forwarding the poisoned data to a memory controller of the system; and forwarding additional data regarding the poisoned data to a memory controller. The memory controller writes the poisoned data to the system memory wherein the written poisoned data includes a poison signature and a hint based on the additional data regarding the poisoned data; and when the written poisoned data is read signaling a system error and returning the poison signature and the hint to a system software of the system.

BACKGROUND INFORMATION

In computer systems Memory Poisoning refers to the process of storing a special signature in memory to identify bad or corrupted memory data and warn the system when this bad data is eventually read, thereby enabling Enhanced Error Containment and Recovery (EECR). There are several conditions that can give rise to bad memory data, for example:

PCI Express packets with corrupted data received from a PCI Express endpoint performing a direct memory access write operation; or

Cache lines with corrupted data received from the last level cache, e.g., data corruption during the process of write-back operations.

In current implementations, memory poisoning involves storing a special poison signature to identify the poisoned memory data. For example, an implementation could set the data bits all to 0's, and the parity bits all to 1's. In such an implementation, the poisoned data itself doesn't convey any further meaning to the system. Therefore, the main function of memory poisoning in current implementations today is restricted to allowing the memory controller to store corrupted data in memory as a poison that is unusable, such that the memory controller can recognize the presence of the corrupted data on a subsequent access to the data, reject the request and raise an alert to the caller to do the same and/or take appropriate corrective actions. Because such poisoned data does not provide any further information related to the source of the poison or the way this error needs to be handled, the system must rely on other means such as special logging registers (which are expensive to implement in hardware) to track the source of the error, whenever the poisoned memory is eventually read (consumed). This may also involve costly and time consuming procedures like scanning through the entire system hardware to trace the source of the error.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Embodiments of the present invention include methods and systems for memory poisoning that use the poisoned (e.g. bad or corrupted) memory data itself to store a hint regarding the poisoned data, for example, the source of the poisoned data. This may be accomplished in embodiments of the present invention because the memory location to which the poisoned memory data is written may include a special poison signature to signify the bad or corrupted nature of the data and a hint in the data field itself that provides further information regarding the poisoned memory data.

Embodiments of the present invention will now be described in detail, by way of example only, with reference to the accompanying drawings in which identical or corresponding parts/features are provided with the same reference numerals in the figures.

FIG. 1is a block diagram of a system100for storing hints in poisoned data in accordance with an example embodiment of the present invention showing the flow of poisoned data. System100includes a CPU105and a system memory110. Other components of the system100may communicate with the CPU105, for example, a PCI Express device115or a higher level cache (not shown). The CPU105may include components such as PCI Express root port125or last level cache130that may communicate with other components of system100, such as the above mentioned other components (e.g.115) of the system100, and may also communicate with a memory controller120of system100. Accordingly, a component of system100such as PCI Express root port125may receive poisoned data, for example, a bad or corrupted Transaction Layer Packet (TLP) packet135from PCI Express device115125or last level cache130may receive poisoned data, for example, bad or corrupted data140received from a higher level cache (not shown). The poisoned data received by these components (e.g.125,130) may be forwarded to memory controller120by the receiving component, for example, in a direct memory access operation155by PCI Express root port125or a writeback operation165by last level cache130, and placed in a queue145of pending requests to the memory controller120. In addition, the receiving component (e.g.125,130) may forward additional data (e.g.160or170) regarding the poisoned data (e.g.135,140) to the memory controller120. The additional data may include, for example, the source of the poisoned data and/or suggestions for handling the poisoned data. The memory controller120may then, in turn, write the poisoned data (e.g.135,140) to the system memory110in a write operation175. This writing operation175may include writing the poisoned data (e.g.135or140) to the system memory110such that it includes a poison signature to identify the poisoned (bad or corrupted) nature of the data and/or a hint based on the additional data regarding the poisoned data (e.g. written memory locations180or190). Specific examples of such hints are described in more detail below with respect toFIGS. 3A-3Band may include: a data field, called the hint packet, or simply the hint, that contains information about the poison source or any additional/related data such as the preferred method for handling the poison consumption or a pointer to a hint table in system memory110that contains such information. For example, if the poison data was received in a bad TLP packet sent by the PCI Express device115, then the Requester ID of that device could be stored in the hint packet. If/when the written poisoned data (e.g. at180or190) is eventually read or consumed a system error may be signaled by the memory controller120which also returns the poison signature and the hint, stored at memory locations180or190to a system software (e.g. operating system (OS) or basic input-output system (BIOS)) of the system100.

In such a system100, forwarders of poisoned data—such as the PCI Express root port125or last level cache130—pass additional information (e.g.160or170) to the memory controller120, such as the poison source (e.g. Requester ID of PCI Express device115), along with the poison data (e.g.135or140) itself. The memory controller120may then use this combination of information to construct the hint as well as the poison signature, as shown inFIG. 1. When the poisoned memory (stored at memory locations180or190) is finally consumed (read), the memory controller120may proceed to complete the operation, signal a platform error, and also return the hint into the calling logic of a system software of system100for further analysis. This enables the calling software to then interpret and report the hint as a part of the regular error reporting mechanism (e.g. Machine Check Data).

Therefore, the poison hint may help improve system reliability, availability, and serviceability (RAS) and Enhanced Error Containment and Recovery (EECR) in several ways:

1. It may quickly associate a poisoned memory data (e.g.180or190) with its source (e.g. PCI Express device115) and when the poisoned memory (e.g.180or190) is consumed, the memory controller120may quickly retrieve the source information from the hints, and present that information (e.g. Requester ID of PCI Express device115) to the system software (OS, BIOS) without the need to scan the entire system100;

2. Because the hint is co-located with the poison signature (e.g. stored at memory locations180or190), such a system100may help to avoid the need for expensive log registers in Silicon. For example, a hint table in system memory110may be built to contain as many error logs as needed for handling simultaneous errors (i.e. simultaneous reading of poisoned data which results in an error signal from memory controller120);

3. Additionally, such a system100allows for the flexibility to implement a variety of schemes for providing hints. For example, the hint could include a preferred method of handling the poisoned data (e.g.135,140), for example: Message Signaled Interrupt (MSI), System Management Interrupt (SMI), or Machine Check Exception (MCE), plus the location of the poison source. Alternatively, a particular hint could involve a pointer to an error recovery method or the hint could instruct the system100to be reset; and

4. Furthermore, in such a system100, cache lines in the last level cache130that belong to protected memory regions (e.g., critical OS/platform data or code) could be subject to malware attack. When these cache lines are written back to memory, for example in a writeback operation165, the memory controller120may write them (175) to the system memory110as poisoned data with hints to indicate a malware attack and/or to point to the source of the attack and initiate attack recovery. For example, the hint could be the logical processor ID that triggered the malicious write operation175and the system software (e.g. the OS) can then choose to terminate the system software task running on that logical processor. Thus, the poison hint can assist platform robustness and enable recovery from cache-based malware attacks.

FIG. 2is a flow chart of a method for storing hints in poisoned memory data of a system memory of a computer system according to an example embodiment of the present invention. In a first operation200, poisoned data (e.g.135or140) is received in a component (e.g.125,130,404,409,412or430) of the computer system (e.g.100,305,310,400). In operation210, the poisoned data (e.g.135or140) is forwarded by the receiving component (e.g.125,130,404,409,412or430), for example, in a direct memory access operation (e.g.155) by a PCI Express root port (e.g.125) or a writeback operation (e.g.165) by a last level cache (e.g.130) to a memory controller (e.g.120,416), and placed in a queue (e.g.145) of pending requests to the memory controller (e.g.120,416). In operation220the receiving component (e.g.125,130,404,409,412or430) forwards additional data (e.g.160or170) regarding the poisoned data (e.g.135or140) to the memory controller (e.g.120,416). As explained above the additional data (e.g.160or170) may include, for example, the source of the poisoned data (e.g. Requester ID of PCI Express device115) or suggestions for handling the poisoned data. In operation230the poisoned data (e.g.135or140) is written (e.g.175) by the memory controller (e.g.120,416) to the system memory (e.g.110,420) wherein the written poisoned data (e.g.180or190) includes a poison signature (e.g.182or192) and a hint (e.g.184or194) based on the additional data (e.g.160or170) regarding the poisoned data (e.g.135or140). For example, the hint could indicate the source of the poisoned data (e.g. PCI Express device115or higher level cache lines) and if/when the source of the poisoned data is a protected memory region (e.g., critical OS/platform data or code) of the system (e.g.100,305,310,400) the memory controller (e.g.120,416) may flag the source (e.g. higher level cache lines) of the poisoned data (e.g.140) as being under malware attack by including an indication of the malware attack in the hint constructed for said poisoned data (e.g.140). In optional operation240, if/when the written poisoned data (e.g. at180or190) is consumed (read) a system error is signaled by the memory controller (e.g.120,416) which also returns the poison signature and the hint to a system software of the system (e.g.100,305,310,400).

Systems305and310, shown inFIGS. 3A and 3B, differ from system100, shown inFIG. 1, only in the details of the poison signature (e.g.182,192) and hint (e.g.184,194) constructed by the memory controller120at memory location180and190based on poisoned data (e.g.135or140) and additional data (e.g.160or170) regarding the poisoned data (e.g.135or140). In order to avoid repetition, the subsequent descriptions are limited to this aspect of the systems305and310. Specific examples of hints (e.g.184,194) are described in more detail below with respect toFIGS. 3A and 3Band may include: a data field, called the hint packet, or simply the hint, that contains information about the poison data (e.g.135or140) or a pointer to a hint table in system memory110that contains such information.

FIG. 3Ais a block diagram of a system for storing hints in poisoned data in accordance with an example embodiment of the present invention showing the flow of poisoned data. InFIG. 3A, as inFIG. 1, the receiving component (e.g.125,130) may forward additional data (e.g.160or170) regarding the poisoned data (e.g.135,140) to the memory controller120. As explained above, the additional data (e.g.160or170) may include, for example, the source of the poisoned data (e.g.135,140) and/or suggestions for handling the poisoned data (e.g.135,140). The memory controller120may then, in turn, write the poisoned data (e.g.135,140) to the system memory110in a write operation175. This writing operation175may include writing the poisoned data (e.g.135or140) to the system memory110such that it includes a poison signature (e.g.182,192) to identify the poisoned (bad or corrupted) nature of the data and/or a hint (e.g.184,194) based on the additional data (e.g.160or170) regarding the poisoned data (e.g.135,140). In system305the hints184and194include a data field, called the hint packet, or simply the hint, that may contain data about the poison source or any additional/related information such as a preferred method to handle the poison consumption. For example, if the poison data was received in a bad TLP packet sent by a PCI Express device115, then the Requester ID of that device could be stored in the hint packet. Alternatively or in addition the hint could include a preferred method of handling the poisoned data (e.g.135,140), for example: Message Signaled Interrupt (MSI), System Management Interrupt (SMI), or Machine Check Exception (MCE). As inFIG. 1, if/when the written poisoned data (e.g.182,192,184,194) is read a system error may be signaled by the memory controller120which also returns the poison signature (e.g.182,192) and the hint (e.g.184,194) to a system software (e.g. OS or BIOS) of the system100.

FIG. 3Bis a block diagram of a system for storing hints in poisoned data in accordance with an example embodiment of the present invention showing the flow of poisoned data. InFIG. 3A, as inFIG. 1, the receiving component (e.g.125,130) may forward additional data (e.g.160or170) regarding the poisoned data (e.g.135,140) to the memory controller120. As explained above, the additional data (e.g.160or170) may include, for example, the source of the poisoned data (e.g.135,140) and/or suggestions for handling the poisoned data (e.g.135,140). The memory controller120may then, in turn, write the poisoned data (e.g.135,140) to the system memory110in a write operation175. This writing operation175may include writing the poisoned data (e.g.135or140) to the system memory110such that it includes a poison signature (e.g.182,192) to identify the poisoned (bad or corrupted) nature of the data and/or a hint (e.g.184,194) based on the additional data (e.g.160or170) regarding the poisoned data (e.g.135,140). In system310the hints184and194include pointers to table entries (e.g. indexes: I1and I2) of a hint table199in system memory110. The indexes (e.g. I1and I2) may contain data about the poison source or any additional/related information such as a preferred method to handle the poison consumption. For example, if the poison data was received in a bad TLP packet sent by a PCI Express device115, then the Requester ID of that device could be stored in an index (e.g. I1and I2) of the hint table199. Alternatively or in addition the hint table may include a preferred method of handling the poisoned data (e.g.135,140), for example: a particular hint could involve a pointer to an error recovery method or a pointer to an instruction for the system310to be reset. The hint table199in system memory110may be built to contain as many error logs (e.g. indexes: I1and I2) as needed for handling simultaneous errors (i.e. simultaneous reading of poisoned data which results in an error signal from memory controller120). As inFIG. 1, if/when the written poisoned data (e.g.182,192,184,194) is read a system error may be signaled by the memory controller120which also returns the poison signature (e.g.182,192) and the hint (e.g.184,194) to a system software (e.g. OS or BIOS) of the system100.

FIG. 4is a block diagram of a system for storing hints in poisoned data in accordance with an example embodiment of the present invention. System400includes a memory controller416(the system logic chip416coupled to the processor bus410and memory420in the illustrated embodiment is a memory controller hub (MCH416)) which can process data, in accordance with the present invention, such as in the embodiment described herein. System400is representative of processing systems based on the PENTIUM® III, PENTIUM® 4, Xeon™, Itanium®, XScale™ and/or StrongARM™ microprocessors available from Intel Corporation of Santa Clara, Calif., although other systems (including PCs having other microprocessors, engineering workstations, set-top boxes and the like) may also be used. In one embodiment, sample system400may execute a version of the WINDOWS™ operating system available from Microsoft Corporation of Redmond, Washington, although other operating systems (UNIX and Linux for example), embedded software, and/or graphical user interfaces, may also be used. Thus, embodiments of the present invention are not limited to any specific combination of hardware circuitry and software.

Embodiments are not limited to computer systems. Alternative embodiments of the present invention can be used in other devices such as handheld devices and embedded applications. Some examples of handheld devices include cellular phones, Internet Protocol devices, digital cameras, personal digital assistants (PDAs), and handheld PCs. Embedded applications can include a micro controller, a digital signal processor (DSP), system on a chip, network computers (NetPC), set-top boxes, network hubs, wide area network (WAN) switches, or any other system that can perform one or more instructions in accordance with at least one embodiment.

FIG. 4is a block diagram of a computer system400formed with processor402that includes an execution unit408and a register file406for storing different types of data in various registers. One embodiment may be described in the context of a single processor desktop or server system, but alternative embodiments can be included in a multiprocessor system. System400is an example of a ‘hub’ system architecture. The computer system400includes a processor402to process data signals. The processor402is coupled to a processor bus410that can transmit data signals between the processor402and other components in the system400. The elements of system400perform their conventional functions that are well known to those familiar with the art.

In one embodiment, the processor402includes a Level 1 (L1) internal cache memory404. Depending on the architecture, the processor402can have a single internal cache or multiple levels of internal cache. Alternatively, in another embodiment, the cache memory can reside external to the processor402. Other embodiments can also include a combination of both internal and external caches depending on the particular implementation and needs. Register file406can store different types of data in various registers including integer registers, floating point registers, status registers, and instruction pointer register.

System400includes a memory420. Memory420can be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, flash memory device, or other memory device. Memory420can store instructions and/or data represented by data signals that can be executed by the processor402.

A system logic chip416is coupled to the processor bus410and memory420. The system logic chip416in the illustrated embodiment is a memory controller hub (MCH416). The processor402can communicate to the MCH416via a processor bus410. The MCH416provides a high bandwidth memory path418to memory420for instruction and data storage and for storage of graphics commands, data and textures. The MCH416is to direct data signals between the processor402, memory420, and other components in the system400and to bridge the data signals between processor bus410, memory420, and system I/O422. In some embodiments, the system logic chip416can provide a graphics port for coupling to a graphics controller412. The MCH416is coupled to memory420through a memory interface418. The graphics card412is coupled to the MCH416through an Accelerated Graphics Port (AGP) interconnect414.

In such a system400, potential forwarders of poisoned data to the MCH416—such as404,409,412or430—also pass additional information to the MCH416, such as the poison data source (e.g. Requester ID of a PCI Express device in communication with PCI Express root port409), along with the poison data itself. The MCH416may then use this combination of information to construct a hint as described above as well as a poison signature when it writes the data to system memory420. When the poisoned memory (stored in system memory420) is finally consumed (read), the MCH416may proceed to complete the operation, signal a system error, and also return the constructed hint into the calling logic of a system software of system400for further analysis. This enables the calling software to then interpret and report the hint as a part of the regular error reporting mechanism (e.g. Machine Check Data).

System400uses a proprietary hub interface bus422to couple the MCH416to the I/O controller hub (ICH)430. The ICH430provides direct connections to some I/O devices via a local I/O bus and may include a PCI Express root port409. The local I/O bus is a high-speed I/O bus for connecting peripherals to the memory420, chipset, and processor402. Some examples are the audio controller, firmware hub (flash BIOS)428, wireless transceiver426, data storage424, legacy I/O controller containing user input and keyboard interfaces, a serial expansion port such as Universal Serial Bus (USB), and a network controller434. The data storage device424can comprise a hard disk drive, a floppy disk drive, a CD-ROM device, a flash memory device, or other mass storage device.

For another embodiment of a system, an instruction in accordance with one embodiment can be used with a system on a chip. One embodiment of a system on a chip comprises of a processor and a memory. The memory for one such system is a flash memory. The flash memory can be located on the same die as the processor and other system components. Additionally, other logic blocks such as a memory controller or graphics controller can also be located on a system on a chip.

While certain exemplary embodiments have been described and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art upon studying this disclosure. In an area of technology such as this, where growth is fast and further advancements are not easily foreseen, the disclosed embodiments may be readily modifiable in arrangement and detail as facilitated by enabling technological advancements without departing from the principles of the present disclosure or the scope of the accompanying claims.