Hardware apparatus and method for memory corruption detection

Abstract

Methods and apparatus relating to memory corruption detection are described. In one embodiment, a hardware processor includes an execution unit to execute an instruction to request access to a block of memory through a pointer to the block of memory, and a memory management unit to manage the memory. The memory management unit is configured to allow access to the block of the memory when a memory corruption detection value in the pointer is verified with a memory corruption detection value in the memory for the block, where a location of the memory corruption detection value in the pointer is selectable between a first location and a second, different location.

Description

This application is a divisional application filed again for the divisional application 202110829232.8. The divisional application 202110829232.8 is a divisional application of the application with PCT international application number PCT / US2016 / 063211, international application date November 22, 2016, application number 201680067172.8 entering the Chinese national phase, and titled “Hardware device and method for memory corruption detection”. Technical Field

[0001] The present disclosure relates generally to electronics and, more particularly, embodiments of the present disclosure relate to hardware processors having memory corruption detection hardware. Background Art

[0002] A processor or set of processors executes instructions from an instruction set, such as an instruction set architecture (ISA). An instruction set is the programming-related portion of a computer architecture and generally includes native data types, instructions, register architecture, addressing modes, memory architecture, interrupt and exception handling, and external input and output (I / O). It should be noted that the term "instruction" is generally used herein to refer to macroinstructions, such as instructions provided to a processor for execution, or to microinstructions, such as instructions generated by a processor's decoder decoding a macroinstruction. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure is illustrated by way of example and not by way of limitation in the accompanying figures in which like reference numerals indicate similar elements and in which:

[0004] Figure 1 A hardware processor according to an embodiment of the present disclosure is illustrated.

[0005] Figure 2 Memory corruption detection (MCD) according to an embodiment of the present disclosure is illustrated.

[0006] Figure 3 A pointer format having an address field and without a memory corruption detection (MCD) value field is illustrated according to an embodiment of the present disclosure.

[0007] Figure 4 A pointer format having an address field and a memory corruption detection (MCD) value field is illustrated according to an embodiment of the present disclosure.

[0008] Figure 5 A pointer format having an address field, a memory corruption detection (MCD) space field, and a memory corruption detection (MCD) value field according to an embodiment of the present disclosure is illustrated.

[0009] Figure 6FIG. 1 illustrates a data format of a register used for memory corruption detection (MCD) according to an embodiment of the present disclosure.

[0010] Figure 7 A memory corruption detection (MCD) system with a memory management unit according to an embodiment of the present disclosure is illustrated.

[0011] Figure 8 A memory management unit according to an embodiment of the present disclosure is illustrated.

[0012] Fig. 9 A pointer format having an address field and without a memory corruption detection (MCD) value field is illustrated according to an embodiment of the present disclosure.

[0013] Fig.10 A pointer format having an address field and without a memory corruption detection (MCD) value field is illustrated according to an embodiment of the present disclosure.

[0014] Fig.11 A pointer format having an address field, a memory corruption detection (MCD) space field, and a memory corruption detection (MCD) value field according to an embodiment of the present disclosure is illustrated.

[0015] Fig. 12A A linear address space according to an embodiment of the present disclosure is shown.

[0016] Fig. 12B According to an embodiment of the present disclosure, Fig. 12A A view of a portion of the linear address space in .

[0017] Fig. 12C The embodiment according to the present disclosure is shown in FIG. Fig. 12B A view of a portion of the linear address space in a memory controller having a subset of the space protected by memory corruption detection (MCD).

[0018] Fig.13 A pointer format having an address field and without a memory corruption detection (MCD) value field is illustrated according to an embodiment of the present disclosure.

[0019] Fig.14 A pointer format having an address field, a memory corruption detection (MCD) space field, and a memory corruption detection (MCD) value field according to an embodiment of the present disclosure is illustrated.

[0020] Fig.15A A linear address space according to an embodiment of the present disclosure is shown.

[0021] Fig. 15B According to an embodiment of the present disclosure, Fig.15A A view of a portion of the linear address space in .

[0022] Fig. 15C The embodiment according to the present disclosure is shown in FIG. Fig. 12B A view of a portion of the linear address space in a memory corruption detection (MCD) protected space.

[0023] Fig.16 A pointer format having an address field, a memory corruption detection (MCD) space field, and a memory corruption detection (MCD) value field according to an embodiment of the present disclosure is illustrated.

[0024] Fig.17A A linear address space according to an embodiment of the present disclosure is shown.

[0025] Fig. 17B According to an embodiment of the present disclosure, Fig.17A A view of a portion of the linear address space in .

[0026] Fig. 17C The embodiment according to the present disclosure is shown in FIG. Fig. 17B A view of a portion of the linear address space in having a subset of the space protected by memory corruption detection (MCD).

[0027] Fig.18 A flow chart according to an embodiment of the present disclosure is shown.

[0028] Fig.19A is a block diagram illustrating an exemplary in-order pipeline and an exemplary register-renaming out-of-order issue / execution pipeline according to various embodiments of the present disclosure.

[0029] Fig.19B is a block diagram illustrating an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue / execution architecture core to be included in a processor according to various embodiments of the present disclosure.

[0030] Fig. 20A is a block diagram of a single processor core and its connection to an on-die interconnect network and its local subset of a level 2 (L2) cache in accordance with an embodiment of the present disclosure.

[0031] Fig. 20B According to each embodiment of the present disclosure Fig. 20A An expanded view of a portion of a processor core in FIG.

[0032] Fig.21 is a block diagram of a processor that may have more than one core, may have an integrated memory controller, and may have integrated graphics according to an embodiment of the present disclosure.

[0033] Fig. 22 is a block diagram of a system according to one embodiment of the present disclosure.

[0034] Fig.23 is a block diagram of a more specific exemplary system according to an embodiment of the present disclosure.

[0035] Fig.24 Shown is a block diagram of a second more specific exemplary system according to an embodiment of the present disclosure.

[0036] Fig.25 Shown is a block diagram of a system on a chip (SoC) according to an embodiment of the present disclosure.

[0037] Fig.26 is a block diagram of converting binary instructions in a source instruction set into binary instructions in a target instruction set using a software instruction converter according to various embodiments of the present disclosure. DETAILED DESCRIPTION

[0038] In the following description, numerous specific details are set forth. However, it should be understood that embodiments of the present disclosure may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques are not shown in detail to avoid obscuring the understanding of this description.

[0039] References in the specification to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered to be within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0040] A (e.g., hardware) processor (e.g., having one or more cores) may execute instructions to operate on data, for example, to perform arithmetic, logic, or other functions. A hardware processor may access data in a memory (e.g., a data storage device). In one embodiment, the hardware processor is a client requesting access to (e.g., loading or storing) data, and the memory is a server containing the data. In one embodiment, a computer includes a hardware processor requesting access to (e.g., loading or storing) data, and the storage is local to the computer. The memory may be divided into separate rows of data (e.g., one or more cache rows), which may be managed as units, for example, for consistency purposes. In some embodiments, a (e.g., data) pointer (e.g., address) is a value that references (e.g., points to) a data location, for example, a pointer may be a (e.g., linear) address, and data may be stored at that (e.g., linear) address. In some embodiments, the memory may be divided into multiple rows, and each row may have its own (e.g., unique) address. For example, a memory row may include storage for 512-bit, 256-bit, 128-bit, 64-bit, 32-bit, 16-bit, or 8-bit data.

[0041] In some embodiments, memory corruption (e.g., caused by an attacker) may be caused by an out-of-bounds access (e.g., a memory access using the base address of a block of memory and an offset that exceeds the allocated block size) or by a dangling pointer (e.g., a pointer referencing a block of memory (e.g., a buffer) that has been deallocated).

[0042] Certain embodiments herein may utilize memory corruption detection (MCD) hardware and / or methods to, for example, prevent out-of-bounds accesses or accesses with dangling pointers.

[0043] Go to the attached picture, Figure 1A hardware processor 100 is illustrated according to an embodiment of the present disclosure. The depicted hardware processor 100 includes a hardware decode unit 102 for decoding an instruction, such as an instruction for requesting access to a block of memory 110 via a pointer 105 pointing to the block of memory 110. Pointer 105 may be an operand of the instruction. The depicted hardware execution unit 104 is for executing a decoded instruction, such as a decoded instruction for requesting access to a block of memory 110 via a pointer 105 pointing to the block of memory 110 (e.g., having a value of (e.g., linear) address 114). In one embodiment, a block of data is a single row of data. In one embodiment, a block of data is a plurality of rows of data. For example, a block of memory may be data of rows 1 and 2 of a (e.g., linear or physical) addressable memory 112 of memory 110, including a pointer 105 pointing to one (e.g., first) row (e.g., row 1) (e.g., having an address value 114). Some embodiments may have a memory with a total size of X number of rows.

