CN112149143A - Low memory overhead heap management for memory marking - Google Patents

Abstract

A method comprising, in response to a first instruction requesting a memory heap operation: identifying a data block of a memory heap; accessing a tag history for the data block, the tag history comprising a plurality of tags previously assigned to the data block; assigning a tag to the data block, wherein assigning the tag includes verifying that the tag does not match any of a plurality of tags of the tag history; and providing the assigned tag and a reference to the location of the data block.

Description

Low memory overhead heap management for memory marking

Technical Field

The present disclosure relates generally to the field of computing systems, and more particularly to low memory overhead heap management for memory marking.

Background

Protecting memory in a computer system from software bugs and security breaches is a significant problem. In a computing system, a heap manager may service memory allocation requests from various applications at runtime. Unless the heap manager takes precautions, the contents of a portion of memory previously allocated to a first application may be accessed by another application.

Drawings

FIG. 1 illustrates a computing device in accordance with certain embodiments.

FIG. 2 illustrates a memory heap in accordance with certain embodiments.

Fig. 3A and 3B illustrate a flow for memory defragmentation according to some embodiments.

FIG. 4 illustrates a flow for memory tiling, according to some embodiments.

FIG. 5 illustrates a flow for utilizing an encrypted memory pointer format, in accordance with certain embodiments.

FIG. 6 illustrates a flow for allocating heap memory, in accordance with certain embodiments.

FIG. 7 is a block diagram illustrating an example processor core and memory, in accordance with certain embodiments.

FIG. 8A is a block diagram illustrating an exemplary sequential pipeline and an exemplary register renaming, out-of-order launch/execution pipeline in accordance with certain embodiments.

FIG. 8B is a block diagram illustrating an exemplary embodiment of a sequential architecture core and an exemplary register renaming, out-of-order issue/execution architecture core to be included in a processor according to some embodiments.

FIG. 9 is a block diagram of an example computer architecture, according to some embodiments.

FIG. 10 is a block diagram that compares binary instructions in a source instruction set to binary instructions in a target instruction set using a software instruction converter, according to some embodiments.

FIG. 11 depicts a flow for associating an encryption tag with a corresponding sub-portion of an allocated data block, in accordance with certain embodiments.

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

Detailed Description

Memory marking is a memory security technique that reduces the risk of runtime memory security violations by maintaining reference metadata that includes tags for memory locations and comparing tags in incoming memory access requests to allocation tags for data blocks that include memory locations that are the subject of the memory access requests. If the incoming tag does not match the assigned tag, then the memory access request is not executed. Memory marking solutions are primarily intended to achieve heap protection, e.g., to prevent corruption or illegal access to dynamically allocated memory in a software program. The heap manager may be responsible for managing heap space during memory allocation and deallocation. The heap manager may generate a tag for a block of data during memory allocation and change the tag to a different value when memory is freed or reallocated. The heap manager may prevent tag reuse, such as assigning the same tag to a particular data block through subsequent assignment of that data block.

Various heap management solutions for memory marking (e.g., heap allocator for Linux) rely on quarantining freed memory to prevent mark reuse. When a data block is released, it will not be reusable for a certain duration after the release. Such heap management methods may prevent the use of pointers to portions of data blocks after the data blocks are released and reused, but may result in the sequestered memory remaining unusable for a long period of time, resulting in lower overall memory utilization.

Various embodiments of the present disclosure provide a secure heap management solution that prevents tag reuse without incurring large memory overhead. For example, the heap manager may maintain a history of previous tags as part of the heap management metadata and consider this history during memory heap operations (e.g., memory allocation and/or release operations). This allows a data block to be reused immediately after it is released, provided that a different tag value can be assigned than the previous tag value as indicated by the tag history. Tags may also be assigned to data blocks in a manner that prevents immediately adjacent data blocks in the heap from having the same tag (e.g., to prevent illegal memory accesses due to memory overflows). In various examples, tags may be assigned in a random manner or in a deterministic manner optimized to reduce tag duplication. Various embodiments may significantly reduce the need to isolate heap blocks and thereby reduce memory overhead for heap management of memory marking solutions.

In some embodiments, size information may be encoded into pointers to allocated data blocks, describing the extent of object allocation, instead of or in addition to labels. Various aspects of the present disclosure may provide for an encrypted form of memory marking, wherein a data block allocated from memory is cryptographically bound to a mark or sized pointer encoding.

Referring specifically to fig. 1, computing device 100 may be embodied as any type of electronic device for performing the functions described herein. For example, computing device 100 may be embodied as, but is not limited to, a smart phone, a tablet computer, a wearable computing device, a laptop computer, a notebook computer, a mobile computing device, a cellular phone, a cell phone, a messaging device, a vehicle telematics device, a server computer, a workstation, a distributed computing system, a multi-processor system, a consumer electronics device, and/or any other computing device configured to perform the functions described herein.

As shown in fig. 1, the example computing device 100 includes at least one processor 102. The processor 102 includes a runtime tag generator 105 and a runtime tag checker 106, as well as other components (not shown in fig. 1), such as circuitry for implementing components (e.g., software or other components), such as the heap manager 104. The heap manager 104 is operable to receive requests for memory heap operations, such as memory allocation requests and memory release requests. The heap manager 104 may service such requests. When responding to an allocation request, heap manager 104 may return a reference to the location of the requested data block and a tag assigned to the data block to the application requesting the memory heap operation (where the tag is generated by runtime tag generator 105). When an application attempts to access the allocated memory, it may provide the location of the data block and the tag to the runtime tag checker 106. The runtime tag checker 106 can verify that the provided tag matches the tag assigned to the data block, and if the tags match, can allow the memory request to be serviced; and if the tags do not match, access may be blocked.

Computing device 100 also includes memory 122, input/output subsystem 124, data storage 126, display device 128, User Interface (UI) subsystem 130, communication subsystem 132, at least one user space application 134, and privileged system components 142. In other embodiments, computing device 100 may include other or additional components, such as components that are common in mobile and/or stationary computers (e.g., various sensors and input/output devices). Additionally, in some embodiments, one or more of the example components may be incorporated into or otherwise form a part of another component. Each of the components of computing device 100 may be embodied as software, firmware, hardware, or a combination of software and hardware.

The processor 102 may be embodied as any type of processor capable of performing the functions described herein. For example, the processor 102 may be embodied as a single or multi-core Central Processing Unit (CPU), a multi-CPU processor, processing/control circuitry, or a plurality of different processing units or circuitry (e.g., CPUs, Graphics Processing Units (GPUs), etc.).

The memory 122 of the computing device 100 may be embodied as any type of volatile or non-volatile memory or data storage device capable of performing the functions described herein. Volatile memory is a storage medium that requires power to maintain the state of data stored by the medium. Examples of volatile memory may include various types of Random Access Memory (RAM), such as Dynamic Random Access Memory (DRAM) or Static Random Access Memory (SRAM). One particular type of DRAM that may be used in memory is Synchronous Dynamic Random Access Memory (SDRAM). In a particular embodiment, the DRAM of memory 122 conforms to standards promulgated by the Joint Electron Device Engineering Commission (JEDEC), such as JESD79F for Double Data Rate (DDR) SDRAM, JESD79-2F for DDR2 SDRAM, JESD79-3F for DDR3 SDRAM, or JESD79-4A for DDR4 SDRAM (these standards are available from www.jedec.org). Non-volatile memory is a storage medium that does not require power to maintain the state of data stored by the medium. Non-limiting examples of non-volatile memory may include any one or combination of the following: solid state memory (such as planar or 3D NAND flash memory or NOR flash memory), 3D cross-point memory, memory devices using chalcogenide phase change materials (e.g., chalcogenide glass), byte addressable non-volatile memory devices, ferroelectric memory, silicon oxide-nitride-oxide-silicon (SONOS) memory, polymer memory (e.g., ferroelectric polymer memory), ferroelectric transistor random access memory (Fe-TRAM) ovonic memory, nanowire memory, Electrically Erasable Programmable Read Only Memory (EEPROM), other various types of non-volatile Random Access Memory (RAM), and magnetic storage memory.

In some embodiments, memory 122 includes one or more memory modules, such as dual in-line memory modules (DIMMs). In some embodiments, memory 122 may be located on one or more integrated circuit chips different from the integrated circuit chip that includes processor 102, or may be located on the same integrated circuit chip as processor 102. Memory 122 may include any suitable type of memory and is not limited to a particular speed or memory technology in various embodiments.

In operation, memory 122 may store various data and software used during operation of computing device 100, as well as software applications used by computing device 100, such as operating systems, user applications, programs, libraries, and drivers. The memory 122 may store data and/or sequences of instructions that are executed by the processor 102. In various embodiments, the heap may be stored in memory 122 or other suitable memory of computing device 100.

Memory 122 is communicatively coupled to processor 102, e.g., via an I/O subsystem 124. The I/O subsystem 124 may be embodied as circuitry and/or components to facilitate input/output operations of the processor 102, the memory 122, and other components of the computing device 100. For example, the I/O subsystem 124 may be embodied as or otherwise include a memory controller hub, an input/output control hub, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.), and/or other components and subsystems that facilitate input/output operations. In some embodiments, the I/O subsystem 124 may form part of a system on a chip (SoC) and be incorporated on a single integrated circuit chip with one or more of the processor 102, memory 122, and/or other components of the computing device 100.

The data storage device 126 may be embodied as any type of physical device or device configured for short or long term storage of data, such as, for example, memory devices and circuits, memory cards, hard drives, solid state drives, flash or other read-only memory, memory devices combined with read-only and random access memory, or other data storage devices. In various embodiments, the memory 122 may cache data stored on the data storage device 126.

Display device 128 may be implemented as any type of display capable of displaying digital information, such as a Liquid Crystal Display (LCD), a Light Emitting Diode (LED), a plasma display, a Cathode Ray Tube (CRT), or other type of display device. In some embodiments, display device 128 may be coupled to a touch screen or other human interface device to allow user interaction with computing device 100. Display device 128 may be part of a User Interface (UI) subsystem 130. User interface subsystem 130 may include a number of additional devices to facilitate user interaction with computing device 100, including physical or virtual control buttons or keys, a microphone, a speaker, a one-way or two-way still and/or video camera, and/or others. User interface subsystem 130 may also include devices such as motion sensors, proximity sensors, and eye tracking devices, which may be configured to detect, capture, and process various other forms of human-computer interaction involving computing device 100.

