Patent Application
20080162866
The present invention relates generally to computer memory and in particular, but not exclusively, to an apparatus, system and method for fast and secure memory context switching in a computer memory.
Most if not all computers operate using some sort of context. The most familiar and most used context is the operating system that runs all the basic functions of nearly every computer. The operating system is the “super program” that controls the basic operations of the computer such as input, output, scheduling and memory management and also provides the context within which other programs, such as user applications, can run. Thus, for example, most personal computers use some version of Microsoft Windows as an operating system, and MS Windows provides the context within which application such as Microsoft Outlook, Word and Excel can run.
In some circumstances a user might have some applications that run on MS Windows and others that run on a different operating system such as Linux, and it might occasionally be necessary to switch between Windows and Linux. In these circumstances, it would be most convenient and economical for the user to be able to use more than one operating system on the same computer instead of having a separate computer running each operating system. This can be accomplished by enabling the user to switch contexts by switching operating systems.
When the computer user wants to change operating systems, he or she can instruct system 100 to switch between the first operating system and the second operating system. In a very primitive and basic implementation, upon receiving the instruction to switch operating systems the entire computer shuts down and proceeds to re-boot using the second operating system. In a slightly more sophisticated implementation, when system 100 receives an instruction to switch operating systems the processor sends instructions to memory controller 102 to flush the first operating system from memory 106. Once the first operating system is flushed from memory, memory controller 102 accesses storage 104, where it finds the code for the second operating system and then transfers the code from storage 104 to memory 106. Once the second operating system is loaded in memory 106, system 100 runs using the second operating system and can use applications designed for the second operating system.
The context-switching approaches described above in connection with
Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.
Embodiments of an apparatus, system and method for fast and secure memory context switching are described herein. In the following description, numerous specific details are described to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail but are nonetheless encompassed within the scope of the invention.
Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in this specification do not necessarily all refer to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
In the embodiment shown, memory modules 210, 212, 214 and 216 are Dual In-Line Memory Modules (DIMMs), each of which includes two rows of memory devices commonly known as “ranks.” Memory module 210, for example, consists of a first row or rank 210a and a second row or rank 210b. A memory device used in the modules can, in one embodiment, comprise a DRAM, although embodiments of the invention are not limited in this respect. Although the illustrated embodiment uses DIMM configurations for memory, in other embodiments of memory system 200 other kinds of memory modules, such as Single In-Line Memory Modules (SIMMs) and the like can be used. Moreover, all the memory modules in memory system 200 need not be of the same kind: in other embodiments any combination of different memory modules can be used for memory modules 210, 212, 214 and 216, so long as the memory modules used have sufficient capacity and can be appropriately addressed and configured using configuration register 204 on memory controller 202. Memory modules 210-216 are grouped into two memory partitions: a first memory partition including memory modules 210 and 214, and a second memory partition including memory modules 212 and 216. This memory partitioning is accomplished by setting appropriate parameters in the configuration register 204 so that the controller address decodes for one memory partition at a time, as further described below in connection with
Communication channels 206 and 208 couple memory modules 210, 212, 214 and 216 to memory controller 202 and allow communication and data interchange between the memory modules and the controller. In one embodiment of memory system 200, communication channels 206 and 208 are electrically conductive paths capable of carrying electrical signals; memory buses in a printed circuit board are an example of such a conductive path. In other embodiments, however, the communication channels could be some other type of electrical communication channel, or could be an entirely different type of communication channel, for example an optical communication channel, such as a waveguide or an optical fiber.
Memory controller 202, also known as a Memory Controller Hub (MCH), controls the flow of data between and among memory modules 210, 212, 214 and 216, as well as the flow of data between memory controller 202 and other components found within a computer (not shown), such as a processor and/or a storage medium. Among other things, memory controller 212 includes at least one configuration register 204. In the illustrated embodiment, which uses DIMMs for memory modules, the configuration register 204 comprises DRAM Rank/Row Boundary (DRB) registers. DRB registers are used to map central processing unit (CPU) and direct memory access (DMA) addresses to the physical memory cells in memory modules 210-216.
On a typical computer system, the basic input-output system (BIOS) programs the configuration registers as part of its normal memory initialization sequence. BIOS queries the DIMMs to determine how much memory each DIMM supports and then programs the correct value in the DRB register for each DIMM. The parameters in the DRB registers tell the chipset how much memory each DIMM supports and how to map processor addresses to the physical memory cells on the DIMM. The DRB registers are programmed in an incremental manner. For a dual-channel embodiment such as the one illustrated:
Total Memory in Ch0=C0—DRB0+C0—DRB1+C0—DRB2+C0—DRB3
Total Memory in Ch1=C1—DRB0+C1—DRB1+C1—DRB2+C1—DRB3
Total Memory in a system=Total Memory in Ch0+Total Memory in Ch1
Many memory systems support dual memory channels, and therefore in such systems a separate set of DRB memory registers can be assigned for each memory channel. Such a dual-channel topology creates memory partitions in a way that does not impact system memory bandwidth.
Memory system 300 differs from memory system 200 mostly in the topology of the memory partitions. In memory system 200, each partition includes a memory module coupled to each communication channel; for example, the first partition includes memory module 210 coupled to communication channel 206 and memory module 214 coupled to communication channel 208. As a result, each memory partition in memory system 200 has two channels of communication with memory controller 202. By contrast, in memory system 300 each partition includes multiple memory modules coupled to the same communication channel; thus, in memory system 300 the first partition includes memory modules 310 and 312, both of which are coupled to the same communication channel 306, and the second partition includes memory modules 314 and 316, both of which are coupled to the same communication channel 308. As a result, each memory partition has one channel of communication with memory controller 302. As with memory system 200, in memory system 300 the partitions are created by adjusting parameter values within configuration registers 304 so that memory controller address decodes for one partition at a time. Configuring the registers this way ensures that the context (e.g., operating system) running in the first partition does not have access to memory in the second partition and the context (e.g., operating system) running in the second partition does not have access to memory in the first partition, thus avoiding problems such as memory access conflicts.
Processor 402 can be any kind of processor, from a programmable general-purpose processor such as an Intel Pentium processor to an Application Specific Integrated Circuit (ASIC). Among other things, processor 402 includes a certain amount of on-board memory, such as Random-Access Memory (RAM) or other kind of memory, all or portions of which it can use to run certain programs.
One of the programs that processor 402 can run in its on-board memory is a privileged code module (i.e., a code module having greater memory access privileges than an operating system); in the embodiment shown, the privileged code module is an Authenticated Code Module (ACM) 403, but in other embodiments the privileged code module could be a System Management Mode (SMM) module, an embedded microcontroller, or some other privileged code module. In one embodiment the privileged code module is the sole means of at least un-locking the configuration registers, although in other embodiments the privileged code module can configure and lock the registers in addition to unlocking them. In still other embodiments, the privileged code module can un-lock the module while configuration and locking can be performed by a non-privileged code module. Allowing a privileged code module such as an ACM to at least unlock registers can be desirable because it ensures that at least un-locking of the registers is done by privileged code designed to work with the platform.
In the embodiment shown, ACM 403 is digitally signed and cryptographically bound to the platform. Binding is accomplished by computing the hash of the ACM public key and comparing it to a hash that is resident in the chipset or processor hardware. The ACM is launched using existing Secure Machine Extension (SMX) capabilities of the processor. Upon launch of the ACM, processor 402 loads the module into special memory (known as Authenticated Code RAM, or ACRAM) for verification and execution. In one embodiment, ACRAM can be implemented using a special mode of the processor cache, although in other embodiments it can be implemented differently, such as by using a portion of the on-board RAM. Other implementations of ACRAM are possible.
Once the ACM is loaded in ACRAM, the processor verifies the digital signature-to-platform binding, and then verifies the module itself using the digital signature. If the digital signature is successfully verified, processor 402 begins execution of the ACM in a privileged environment in which the ACM has access to privileged LT.Config.Lock and LT.Config.Un-lock commands in the controller. The controller honors these commands when they are issued by an ACM. The Lock/Un-Lock commands control locking and unlocking of the controller's memory control/configuration registers. Embodiments of the invention can use these special commands to unlock the memory configuration registers, change the memory configuration to create memory partitions, and re-lock the configuration registers to insure that memory partitioning can be enabled/disabled by the signed ACM.
Using these commands and/or others ACM 403 implements a secure switch that turns a memory partition on or off to allow switching between different OS contexts in the memory. This is done by manipulating memory configuration registers in a manner that enables hiding or revealing memory partitions and/or memory modules within a partition. In one embodiment, this memory manipulation involves setting the registers so that they address decode for one partition at a time, which allows the controller to manage multiple overlapping physical memory ranges such that one is visible at a time. In this way, the ACM can effectively partition the physical memory into two or more isolated ranges leveraging the controller decode logic to enforce the isolation. This allows for a quicker switching of OS context and adds security to the switching mechanism.
Processor 402 is coupled to non-volatile memory 404 which can be any kind of non-volatile memory; examples include flash memory, ROM, EPROM and the like. Among other things, non-volatile memory 404 can store the Basic Input-Output System (BIOS) that processor 402 needs operate its basic functions until an operating system can be loaded to take over operation of the computer. The BIOS boots the computer, establishes basic connections, performs certain functions prior to loading an operating system and loads the operating system.
While running the first operating system, at block 518 the computer system checks whether an indication has been received to switch operating systems. If no indication is received, the system continues to run the first operating system at block 516. If an indication to switch operating systems is received at block 518, then the ACM unlocks the configuration registers at block 520 and at block 522 sets the parameters in the configuration register so that the controller now decodes addresses associated with the second partition; with configuration parameters set this way, the memory controller recognizes the second partition and behaves as if the first partition is not there at all. When the parameters in the configuration registers are set, the configuration registers are locked by the ACM at block 524 and the second operating system begins to run at block 526.
While running the second operating system, at block 528 the computer system checks whether an indication has been received to switch operating systems. If no indication is received, the system continues to run the second operating system at block 526. If an indication to switch operating systems is received at block 528, then the process returns to block 510, where the ACM unlocks the configuration registers at block 510 and at block 512 sets the parameters in the configuration register so that the controller again decodes addresses for the first partition. Once the parameters in the configuration registers are set, the configuration registers are locked by the ACM at block 514 and the first operating system begins to run at block 516.
Starting at block 552, the computer system starts up. At block 554 the system, for example by using its basic input-output system (BIOS), loads an Authenticated Code Module (ACM) and authenticates the ACM. After the ACM is authenticated, at block 556 the ACM sets the configuration registers to address decode for the first partition; with configuration parameters set this way, the system recognizes the first partition and behaves as if the second partition is not there at all. After the ACM locks the configuration registers at block 558, at block 560 the system loads the first context—in this embodiment, the first operating system—into the first memory partition, boots the operating system and runs the first operating system at block 562.
At block 564 the system awaits an indication to change contexts (i.e., operating systems). If no indication is received, the system continues to run the first operating system. If an indication to change operating systems is received at block 564, the ACM unlocks the configuration registers at block 566, sets the configuration registers to address decode for the second partition at block 568, and again locks the configuration registers at block 570. After locking the configuration registers, the system loads the second operating system into the second partition at block 572, boots the second operating system, and runs the second operating system at block 574.
At block 576 the system awaits an indication to change operating systems. If no indication is received, the system continues to run the second operating system. If an indication to change operating systems is received at block 576, the ACM unlocks the configuration registers at block 578, sets the configuration registers to address decode for the second partition at block 580, and again locks the configuration registers at block 582. After locking the configuration registers, the system switches over to the first operating system, which is already loaded into the first partition, and runs the first operating system at block 584.
At block 586 the system awaits an indication to change operating systems. If no indication is received, the system continues to run the first operating system at block 584. If an indication to change operating systems is received at block 586, the ACM unlocks the configuration registers at block 588, sets the configuration registers to address decode for the second partition at block 590, and again locks the configuration registers at block 592. After locking the configuration registers, the system switches over to the second operating system, which is already loaded into the second partition, and runs the second operating system at block 594.
At block 596 the system awaits an indication to change operating systems. If no indication is received, the system continues to run the second operating system at block 594. If an indication to change operating systems is received at block 596, the process returns to block 578, where it again goes through the context-switching sequence and runs the first operating system at block 584.
When memory controller 202 or 302 receives an indication to change contexts at block 518—in this embodiment, by changing operating systems—configuration register 604 transitions from state 602 to state 610, where it has been unlocked by the Authenticated Code Module (ACM); state 610 therefore corresponds to block 520. After configuration register 604 is unlocked it transitions from state 610 to state 612, in which the parameters for the first memory partition are set so that there is no address encoding for that portion and the parameters for the second memory partition are set so that there is decoding for that partition. The setup of configuration register 604 at state 612 essentially transposes the setup at state 602 and corresponds to block 522. Finally, at state 614 configuration register 604 is again locked in the configuration of state 612; state 614 therefore corresponds to blocks 524 and 526. To switch context from the second operating system back to the first, the configuration registers 604 is re-configured substantially in the reverse order. In other words, the configuration registers start at state 614 (corresponding to blocks 524 and 526) and transition to state 612 (corresponding to block 510), then to state 610 (corresponding to block 512) and finally to state 602, which corresponds to blocks 514 and 516.
As with configuration register 604, operation of configuration register 658 will be discussed with reference to process 500 shown in
When memory controller 202 or 302 receives an indication to change contexts at block 518—in this example, by changing operating systems—configuration register 658 transitions from state 650 to state 660, where it has been unlocked by an Authenticated Code Module (ACM); state 610 therefore corresponds to block 520. After configuration register 658 is unlocked it transitions from state 650 to state 660, in which data communication is established between configuration register 658 and memory 652. Once data communication is established, the parameters for the first memory partition are copied from configuration register 658 to part 654 of memory 652, while parameters for the second memory partition are copied from part 656 of memory 652 to configuration register 658. At state 662, parameters for the second memory partition are loaded into configuration register 658, and the setup of configuration register 658 at state 662 corresponds to block 522. Finally, at state 664 configuration register 604 is locked in the configuration of state 662; state 664 therefore corresponds to block 524.
To switch context from the second operating system back to the first, the configuration registers 658 is re-configured substantially in the reverse order. In other words, the configuration registers start at state 664 (corresponding to blocks 524 and 526) and transition to state 662 (corresponding to block 510), then to state 660 (corresponding to block 512) and finally to state 650, which corresponds to blocks 514 and 516.
The above description of illustrated embodiments of the invention, including what is described in the abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description.
The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