[0044] The hardware processor 100 may include one or more registers 108, e.g., control registers or configuration registers, such as, but not limited to, model-specific registers (MSRs) or other registers. In one embodiment, a value stored in a control register is used to change (e.g., control) a selectable feature (e.g., a feature of the hardware processor).

[0045] The hardware processor 100 includes a coupling (e.g., connection) to a memory 110. The memory 110 may be a memory local to the hardware processor (e.g., system memory). The memory 110 may be a memory separate from the hardware processor, for example, a memory of a server. Note that the figures herein may not depict all data communication connections. Those skilled in the art will recognize that this is done so as not to obscure certain details in the figures. Note that a bidirectional arrow in the figures may not require bidirectional communication, for example, it may indicate unidirectional communication (e.g., to or from that component or device). Any or all combinations of the communication paths may be used in certain embodiments herein.

[0046] The hardware processor 100 includes a memory management unit 106 to, for example, perform and / or control (e.g., execution unit 104) access to memory (e.g., addressable memory 112). In one embodiment, the hardware processor includes a connection to the memory. Additionally or alternatively, the memory management unit 106 may include a connection to the memory 110 (e.g., addressable memory 112 and / or memory corruption detection table 116).

[0047] Certain embodiments may include a memory corruption detection (MCD) feature, for example, in a memory management unit. Certain embodiments may utilize a memory corruption detection (MCD) value in each pointer and a corresponding (e.g., matching) MCD value for the pointed-to memory maintained in memory, the corresponding (e.g., matching) MCD value being maintained, for example, as metadata (e.g., data describing other data) for each block of data pointed to by the pointer. The MCD value may be a sequence of bits, for example, 2 bits, 3 bits, 4 bits, 5 bits, 6 bits, 7 bits, 8 bits, 9 bits, 10 bits, 11 bits, 12 bits, 13 bits, 14 bits, 15 bits, 16 bits, etc. In one embodiment, a memory corruption detection (MCD) hardware processing system or processor (e.g., a processor or a memory management unit of a system) is used to validate pointers generated by instructions of an application being executed by the processing system or processor requesting access to memory.

[0048] Certain embodiments herein (e.g., of a setup of MMU circuitry) utilize one or more of the following attributes of memory corruption detection: MCD is enabled (e.g., for turning an MCD feature on or off); MCD location (e.g., for defining the location of (multiple) bits of an MCD value (metadata) in a pointer); a prefix in the MCD protected space, e.g., the location of the most significant bit of a pointer (e.g., for defining a linear address range that will be protected by the architecture); and an MCD directory base address (e.g., for pointing to a table (e.g., directory) of memory MCD values ​​(e.g., metadata)).

[0049] Certain embodiments herein allow flexible placement of MCD values ​​(e.g., metadata bits) into pointers, e.g., not limited to the most significant bits. Certain embodiments herein allow for smaller address spaces to be exploited (e.g., reducing linear address space overhead) and / or allow for scaling of (e.g., 64-bit) paging modes. Certain embodiments herein allow for protection of only a subset (e.g., a portion) of memory using MCDs through protected space selection (e.g., selecting (multiple) addresses to be protected using MCDs, and not protecting other addresses using MCDs).

[0050] exist Figure 1In the present disclosure, a memory management unit 106 (e.g., a hardware memory management unit) of a hardware processor 100 may receive a request to access (e.g., load or store) a memory 110 (e.g., an addressable memory 112). The request may include a pointer 105 (e.g., having an address value 114), which is passed in as an operand (e.g., directly or indirectly) of an instruction. The pointer may include a memory corruption detection (MCD) value as part of (e.g., a field) the pointer. A multi-row block of memory may include an MCD value for that block, e.g., the same MCD value for all rows in that block, and the MCD value for that block is used to correspond (e.g., match) with an MCD value within a pointer to that block. The memory management unit 106 (e.g., circuitry of the memory management unit 106) may perform an MCD validation check (e.g., to allow or deny access) according to the present disclosure.

[0051] Figure 2 Memory corruption detection (MCD) is illustrated in accordance with an embodiment of the present disclosure. A processing system or processor may maintain a metadata table (e.g., MCD table 116 or MCD table 216) that stores an MCD value (e.g., MCD identifier) ​​for each of a plurality of rows of blocks of memory, such as a plurality of rows of a predetermined size (e.g., 64 bytes, although other row sizes may be utilized). In one embodiment, when a block of memory is allocated to a (e.g., newly created) memory object, a unique MCD value is generated and associated with one or more rows of that block. The MCD value may be stored in one or more (e.g., metadata) table entries corresponding to the block of memory being allocated for the (e.g., newly created) memory object. In Figure 2 , data row 1 and data row 2 are depicted as being assigned to object 1 (e.g., as a data block), and the MCD value (shown here as "2") is associated in the MCD table 216, e.g., such that each data row is associated with an entry in the MCD table 216 indicating the MCD value (e.g., "2") for that block. Figure 2 , data rows 3-5 are depicted as being allocated to object 2 (e.g., as a data block), and the MCD value (shown here as "7") is associated in the MCD table 216, e.g., such that each data row is associated with an entry in the MCD table 216 indicating the MCD value (e.g., "7") for that block. In one embodiment, the MCD table 216 has an MCD value field for each corresponding row of the addressable memory 112.

[0052] In some embodiments, the generated MCD value, or a different value that corresponds to or maps to the generated MCD value for the data block, is stored in one or more bits of a pointer, such as a pointer returned by a memory allocation routine to an application requesting the memory allocation. Figure 2 , pointer 215 includes an MCD value field 217A having an MCD value ("2") and an address field 215B having a value of the (e.g., linear) address for (e.g., the first row of) the object 1 block of memory. Figure 2 , pointer 217 includes an MCD value field 217A having an MCD value ("7") and an address field 217B having a value of a (eg, linear) address of (eg, the first row of) an object 2 block of memory.

[0053] In certain embodiments, in response to receiving a memory access instruction (e.g., as determined from an opcode of the instruction or an attempt to access memory), a processing system or processor compares an MCD value retrieved from an MCD table (e.g., for a block of data to be accessed) with an MCD value from a pointer specified by the memory access instruction (e.g., extracted from the pointer). In one embodiment, when the two MCD values ​​match, access to the block of data is granted. In one embodiment, when the two MCD values ​​mismatch, access to the block of data is denied, for example, a page fault may be generated. In one embodiment, an MCD table (e.g., MCD table 116 or MCD table 216) may be in a linear address space of a memory. In one embodiment, circuitry and / or logic for performing an MCD validation check (e.g., in a memory management unit (MMU) 106) is used to access memory, but other portions of the processor (e.g., an execution unit) are used to not access the memory unless the MCD validation check passes (e.g., a match is true). In one embodiment, the request for access to a block of memory is a load instruction. In one embodiment, the request for access to a block of memory is a store instruction.

[0054] exist Figure 2, a request to access an object 1 block in addressable memory 212 of memory 210 may initiate (e.g., by a memory management unit) a read of pointer 215 to obtain an MCD value ("2") in MCD value field 215 and a (e.g., linear) address in address field 215B. Subsequently, the system (e.g., a processor) may perform a validation check, for example, by loading an MCD value from an MCD table in memory 210 to obtain one or more rows to be accessed, and comparing the MCD value to the MCD value in pointer 215 pointing to the one or more rows. In some embodiments, if the system determines that the MCD values ​​match (e.g., in this embodiment, both MCD values ​​are "2"), the system allows access (e.g., read and / or write) to the memory (e.g., data row 1 only, or data rows 1 and 2). In some embodiments, if there is no match, the request is denied (e.g., the instruction making the request may fail). In one embodiment, the request for access to the object 1 block may include a request for access to all rows in the object (data row 1 and data row 2), and the system may perform a validation check on data row 1 (e.g., as discussed above), and may perform a second validation check on data row 2. For example, the system (e.g., a processor) may perform a validation check on row 2 by loading an MCD value for row 2 (e.g., an MCD value of "2") from MCD table 216 in memory 210, and comparing the MCD value to the MCD value in pointer 215. In some embodiments, if the system determines that the MCD values ​​match (e.g., in this embodiment, both MCD values ​​are "2"), the system allows access (e.g., read and / or write) to the memory (e.g., data row 2 only).