Computing device 100 further includes a communication subsystem 132, which communication subsystem 132 may be embodied as any communication circuitry, device, or other electronic device capable of enabling communication between computing device 100 and other electronic devicesAnd (4) collecting. The communication subsystem 132 may be configured to use any one or more communication technologies (e.g., wireless or wired communication) and related protocols (e.g., ethernet, bluetooth)^TM、Wi-Fi^TMWiMAX, 3G/LTE, etc.) to enable such communication. In some embodiments, the communication subsystem 132 may be embodied as a network adapter, such as a wireless network adapter.

The example computing device 100 also includes a plurality of computer program components, such as one or more user space applications 134 or other applications. User space application 134 may be embodied as any computer application (e.g., software, firmware, hardware, or combinations thereof) that interacts directly or indirectly with an end user via, for example, display device 128 or UI subsystem 130. Some examples of user space applications 134 include word processing programs, document viewers/readers, Web browsers, email programs, messaging services, computer games, camera and video applications, and so forth. The privileged system component 142 facilitates, among other things, communication between the user space application 134 and hardware components of the computing device 100. Portions of the privileged system component 142 may be embodied as any operating system capable of performing the functions described herein, such as the WINDOWS version of Microsoft Corporation, the ANDROID version of Google Corporation, and/or others. Alternatively or additionally, a portion of the privileged system component 142 may be embodied as any type of virtual machine monitor (e.g., a type I or type II hypervisor) capable of performing the functions described herein.

FIG. 2 illustrates a memory heap 200 according to some embodiments. Memory heap 200 may be stored in any suitable memory, such as memory 122. Memory heap 200 includes a plurality of blocks, some of which are used (e.g., allocated to an application) or freed (e.g., available for allocation to a requesting application). Memory heap 200 may also include other allocatable portions of memory, such as sequestered blocks that later become available or other memory not allocated to a block. Memory heap 200 is depicted as a interspersed set of variable sized used and free blocks.

Memory heap 200 may be used to allocate dynamic objects (e.g., objects not stored in an application stack) for an application at runtime. A portion of memory heap 200 may be made available to each application program requesting a memory allocation. The heap manager 104 may receive requests from applications and service the requests. For example, the request may include a request to allocate a data block of a particular size, a request to resize the allocated data block (which may include an adjusted size), or a request to release the allocated data block. For example, in the C programming language, such requests may include instructions associated with malloc (), calloc (), dealloc (), realloc () and free () function calls, although this disclosure contemplates any suitable memory allocation request. In response to a memory allocation request from an application, the heap manager 104 may return information associated with the allocated block. For example, the heap manager 104 may return one or more of a pointer to the block, a tag assigned to the block, a size of the block, and an encryption key or adjustment associated with the block. In some embodiments, a tag, size, or key or adjustment may be embedded within the returned pointer. Example formats for such pointers are discussed in further detail below in conjunction with fig. 5.

Blocks of the heap may be associated with metadata. The metadata for a block may be stored contiguously with the block in the memory heap, in some other location in the memory heap, or at other suitable locations within processor 102 or in a memory coupled to processor 102. For example, in some embodiments, various sets of metadata may be stored together in a table, or each set may be stored with the block with which it is associated. In the illustrated embodiment, a set of metadata 202 associated with used blocks and a set of metadata 204 associated with free blocks are shown. Metadata 202 includes tag history 206 and other metadata 210, while metadata 204 includes tag history 208 and other metadata 212. Metadata 204 may be similar to metadata 202, but specific to associated free blocks, rather than used blocks associated with metadata 202.

Other metadata 210 and other metadata 212 may include any suitable data associated with the respective blocks. For example, the other metadata 210 or 212 may include data indicating the size of the associated chunk, the data type of the object to be stored in the associated chunk, or an encryption key or adjustment (described in more detail below) associated with the chunk. For example, a data type may include a type of data or code defined by a programming language. For example, the data types may include a type ID of "0" for an integer, a type ID of "1" for a floating point value, a type ID of "2" for a particular complex structure type, and so on. In some embodiments, the encryption key or adjustment associated with the chunk may include or otherwise be based on other portions of the metadata.

The tag history 206 includes a plurality of previous tags (T) assigned to data blocks associated with the metadata 202₁To T_KWhere K is any suitable integer). E.g. T_KMay be the currently assigned tag, T_K-1May be immediately adjacent to T_KPreviously assigned tag, T_K-2May be immediately adjacent to T_K-1Previously assigned labels, and so on. In other embodiments, the current tag may be stored separately from the tag history 206, and thus the tag T₁To T_KMay be the label previously assigned to the block. The tag may include any suitable identifier, such as a sequence of bits. When a block is first allocated, a first label may be allocated to the block. Each time a block is reallocated (e.g., upon release or upon allocation to the same or a new application), it may be assigned a different tag to prevent unauthorized access. Alternatively, if the block is encrypted (e.g., as a cryptographic adjustment) using information from the tag in conjunction with an encryption key, the same tag may be reused for the block as long as it is used with a different key each time. In various embodiments, if the number of tags that can be stored in the tag history is limited, the oldest tag may be deleted to make room for the newest tag when the tag history 206 is full. In another embodiment, the size of the tag history is not limited. In various embodiments, a triggering event (e.g., a reset of device 100, a change in the size of a block, a change in the encryption key associated with the block, etc.) may reset the tagAnd (4) history.

In various embodiments, the size of the tag and the size of the tag history may be any suitable size. As just one example, a tag may be one byte (e.g., 8 bits of data) and the tag history may include 8 tags. In a particular embodiment, the size of the tag is consistent across all blocks, and the size of the tag history is consistent across all blocks, although in other embodiments the size may vary between blocks of the heap.

When the block is initialized for the first time (e.g., after system power-up or even some other event that causes the tag history to reset), all of the tags in tag history 206 may be initialized to a reserved value (e.g., all zeros, all ones, or other suitable value) that is not used as a tag.

When the heap manager 104 receives a memory allocation request (e.g., a malloc () is called), the heap manager 104 may search for a correctly sized heap block (e.g., matching or larger than the size included in the request) from the freed heap blocks. If such a block is not found, a new block may be generated to satisfy the request. The new block may be generated in any suitable manner. For example, a new block may be formed by defragmenting (defragmenting) a plurality of smaller blocks or chunking (fragmenting) a larger block (the generation of a tag history for the new block will be described in further detail below in connection with fig. 3A, 3B and 4).

A block identified or generated to satisfy a request may be assigned a tag that is not part of the tag history for that block. In various embodiments, the tags may be allocated in response to a memory allocation request (e.g., when a new block is created due to chunking or defragmentation, when a block is first allocated, or when a block is reallocated), or may be pre-allocated (e.g., in response to an identified block being previously freed as opposed to allocating a tag during reallocation). In various embodiments, the assigned tag is also different from the current tag of any block that is physically adjacent to the block in the heap (e.g., the block with the next lower physical address and the block with the next higher physical address). If no new tags can be found that satisfy the constraint (e.g., cannot be in the tag history, cannot be matched with tags of neighboring blocks, and/or other specified constraints), the block can be isolated, additional blocks identified or generated (e.g., using the methods described above), and a determination can be made as to whether tags that satisfy the constraint can be assigned to the additional blocks. These operations may be repeated until a feasible block is found.

In various embodiments, if a tag that satisfies a constraint is not available for a particular block, the block may be quarantined for a period of time. When the block is isolated, the block will be considered unavailable for allocation. The block may be deleted from the isolation for any suitable reason. In various embodiments, the block may be deleted from the isolation if any of a number of conditions are met. For example, if a certain amount of time has elapsed, the block may be deleted from the quarantine. As another example, if the labels of neighboring blocks have changed, the block may be deleted from the quarantine, thereby allowing the previous label to be used for the quarantine block. As another example, the block may be deleted from the quarantine when the encryption key or adjustment associated with the encryption operation for the block has changed. In some embodiments, when all of the tag and size values for one or more physical pages have been used up, the heap manager 104 may unmap the linear addresses for the physical pages and alias the same physical pages as the new linear address mapping, and then proceed with allocation from one or more new memory pages, providing a non-duplicate tag value for the new linear address allocation.

When the heap manager 104 receives a memory release request (e.g., calls free ()), the heap manager 104 may assign a new tag to the block that is not part of the tag history for the block (and that satisfies other potential constraints). This may protect the freed block from unauthorized access that references previously assigned tags. If no new tags can be found that satisfy the constraints (e.g., cannot be in the tag history, cannot match the tags of neighboring blocks, and/or other specified constraints), the block can be isolated as described above.

