Aspects of the present disclosure relate generally to integrity-protected memory, and more specifically to dynamic management of integrity-protected memory during run-time.
A computing device may be exposed to various kinds of attacks on their system memories (e.g., DRAM), as a result of attackers wanting to take control of the computing device for the purposes of executing malicious code (including by triggering a replay of a code and/or data segment that has been replaced with “rolled-back” code and/or data, but appears to be legitimate from the perspective of the computing device, usually referred to as replay protection), read sensitive data that resides within the system memory, or otherwise defeat the computing device's security measures. This may be an issue in all computing environments, but may be especially important in the mobile processing and server environments, since those environments often handle sensitive or confidential data, and are thus readily targeted by attackers.
Integrity protection of the system memory of the computing device can provide a solution to the above-described memory modification and rollback attacks, and thus support for integrity protection is desirable from both a technical and a commercial standpoint. One approach is to apply integrity protection to the entire system memory. However, this approach carries with it significant costs—performing the operations associated with integrity protection (e.g. creating, maintaining, and managing the integrity tree structures) for the entire memory system and on every memory transaction is computationally expensive and involves significant system memory overhead. Thus, it is undesirable to provide integrity protection for the entire system memory. Another approach is to pre-define regions of integrity-protected memory within the system memory, but it is often difficult to know a priori how much integrity-protected memory will be needed by the various software programs that will be executed by the computing device. Additionally, pre-defining regions of integrity-protected memory in this way reduces the flexibility of the system and makes overall system memory management more cumbersome.
It is thus desirable to design a memory system that is able to dynamically expand or contract the amount of memory designated as integrity-protected memory within the memory system.
The following presents a simplified summary of one or more aspects in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated aspects, and is intended to neither identify key or critical elements of all aspects nor delineate the scope of any or all aspects. Its sole purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.
In a particular aspect, an apparatus comprises a first memory and a second memory. The first memory comprises a plurality of bits, where each bit of the plurality of bits of the first memory is associated with a region of the second memory. Further, each bit of the plurality of bits of the first memory indicates whether the associated region of the second memory is to be integrity-protected. Further, a first bit of the plurality of bits of the first memory may be associated with a first region of the second memory, and a second bit of the plurality of bits of the first memory may be associated with a second region of the second memory, where the first region of the second memory and the second region of the second memory are non-contiguous.
In another aspect, a method comprises setting a first bit of a plurality of bits of a first memory. Each bit of the plurality of bits of the first memory is associated with a region of a second memory, and indicates whether the associated region of the second memory is to be integrity-protected. The method may further comprise setting a second bit of the plurality of bits of the first memory. The second bit indicates that an associated second region of the second memory is to be integrity protected, and the second region of the second memory is non-contiguous with the first region of the second memory.
In yet another aspect, an apparatus comprises a means for storing integrity protection information including a plurality of indicators. The apparatus further comprises a means for storing. Each indicator of the plurality of indicators is associated with a region of the means for storing, and each indicator indicates whether the associated region of the means for storing is to be integrity-protected. Further, a first indicator may be associated with a first region of the means for storing and a second indicator may be associated with a second region of the means for storing. The first region and the second region may be non-contiguous.
In yet another aspect, a non-transitory computer readable medium comprises instructions which, when executed by a processor, cause the processor to set a first bit of a plurality of bits of a first memory. Each bit of the plurality of bits is associated with a region of a second memory, and the first bit of the plurality of bits indicates whether an associated first region of the second memory is to be integrity-protected. Further, the instructions may cause the processor to set a second bit of the plurality of bits of the first memory. The second bit indicates than an associated second region of the second memory is to be integrity-protected, where the second region of the second memory is non-contiguous with the first region of the second memory.
One advantage of one or more disclosed aspects is that the disclosed aspects allow for non-contiguous regions of the system memory to have integrity protection, and further allow for the adjustment of which regions of system memory have integrity protection during run-time, which reduces the overhead associated with integrity protection and improves system power and performance characteristics.
Aspects of the inventive teachings herein are disclosed in the following description and related drawings directed to specific aspects. Alternate aspects may be devised without departing from the scope of the inventive concepts herein. Additionally, well-known elements of the environment may only be generally described or omitted so as not to obscure the relevant details of the inventive teachings herein.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects. Likewise, the term “aspects of the invention” does not require that all aspects of the invention include the discussed feature, advantage or mode of operation.
The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of aspects of the invention. As used herein, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising,” “includes,” and/or “including,” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
Further, certain aspects are described in terms of sequences of actions to be performed by, for example, elements of a computing device. It will be recognized that various actions described herein can be performed by specific circuits (e.g., application specific integrated circuits (ASICs)), by program instructions being executed by one or more processors, or by a combination of both. Additionally, these sequences of actions described herein can be considered to be embodied entirely within any form of computer readable storage medium having stored therein a corresponding set of computer instructions that upon execution would cause an associated processor to perform the functionality described herein. Thus, the various aspects of the invention may be embodied in a number of different forms, all of which have been contemplated to be within the scope of the claimed subject matter. In addition, for each of the aspects described herein, the corresponding form of any such aspects may be described herein as, for example, “logic configured to” perform the described action.
Aspects of the present disclosure include an apparatus for dynamic management of integrity-protected memory. In this regard,
The on-die memory 112 provides secure storage for the minimum set of data necessary to provide integrity protection for the memory 104. In this regard, to provide for dynamic management of integrity protection for the memory 104, in one aspect, the on-die memory 112 includes integrity protection information 130. As will be further explained in reference to
In addition to storing the integrity protection bitmap, the integrity protection information 130 also is configured to store a minimum set of data necessary to provide integrity protection (e.g. a root hash for a standard Merkle integrity protection tree, or a counter and MAC for a Bonsai Merkle tree, as non-limiting examples), hereinafter referred to as the “MSD,” per bit of the integrity protection bitmap that is set to indicate that the associated chunk of memory 104 is to be integrity-protected. Each MSD is associated with an integrity protection tree, and is also associated with a bit of the integrity protection bitmap. Thus, each bit of the integrity protection bitmap is associated with a full integrity protection tree, where only the MSD of the integrity protection tree is stored in the on-die memory 112. By storing only the integrity protection bitmap and MSD for each integrity protection tree in the on-die memory 112 (which is sufficient to provide integrity protection for the associated chunk of memory 104), the size of the on-die memory 112 may be kept relatively smaller, conserving die area.
Although the aspect illustrated in
Further implementation details of the integrity protection information 130 are illustrated in
As discussed above with reference to
Upon system initialization, re-start, or other similar events, all of the integrity protection bits 232-0 through 232-N may be set to a value indicating that no integrity protection for memory 104 is desired (for example, logic 0 in the illustrated aspect). Thereafter, during run-time, when the operating system or other software needs integrity protection for a chunk of memory, the integrity protection bit 232 corresponding to that chunk of memory is set to a value indicating that integrity protection is desired (for example, logic “1” in the illustrated aspect), and an integrity protection tree associated with that integrity protection bit 232 is created (for example, integrity protection bit 232-3 is set to logic “1,” which triggers creation of the integrity protection tree 260). When a particular chunk of memory 104 no longer needs to be integrity-protected, the associated integrity protection bit can be set to a logic “0.”
The number and type of tree sub-nodes and sub-sub-nodes depicted in
Details of the operation of the integrity protection apparatus described with respect to
In block 320, in response to the request described in block 310, a bit associated with the requested chunk of integrity-protected memory is set in the integrity protection bitmap 232. In reference to
In block 330, an integrity tree corresponding to the requested chunk of integrity protected memory is established by creating an MSD in the on-die memory. For example, MSD 234 of the integrity protection tree 260 is established in the integrity protection information 130 (which is contained within the on-die memory 112). Once the MSD 234 has been established in the integrity protection information 130, the rest of the integrity protection tree 260 may be created within the associated chunk of memory 104 as needed.
The preceding method steps 310-330 may be repeated each time a request to establish a new chunk of integrity protected memory is received. The requested chunks may be contiguous or non-contiguous to previously requested chunks, and requests for new chunks of integrity protected memory may be made during run-time. Once a chunk of memory has been established as integrity protected as described with respect to blocks 310-330, all memory operations on that chunk of memory are accompanied by a verification and/or update of the associated integrity protection tree by the integrity protection logic. Additionally, the region of the chunk of memory dedicated to storing the integrity protection tree will be inaccessible to normal software.
Further, to reduce system overhead during periods of run-time when less integrity-protected memory is needed, chunks of integrity-protected memory may be released by the operating system and returned to a non-integrity-protected status. For example, in block 340, a request to release the chunk of integrity-protected memory is received. Similar to the request in block 310, this request may be in the form of an exception coupled with a macro instruction, a dedicated architected instruction, a system call to a security extension, or any other method known to those having skill in the art.
In response, in block 350, the bit associated with the requested chunk of integrity-protected memory in the integrity protection bitmap is cleared. Once the bit has been cleared, the associated chunk of memory may be used normally and without the overhead associated with integrity protection, and the region of the chunk of memory dedicated to storing the integrity protection tree may be made accessible to normal software. Blocks 340 and 350 may be repeated as needed by the computing device until there are no longer any regions of memory that are integrity-protected, and as with establishing integrity-protected chunks of memory, releasing chunks of integrity-protected memory may be done during run-time. Thus, a computing device that implements the above-described aspects may be able to effectively manage integrity-protected memory as needed during normal device operation, and need not be reset to change the amount of integrity-protected memory provided, nor pay the overhead associated with integrity-protecting the entire memory system.
Although the preceding description illustrates the integrity protection information 130 as residing specifically in a separate on-die memory 112, in other aspects, the integrity protection information may be stored in the memory controller 124 or elsewhere on die. Similarly, although a single memory controller 124 and on-die memory 112 have been illustrated, related aspects contemplate the use of multiple memory controllers and on-die memories, all of which may implement integrity protection as described in
An example apparatus in which aspects of this disclosure may be utilized will now be discussed in relation to
In a particular aspect, input device 430 and power supply 444 are coupled to the system-on-chip device 422. Moreover, in a particular aspect, as illustrated in
It should be noted that although
Those of skill in the art will appreciate that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
Further, those of skill in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The methods, sequences and/or algorithms described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.
Accordingly, an aspect of the invention can include a computer readable media embodying a method for dynamically managing an integrity protected memory, as described in reference to
Further, those having skill in the art will recognize that the described systems and methods for dynamically managing an integrity protected memory may be combined with other mechanisms. For example, integrity protection may be combined with memory encryption (which provides confidentiality of memory contents).
While the foregoing disclosure shows illustrative aspects of the invention, it should be noted that various changes and modifications could be made herein without departing from the scope of the invention as defined by the appended claims. The functions, steps and/or actions of the method claims in accordance with the aspects of the invention described herein need not be performed in any particular order. Furthermore, although elements of the invention may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.