[0055] Figure 3 A pointer format 301 with an address field 300 and without a memory corruption detection (MCD) value field is illustrated according to an embodiment of the present disclosure. In one embodiment, the address field 301 contains the linear address of the data row storing the data to be accessed. The illustrated bit positions are examples. The pointer size of 64 bits is an example.

[0056] Figure 4A pointer format 400 having an address field 401 and a memory corruption detection (MCD) value field 403 is illustrated according to an embodiment of the present disclosure. In one embodiment, the MCD value field 403 is used to store an MCD value for a pointer, for example, where the MCD value and the address for the pointer are returned by a memory allocation routine to an application requesting memory allocation. The MCD value field 403 may be located at any position (e.g., place) in the pointer, for example, it is not fixed in one position. The MCD value 403 may have a size of 1 bit, 2 bits, 3 bits, 4 bits, 5 bits, 6 bits, 7 bits, 8 bits, 9 bits, 10 bits, etc. In one embodiment, the MCD value field is not in the most significant or least significant 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, etc. bits of the pointer. In one embodiment, the location of the memory corruption detection value in the pointer is selectable between a first position and a different second position. In one embodiment, the location of the memory corruption detection value in the pointer is selectable between a first position, a different second position, and a different third position. In one embodiment, the location of the memory corruption detection value in the pointer is selectable between a first location, a different second location, a different third location, and a different fourth location, etc. In one embodiment, the plurality of different locations include non-overlapping one or more bit locations. In one embodiment, the plurality of different locations include overlapping one or more bit locations.

[0057] Figure 5 A pointer format 500 is illustrated having an address field 501, a memory corruption detection (MCD) protected space field 505, and a memory corruption detection (MCD) value field 503 according to an embodiment of the present disclosure. In one embodiment, the address field 501 is a linear address of a data row storing data to be accessed. In one embodiment, the MCD value field 503 is used to store an MCD value for the pointer. In one embodiment, the MCD protected space field 505 is used to store a value indicating whether the pointer points to a memory region that will cause an MCD validation check to be performed.

[0058] In one embodiment, the location of the memory corruption detection value in each pointer is selectable, e.g., at manufacturing time, at setup time, or by an application (e.g., software, such as but not limited to an operating system), e.g., during MCD feature activation. The location may be set in a hardware processor, e.g., by writing to a control (or configuration) register. In one embodiment, the space protected by the MCD (e.g., which subset(s) of memory are protected by the MCD feature) is selectable, e.g., at manufacturing time, at setup time, or by an application (e.g., software, such as but not limited to an operating system), e.g., during MCD feature activation. The protected space (e.g., less than all (addressable) memory) may be set in a hardware processor, e.g., by writing to a control (or configuration) register. In one embodiment, MCD hardware and methods, for example, via an ISA interface, for example, by software (e.g., OS), allow definition of one or more of the following: (1) the location of an MCD value (e.g., metadata) in a pointer, for example, which bits in a linear address in a pointer are used to store the MCD value; (2) an MCD protected space (e.g., range) that is used to define a subset of memory (e.g., addresses) that is subject to memory corruption detection (and, for example, address rows in memory that will have MCD values), for example, the MCD protected space can be a linear address bit prefix that defines a protected area or memory range that will be subject to memory corruption detection (and, for example, contain MCD values); and (3) a pointer (e.g., linear address pointer) to the base address of (multiple) memory MCD (e.g., metadata) tables. In one embodiment, for example, by having multiple attribute sets include the above information, multiple subsets of memory (e.g., regions) can be protected by MCD. In one embodiment, these attributes can be implemented (e.g., set) via registers (e.g., control and / or configuration registers).

[0059] In one embodiment, the pseudo code in Table 1 below may be used to check whether the linear address in the pointer is part of the MCD protected space (eg, such that an MCD validation check will be performed). Table 1 LA_Prefix=LA[63:(MCD.Position+6)] If(MCD.Enabled&&MCD.Prefix==LA_Prefix) MCD Check LA against MCD.MemoryMetadataTable In one embodiment, there are multiple regions (e.g., [i] with a different index i for each region), and each region to be protected by the MCD may be defined by one or more of: MCD[i].Enabled, MCD[i].Position, MCD[i].ProtectedSpace (e.g., MCD[i].Prefix), and MCD[i].BaseAddressOfMCDTable. In one embodiment, the (e.g., arbitrary) order of the space protected by the MCD may be as in the following pseudo code for N protected regions in Table 2: Table 2 For i=1toN LA_Prefix=LA[63:(MCD[i].Position+6)] If(MCD[i].Enabled&&MCD[i].Prefix==LA_Prefix) MCD Check against MCD[i].MemoryMetadataTable / / Control MCD[i].MemoryMetadataTable performs MCD inspection Break As noted above, the MCD value being 6 bits wide is merely an example, and other sizes may be utilized.

[0060] Figure 6The data format of register 608 for memory corruption detection (MCD) according to an embodiment of the present disclosure is illustrated. Although two registers are depicted, one or more registers may be utilized. In one embodiment, the control or configuration register may be a model-specific register (MSR). The MCD configuration register (CFG MSR) 620 may include one or more of the following: a space field 622 protected by memory corruption detection (MCD) (e.g., for setting which subset of memory will be protected by the MCD hardware and / or methods disclosed herein); a size field 626 (e.g., for setting the size (e.g., the number of bit positions) that the MCD value in the pointer and / or MCD table will include); and a position field 628 (e.g., for setting which bits in the pointer will be used as the MCD value, e.g., the first bit position or the last bit position of the MCD value). In one embodiment, one or more fields (e.g., reserved field 624) may not be used for MCD. The MCD control register (CTRL MSR) 630 may include one or more of the following: a base address 632 of an MCD table field (e.g., where the base address plus an offset (e.g., an offset from the address of the row(s) from the pointer) indicates the MCD value for the corresponding row in memory) and an enable field 638 (e.g., when set (e.g., to 1), MCD verification is enabled). In one embodiment, one or more fields (e.g., reserved field 634) are not used for MCD. In one embodiment, reserved fields (e.g., reserved field 624 and / or reserved field 634) are used to define different modes of behavior for MCD verification. Although bit positions (e.g., size) are listed, these are example embodiments, and other bit positions (e.g., size) may be used, for example, in certain embodiments, and in some embodiments, the bit positions may also be fixed (e.g., constant and non-configurable). In one embodiment, one or more of the above fields may be included in a single register, or each field may be in its own register.

[0061] A write to the register (e.g., a store instruction) may set one or more of the fields, e.g., a write from software to enable and / or set MCD protection. Multiple sets of MCD configuration and / or control registers may be utilized, e.g., MCDCFG MSR[i] and MCD CTRL MSR[i], e.g., where i may be any positive integer. In one embodiment, there is a different value of i for each subset (e.g., region) of memory to be protected by the MCD, e.g., where each subset (e.g., region) may have a different MCD table (e.g., and thus a different base address) and / or a different size, location, protected space, combinations of the above, and the like.

[0062] Figure 7A memory corruption detection (MCD) system 700 with a memory management unit 706 is illustrated in accordance with an embodiment of the present disclosure. In the depicted embodiment, the memory management unit 706 (e.g., memory management circuitry) is used to receive (e.g., from a configuration and / or control register) features to be enabled, such as the location of an MCD value in a pointer and / or the location of an MCD table for a row in a memory. In the depicted embodiment, the memory management unit 706 is used to receive a pointer (e.g., for a memory access request). In one embodiment, the memory management unit 706 may perform a linear address translation on the address value from the pointer to determine the linear address of the row of memory pointed to by the pointer. In one embodiment, the memory management unit 706 removes the MCD value in the pointer from the linear address. In one embodiment, the memory management unit inserts a value into the bit position of the removed MCD value. For example, all removed bits from the removed value may be replaced with all zeros or all ones, for example, matching the value of the most significant bit (e.g., bit position 63) of the pointer. The linear address without the MCD value may be utilized to obtain the associated MCD value for the row of memory 710. The MCD value in the pointer may then be compared to the MCD value in the table for the row being pointed to to determine (e.g., by the memory management unit 706) whether there is a match. In some embodiments, if the MCD values ​​match, the data request is fulfilled. In some embodiments, if the MCD values ​​do not match, the data request is rejected.