When the heap manager 104 receives a memory sizing request (e.g., calls realoc ()), the heap manager may search for a correctly sized heap block from the freed heap blocks (e.g., matching or larger than the size included in the request). If such a block is not found, a new block may be generated to satisfy the request. The new block may be generated in any suitable manner. For example, a new chunk may be formed by defragmenting a plurality of smaller chunks or chunking a larger chunk. The block that has been identified or generated to satisfy the request may be assigned (or may have been assigned, e.g., when last released) a label that satisfies all of the set of constraints (e.g., the label is not part of the block's label history, the label does not match the labels of neighboring blocks, and/or other specified constraints). If no tags that satisfy the constraint can be found, the block can be isolated, other blocks identified or generated (e.g., using the methods described above), and a determination made as to whether tags that satisfy the constraint can be assigned to additional blocks. These operations may be repeated until a viable resize operation block is found.

Fig. 3A and 3B illustrate a flow for memory defragmentation according to some embodiments. Dynamic allocation and release of blocks may result in a chunk of fragments within runtime heap 200. Further, heap 200 may include many different sized blocks. Thus, it may be necessary to defragment multiple blocks (which may or may not be of different sizes) by combining them together. For example, an incoming memory request may request a larger block of data when only a smaller block of data is available. Thus, the heap manager 104 may combine multiple small data blocks into a single larger block.

When multiple blocks are combined into a single block, a set of metadata for the new block is generated. For example, when a block associated with metadata 302 is combined with a block associated with metadata 304, a new set of metadata 306 is formed and associated with the combined block. Similarly, when a block associated with metadata 320 is combined with a block associated with metadata 322, a new set of metadata 324 is formed and associated with the combined block.

The new set of metadata may include a combination of tag histories for respective blocks used to form the new block. For example, tag history 312 includes a combination of tag histories 308 and 310, while tag history 330 includes a combination of tag histories 326 and 328. The tag histories may be combined in any suitable manner. For example, in FIG. 3A, combined tag history 312 includes each tag from tag histories 308 and 310. Thus, in the illustrated embodiment, new tag history 312 includes a total of K + N tags (where N is the number of tags in tag history 310) and all tag histories are retained. Similarly, if more than two blocks are combined to form a new block, the tags from the tag history of each of the blocks may remain in the tag history for the new block. In one embodiment, if the same tag value exists in the combined plurality of tag histories, a single instance of the tag value is included in the combined tag history.

In the embodiment of FIG. 3B, tag histories 326 and 328 are combined by merging tag histories and deleting some tags (e.g., due to a limitation on the size of the tag history for each block). Thus, although tag history 326 and tag history 328 each include K tags, combined tag history 330 includes only K tags (assuming that the tag history is limited to K sizes). When tags have to be omitted in a merge due to size limitations, it may be determined which tags are retained in any suitable way. In one embodiment, the tags may be staggered such that the newest tag from tag history 326 is placed in tag history 330, the newest tag from tag history 328 is placed in tag history 330, the next-to-new tag from tag history 326 is placed in tag history 330, the next-to-new tag from tag history 328 is placed in tag history 330, and so on. In another embodiment, the relative frequency of use of certain tags may be considered, and more frequently used tags selected for inclusion in combined tag history 330. In another embodiment, tags from tag history 326 associated with a particular block may be more preferred than tags from tag histories of other blocks (e.g., the block that will form the block with the lowest address in the combined block may retain its tag, or retain more tags relative to other blocks, since such blocks are most susceptible to illegal addressing in some cases). In one embodiment, if the same tag value exists in the combined plurality of tag histories, a single instance of the tag value is selected for inclusion in the combined tag history.

When multiple blocks are combined, a new set of other metadata is also generated. For example, when the associated blocks of other metadata 318 and other metadata 336 are formed from a plurality of other blocks, the other metadata 318 and metadata 336 may be generated (and the metadata 318 and 336 may be at least partially different from the other metadata 314, 316, 332, and 334, respectively). For example, the new other metadata may include metadata specific to the combined chunk, such as a new tag for the chunk (although in some embodiments the current tag is stored in a tag history rather than separately), the size of the combined chunk, the type of data to be stored in the combined chunk, the encryption key or adjustment of the combined chunk, or other suitable metadata.

FIG. 4 illustrates a flow for memory tiling, according to some embodiments. Sometimes, during certain heap management operations, a given free block may split into two parts. For example, when only large free blocks are available, the larger block may be split into two smaller blocks in order to satisfy smaller memory allocation requests. As another example, a resizing operation that specifies a block size smaller than the size of the subject block may result in a block split.

During such splitting, the set of metadata for the newly formed chunk each stores a copy of the tag history from the parent chunk. For example, in the depicted embodiment, the chunks associated with metadata 402 are split to form chunks associated with metadata 404 and chunks associated with metadata 406. Thus, tag history 408 is replicated within metadata 404 as well as within metadata 406.

When a chunk is split, a new set of other metadata is also generated for each of the result chunks. For example, other metadata 412 and other metadata 414 may be generated when their associated chunks are formed from the split (and they may be at least partially different from other metadata 410). Other new sets of metadata may include metadata specific to their respective chunk, such as a new tag for the chunk (e.g., in embodiments where the current tag is stored separately rather than in a tag history), the size of the new chunk, the type of data to be stored in the new chunk, an encryption key or adjustment for the new chunk, or other suitable metadata.

While the large tag history is more secure by preventing access through persistent hover pointers, the large tag history may present challenges when finding new tags for blocks, especially after defragmentation (where tag histories from each block are combined together into a tag history for a new block). In some embodiments where the tag history length is not limited (or is different for different chunks), to alleviate this problem, the heap manager 104 may limit the number of chunks that may be combined into a new chunk during a defragmentation operation.

In various embodiments, the maximum size of the tag history for each block (e.g., when all blocks have the same maximum tag history size) may be configured by a user of device 100 or dynamically modified during runtime based on allocation behavior observed by heap manager 104. If the key used by the processor changes frequently (the tag history may be reinitialized each time the key is changed), the maximum size of the tag history may be kept relatively short, while if the key changes infrequently, the maximum size of the tag history may be larger to reduce isolation.

In various embodiments, rather than a random string of blocks, the tags for the blocks may include other metadata or block-based information associated with the blocks (or may have a portion dedicated to such metadata and another portion that is random). For example, the tag may include an ID of the data type associated with the block (e.g., the data type described above or other suitable data type) or a portion of the ID of the data type. Such embodiments may reduce isolation as it allows the same data block to be reused for allocations involving different data types. In some embodiments, the ID of the data type may be specified in the memory allocation request, allowing the heap manager 104 to include the ID of the data type (or a portion thereof) in the tag.

As another example, the tag may include the size of the block (or other information indicating the size of the block). Such embodiments may also reduce isolation because it allows reuse of a given data block for allocation (in some cases even the same data type) as long as the allocations are of different sizes. In some embodiments, the heap manager 104 may respond to a memory allocation request for a block of a particular size by allocating the same block, but changing the size of the block, such that the tag for the block is different than the previously allocated block. In some embodiments, the heap manager may change the size of a block in response to determining that keeping the same block size will result in isolation of the block (e.g., because no allowable tag values are available). Changing the size of the blocks may be accomplished in any suitable manner. For example, a data block may be partitioned and one of the resulting data blocks allocated. As another example, a data block may be combined with an adjacent data block, and the combined data block may be allocated. In some embodiments, the size of the data blocks may be changed by requesting allocation of the same data blocks for various allocation sizes. For example, a given block may be used to request an allocation of a size equal to or less than the size of the block. For example, a 32 byte block may be used for a data block size of 4, 8, 16, or 32 bytes. As long as the size information is encoded in the tags, the tags assigned to the data blocks are unique in the allocations of various sizes.

Fig. 5 depicts a flow 500 for a pointer 510 encoded with an example encryption, the pointer 510 including an embedded size 502 and an embedded tag 501, in accordance with certain embodiments of the present disclosure. In various embodiments, the embedded size bit 502 in combination with one or more other bits (e.g., embedded tag 501 or other bits) in the cryptographically encoded pointer 510 (or other data described herein) may be considered a tag (as described above in connection with tag history) or may be used as an added security metric in connection with such tags for the data block associated with the pointer.

Fig. 5 shows a 64-bit pointer (address) that is cryptographically encoded in its basic format using exponent (power) sized metadata. Such pointers may be returned to the calling application by the heap manager 104 in response to the allocation of blocks in the heap fitting with an allocation size of the nearest power of 2. In the illustrated example, the encoding pointer includes a size metadata portion 502 (e.g., 5 bits in the illustrated example) that indicates the size of a variable plaintext portion 508 (e.g., 6 bits in the illustrated example) of a pointer 510 (e.g., a number of low-order address bits of the variable plaintext portion 508 that include the pointer 510, which bits may be freely manipulated by an application for pointer arithmetic when the application accesses memory within the block, and thus, the number of bits of the variable plaintext portion 508 indicates the size of the allocated block that is addressed by the pointer that points to the nearest power of 2). In some embodiments, the size portion 502 may include power (exponent) size metadata bits that indicate a size based on a power of 2. Other embodiments may provide more granularity of metadata or metadata offsets to better fit the data allocation size.

As shown in fig. 5, the size metadata portion 502 may indicate the number of bits that make up the immutable plaintext portion 506 and the mutable plaintext portion 508. In some embodiments, the total number of bits making up the immutable plaintext portion 506 and the mutable plaintext portion 508 may be constant, with the size of the respective portions being determined by the size metadata portion 502. For example, if the power metadata value is 0, then there are no variable plaintext bits, and all 27 remaining address bits (i.e., the immutable plaintext portion 506) are used as adjustments to generate the ciphertext portion 504 from the address slice (i.e., the subset of linear address bits), where the ciphertext portion 504 is adjacent to and more significant than the immutable plaintext portion 506. Additionally, the embedded tag 501 may be encrypted using the same block cipher as the ciphertext portion of the address, while the immutable plaintext portion of the address 506 is used as an adjustment to encrypt the combination of the embedded tag 501 and the address 504. As another example, if the power metadata value is 1, there is one variable plaintext bit, and if the power metadata value is 2, there are 2 variable plaintext bits, up to 27 variable plaintext bits, resulting in no immutable plaintext bits (506). The variable plaintext portion 508 may be manipulated by software, for example, for pointer arithmetic or other operations. Meanwhile, some embodiments may retain a special value of the size field 502 to indicate a legacy canonical linear address (e.g., a size value in which all bits are set to zero or all bits are set to one indicates a non-encoded or regular linear address that may be used to access memory in the clear). The ciphertext portion 504 (e.g., 32 bits in the illustrated example) of the pointer 510 may be encrypted with a small adjustable block cipher (e.g., a 32-bit block size k cipher, a SIMON, a PRINCE, or a SPECK cipher, or other variable bit size block cipher). The remaining address bits constitute the immutable plaintext portion 506 (e.g., 21 bits in the illustrated example) and are used as part of an adjustment to the adjustable block cipher used to encrypt the ciphertext portion 504. Although these bits are also the plaintext (unencrypted) portion of the address, they cannot be modified by an application like the bits of the variable plaintext portion 508 (e.g., using pointer arithmetic) without causing the ciphertext portions 504 and 501 to be decrypted incorrectly, thereby corrupting the values of both the result address 524 and the tag 521 (possibly resulting in a page fault and/or a tag mismatch). The basic pointer format shown in fig. 5 allows encryption to describe the object size and its location in memory. In some cases, the exponent/power/size metadata portion 502 may be provided as a separate parameter in addition to the pointer. However, in some cases (e.g., as shown), bits of size metadata portion 502 may be integrated with pointer 510 to provide legacy compatibility.

In an alternative embodiment, the size metadata portion 502 may indicate the number of bits making up the immutable plaintext portion 506, and thus the number of remaining bits making up the alterable plaintext portion 508. For example, if the power metadata value is 1, then there are no immutable plaintext bits (506), and all 27 remaining address bits (i.e., the mutable plaintext portion 508) can be manipulated by software. As another example, if the power metadata value is 2, there is one bit of immutable plaintext 506, if the power metadata value is 3, there is 2 bits of immutable plaintext 506, up to 27 bits of immutable plaintext, resulting in no variable plaintext bits (508), and thus, no bits that can be manipulated by software.

Further, although pointer 510 is shown and described based on using 32 bits for ciphertext portion 504, the pointer format is not intended to be so limited. The address slice to be encrypted may be selected based on a readily available 32-bit block encryption cipher. However, encryption ciphers using any other block size (e.g., 27, 16, variable, etc.) may be used instead. If the number of ciphertext bits is adjusted (up or down), the remaining address bits to be encoded (e.g., the immutable and variable portions) may be adjusted accordingly. For example, if the ciphertext portion is adjusted to 16 bits, the combined immutable and mutable plaintext portions (506 and 508) may be encoded to 43 bits. In this case, however, additional bits may be added to the size metadata portion 502, reducing the combined immutable and variable portion to 42 bits, such that the size metadata portion 502 may indicate that any possible number of bits (e.g., 0-42 bits) make up the immutable plaintext portion 506 and the variable plaintext portion 508.

When the processor is operating in an encrypted mode and accesses memory using an encoded pointer (address) (e.g., a pointer formatted in the same or similar manner as pointer 510 of fig. 5) to obtain the actual linear/virtual address memory location, the processor employs the encoded address format and decrypts the ciphertext portion (e.g., 504 of fig. 5) using a variable number of immutable plaintext bits (e.g., 506 of fig. 5) determined by the size/power/exponent metadata bits (e.g., 502 of fig. 5) and the secret key. In some cases, size/power/exponent metadata and/or other metadata or context information may be included as part of the adjustment for decrypting ciphertext portion 504. If the address decryption is incorrect, the processor may cause a general protection fault (# GP) or a page fault due to an attempt to memory access with a corrupted linear/virtual address or otherwise incorrect tag value.

In various embodiments, data (e.g., data that includes or depends on size) from pointer 510 may be used (e.g., as a key or adjustment) to encrypt data in the block to which the pointer refers (thus, the pointer may reference data and may also describe how the data is encrypted). Thus, if the size in pointer 510 is changed, the data for the block will be encrypted differently, and the pointer previously used to reference the block (in the previous allocation of the block) cannot be used to decrypt the data for the block.

The operation of flow 500 is described in three phases: address decryption (stage I), address formation (stage II) and data decryption (stage III). In stage I, the linear address embedded in pointer 510 is decrypted. Specifically, the encoded linear address and the ciphertext portion 504 of the embedded tag 501 are decrypted by a decryption algorithm, such as an adjustable block cipher 520, using an address key 518 and an address adjustment 516. In the illustrated embodiment, address adjustment 516 includes bits of size metadata portion 502 and immutable plaintext portion 506 in addition to zero padding 511. The size metadata portion 502 is used to determine the number of bits in the immutable plaintext portion 506 and the number of bits in the changeable plaintext portion 508 that is equal to the number of bits used for padding 511 in the address adjustment 516. In at least some embodiments, the additional one or more items of variable length metadata may also be used as part of the address adjustment 516 for the adjustable block cipher 520. For example, the variable length metadata may include other contextual information or metadata (e.g., rights, privilege levels, types, locations, ownership, etc.). The block CIPHER 520 may be any suitable decryption algorithm (e.g., an adjustable version of a 32-bit block size CIPHER may be used, such as SIMON, SPECK, K-CIPHER, or PRINCE, XTS-AES block CIPHER, LRW, AES-CTR mode, etc. for larger addresses).

When the encoded linear address and the ciphertext 504 portion of the embedded tag 501 have been decrypted by the adjustable block cipher 520 into a decrypted address slice 524 and a tag 521, then a decoded linear address 530 may be formed in stage II. In at least one embodiment, the most significant bits (e.g., the size portion 502) may be set to the same bit value (e.g., 0 or 1) to represent a canonical linear address. In addition, the bits of the immutable plaintext portion 506 and the variable plaintext portion 508 constitute the lower bits of the decoded linear address 530. In some embodiments, the processor may check whether the higher order bits of decrypted address pieces 524 have the expected specification value as an indication of whether decrypted address pieces 524 were incorrectly decrypted. For example, in some paging modes, all of the same values (i.e., all 0 s or all 1 s) require a certain number of higher address bits. If the corresponding bits in decrypted address slice 524 have different values, this indicates that decrypted address slice 524 was decrypted incorrectly. In this case, some embodiments may generate a fault. In the case of using the decoded linear address 530, some other embodiments may rely on existing specification checks to generate a fault. Even if the upper bits do have the same value, there may be no conclusive indication that the decrypted address slice 524 has been correctly decrypted. Some embodiments may perform the above checks on the expected bit values for both the minimum and maximum addresses to be accessed in the current operation, such that if any portion of the access is out of range, a fault is likely to be generated. Other embodiments may require that only a particular portion of the access (e.g., the first byte) is within the range of the pointer, and thus the above check is performed only on the expected bit value on the pointer for that portion of the access. Other embodiments may check the minimum and maximum addresses for a write operation, but only check a single pointer value for a read, relying on data encryption to prevent partial out-of-bounds reads from returning the correct plaintext. Given the sparse nature of the linear address space, a wrongly decrypted address slice 524 will most likely result in a page fault since no page is present in the page table. Finally, the decrypted tag 521 (shown, for example, as a three-bit tag, although other embodiments may use a larger or smaller tag field) must also correctly match the tag value associated with the memory allocation.

The decoded linear address 530 is used to find the memory location of the encrypted data to be decrypted in phase III (the encrypted data may be stored in a cache). The encrypted data is decrypted by a decryption algorithm, such as counter mode key stream generator 550. In at least one embodiment, the keystream generator 550 may be implemented as an AES-CTR mode block cipher at a particular size granularity (any suitable size). In this embodiment, the contents of the cryptographically encoded pointer are used as an Initialization Vector (IV) or data adjust 544, while the plaintext offset (e.g., 508) is used as a counter value (CTR). The generation of the keystream 551 may begin without waiting for the encrypted address slice 504 to complete. Keystream generator 550 encrypts data adjustment 544 based on data key 542 to generate keystream 551. The value of data adjust 544 may be adjusted to equal 0 (modulo the block size of keystream generator 550) before being used as input to the keystream generator. The value of data adjustment 544 may have some suitable number of least significant bits set to 0 to satisfy the requirement, and the prefix of keystream 551 may be dropped to account for the adjustment. The number of bytes of keystream 551 to discard may be calculated by subtracting the adjusted value of data adjustment 544 from the unadjusted value of data adjustment 544. This adjustment may modify the value of immutable plaintext 506 in pointers to objects smaller than the block size. However, data encryption may be indirectly tied to the value of the modified non-variable bits, as these bits may be incorporated into the adjustments used to generate the ciphertext 504. If the memory to be encrypted crosses one or more block-aligned boundaries, keystream generator 550 may be recalled for subsequent blocks, with data adjust 544 increasing by an amount equal to the block size each time it is recalled. The suffix of the generated keystream 551 may not be needed and is therefore discarded. An XOR operation 552 may then be performed on the keystream 551 and the encrypted input data block (or cache line) 546 selected from the memory location referenced by the decoded linear address 530. The granularity of the encrypted input data block 546 matches the keystream 551 output from the keystream generator 550, and an XOR operation 552 produces a decrypted output data block 554. Likewise, when storing data back to cache/memory, the same operation may be performed, where the plain data from the processor registers may be XOR' ed with the keystream output 551 for the encoded address 544, and the resulting encrypted data written back to memory.

When embedded size and tags are included in the cryptographic encoding (e.g., as shown in fig. 5 or similar embodiments), the tags are by object size and location of the object in memory. Thus, if the heap manager 104 is consistent with respect to object size (e.g., always replacing a released object with another object of the same size but with a different embedded tag, e.g., by incrementing the last tag value), the heap manager 104 does not have to worry about the adjacency of tags nor keep a history of the assignment of these tags. If the access object is beyond its boundary, the pointer decode logic will catch the error. The tag can then simply be used to prevent post-release use attacks. Furthermore, if the tag values stored in memory are also encrypted as data as shown herein, the memory tags themselves become dependent on the size and location in memory of the object, allowing the heap manager 104 to freely allocate the same tag values for different object sizes, occupying the same location in memory over time (multiple allocations and releases). In the encrypted tag scheme, each memory access to the data also includes decryption and verification of the corresponding tag value stored in memory.

When the tag is encrypted in memory, the heap manager 104 prepares the correct encrypted tag value that is bound to the cryptographically encoded pointer. This may be accomplished, for example, using a SetTag processor instruction (or equivalent) that has the cryptographically encoded address 510 as an input for the associated data. Thus, the SetTag instruction may generate an appropriate encrypted tag value in memory for the encoded linear address 510, encrypt a memory tag based on the encoded address, determine a tag value based on the decoded (e.g., decrypted) linear address 530, and locate a tag entry in memory (e.g., when a table of tag values is stored in linear memory). For example, if each 4-bit tag stored in memory represents a 16-byte allocation, by invoking the SetTag instruction four times for the beginning of each 16-byte offset 508, 4 tags may be set to cover the 64-byte allocation in memory to ensure that each tag is encrypted for the corresponding data offset. The tag table will then have an entry for each 16 bytes of the linear address and be sized to 1/32 of the addressable linear memory, where each entry includes an encrypted version of the same tag (e.g., 521), but since each entry is encrypted based on a different encryption coded address 510 (e.g., since the variable plain text bits 508 may vary across the address 510 used to encrypt the tag entry), the entries corresponding to the same allocated block of data may have different values. Similarly, the GetTag instruction may provide a decrypted memory tag value for the incoming encoded linear address 510, returning the decrypted tag from memory given the decoded address 530. In various embodiments, encryption and decryption of the memory tag is performed by using the encoded linear address 510 as an adjustment (or as a counter initialization value).

FIG. 11 depicts a flow for associating an encryption tag with a corresponding sub-portion of an allocated data block, in accordance with certain embodiments. The figure depicts an example showing some of the embodiments described in the preceding paragraph. The encoded linear address 510 corresponds to a data block allocation defined by a variable number of address bits enumerated by the size bits at the address represented by the encoded linear address 510 (in this example, a four 16-byte portion or an allocation of 64 bytes is covered by 6 least significant address bits of the 502 size value, indicating that the 6 address bits are variable and are not used for address adjustment, because 64 ═ 2^ 6). In some embodiments, the size field 502 indirectly relates to the data allocation size by specifying how many plaintext address bits 506 to use to calculate an adjustment of the encrypted portion of the address 504. The remainder (508) corresponds to address bits that can be manipulated for pointer arithmetic. As long as the array index stays within its bounds, the requestor will not increment its size beyond the number of address bits indicated by the size field 502. However, if such an increase does occur, 504 will not decrypt properly, possibly generating a failure or other error. Each different portion of the data block is associated with a 4-bit memory tag value in the memory tag table 1104 (various embodiments may choose different tag sizes) (in various embodiments, the memory tag table 1104 may be stored in the same memory as the data 1102 or in a separate memory). Thus, the allocated data block includes 4 portions, each portion associated with a different memory tag value. As described above, each memory tag value may be encrypted based on the encrypted encoded address of the corresponding 16-byte portion of the allocated data block. Thus, although the four memory tag values of the four sub-portions of the allocated data block represent the same value (i.e., the plaintext tag value), each memory tag value may be encrypted differently (since each memory tag value is encrypted using a different encoded address offset). When a portion (e.g., a 16-byte portion) of a block of data is referenced in a memory access instruction, the memory tag value associated with the portion may be decrypted and compared to the tag provided in the decrypted address 530 via a memory load/store access request (in at least some embodiments, the tag may also be decrypted during the address decryption operation 520). Thus, the correct decryption of the memory tag value in 1104 depends on the size of the associated data allocation, its location in memory, the encrypted address slice 504, and the tag value in the address. If the decrypted tag values match, a memory access instruction is executed. If not, an exception or fault (or other error) may be triggered. In the illustrated embodiment, the other assigned data blocks have corresponding memory tag values that include encrypted versions of the tags assigned to their respective data blocks.

Instructions that access the memory tag table 1104 (e.g., SetTag, GetTag, or the like) may be privileged or invoked only by the heap manager 104 (e.g., based on the location of the code in memory), or otherwise restricted to prevent malicious tampering with tag values stored in memory (e.g., by requiring an authorization code known only to authorized software such as the heap manager 104). To ensure that an adversary cannot infer a keystream (e.g., 551) by observing the encrypted memory tag, a different data key 542 may be used when encrypting (e.g., using the SetTag instruction) or decrypting (e.g., using the GetTag instruction) the memory tag value to verify during execution of a data store and/or load instruction. Other embodiments may adjust the keystream input 544 to indicate whether the memory access is for allocated data or a memory tag.

Embodiments in which the tag is encrypted and stored based on encryption pointer 510 may provide additional protection against hostile participants. For example, when the tag is not encrypted, the same tag value (e.g., the unencrypted tag value) may be repeated for each entry corresponding to a portion (e.g., a 16 byte portion) of the allocated block of data. Thus, if an adversary can guess the tag value, the adversary can access the entire buffer using the same tag value. However, when memory tags are encrypted, each encrypted tag will have a different encrypted value depending on its location (and therefore each incorrectly decrypted memory tag will produce a different random value), and therefore an adversary will have to correctly guess the tag value of each access of a portion of the block of data, thus significantly increasing the chance of capturing invalid or malicious buffer accesses.

In various embodiments, the above-described tagging constraints may be considered on a key-by-key basis. For example, the heap manager 104 may encrypt a portion of the pointer returned in response to the memory allocation request using an encryption key stored in a register of the processor 102, and/or the processor 102 may encrypt data stored in a heap block. Thus, when a particular key is used, the label assigned to a particular data block must be different from the label of the block's label history, and possibly different from the label used by the adjacent data block. However, if the key being used is changed, the tag history for the various blocks associated with the key may be reset or otherwise modified so that the tag history generated when the previous key was used does not affect the tag selection for the data block assigned when the new key was used. In some embodiments, the tag histories may each be associated with a respective key. For example, a first set of tag histories for a block of data may be generated and used to constrain the assignment of tags to assignment blocks encrypted based on a first key, while a second set of tag histories may be generated and used to constrain the assignment of tags to assignment blocks encrypted based on a second key.

In particular embodiments, an application requesting memory allocation may provide a key that should be used to encrypt the data of the resulting block (either by encrypting the data directly using the key or by encrypting a portion of the pointer and possibly using the data from the pointer to encrypt the data to be stored in the block). Upon receiving the identification of the key, the heap manager 104 may look up a tag history associated with the key to find blocks to allocate, and may allocate tags that are not part of the tag history.

The above description relates to keys and adjustments. As used herein, the term "key" may refer to a cryptographic secret that is passed as input to a cryptographic mode, and may support at least one of confidentiality and data integrity functions. For example, a key may refer to a secret bit string that is extended into a circular key schedule string as is performed by typical block ciphers. As used herein, "adjusting" may refer to a value comprising one or more bits used to customize the operation of a block cipher or cryptographic hash function. For example, an adjustment may refer to an additional input to a block cipher (e.g., an input other than the usual plaintext or ciphertext input and encryption key), among other things. When the same plaintext is encrypted using the same encryption key, different adjustment values will result in different encrypted data outputs. Similarly, when the same cipher text is decrypted using the same encryption key, different adjustment values will result in different plaintext outputs. Any suitable cryptographic mode may be used to perform the encryption and decryption operations described herein. For example, the processor 102 may utilize an advanced encryption Standard electronic codebook (AES-ECB), an AES xor-encrypt-xor (XEX) -based modified codebook mode with cipher-stealing (AES-XTS), an AES counter (AES-CTR), a k-cipher, a SIMON, a PRINCE, or a SPECK cipher, or other suitable encryption modes of operation.

FIG. 6 illustrates a flow for allocating heap memory, in accordance with certain embodiments. The operations of the flow may be performed by any suitable logic, such as processor 102.

At 602, a memory heap operation is requested. For example, a memory heap operation may include a request to allocate a data block in a heap memory, to free a data block in a heap memory, or to adjust a data block size in a heap memory. At 604, a data block of the memory heap is identified. For example, when the request is a request to allocate a data block, the identified data block may be a data block that matches a size included in the request. As another example, when the request is a request to release a data block, the identified data block may be the data block identified by the request.

At 606, candidate tags for the data block are identified. At 608, it is determined whether the candidate tag matches a tag in the tag history for the data block, or whether the candidate tag violates any other constraints (e.g., matches a tag of a neighboring data block). If the constraint is not violated, a label is assigned to the data block at 610. If the candidate tag violates the constraint, a determination is made at 612 whether additional candidate tags are available. If additional candidate tags are available, flow returns to 606. If all possible tags have been exhausted and the data block does not have a suitable tag available, the data block may be quarantined at 614.

The flows depicted in fig. 3, 4, and 6 are merely representative of operations or communications that may occur in a particular embodiment. In other embodiments, additional operations or communications may be performed in the flow. Various embodiments of the present disclosure contemplate any suitable signaling mechanism for implementing the functionality described herein. Some of the operations illustrated in fig. 3, 4, and 6 may be repeated, combined, modified, or deleted where appropriate. Additionally, operations may be performed in any suitable order without departing from the scope of particular embodiments.

7-10 are block diagrams of exemplary computer architectures that can be used in accordance with any of the embodiments disclosed herein. In general, any computer architecture design known in the art for processors and computing systems may be used. In examples, system designs and configurations known in the art for laptop computers, desktop computers, handheld PCs, personal digital assistants, tablet computers, engineering workstations, servers, network devices, servers, devices, network hubs, routers, switches, embedded processors, Digital Signal Processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, smart phones, mobile devices, wearable electronic devices, portable media players, handheld devices, and various other electronic devices are also applicable to embodiments of the computing systems described herein. In general, suitable computer architectures for the embodiments disclosed herein may include, but are not limited to, the configurations shown in fig. 7-10.

Fig. 7 is an example illustration of a processor according to an embodiment. Processor 700 is an example of one type of hardware device (e.g., processor 102) that may be used in connection with the implementations shown and described herein. Processor 700 may be any type of processor, such as a microprocessor, an embedded processor, a Digital Signal Processor (DSP), a network processor, a multi-core processor, a single-core processor, or other device that executes code. Although only one processor 700 is shown in fig. 7, the processing elements may alternatively comprise more than one of the processors 700 shown in fig. 7. Processor 700 may be a single-threaded core, or for at least one embodiment, processor 700 may be a multi-threaded core in that each core may contain more than one hardware thread context (or "logical processor").

Fig. 7 also shows a memory 702 coupled to the processor 700 according to an embodiment. Memory 702 is an example of one type of hardware device (e.g., memory 122) that may be used in connection with the implementations illustrated and described herein. The memory 702 may be any of a wide variety of memories (including various layers of a memory hierarchy) known or otherwise available to those of skill in the art. Such memory elements may include, but are not limited to, Random Access Memory (RAM), Read Only Memory (ROM), logic blocks of a Field Programmable Gate Array (FPGA), Erasable Programmable Read Only Memory (EPROM), and electrically erasable programmable ROM (eeprom).

Processor 700 may execute any type of instructions associated with the algorithms, processes, or operations detailed herein. In general, the processor 700 may transform an element or an article (e.g., data) from one state or thing to another state or thing.

Code 704, which may be one or more instructions to be executed by processor 700, may be stored in memory 702, or in software, hardware, firmware, or any suitable combination thereof, or in any other internal or external component, device, element, or object, where appropriate and according to particular needs. In one example, the processor 700 may follow a program sequence of instructions indicated by code 704. Each instruction enters front-end logic 706 and is processed by one or more decoders 708. The decoder may generate as its output a micro-operation, such as a fixed width micro-operation, in a predetermined format, or may generate other instructions, micro-instructions, or control signals that reflect the original code instruction. Front-end logic 706 also includes register renaming logic 710 and scheduling logic 712, which typically allocate resources and queue the operation corresponding to the instruction for execution.

Processor 700 may also include execution logic 714 having a set of execution units 716a, 716b, 716n, etc. 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 one execution unit that may perform a particular function. The execution logic 714 performs the operations specified by the code instructions.

After completing execution of the operations specified by the code instructions, back-end logic 718 may undo the instructions of code 704. In one embodiment, processor 700 allows out-of-order execution but requires instructions to be retired in order. Retirement logic 720 may take various known forms (e.g., reorder buffer, etc.). In this manner, processor 700 is transformed during execution of code 704, at least in terms of the decoder-generated outputs, the hardware registers and tables utilized by register renaming logic 710, and any registers (not shown) modified by execution logic 714.

Although not shown in fig. 7, the processing elements may include other elements on a chip with the processor 700. For example, the processing elements may include memory control logic with processor 700. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element may also include one or more caches. In some embodiments, non-volatile memory (such as flash memory or fuses) may also be included on the chip with the processor 700.

Fig. 8A is a block diagram illustrating both an example sequential pipeline and an example register renaming, out-of-order launch/execution pipeline in accordance with one or more embodiments of the present disclosure. Fig. 8B is a block diagram illustrating an example embodiment of a sequential architecture core and an example register renaming, out-of-order launch/execution architecture core to be included in a processor according to one or more embodiments of the present disclosure. The solid boxes in fig. 8A-8B show sequential pipelines and sequential cores, while the optional addition of dashed boxes shows register renaming, out-of-order launch/execution pipelines and cores. The unordered aspect will be described assuming that the order aspect is a subset of the unordered aspect.

In FIG. 8A, a processor pipeline 800 includes a fetch stage 802, a length decode stage 804, a decode stage 806, an allocation stage 808, a rename stage 810, a scheduling (also known as dispatch or issue) stage 812, a register read/memory read stage 814, an execution stage 816, a write back/memory write stage 818, an exception handling stage 822, and a commit stage 824.

Fig. 8B shows a processor core 890, the processor core 890 comprising a front end unit 830 coupled to an execution engine unit 850, and both coupled to a memory unit 870. Processor core 890 and memory unit 870 are examples of the types of hardware that may be used in connection with the embodiments shown and described herein (e.g., processor 102, memory 122). The core 890 may 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. Alternatively, the core 890 may be a dedicated core, such as, for example, a network or communication core, compression engine, coprocessor core, general purpose computing graphics processing unit (GPGPU) core, graphics core, or the like. Additionally, processor core 890 and its components represent an example architecture that may be used to implement a logical processor and its corresponding components.

The front end unit 830 includes a branch prediction unit 832, the branch prediction unit 832 coupled to an instruction cache unit 834, the instruction cache unit 834 coupled to an instruction Translation Lookaside Buffer (TLB) unit 836, the instruction Translation Lookaside Buffer (TLB) unit 836 coupled to an instruction fetch unit 838, the instruction fetch unit 838 coupled to a decode unit 840. The decode unit 840 (or decoder) may decode the instruction and generate as output one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals, which are decoded from, or otherwise reflect, or are derived from, the original instruction. The decoding unit 840 may be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, look-up tables, hardware implementations, Programmable Logic Arrays (PLAs), microcode read-only memories (ROMs), and the like. In one embodiment, core 890 includes a microcode ROM or other medium that stores microcode for certain macroinstructions (e.g., in decode units 840 or otherwise within front-end units 830). The decode unit 840 is coupled to a rename/allocator unit 852 in the execution engine unit 850.

The execution engine unit 850 includes a rename/allocator unit 852 coupled to an exit unit 854 and a set of one or more scheduler units 856. Scheduler unit 856 represents any number of different schedulers, including reservation stations, central instruction windows, and so forth. The scheduler unit 856 is coupled to a physical register file unit 858. Each of the physical register file units 858 in the physical register file units 858 represents one or more physical register files, different ones of which store one or more different data types, such as scalar integers, scalar floating points, packed integers, packed floating points, vector integers, vector floating points, states (e.g., an instruction pointer, which is the address of the next instruction to be executed), and so forth. In one embodiment, one or more physical register file units 858 include a vector register unit, a writemask register unit, and a scalar register unit. These register units may provide architectural vector registers, vector mask registers, and General Purpose Registers (GPRs). In at least some embodiments described herein, the register unit 858 is an example of the type of hardware (e.g., registers 112) that may be used in connection with the implementations shown and described herein. The retirement unit 854 overlaps the physical register file unit 858 to illustrate the various ways in which register renaming and retirement register files may be implemented (e.g., using a reorder buffer and retirement register file; using future files, history buffers, and retirement register files; using register maps and register pools; etc.). An exit unit 854 and a physical register file unit 858 are coupled to the execution cluster 860. The execution cluster 860 includes a set of one or more execution units 862 and a set of one or more memory access units 864. The execution units 862 may perform various operations (e.g., shifts, additions, subtractions, multiplications) on various types of data (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 group of functions, other embodiments may include only one execution unit or multiple execution units that all perform all functions. Execution units 862 may also include address generation units (e.g., 822) to compute addresses used by the cores to access main memory (e.g., memory unit 870) and Page Miss Handlers (PMHs) (e.g., 826).

The scheduler unit 856, physical register file unit 858, and execution cluster 860 are shown as possibly complex because certain embodiments create separate pipelines for certain types of data/operations (e.g., a scalar integer pipeline, a scalar floating point/packed integer/packed floating point/vector integer/vector floating point pipeline, and/or a memory access pipeline, each having its own scheduler unit, physical register file unit, and/or execution cluster-and in the case of a separate memory access pipeline, certain embodiments are implemented in which only the execution cluster of that pipeline has a memory access unit 864). It should also be understood that where separate pipelines are used, one or more of these pipelines may be launched/executed out of order, while the rest are sequential.

The set of memory access units 864 is coupled to a memory unit 870, the memory unit 870 including a data TLB unit 872, the data TLB unit 872 coupled to a data cache unit 874, the data cache unit 874 coupled to a level two (L2) cache unit 876. In one exemplary embodiment, the memory access units 864 may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit 872 in the memory unit 870. Instruction cache unit 834 is further coupled to a level two (L2) cache unit 876 in memory unit 870. The L2 cache unit 876 is coupled to one or more other levels of cache and ultimately to main memory. Additionally, if a match is not found in the data TLB unit 872, a page miss handler (e.g., page miss handler 826) may also be included in the core 890 to look up the address mapping in the page table.

By way of example, the exemplary register renaming, out-of-order launch/execution core architecture may implement pipeline 800 as follows: 1) instruction fetch 838 performs fetch and length decode stages 802 and 804; 2) the decode unit 840 performs a decode stage 806; 3) rename/allocator unit 852 performs allocation stage 808 and renaming stage 810; 4) the scheduler unit 856 executes the scheduling stage 812; 5) the physical register file unit 858 and the memory unit 870 execute the register read/memory read stage 814; the execution cluster 860 executes the execution stage 816; 6) the memory unit 870 and the physical register file unit 858 execute the write-back/memory write stage 818; 7) various units may be involved in the exception handling stage 822; 8) the retirement unit 854 and the physical register file unit 858 execute the commit stage 824.