[0063] Figure 8 The memory management unit 806 according to an embodiment of the present disclosure is illustrated. Figure 8 In the depicted circuit in FIG. 8 , a hardware comparator 840 is used to compare a space value (eg, a configuration register (eg, Figure 6 The bit position 63:(X+6) of the CFGMSR 620) is the same as the bit position (e.g., 63:(X+6)) of the pointer (e.g., Figure 5 In the depicted embodiment, if the output of the comparator is true (e.g., binary 1) and the MCD enable bit is enabled (e.g., Figure 6CTRL MSR 630 is set to binary 1), then the logical AND gate 842 may output a signal (e.g., binary 1). The 1 from the logical AND gate may be a control signal to multiplexer 844, thereby resulting in the output of a pointer (e.g., a linear address) and the MCD value of the pointer being removed therefrom. In the depicted embodiment, each of the removed MCD value bits is replaced by the value in the most significant bit position of the pointer (bit position 63). A zero as a control signal to multiplexer 844 may result in the output of the original pointer (e.g., for a non-MCD protected area). The "1" output from the logical AND gate 842 may cause the logical AND gate 848 to output the result of a logical exclusive OR (XOR) gate multiplying the MCD value from the pointer (e.g., (X+5):X) and the number of bits in the MCD value in the pointer by the bit value from bit 63. In one embodiment, this is used to output the MCD value. In one embodiment for a normalized pointer (e.g., a pointer in which all normalized bits are exactly equal), XOR gate 846 is used to output an MCD value of 0. Fig.16 In the embodiment of the MCD value field, the MCD value field is stored in some of the normalized bits (62:57), and in the absence of MCD, all of these bits will be 0, and in the case of MCD, if those bits are 0, it means that the MCD value is 0. In reference to Fig.16 In one embodiment, with bit 63 being 1, without MCD, all those bits would be normalized (e.g., bits 63:56=1), and with MCD, if bits 62:57 are 1, then XORing bits 62:57 with bit 63 would also result in an MCD value of 0. In one embodiment, this causes all normalized pointers to have an MCD value of 0, which is beneficial in software implementations, for example. A zero to AND gate 848 would result in an output zero. A 1 from logical AND gate 842 could be an output as a signal that the input pointer is pointing to a memory row in a space protected by the MCD. A 0 from logical AND gate 842 could be an output as a signal that the input pointer is pointing to a memory row that is not in a space protected by the MCD. Note that 6 is an example bit size for an MCD value, and other sizes may be used.

[0064] The number of rows that a pointer of a certain size can uniquely identify is discussed below, for example, a 57-bit linear address can allow multiple unique pointers to 128 petabytes (PB).

[0065] Fig. 9A pointer format 900 is illustrated with an address field 901 and without a memory corruption detection (MCD) value field according to an embodiment of the present disclosure. For example, a 5-level paging operating system (OS) may support a 57-bit linear address in the address field 901 (e.g., in the 64-bit space in the pointer 900). The remaining seven high (e.g., most significant) linear bits may be normalized (e.g., so that all bits in bits 63:57 have the same value as bit 56).

[0066] Fig.10 A pointer format 1001 is illustrated with an address field 1000 and without a memory corruption detection (MCD) value field according to an embodiment of the present disclosure. For example, the OS may give the positive linear address space (e.g., bits 63:56 equal to 0) to software applications and reserve the negative linear address space (e.g., bits 63:56 equal to 1) for its own use.

[0067] Fig.11 A pointer format 1100 is illustrated having an address field 1101, a memory corruption detection (MCD) protected space field in bits 63:56, and a memory corruption detection (MCD) value field 1103 in accordance with an embodiment of the present disclosure. For example, in an embodiment with MCD protection for applying a linear address space and still remaining within the normalized address range, the following attributes may be set (e.g., in register(s): MCD.Enabled = true, MCD.Position = 50, and MCD.Prefix = 00000000.

[0068] Fig. 12A A linear address space 1200 is shown according to an embodiment of the present disclosure. The depicted linear address space 1200 may be a complete linear address space addressable (e.g., by an OS). The depicted linear address space 1200 includes a negative normalized linear address space 1250, a positive normalized linear address space 1258, a positive denormalized linear address space 1256, and a negative denormalized linear address space 1254. In one embodiment, the denormalized linear address space 1252 includes addresses in which bits 63:57 are each not equal to bit 56.

[0069] Fig. 12B The embodiment according to the present disclosure is shown in FIG. Fig. 12A More specifically, Fig. 12B is a magnified view of the positive linear address space (1256 and 1258).

[0070] Fig. 12C The embodiment according to the present disclosure is shown in FIG. Fig. 12B12 is a view of a portion of linear address space 1200 in FIG. 12 with a subset of space 1260 protected by memory corruption detection (MCD). In one embodiment, MCD protected space 1260 is 63 petabytes of normalized linear address space out of 64 petabytes of normalized linear address space 1258, e.g., leaving 1 petabyte of normalized denormalized linear address space 1262 that is not protected by MCD.

[0071] Fig.13 13. The pointer format 1300 is illustrated with an address field 1301 and without a memory corruption detection (MCD) value field according to an embodiment of the present disclosure. For example, MCD may be used (e.g., by an OS) to protect a subset of a linear address space within its entire address space. In one embodiment, the OS may reserve a negative address range for its own use, e.g., as Fig.13 As shown in , where bits 63:56 are equal to 1.

[0072] Fig.14 A pointer format 1400 is illustrated having an address field 1401, a memory corruption detection (MCD) protected space field 1405 (and, e.g., bits 63:56), and a memory corruption detection (MCD) value field 1403, in accordance with an embodiment of the present disclosure. For example, in an embodiment with MCD protection for a subset of the OS linear address space, the following properties may be set (e.g., in register(s): MCD.Enabled = true, MCD.Position = 41, and MCD.Prefix = 111111111 XXXXXXXXX (e.g., where XXXXXXXX is a specific 9-bit value that defines which region in the negative linear address space is MCD protected).

[0073] Fig.15A A linear address space 1500 is shown according to an embodiment of the present disclosure. The depicted linear address space 1500 may be a complete linear address space addressable (e.g., by an OS). The depicted linear address space 1500 includes a negative normalized linear address space 1550, a positive normalized linear address space 1558, a positive denormalized linear address space 1556, and a negative denormalized linear address space 1554. In one embodiment, the denormalized linear address space 1552 includes addresses in which bits 63:57 are each not equal to bit 56.

[0074] Fig. 15B The embodiment according to the present disclosure is shown in FIG. Fig.15A More specifically, Fig. 15B is a magnified view of the negative normalized linear address space 1550 .

[0075] Fig. 15C The embodiment according to the present disclosure is shown in FIG. Fig. 15B 1500 with a subset of space 1560 protected by memory corruption detection (MCD). In one embodiment, MCD protected space 1560 is 128 terabytes of available linear address space in 64 terabytes of negative normalized linear address space 1550. In one embodiment, combined MCD protected space segment 1560 and MCD protected space segment 1560 contain the entire address range that matches the MCD.Prefix value (e.g., 111111XXXXXXXXX). In one embodiment, MCD protected space segment 1560B is an address where the MCD value of a pointer is not 0 (e.g., with Fig. 12C In one embodiment, the MCD protected space segment 1560A is an address where the pointer MCD value is 0 (e.g., the same as the MCD protected space 1260 in FIG. 1 ). Fig. 12C In some embodiments, all addresses residing in the MCD protected space segment 1560 (e.g., according to Figure 8 ) is transformed, and the actual memory operation will go to the address in the MCD protected space segment 1560A.

[0076] Fig.16 A pointer format 1600 is illustrated according to an embodiment of the present disclosure having an address field 1601, a memory corruption detection (MCD) space field, and a memory corruption detection (MCD) value field 1603. For example, the following properties may be set (e.g., in register(s): MCD.Enabled=True, MCD.Position=57, and MCD.Prefix=0).

[0077] Fig.17A A linear address space 1700 is shown according to an embodiment of the present disclosure. The depicted linear address space 1700 may be a complete linear address space addressable (e.g., by an OS). The depicted linear address space 1700 includes a negative normalized linear address space 1750, a positive normalized linear address space 1758, a positive denormalized linear address space 1756, and a negative denormalized linear address space 1754. In one embodiment, the denormalized linear address space 1752 includes addresses in which bits 63:57 are each not equal to bit 56.

[0078] Fig. 17B The embodiment according to the present disclosure is shown in FIG. Fig.17A More specifically, Fig. 17Bis a magnified view of the positive linear address space (1758 and 1756).

[0079] Fig. 17C The embodiment according to the present disclosure is shown in FIG. Fig. 17B 1756, with a subset of memory corruption detection (MCD) protected space in the positive denormalized linear address space 1756. In one embodiment, the MCD protected space is in an alternate segment, e.g., in the positive denormalized linear address space 1756. In one embodiment, the MCD value in the pointer is in normalized bits (62:57), but bit 63 is (e.g., is required to be) normalized and equal to bit 56. In one embodiment, this means that addresses where bit 63 is equal to bit 56 are MCD protected space, while addresses where bit 63 is not equal to bit 56 are denormalized. In the depicted embodiment, the size of each MCD protected space segment (e.g., box) is the size of address space 1758, but they are compressed in order to illustrate them in the figure.

[0080] Fig.18 A flowchart 1800 according to an embodiment of the present disclosure is shown. The flowchart 1800 includes: 1802: receiving a request to access a block of a memory through a pointer to the block of the memory; and 1804: allowing access to the block of the memory when a memory corruption detection value in the pointer is verified with a memory corruption detection value for the block in the memory, wherein the location of the memory corruption detection value in the pointer is selectable between a first location and a different second location.

[0081] In one embodiment, a hardware processor includes: an execution unit for executing instructions to request access to a block of memory through a pointer to the block of memory; and a memory management unit for allowing access to the block of memory when the memory corruption detection value in the pointer is verified with the memory corruption detection value in the memory for the block, wherein the location of the memory corruption detection value in the pointer is selectable between a first location and a different second location. The hardware processor may include a control register for setting the location to the first location or the different second location. The hardware processor may include a control register for setting a memory corruption detection protected space for a subset of the memory. The pointer may include a memory corruption detection protected space value, and the memory management unit may be configured to: when the memory corruption detection protected space value is not within the memory corruption detection protected space for the subset of the memory, allow access to the block of memory without verifying the memory corruption detection value in the pointer with the memory corruption detection value in the memory for the block. The pointer may include a memory corruption detection protected space value, and the memory management unit may perform a validation check on the memory corruption detection value in the pointer with the memory corruption detection value for the block in the memory when the memory corruption detection protected space value is within the memory corruption detection protected space for the subset of the memory. The hardware processor may include a register for storing a base address of a memory corruption detection table in the memory including the memory corruption detection value for the block. The location of the memory corruption detection value in the pointer is selectable between a first location, a different second location, and a different third location. The pointer may include a linear address of the block of the memory.

[0082] In another embodiment, a method includes receiving a request to access a block of memory through a pointer to the block of memory; and allowing access to the block of memory when the memory corruption detection value in the pointer is verified with the memory corruption detection value in the memory for the block, wherein the location of the memory corruption detection value in the pointer is selectable between a first location and a different second location. The method may include setting the location to the first location or the different second location. The method may include setting a memory corruption detection protected space for a subset of the memory. The pointer may include a memory corruption detection protected space value, and the method may include allowing access to the block of memory without verifying the memory corruption detection value in the pointer with the memory corruption detection value in the memory for the block when the memory corruption detection protected space value is not within the memory corruption detection protected space for the subset of the memory. The pointer may include a memory corruption detection protected space value, and the method may include: when the memory corruption detection protected space value is within the memory corruption detection protected space for the subset of the memory, performing a validation check on the memory corruption detection value in the pointer with the memory corruption detection value for the block in the memory. The method may include: storing a base address of a memory corruption detection table in the memory that includes the memory corruption detection value for the block. The location of the memory corruption detection value in the pointer is selectable between a first location, a different second location, and a different third location. The pointer may include a linear address of the block of the memory.

[0083] In yet another embodiment, a system includes: a memory; a hardware processor including an execution unit for executing instructions to request access to a block of the memory through a pointer to the block of the memory; and a memory management unit for allowing access to the block of the memory when a memory corruption detection value in the pointer is verified with a memory corruption detection value in the memory for the block, wherein a location of the memory corruption detection value in the pointer is selectable between a first location and a different second location. The system may include a control register for setting the location to the first location or the different second location. The system may include a control register for setting a memory corruption detection protected space for a subset of the memory. The pointer may include a memory corruption detection protected space value, and the memory management unit may be configured to: when the memory corruption detection protected space value is not within the memory corruption detection protected space for the subset of the memory, allow access to the block of the memory without verifying the memory corruption detection value in the pointer with the memory corruption detection value in the memory for the block. The pointer may include a memory corruption detection protected space value, and the memory management unit may perform a validation check on the memory corruption detection value in the pointer with the memory corruption detection value for the block in the memory when the memory corruption detection protected space value is within the memory corruption detection protected space for the subset of the memory. The system may include a register for storing a base address of a memory corruption detection table in the memory including the memory corruption detection value for the block. The location of the memory corruption detection value in the pointer is selectable between a first location, a different second location, and a different third location. The pointer may include a linear address of the block of the memory.

[0084] In another embodiment, a hardware processor includes: means for executing instructions to request access to a block of memory through a pointer to the block of memory; and means for allowing access to the block of memory when a memory corruption detection value in the pointer is verified with a memory corruption detection value for the block in the memory, wherein a location of the memory corruption detection value in the pointer is selectable between a first location and a different second location.

[0085] In yet another embodiment, an apparatus includes a data storage device storing code that, when executed by a hardware processor, causes the hardware processor to perform a method disclosed herein. The apparatus may be as described in the detailed description. The method may be as described in the detailed description.

[0086] An instruction set may include one or more instruction formats. A given instruction format may define various fields (e.g., the number of bits, the position of the bits) to specify the operation to be performed (e.g., an opcode) and the operands and / or other data fields (e.g., a mask) on which the operation will be performed, etc. Some instruction formats are further decomposed by the definition of instruction templates (or sub-formats). For example, an instruction template of a given instruction format may be defined as having different subsets of the fields of the instruction format (the included fields are usually in the same order, but at least some fields have different bit positions because fewer fields are included), and / or defined as having a given field interpreted in a different manner. Thus, each instruction of the ISA is expressed using a given instruction format (and, if defined, according to a given one of the instruction templates of the instruction format), and includes fields for specifying operations and operands. For example, an exemplary ADD (addition) instruction has a specific opcode and instruction format, the specific instruction format including an opcode field for specifying the opcode and an operand field for selecting operands (source 1 / destination and source 2); and the ADD instruction appears in an instruction stream with specific contents in the operand field for selecting a specific operand. A set of SIMD extensions known as Advanced Vector Extensions (AVX) (AVX1 and AVX2) and utilizing a vector extension (VEX) encoding scheme have been introduced and / or released (see, e.g., September 2015 64 and IA-32 Architectures Software Developer's Manual; and see the August 2015 Architecture Instruction Set Extension Programming Reference). Exemplary Core Architectures, Processors, and Computer Architectures

[0087] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of such cores may include: 1) a general-purpose in-order core intended for general-purpose computing; 2) a high-performance general-purpose out-of-order core intended for general-purpose computing; 3) a special-purpose core intended primarily for graphics and / or scientific (throughput) computing. Implementations of different processors may include: 1) a CPU that includes one or more general-purpose in-order cores intended for general-purpose computing and / or one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) a coprocessor that includes one or more special-purpose cores intended primarily for graphics and / or scientific (throughput). Such different processors lead to different computer system architectures, which may include: 1) a coprocessor on a separate chip from the CPU; 2) a coprocessor in the same package as the CPU but on a separate die; 3) a coprocessor on the same die as the CPU (in which case such a coprocessor is sometimes referred to as dedicated logic or as a dedicated core, such as integrated graphics and / or scientific (throughput) logic); and 4) a system on a chip, which may include the described CPU (sometimes referred to as application core(s) or application processor(s), the coprocessor described above, and additional functionality on the same die. An exemplary core architecture is described next, followed by a description of an exemplary processor and computer architecture. Exemplary Core Architecture In-order and out-of-order core block diagram

[0088] Fig.19A is a block diagram illustrating an exemplary in-order pipeline and an exemplary register-renaming out-of-order issue / execution pipeline according to various embodiments of the present disclosure. Fig.19B is a block diagram illustrating an exemplary embodiment of an in-order architecture core and an exemplary register renaming, out-of-order issue / execution architecture core to be included in a processor according to various embodiments of the present disclosure. Figure 19A-19B The solid line boxes in illustrate the in-order pipeline and in-order core, while the optional addition of dashed line boxes illustrates the register renaming, out-of-order issue / execution pipeline and core. Considering that the in-order aspect is a subset of the out-of-order aspect, the out-of-order aspect will be described.

[0089] exist Fig.19A , the processor pipeline 1900 includes a fetch stage 1902, a length decode stage 1904, a decode stage 1906, an allocation stage 1908, a rename stage 1910, a scheduling (also known as dispatch or issue) stage 1912, a register read / memory read stage 1914, an execute stage 1916, a write back / memory write stage 1918, an exception handling stage 1922, and a commit stage 1924.

[0090] Fig.19BA processor core 1990 is shown, which includes a front end unit 1930, which is coupled to an execution engine unit 1950, and both the front end unit 1930 and the execution engine unit 1950 are coupled to a memory unit 1970. The core 1990 can be a reduced instruction set computing (RISC) core, a complex instruction set computing (CISC) core, a very long instruction word (VLIW) core, or a hybrid or alternative core type. As another option, the core 1990 can be a special-purpose core, such as, for example, a network or communication core, a compression engine, a coprocessor core, a general-purpose computing graphics processing unit (GPGPU) core, a graphics core, and the like.

[0091] The front end unit 1930 includes a branch prediction unit 1932, which is coupled to an instruction cache unit 1934, which is coupled to an instruction translation lookaside buffer (TLB) 1936, which is coupled to an instruction fetch unit 1938, which is coupled to a decode unit 1940. The decode unit 1940 (or decoder or decode unit) can decode instructions (e.g., macroinstructions) and generate one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals decoded from the original instruction, or otherwise reflecting the original instruction, or derived from the original instruction as output. The decode unit 1940 can be implemented using a variety of different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLA), microcode read-only memories (ROMs), etc. In one embodiment, core 1990 includes a microcode ROM or other medium (e.g., in decode unit 1940, or otherwise within front end unit 1930) that stores microcode for certain macroinstructions. Decode unit 1940 is coupled to rename / allocator unit 1952 in execution engine unit 1950.

[0092] The execution engine unit 1950 includes a rename / allocator unit 1952, which is coupled to a retirement unit 1954 and a set of one or more scheduler units 1956. The scheduler unit(s) 1956 represent any number of different schedulers, including reservation stations, central instruction windows, etc. The scheduler unit(s) 1956 are coupled to physical register file(s) units 1958. Each of the physical register file(s) units 1958 represents one or more physical register files, where different physical register files store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, status (e.g., an instruction pointer that is the address of the next instruction to be executed), etc. In one embodiment, the physical register file(s) units 1958 include a vector register unit, a write mask register unit, and a scalar register unit. These register units may provide architectural vector registers, vector mask registers, and general purpose registers. The physical register file(s) units 1958 are overlapped by the retirement unit 1954 to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using reorder buffer(s) and retirement register file(s); using future files(s), history buffer(s), retirement register file(s); using register maps and register pools, etc.). The retirement unit 1954 and the physical register file(s) units 1958 are coupled to the execution cluster(s) 1960. The execution cluster(s) 1960 include a set 1962 of one or more execution units and a set 1964 of one or more memory access units. The execution unit 1962 may perform various operations (e.g., shifts, additions, subtractions, multiplications) and may perform on various data types (e.g., scalar floating point, packed integer, packed floating point, vector integer, vector floating point). While some embodiments may include multiple execution units dedicated to a particular function or set of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. Scheduler unit(s) 1956, physical register file(s) units 1958, and execution cluster(s) 1960 are shown as potentially multiple, as some embodiments create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating point / packed integer / packed floating point / vector integer / vector floating point pipelines, and / or memory access pipelines each with its own scheduler unit, physical register file(s) units, and / or execution cluster—and in the case of separate memory access pipelines, certain embodiments are implemented where only the execution cluster of that pipeline has memory access unit(s) 1964). It should also be understood that where separate pipelines are used, one or more of these pipelines may be out-of-order issue / execution, and the rest may be in-order.