Core 890 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, sunnyvale, california; the ARM instruction set (with optional additional extensions, such as nen), of ARM Holdings, sunnyvale, california), including instructions described herein.

It should be appreciated that a core may support multithreading (performing two or more parallel operations or sets of threads), and this may be done in a variety of ways, including slice multithreading, simultaneous multithreading (a logical core in which a single physical core provides multiple threads for each thread simultaneously), or a combination thereof (e.g., slice fetching and decoding and simultaneous multithreading thereafter, such as

Hyper threading technology). Thus, in at least some embodiments, a multi-threaded enclave (multi-threaded enclave) may be supported.

Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming may be used in a sequential architecture. While the illustrated embodiment of the processor also includes a separate instruction and data cache unit 834/874 and a shared L2 cache unit 876, alternative embodiments may have a single internal cache for both instructions and data, such as, for example, a level 1 (L1) internal cache, or multiple levels of internal cache. In some embodiments, a system may include a combination of internal caches and external caches that are external to the core and/or processor. Alternatively, all caches may be external to the core and/or processor.

Fig. 9 illustrates a computing system 900 that is arranged in a point-to-point (PtP) configuration, according to an embodiment. In particular, FIG. 9 shows a system where processors, memory, and input/output devices are interconnected by a number of point-to-point interfaces. In general, one or more computing systems or computing devices (e.g., computing device 100) described herein may be configured in the same or similar manner as computing system 900.