[0093] A set of memory access units 1964 is coupled to a memory unit 1970, which includes a data TLB unit 1972, which is coupled to a data cache unit 1974, which is coupled to a second level (L2) cache unit 1976. In an exemplary embodiment, the memory access unit 1964 may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit 1972 in the memory unit 1970. The instruction cache unit 1934 is also coupled to a second level (L2) cache unit 1976 in the memory unit 1970. The L2 cache unit 1976 is coupled to one or more other levels of cache and ultimately to the main memory.

[0094] As an example, an exemplary register renaming out-of-order issue / execution core architecture may implement pipeline 1900 as follows: 1) instruction fetch 1938 executes fetch stage 1902 and length decode stage 1904; 2) decode unit 1940 executes decode stage 1906; 3) rename / allocator unit 1952 executes allocation stage 1908 and rename stage 1910; 4) (multiple) scheduler units 1956 execute scheduling stage 1912; 5) (multiple) physical register file units 1958 and memory units 1970 execute register read / memory read stage 1914; execution cluster 1960 executes execution stage 1916; 6) memory unit 1970 and (multiple) physical register file units 1958 execute write back / memory write stage 1918; 7) each unit may be involved in exception handling stage 1922; and 8) retirement unit 1954 and (multiple) physical register file units 1958 execute commit stage 1924.

[0095] Core 1990 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions that have been added with newer versions); the MIPS instruction set of MIPS Technologies, Inc. of Sunnyvale, California; the ARM instruction set of ARM Holdings, Inc. of Sunnyvale, California (with optional additional extensions such as NEON)), including the instruction(s) described herein. In one embodiment, core 1990 includes logic to support packed data instruction set extensions (e.g., AVX1, AVX2), thereby allowing operations used by many multimedia applications to be performed using packed data.

[0096] It should be understood that a core may support multithreading (executing a set of two or more operations or threads in parallel), and that this multithreading may be accomplished in a variety of ways, including time-division multithreading, simultaneous multithreading (where a single physical core provides a logical core for each of the threads that the physical core is simultaneously multithreading), or a combination thereof (e.g., time-division fetching and decoding and subsequent operations such as Hyper-Threading (Simultaneous Multithreading).

[0097] Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming can be used in an in-order architecture. Although the illustrated embodiment of the processor also includes separate instruction and data cache units 1934 / 1974 and a shared L2 cache unit 1976, alternative embodiments may have a single internal cache for both instructions and data, such as, for example, a first level (L1) internal cache or multiple levels of internal cache. In some embodiments, the system may include a combination of internal caches and external caches external to the core and / or processor. Alternatively, all caches may be external to the core and / or processor. Specific Exemplary In-Order Core Architecture

[0098] Figure 20A-20B A block diagram illustrating a more specific exemplary in-order core architecture, which would be one logic block among several logic blocks in a chip (including other cores of the same type and / or different types). Depending on the application, the logic block communicates with some fixed function logic, memory I / O interfaces, and other necessary I / O logic via a high bandwidth interconnect network (e.g., a ring network).

[0099] Fig. 20A 2004 and its local subset 2004 of the second level (L2) cache. In one embodiment, the instruction decode unit 2000 supports the x86 instruction set with the packed data instruction set extension. The L1 cache 2006 allows low latency access to the cache memory into the scalar and vector units. Although in one embodiment (to simplify the design), the scalar unit 2008 and the vector unit 2010 use separate register sets (scalar registers 2012 and vector registers 2014, respectively), and data transferred between these registers is written to the memory and then read back from the first level (L1) cache 2006, alternative embodiments of the present disclosure may use different approaches (e.g., using a single register set or including a communication path that allows data to be transferred between the two register files without being written and read back).

[0100] The local subset 2004 of the L2 cache is part of the global L2 cache, which is divided into multiple separate local subsets, one local subset for each processor core. Each processor core has a direct access path to its own local subset 2004 of the L2 cache. The data read by the processor core is stored in its L2 cache subset 2004 and can be quickly accessed in parallel with other processor cores accessing their own local L2 cache subsets. The data written by the processor core is stored in its own L2 cache subset 2004 and is dumped and cleared from other subsets when necessary. The ring network ensures the consistency of shared data. The ring network is bidirectional to allow agents such as processor cores, L2 caches and other logic blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.

[0101] Fig. 20B According to the embodiment of the present disclosure Fig. 20A An expanded view of a portion of a processor core in FIG. Fig. 20B The L1 data cache 2006A portion of the L1 cache 2004 is included, as well as more details about the vector unit 2010 and vector registers 2014. Specifically, the vector unit 2010 is a 16-wide vector processing unit (VPU) (see 16-wide ALU 2028) that executes one or more of integer, single-precision floating point, and double-precision floating point instructions. The VPU supports blending of register inputs through blending unit 2020, supports numerical conversion through numerical conversion units 2022A-B, and supports copying of memory inputs through copy unit 2024. Write mask register 2026 allows predicted vector writes.

[0102] Fig.21 is a block diagram of a processor 2100 that may have more than one core, may have an integrated memory controller, and may have integrated graphics according to an embodiment of the present disclosure. Fig.21 The solid line box in the figure illustrates a processor 2100 having a single core 2102A, a system agent 2110, a set 2116 of one or more bus controller units, while the optional addition of the dashed line box illustrates an alternative processor 2100 having multiple cores 2102A-N, a set 2114 of one or more integrated memory controller units in the system agent unit 2110, and dedicated logic 2108.

[0103] Thus, different implementations of processor 2100 may include: 1) a CPU, where the dedicated logic 2108 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores), and cores 2102A-N are one or more general purpose cores (e.g., general purpose in-order cores, general purpose out-of-order cores, combinations of the two); 2) a coprocessor, where cores 2102A-N are a large number of dedicated cores intended primarily for graphics and / or scientific (throughput); and 3) a coprocessor, where cores 2102A-N are a large number of general purpose in-order cores. Thus, processor 2100 may be a general purpose processor, a coprocessor, or a dedicated processor, such as, for example, a network or communication processor, a compression engine, a graphics processor, a GPGPU (general purpose graphics processing unit), a high throughput integrated many-core (MIC) coprocessor (including 30 or more cores), an embedded processor, and the like. The processor may be implemented on one or more chips. Processor 2100 may be part of one or more substrates, and / or may be implemented on one or more substrates using any of a variety of process technologies (such as, for example, BiCMOS, CMOS, or NMOS).