Processors 970 and 980 may be implemented as single- core processors 974a and 984a or multi-core processors 974a-974b and 984a-984 b. Processors 970 and 980 may each include a cache 971 and 981 for use by their respective core or cores. A shared cache (not shown) may be included in one or both processors but still connected with the processors via the PP interconnect such that local cache information for one or both processors may be stored in the shared cache if the processors are placed in a low power mode. It should be noted that one or more embodiments described herein may be implemented in a computing system, such as computing system 900. Further, processors 970 and 980 are examples of the types of hardware (e.g., processor 102) that may be used in connection with the implementations illustrated and described herein.

Processors 970 and 980 may also each include integrated memory controller logic (MC)972 and 982 to communicate with memory elements 932 and 934, which may be portions of main memory locally attached to the respective processors. In alternative embodiments, memory controller logic 972 and 982 may be discrete logic separate from processors 970 and 980. Memory elements 932 and/or 934 may store various data to be used by processors 970 and 980 to implement the operations and functions outlined herein.

Processors 970 and 980 may be any type of processor, such as those discussed in connection with the other figures. Processors 970 and 980 may exchange data via a point-to-point (PtP) interface 950 using point-to- point interface circuits 978 and 988, respectively. Processors 970 and 980 may each exchange data with an input/output (I/O) subsystem 990 via separate point-to- point interfaces 952 and 954 using point-to- point interface circuits 976, 986, 994, and 998. The subsystem 990 may also exchange data with a high-performance graphics circuit 938 via a high-performance graphics interface 939 using an interface circuit 992, which may be a PtP interface circuit. In one embodiment, the high performance graphics circuit 938 is a special-purpose processor, such as, for example, a high-throughput MIC processor, a network or communication processor, compression engine, graphics processor, GPGPU, embedded processor or processor, or the like. I/O subsystem 990 may also communicate with a display 933 to display data visible to a human user. In alternative embodiments, any or all of the PtP links shown in figure 9 could be implemented as a multi-drop bus instead of PtP links.