[0104] The memory hierarchy includes one or more cache levels within the core, a set of one or more shared cache units 2106, and external memory (not shown) coupled to a set of integrated memory controller units 2114. The set of shared cache units 2106 may include one or more intermediate levels of cache, such as a second level (L2), a third level (L3), a fourth level (L4), or other levels of cache, a last level cache (LLC), and / or a combination of the above. Although in one embodiment, a ring-based interconnect unit 2112 interconnects the integrated graphics logic 2108, the set of shared cache units 2106, and the system agent unit 2110 / (multiple) integrated memory controller units 2114, alternative embodiments may use any number of well-known techniques to interconnect such units. In one embodiment, coherency is maintained between the one or more cache units 2106 and the cores 2102A-N.

[0105] In some embodiments, one or more of the cores 2102A-N may be multithreaded. The system agent 2110 includes those components that coordinate and operate the cores 2102A-N. The system agent unit 2110 may include, for example, a power control unit (PCU) and a display unit. The PCU may be, or may include, the logic and components required to regulate the power state of the cores 2102A-N and the integrated graphics logic 2108. The display unit is used to drive one or more externally connected displays.

[0106] The cores 2102A-N may be homogeneous or heterogeneous in terms of the architectural instruction set; that is, two or more of the cores 2102A-N may be capable of executing the same instruction set, while other cores may be capable of executing only a subset of the instruction set or a different instruction set. Exemplary Computer Architecture

[0107] Figure 22-25 is a block diagram of an exemplary computer architecture. Other system designs and configurations known in the art for laptops, desktops, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices are also suitable. In general, a wide variety of systems or electronic devices that can contain processors and / or other execution logic as disclosed herein are generally suitable.

[0108] Reference now Fig. 22 , shown is a block diagram of a system 2200 according to one embodiment of the present disclosure. The system 2200 may include one or more processors 2210, 2215, which are coupled to a controller hub 2220. In one embodiment, the controller hub 2220 includes a graphics memory controller hub (GMCH) 2290 and an input / output hub (IOH) 2250 (which may be on separate chips); the GMCH 2290 includes a memory and a graphics controller, to which a memory 2240 and a coprocessor 2245 are coupled; and the IOH 2250 couples an input / output (I / O) device 2260 to the GMCH 2290. Alternatively, one or both of the memory and the graphics controller are integrated within a processor (as described herein), the memory 2240 and the coprocessor 2245 are directly coupled to the processor 2210, and the controller hub 2220 and the IOH 2250 are in a single chip. The memory 2240 may include a memory corruption detection module 2240A, which is used to store code, which when executed causes the processor to perform any method of the present disclosure. In another embodiment, the memory corruption detection module 2240A resides in the processor and communicates with the memory 2240.

[0109] The optional nature of the additional processor 2215 is Fig. 22 Each processor 2210 , 2215 may include one or more of the processing cores described herein, and may be a version of processor 2100 .

[0110] The memory 2240 may be, for example, dynamic random access memory (DRAM), phase change memory (PCM), or a combination of the two. For at least one embodiment, the controller hub 2220 communicates with the processor(s) 2210, 2215 via a multi-drop bus such as a front-side bus (FSB), a point-to-point interface such as a Quick Path Interconnect (QPI), or a similar connection 2295.

[0111] In one embodiment, coprocessor 2245 is a special purpose processor such as, for example, a high throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, etc. In one embodiment, controller hub 2220 may include an integrated graphics accelerator.

[0112] There may be various differences between the physical resources 2210 , 2215 in terms of a range of quality metrics including architectural, microarchitectural, thermal, power consumption characteristics, etc.

[0113] In one embodiment, the processor 2210 executes instructions that control general types of data processing operations. Embedded within these instructions may be coprocessor instructions. The processor 2210 recognizes these coprocessor instructions as being of a type that should be executed by the attached coprocessor 2245. Therefore, the processor 2210 issues these coprocessor instructions (or control signals representing coprocessor instructions) to the coprocessor 2245 on a coprocessor bus or other interconnect. The coprocessor (s) 2245 accept and execute the received coprocessor instructions.

[0114] See now Fig.23 , shown is a block diagram of a first more specific exemplary system 2300 according to an embodiment of the present disclosure. Fig.23 As shown in , the multiprocessor system 2300 is a point-to-point interconnect system and includes a first processor 2370 and a second processor 2380 coupled via a point-to-point interconnect 2350. Each of the processors 2370 and 2380 can be a version of the processor 2100. In one embodiment of the present disclosure, the processors 2370 and 2380 are processors 2310 and 2215, respectively, and the coprocessor 2338 is the coprocessor 2245. In another embodiment, the processors 2370 and 2380 are the processor 2210 and the coprocessor 2245, respectively.

[0115] Processors 2370 and 2380 are shown as including integrated memory controller (IMC) units 2372 and 2382, respectively. Processor 2370 also includes point-to-point (PP) interfaces 2376 and 2378 as part of its bus controller unit; similarly, second processor 2380 includes PP interfaces 2386 and 2388. Processors 2370, 2380 can exchange information via PP interface 2350 using point-to-point (PP) interface circuits 2378, 2388. Fig.23 As shown in FIG. 2 , IMCs 2372 and 2382 couple the processors to respective memories, namely, memory 2332 and memory 2334 , which may be portions of main memory locally attached to the respective processors.

[0116] The processors 2370, 2380 may each exchange information with the chipset 2390 via respective PP interfaces 2352, 2354 using point-to-point interface circuits 2376, 2394, 2386, 2398. The chipset 2390 may optionally exchange information with the coprocessor 2338 via a high performance interface 2339. In one embodiment, the coprocessor 2338 is a special purpose processor such as, for example, a high throughput MIC processor, a network or communication processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, or the like.

[0117] A shared cache (not shown) may be included in either processor, or external to both processors but connected to the processors via the PP interconnect, so that if the processors are placed in a low power mode, local cache information of either or both processors may be stored in the shared cache.

[0118] Chipset 2390 may be coupled to first bus 2316 via interface 2396. In one embodiment, first bus 2316 may be a peripheral component interconnect (PCI) bus or a bus such as a PCI Express bus or another third generation I / O interconnect bus, but the scope of the present disclosure is not limited in this regard.