The I/O subsystem 990 may communicate with the bus 910 via the interface circuit 996. The bus 910 may have one or more devices that communicate over it, such as a bus bridge 918, I/O devices 916, audio I/O924, and a processor 915. The bus bridge 918 may communicate with other devices via a bus 920, such as a user interface 922 (such as a keyboard, mouse, touch screen, or other input device), a communication device 926 (such as a modem, network interface device, or other type of communication device that may communicate over a computer network 960), and/or a data storage device 928. The data storage device 928 may store code and data 930 that may be executed by the processors 970 and/or 980. In alternative embodiments, any portion of the bus architecture may be implemented using one or more PtP links.

Program code, such as code 930, may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For purposes of this application, a processing system may be part of computing system 900 and include 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.

Program code (e.g., 930) may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. Program code can also be implemented in assembly or machine language, if desired. Indeed, the scope of the mechanisms described herein is not limited to any particular programming language. In any case, the language may be a compiled or interpreted language.

One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium which represents various logic within a processor, which when read by a machine, causes the machine to fabricate logic to perform one or more of the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible, machine-readable medium and provided to various customers or manufacturing facilities for loading into the fabrication machines that actually manufacture the logic or processor.

Such machine-readable storage media may include, but are not limited to, a non-transitory tangible arrangement of articles manufactured or formed by a machine or device, including storage media such as a hard disk, any other type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), Random Access Memories (RAMs) such as Dynamic Random Access Memories (DRAMs), Static Random Access Memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), Phase Change Memories (PCMs), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.

Accordingly, 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 define structures, circuits, devices, processors, and/or system features described herein. Such embodiments may also be referred to as program products.

The computing system depicted in fig. 9 is a schematic diagram of an embodiment of a computing system that may be used to implement the various embodiments discussed herein. It will be appreciated that the various components of the system depicted in fig. 9 may be combined in a system-on-a-chip (SoC) architecture or any other suitable configuration capable of implementing the functions and features of the examples and implementations provided herein.

In some cases, an instruction converter may be used to convert instructions from a source instruction set to a target instruction set. For example, the instruction converter may translate (e.g., using static binary translation, including dynamic binary translation of dynamic compilation), morph, emulate, or otherwise convert an instruction into one or more other instructions to be processed by the core. The instruction converter may be implemented in software, hardware, firmware, or a combination thereof. The instruction converter may be on the processor, off the processor, or partially on and partially off the processor.

FIG. 10 is a block diagram comparing conversion of binary instructions in a source instruction set to binary instructions in a target instruction set using a software instruction converter, according to an embodiment of the disclosure. In the illustrated embodiment, the instruction converter is a software instruction converter, but alternatively, the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof. Fig. 10 shows a program that may compile a high-level language 1002 using an x86 compiler 1004 to generate x86 binary code 1006 that may be natively executed by a processor having at least one x86 instruction set core 1016. A processor having at least one x86 instruction set core 1016 represents any processor that can perform substantially the same functions as 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 by compatibly executing or otherwise processing (1) a majority of the instruction set of the Intel x86 instruction set core, or (2) an object code version for an application or other software running on the Intel processor having at least one x86 instruction set core. The x86 compiler 1004 represents a compiler operable to generate x86 binary code 1006 (e.g., object code), which x86 binary code may execute on a processor having at least one x86 instruction set core 1016 with or without additional linking processing. Similarly, fig. 10 shows a program that may compile a high-level language 1002 using an alternative instruction set compiler 1008 to generate alternative instruction set binary code 1010 that may be natively executed by a processor that does not have at least one x86 instruction set core 1014 (e.g., a processor having a core that executes a MIPS instruction set of MIPS Technologies, sunnyvale, california and/or an ARM instruction set that executes ARM Holdings, sunnyvale, california). The instruction converter 1012 is used to convert the x86 binary code 1006 into code that can be natively executed by a processor without the x86 instruction set core 1014. This translation code is unlikely to be the same as the alternate instruction set binary code 1010 because instruction translators with this capability are difficult to manufacture; however, the translated code will perform as normal and consist of instructions from the standby instruction set. Thus, the instruction converter 1012 represents software, firmware, hardware, or a combination thereof that, through emulation, simulation, or any other process, allows a processor or other electronic device that does not have an x86 instruction set processor or core to execute the x86 binary code 1006.

Logic may be used to implement the functionality of any of the flows or various components described herein, such as the heap manager 104, the runtime tag generator 105, the runtime tag checker 106, other components of the computing device 100, the processor 700, the pipeline 800, the core 890, the system 900, subcomponents of any of them (e.g., the heap manager 104), or other entities or components described herein. "logic" may refer to hardware, firmware, software, and/or combinations of each to perform one or more functions. In various embodiments, logic may comprise a microprocessor or other processing element operable to execute software instructions, discrete logic such as an Application Specific Integrated Circuit (ASIC), a programmed logic device such as a Field Programmable Gate Array (FPGA), a memory device containing instructions, a combination of logic devices (e.g., as would be found on a printed circuit board), or other suitable hardware and/or software. Logic may include one or more gates or other circuit components. In some embodiments, logic may also be fully embodied as software. The software may be embodied as a software package, code, instructions, instruction sets, and/or data recorded on a non-transitory computer-readable storage medium. Firmware may be embodied as code, instructions or instruction sets and/or data that are hard-coded (e.g., nonvolatile) in a storage device.

While the present disclosure has been described in terms of certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. For example, the acts described herein may be performed in an order different than that described and still achieve desirable results. As one example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may be advantageous. Other variations are within the scope of the following claims.

The architecture presented herein is provided by way of example only and is intended to be non-exclusive and non-limiting. Moreover, the various portions disclosed are merely intended to be logical partitions and do not necessarily represent physically separate hardware and/or software components. Some computing systems may provide memory elements in a single physical memory device, and in other cases, memory elements may be functionally distributed across many physical devices. In the case of a virtual machine manager or virtual machine hypervisor, all or part of the functionality may be provided in the form of software or firmware running on the virtualization layer to provide the disclosed logical functionality.

Note that with the examples provided herein, interaction may be described in terms of a single computing system. However, this is done for clarity and example purposes only. In some cases, it may be easier to describe one or more functions of a given set of streams with reference to only a single computing system. Moreover, the system for deep learning and malware detection is easily scalable and can be implemented across a large number of components (e.g., multiple computing systems) and more complex/sophisticated arrangements and configurations. Thus, the examples provided should not limit or potentially apply to the broad teachings of computing systems of myriad other architectures.

As used herein, unless explicitly stated to the contrary, use of the phrase "at least one" refers to any combination of named items, elements, conditions, or activities. For example, "at least one of X, Y and Z" is intended to mean any of the following: 1) at least one X, but not Y, but not Z; 2) at least one Y, but not X, but not Z; 3) at least one Z, but not X, but not Y; 4) at least one X and at least one Y, but not Z; 5) at least one X and at least one Z, but not Y; 6) at least one Y and at least one Z, but not X; or 7) at least one X, at least one Y and at least one Z.

In addition, unless explicitly stated to the contrary, the terms "first," "second," "third," and the like are intended to distinguish between particular nouns (e.g., elements, conditions, modules, activities, operations, claim elements, and the like) that are modified, but are not intended to indicate any type of order, hierarchy, importance, chronological order, or hierarchy of the modified nouns. For example, "first X" and "second X" are intended to mean two separate X elements, which are not necessarily limited by any order, hierarchy, importance, chronological order, or hierarchy of the two elements.

References in the specification to "one embodiment," "an embodiment," "some embodiments," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may or may not include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment.

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

Similarly, the separation of various system components and modules in the embodiments described above should not be understood as requiring such separation in all embodiments. It should be understood that the described program components, modules and systems can generally be integrated together in a single software product or packaged into multiple software products.

Thus, particular embodiments of the present subject matter have been described. Other embodiments are within the scope of the present disclosure. Numerous other changes, substitutions, variations, alterations, and modifications may be ascertained to one skilled in the art and it is intended that the present disclosure encompass all such changes, substitutions, variations, alterations, and modifications as falling within the scope of the appended claims.

Example 1 may include a processor, comprising: a decoder to decode a first instruction requesting a memory heap operation; and a heap manager comprising circuitry, the heap manager to: identifying a data block of a memory heap in response to a first instruction requesting a memory heap operation; accessing a tag history for the data block, the tag history comprising a plurality of tags previously assigned to the data block; assigning a tag to the data block, wherein assigning the tag includes verifying that the tag does not match any of a plurality of tags of the tag history; and provides the assigned tag and a reference to the location of the data block.

Example 2 may include the subject matter of example 1, wherein assigning a tag to the data block further comprises verifying that the tag does not match a tag of a data block adjacent to the data block.

Example 3 may include the subject matter of any one of examples 1-2, wherein the requested memory heap operation is a memory allocation operation.

Example 4 may include the subject matter of any one of examples 1-2, wherein the requested memory heap operation is a memory release operation.

Example 5 may include the subject matter of any one of examples 1-4, wherein the decoder is to decode a second instruction requesting a second memory heap operation; and a heap manager for: in response to a second instruction requesting a second memory heap operation: identifying a second data block of the memory heap; accessing a tag history for the second data block, the tag history including a plurality of tags previously assigned to the second data block; and isolating the second data block in response to determining that no tags are available for the second data block, the determining that no tags are available for the second data block based at least in part on a tag history for the second data block.

Example 6 may include the subject matter of any one of examples 1-5, wherein the heap manager is further to reset the tag history in response to a switch in encryption keys.

Example 7 may include the subject matter of any one of examples 1-6, wherein the heap manager is to: in response to a first instruction requesting a memory heap operation, defragmenting a plurality of data blocks to form data blocks; and combining the tag histories for the multiple data chunks to form a tag history for the data chunks.

Example 8 may include the subject matter of any one of examples 1-6, wherein the heap manager is to: partitioning the second data block into a data block and a third data block in response to a first instruction requesting a memory heap operation; and copying the tag history for the second data block to form a tag history for the data block and a tag history for a third data block.

Example 9 may include the subject matter of any one of examples 1-8, wherein at least a portion of the tag indicates a size of the data block.

Example 10 may include the subject matter of any one of examples 1-9, wherein at least a portion of the tag indicates a data type of the data block.

Example 11 may include the subject matter of any one of examples 1-10, wherein the processor is to: receiving a request to access a data block, the request indicating a location of the data block and a second tag; and granting access to the data block in response to determining that the second tag matches the tag assigned to the data block.

Example 12 may include the subject matter of any one of examples 1-11, further including one or more of: a battery communicatively coupled to the processor, a display communicatively coupled to the processor, or a network interface communicatively coupled to the processor.

Example 13 may include a method comprising: identifying a data block of a memory heap in response to a first instruction requesting a memory heap operation; accessing a tag history for the data block, the tag history comprising a plurality of tags previously assigned to the data block; assigning a label to the data block, wherein assigning the label comprises: verifying that the tag does not match any of the plurality of tags of the tag history; and providing the assigned tag and a reference to the location of the data block.

Example 14 may include the subject matter of example 13, wherein assigning the tag to the data block further comprises: the authentication tag does not match the tag of the data block adjacent to the data block.

Example 15 may include the subject matter of any one of examples 13-14, wherein the requested memory heap operation is a memory allocation operation.

Example 16 may include the subject matter of any one of examples 13-14, wherein the requested memory heap operation is a memory release operation.