[0119] like Fig.23As shown in , various I / O devices 2314 may be coupled to the first bus 2316 along with a bus bridge 2318 that couples the first bus 2316 to a second bus 2320. In one embodiment, one or more additional processors 2315 such as a coprocessor, a high throughput MIC processor, a GPGPU, an accelerator (such as, for example, a graphics accelerator or a digital signal processing (DSP) unit), a field programmable gate array, or any other processor are coupled to the first bus 2316. In one embodiment, the second bus 2320 may be a low pin count (LPC) bus. In one embodiment, various devices may be coupled to the second bus 2320 including, for example, a keyboard and / or mouse 2322, communication devices 2327, and a storage unit 2328 such as a disk drive or other mass storage device which may include instructions / code and data 2330. Additionally, an audio I / O 2324 may be coupled to the second bus 2320. Note that other architectures are possible. For example, instead of Fig.23 Instead of a point-to-point architecture, the system may implement a multi-drop bus or other such architecture.

[0120] Reference now Fig.24 , shown is a block diagram of a second more specific exemplary system 2400 according to an embodiment of the present disclosure. Fig.23 and 24 Similar elements in the same reference numerals are used, and Fig.24 Omitted Fig.23 to avoid confusion Fig.24 other aspects.

[0121] Fig.24 The illustrated processors 2370, 2380 may include integrated memory and I / O control logic ("CL") 2372 and 2382, respectively. Thus, the CL 2372, 2382 includes an integrated memory controller unit and includes I / O control logic. Fig.24 The illustration shows that not only the memories 2332, 2334 are coupled to the CL 2372, 2382, but also the I / O devices 2414 are coupled to the control logic 2372, 2382. Legacy I / O devices 2415 are coupled to the chipset 2390.

[0122] Reference now Fig.25 , which is a block diagram of a SoC 2500 according to an embodiment of the present disclosure. Fig.21 Similar elements in the same figure are marked with similar reference numerals. In addition, the dashed boxes are optional features on more advanced SoCs. Fig.25, interconnect unit(s) 2502 are coupled to: application processor 2510, which includes a set of one or more cores 202A-N and a shared cache unit(s) 2106; system agent unit 2110; bus controller unit(s) 2116; integrated memory controller unit(s) 2114; a set of one or more coprocessors 2520, which may include integrated graphics logic, image processors, audio processors, and video processors; static random access memory (SRAM) unit 2530; direct memory access (DMA) unit 2532; and a display unit 2540 for coupling to one or more external displays. In one embodiment, coprocessor(s) 2520 include special purpose processors such as, for example, network or communication processors, compression engines, GPGPUs, high throughput MIC processors, or embedded processors, among others.

[0123] The various embodiments (e.g., mechanisms) disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementations. The embodiments of the present disclosure may be implemented as a computer program or program code executed on a programmable system, the programmable system comprising at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0124] Program code (such as Fig.23 The code 2330 illustrated in FIG. 23 is applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, a processing system includes any system having a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application specific integrated circuit (ASIC), or a microprocessor.

[0125] The program code can be implemented with a high-level process-oriented programming language or an object-oriented programming language to communicate with the processing system. If necessary, the program code can also be implemented with assembly language or machine language. In fact, the mechanism described herein is not limited to the scope of any specific programming language. In any case, the language can be a compiled language or an interpreted language.

[0126] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium, which represent various logic in a processor, which when read by a machine causes the machine to fabricate logic for performing the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible, machine-readable medium and supplied to various customers or manufacturing facilities to load into a manufacturing machine that actually manufactures the logic or processor.

[0127] Such machine-readable storage media may include, but are not limited to, a non-transitory, tangible arrangement of an article manufactured or formed by a machine or apparatus, including storage media such as a hard disk; any other type of disk, including a floppy disk, an optical disk, a compact disk-read only memory (CD-ROM), a compact disk-rewritable (CD-RW), and a magneto-optical disk; semiconductor devices, such as read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM) and static random access memory (SRAM), erasable programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM); phase change memory (PCM); a magnetic card or an optical card; or any other type of medium suitable for storing electronic instructions.

[0128] Therefore, embodiments of the present disclosure also include non-transitory tangible machine-readable media containing instructions or containing design data, such as hardware description language (HDL), which defines the structures, circuits, devices, processors and / or system features described herein. These embodiments are also referred to as program products. Simulation (including binary conversion, code deformation, etc.)

[0129] In some cases, the instruction converter can be used to convert instructions from a source instruction set to a target instruction set. For example, the instruction converter can convert (e.g., using static binary conversion, dynamic binary conversion including dynamic compilation), deform, simulate or otherwise convert instructions into one or more other instructions to be processed by the core. The instruction converter can be implemented in software, hardware, firmware, or a combination thereof. The instruction converter can be on the processor, outside the processor, or partially on the processor and partially outside the processor.

[0130] Fig.26 1 is a block diagram of using a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set according to an embodiment of the present disclosure. In the illustrated embodiment, the instruction converter is a software instruction converter, but alternatively, the instruction converter can be implemented in software, firmware, hardware, or various combinations thereof. Fig.26It is shown that an x86 compiler 2604 can be used to compile a program in a high-level language 2602 to generate x86 binary code 2606 that can be natively executed by a processor 2616 having at least one x86 instruction set core. A processor 2616 having at least one x86 instruction set core represents any processor that performs substantially the same functionality as an Intel processor having at least one x86 instruction set core by compatibly executing or otherwise performing: (1) an essential portion of the instruction set of an Intel x86 instruction set core, or (2) an object code version of an application or other software that is targeted to run on an Intel processor having at least one x86 instruction set core to achieve substantially the same results as an Intel processor having at least one x86 instruction set core. The x86 compiler 2604 represents a compiler that can be used to generate x86 binary code 2606 (e.g., object code) that can be executed on a processor 2616 having at least one x86 instruction set core with or without additional linking processing. Similarly, Fig.26 It is shown that a program in a high-level language 2602 can be compiled using an alternative instruction set compiler 2608 to generate an alternative instruction set binary code 2610 that can be natively executed by a processor 2614 that does not have at least one x86 instruction set core (e.g., a processor that has a core that executes the MIPS instruction set of MIPS Technologies, Inc. of Sunnyvale, California, and / or executes the ARM instruction set of ARM Holdings, Inc. of Sunnyvale, California). The instruction converter 2612 is used to convert the x86 binary code 2606 into code that can be natively executed by the processor 2614 that does not have an x86 instruction set core. The converted code is unlikely to be the same as the alternative instruction set binary code 2610 because an instruction converter that can do so is difficult to manufacture; however, the converted code will complete the general operation and be composed of instructions from the alternative instruction set. Therefore, the instruction converter 2612 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device that does not have an x86 instruction set processor or core to execute the x86 binary code 2606 through simulation, emulation, or any other process.

Claims

1. A hardware processor, comprising: an execution unit for executing instructions to request access to a block of memory via a pointer to the block of memory; as well as A memory management unit is configured to allow access to the block of the memory when the memory corruption detection value in the pointer is verified with the memory corruption detection value for the block in the memory, wherein the position of the memory corruption detection value in the pointer is selectable between a first position and a different second position.

2. The hardware processor of claim 1, further comprising a control register for setting the position to the first position or the different second position.

3. The hardware processor of claim 1, further comprising a control register for setting a space for a subset of the memory that is protected by memory corruption detection.

4. A method comprising: receiving a request to access a block of memory via a pointer to the block of memory; as well as Access to the block of the memory is permitted when the memory corruption detection value in the pointer is verified with the memory corruption detection value for the block in the memory, wherein the location of the memory corruption detection value in the pointer is selectable between a first location and a different second location. The method of claim 4 , further comprising setting the position to the first position or the different second position.

6. The method of claim 4, further comprising: Memory corruption detection protected space is provided for a subset of the memory.

7. A system comprising: Memory; a hardware processor comprising an execution unit for executing instructions to request access to a block of memory via a pointer to the block of memory; as well as A memory management unit is configured to allow access to the block of the memory when the memory corruption detection value in the pointer is verified with the memory corruption detection value for the block in the memory, wherein the position of the memory corruption detection value in the pointer is selectable between a first position and a different second position.

8. The system of claim 7, further comprising a control register for setting the position to the first position or the different second position.

9. The system of claim 7, further comprising a control register for setting a memory corruption detection protected space for a subset of the memory.

10. A hardware processor comprising: means for executing instructions to request access to a block of memory via a pointer to the block of memory; as well as Means for allowing access to the block of the memory when the memory corruption detection value in the pointer is verified with the memory corruption detection value for the block in the memory, wherein the location of the memory corruption detection value in the pointer is selectable between a first location and a different second location.

Images