Example 17 may include the subject matter of any one of examples 13-16, wherein the method further comprises: identifying a second data block of the memory heap in response to a second instruction requesting a second memory heap operation; accessing a tag history for the second data block, the tag history including a plurality of tags previously assigned to the second data block; and isolate the second data block in response to a determination that no tag is available for the second data block, the determination that no tag is available for the second data block based at least in part on a tag history for the second data block.

Example 18 may include the subject matter of any one of examples 13-17, the method further comprising resetting the tag history in response to a switch in the encryption key.

Example 19 may include the subject matter of any one of examples 13-18, further comprising: in response to a first instruction requesting a memory heap operation, defragmenting a plurality of data blocks to form data blocks; and combining the tag histories for the multiple data chunks to form a tag history for the data chunks.

Example 20 may include the subject matter of any one of examples 13-18, further comprising: partitioning the second data block into a data block and a third data block in response to a first instruction requesting a memory heap operation; and copying the tag history for the second data block to form a tag history for the data block and a tag history for a third data block.

Example 21 may include the subject matter of any one of examples 13-20, wherein at least a portion of the tag indicates a size of the data block.

Example 22 may include the subject matter of any one of examples 13-21, wherein at least a portion of the tag indicates a data type of the data block.

Example 23 may include the subject matter of any one of examples 13-22, wherein the processor is to receive a request to access the data block, the request indicating a location of the data block and the second tag; and in response to determining that the second tag matches the tag assigned to the data block, authorizing access to the data block.

Example 24 may include one or more non-transitory computer-readable media having code stored thereon, wherein the code is executable to cause a machine to, in response to a first instruction requesting a memory heap operation: identifying a data block of a memory heap; accessing a tag history for the data block, the tag history comprising a plurality of tags previously assigned to the data block; assigning a label to the data block, wherein assigning the label comprises: verifying that the tag does not match any of the plurality of tags of the tag history; and providing the assigned tag and a reference to the location of the data block.

Example 25 may include the subject matter of example 24, wherein assigning a label to the data block further comprises: the authentication tag does not match the tag of the data block adjacent to the data block.

Example 26 may include the subject matter of any one of examples 24-25, wherein the requested memory heap operation is a memory allocation operation.

Example 27 may include the subject matter of any one of examples 24-25, wherein the requested memory heap operation is a memory release operation.

Example 28 may include the subject matter of any one of examples 24-27, wherein the code is executable to cause a machine to: in response to a second instruction requesting a second memory heap operation: identifying a second data block of the memory heap; accessing a tag history for the second data block, the tag history including a plurality of tags previously assigned to the second data block; and isolating the second data block in response to determining that no tags are available for the second data block, the determining that no tags are available for the second data block based at least in part on a tag history for the second data block.

Example 29 may include the subject matter of any one of examples 24-28, wherein the code is executable to cause the machine to reset the tag history in response to a switch of the encryption key.

Example 30 may include the subject matter of any one of examples 24-29, wherein the code is executable to, in response to a first instruction requesting a memory heap operation, defragment a plurality of data blocks to form the data blocks; and combining the tag histories for the multiple data chunks to form a tag history for the data chunks.

Example 31 may include the subject matter of any one of examples 24-29, wherein the code is executable to, in response to a first instruction requesting a memory heap operation, chunk a second data block into a data block and a third data block; and copying the tag history for the second data block to form a tag history for the data block and a tag history for a third data block.

Example 32 may include the subject matter of any one of examples 24-31, wherein at least a portion of the tag indicates a size of the data block.

Example 33 may include the subject matter of any one of examples 24-32, wherein at least a portion of the tag indicates a data type of the data block.

Example 34 may include the subject matter of any one of examples 24-33, wherein the code is executable to cause a machine to receive a request to access the data block, the request indicating a location of the data block and the second tag; and in response to determining that the second tag matches the tag assigned to the data block, authorizing access to the data block.

Example 35 may include the subject matter of any one of examples 1-12, wherein the heap manager is to request an association of a first encryption tag with a first sub-portion of the block of data and request an association of a second encryption tag with a second sub-portion of the block of data, wherein the first encryption tag includes an assignment tag encrypted based on an address of the first sub-portion, and wherein the second encryption tag includes an assignment tag encrypted based on an address of the second sub-portion.

Example 36 may include the subject matter of example 35, wherein the address of the first sub-portion and the address of the second sub-portion each comprise cryptographically encoded address bits.

Example 37 may include the subject matter of any one of examples 13-23, further comprising: an association of a first encryption tag with a first sub-portion of the block of data and an association of a second encryption tag with a second sub-portion of the block of data will be requested, wherein the first encryption tag includes an assignment tag encrypted based on an address of the first sub-portion, and wherein the second encryption tag includes an assignment tag encrypted based on an address of the second sub-portion.

Example 38 may include the subject matter of example 37, wherein the address of the first sub-portion and the address of the second sub-portion each comprise cryptographically encoded address bits.

Example 39 may include the subject matter of any one of examples 24-34, wherein the code is executable to cause the machine to request an association of a first encryption tag with a first sub-portion of the block of data and to request an association of a second encryption tag with a second sub-portion of the block of data, wherein the first encryption tag includes an assignment tag encrypted based on an address of the first sub-portion, and wherein the second encryption tag includes an assignment tag encrypted based on an address of the second sub-portion.

Example 40 may include the subject matter of example 39, wherein the address of the first sub-portion and the address of the second sub-portion each comprise cryptographically encoded address bits.

Claims (27)

1. A processor, comprising:

a decoder to decode a first instruction requesting a memory heap operation; and

circuitry implementing a heap manager, the heap manager to:

in response to the first instruction requesting the memory heap operation:

identifying a data block of a memory heap;

accessing a tag history for the data chunk, the tag history comprising a plurality of tags previously assigned to the data chunk;

assigning a label to the data block, wherein assigning the label comprises: verifying that the tag does not match any of the plurality of tags of the tag history; and

providing the assigned tag and a reference to the data chunk location.

2. The processor of claim 1, wherein assigning the label to the data block further comprises: verifying that the tag does not match a tag of a data block adjacent to the data block.

3. The processor of any of claims 1-2, wherein the requested memory heap operation is a memory allocation operation.

4. The processor of any of claims 1-2, wherein the requested memory heap operation is a memory release operation.

5. The processor of any one of claims 1-4, wherein:

the decoder decodes a second instruction requesting a second memory heap operation; and

the heap manager is to:

in response to the second instruction requesting the second memory heap operation:

identifying a second data block of the memory heap;

accessing a tag history for the second data block, the tag history including a plurality of tags previously assigned to the second data block; and

isolating the second data block in response to determining that no tags are available for the second data block, the determining that no tags are available for the second data block based at least in part on the tag history for the second data block.

6. The processor of any one of claims 1-5, wherein the heap manager is further to: resetting the tag history in response to a switch in encryption keys.

7. The processor of any one of claims 1 to 6, wherein the heap manager is to:

in response to the first instruction requesting the memory heap operation, defragmenting a plurality of data blocks to form the data blocks; and

combining tag histories for the plurality of data chunks to form the tag history for the data chunks.

8. The processor of any one of claims 1 to 6, wherein the heap manager is to:

in response to the first instruction requesting the memory heap operation, blocking a second data block into the data block and a third data block; and

copying a tag history for the second data block to form the tag history for the data block and a tag history for the third data block.

9. The processor of any one of claims 1-8, wherein at least a portion of the tag indicates a size of the data block.

10. The processor of any one of claims 1-9, wherein at least a portion of the tag indicates a data type of the data block.

11. The processor of any one of claims 1-10, wherein the processor is to:

receiving a request to access the data block, the request indicating the location and a second tag of the data block; and

in response to determining that the second tag matches the tag assigned to the data block, access to the data block is authorized.

12. The processor of any one of claims 1-11, further comprising one or more of: a battery communicatively coupled to the processor, a display communicatively coupled to the processor, or a network interface communicatively coupled to the processor.

13. The processor of any one of claims 1 to 12, wherein the heap manager is to request an association of a first encryption tag with a first sub-portion of the block of data and to request an association of a second encryption tag with a second sub-portion of the block of data, wherein the first encryption tag includes the assignment tag encrypted based on an address of the first sub-portion, and wherein the second encryption tag includes the assignment tag encrypted based on an address of the second sub-portion.

14. The processor of claim 13, wherein said address of said first subpart and said address of said second subpart each comprise cryptographically encoded address bits.

15. A method, comprising:

in response to a first instruction requesting a memory heap operation:

identifying a data block of a memory heap;

accessing a tag history for the data chunk, the tag history comprising a plurality of tags previously assigned to the data chunk;

assigning a label to the data block, wherein assigning the label comprises: verifying that the tag does not match any of the plurality of tags of the tag history; and

providing the assigned tag and a reference to the data chunk location.

16. The method of claim 15, wherein assigning a label to the data block further comprises: verifying that the tag does not match a tag of a data block adjacent to the data block.

17. The method of any of claims 15-16, wherein the requested memory heap operation is a memory allocation operation.

18. The method of any of claims 15-16, the requested memory heap operation is a memory release operation.

19. The method according to any one of claims 15-18, wherein the method further comprises:

in response to the second instruction requesting the second memory heap operation:

identifying a second data block of the memory heap;

accessing a tag history for the second data block, the tag history including a plurality of tags previously assigned to the second data block; and

isolating the second data block in response to determining that no tags are available for the second data block, the determining that no tags are available for the second data block based at least in part on the tag history for the second data block.

20. The method of any of claims 15-19, further comprising: the tag history is reset in response to the switching of the encryption key.

21. The method of any of claims 15-20, further comprising:

in response to the first instruction requesting the memory heap operation, defragmenting a plurality of data blocks to form the data blocks; and

combining tag histories for the plurality of data chunks to form the tag history for the data chunks.

22. The method of any of claims 15-20, further comprising:

in response to the first instruction requesting the memory heap operation, blocking a second data block into the data block and a third data block; and

copying a tag history for the second data block to form the tag history for the data block and a tag history for the third data block.

23. The method of any of claims 15-22, wherein at least a portion of the tag indicates a size of the data block.

24. The method of any of claims 15-23, wherein at least a portion of the tag indicates a data type of the data block.

25. The method of any of claims 15-24, further comprising:

receiving a request to access a data block, the request indicating a location of the data block and a second tag; and

access to the data block is authorized in response to determining that the second tag matches the tag assigned to the data block.

26. A system comprising means to perform the method of any of claims 14-25.

27. The system of claim 26, wherein the apparatus comprises machine readable code which when executed causes a machine to perform one or more steps of the method of any one of claims 14-25.

Images