US20030229794A1 - System and method for protection against untrusted system management code by redirecting a system management interrupt and creating a virtual machine container - Google Patents

Abstract

A system and method for permitting the execution of system management mode (SMM) code during secure operations in a microprocessor system is described. In one embodiment, the system management interrupt (SMI) may be first directed to a handler in a secured virtual machine monitor (SVMM). The SMI may then be re-directed to SMM code located in a virtual machine (VM) that is under the security control of the SVMM. This redirection may be accomplished by allowing the SVMM to read and write the system management (SM) base register in the processor.

Description

FIELD
• The present disclosure relates generally to microprocessor systems, and more specifically to microprocessor systems that may operate in a trusted or secured environment.[0001]
BACKGROUND
• Processors may operate in several processor operating modes depending upon the immediate requirements of system operation. Generally processors may have a supervisor mode, a user mode, and sometimes other special-purpose modes. Supervisor mode may support the execution of the operating system, and may enable the execution of most instructions, including privileged instructions. Access may be given in supervisor mode to a different address space and peripheral devices. User mode may be restricted to non-privileged instructions when compared with supervisor mode, so that user code may not disrupt system functionality.[0002]
• It is often the case that commercially released software is not a perfect fit on a particular original equipment manufacturer's (OEM) hardware suite. Due to specification misunderstandings or implementation errors, there may be situations where the software attempts to access hardware in a manner not anticipated or supported by the hardware. A simple example could be where a software program expects to place a value in a register at address x whereas the actual register in the hardware is at address x+y. This could cause a system exception.[0003]
• In order to deal with such situations, processors may be designed to support an operating mode having the ability to operate in operating system transparent or quasi-transparent manner, or in a privilege-level independent manner, for the purpose of executing low-level patches. For the purpose of the present application such a mode may be defined as a “sub operating system mode”. One such mode is the system management mode (SMM) of the Intel® Pentium® processor family and compatible processors. (See Chapter 14 of the Pentium® 4 Processor Software Developer's Manual, Vol. III, 2001 edition, order number 245472, available from Intel Corporation of Santa Clara, Calif.) Other sub operating system modes may exist in a MIPS Technologies® MIPS32™ or MIPS64™ architecture processor, in an IBM® PowerPC™ architecture processor, in a SPARC International® SPARC® architecture processor, or in many other processors. The existence of a sub operating system mode may have additional system benefits, such as supporting transitions into a power-down mode. In order to deal with software and hardware mismatches as outlined above, existing sub operating system mode implementations may have no privilege restrictions or address mapping restrictions. Sub operating system modes may be invoked by a dedicated sub operating system mode interrupt, sometimes generated by system firmware or system hardware. This dedicated sub operating system mode interrupt is usually designed to be non-maskable in order to respond to the exigencies that required the entry into the mode.[0004]
• A sub operating system mode may generally have the following major mechanisms. The only way to enter the mode is by means of a special sub operating system mode interrupt. In the case of SMM, the dedicated sub operating system mode interrupt is called a system management interrupt (SMI). The processor may execute the mode's code in a separate address space. For example, when the mode is SMM, the separate address space allows access to system management random-access memory (SMRAM), which may be made inaccessible to the other operating modes. When entering the mode, the processor saves the context of the interrupted program or task within the separate address space. For example, in SMM the context is saved into SMRAM. During the execution within the mode, normal interrupts may be disabled. Finally, the mode may be exited by means of a resume instruction that may only be executed while executing within the mode.[0005]
• The increasing number of financial and personal transactions being performed on local or remote microcomputers has given impetus for the establishment of “trusted” or “secured” microprocessor environments. The problem these environments try to solve is that of loss of privacy, or data being corrupted or abused. Users do not want their private data made public. They also do not want their data altered or used in inappropriate transactions. Examples of these include unintentional release of medical records or electronic theft of funds from an on-line bank or other depository. Similarly, content providers seek to protect digital content (for example, music, other audio, video, or other types of data in general) from being copied without authorization.[0006]
• The existence of a sub operating system mode, such as SMM, is a design challenge for designers of secure or trusted systems. The fact that such a sub operating system mode may have no privilege restrictions or address mapping restrictions is incompatible with secure or trusted system architecture. And this lack of privilege restrictions or address mapping restrictions often cannot be avoided by attempting to mask such a mode's dedicated interrupts, because these are usually designed to be non-maskable.[0007]
BRIEF DESCRIPTION OF THE DRAWINGS
• The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:[0008]
• FIG. 1 is a memory mapping of system management mode code in system management RAM in an existing implementation.[0009]
• FIG. 2 is a diagram of an exemplary software environment having trusted and untrusted areas, according to one embodiment.[0010]
• FIG. 3 is a schematic diagram of an exemplary microprocessor system adapted to support the software environment of FIG. 2, according to one embodiment of the present invention.[0011]
• FIG. 4 is a diagram showing a system management code operating in a virtual machine container, according to one embodiment of the present invention.[0012]
• FIG. 5 is diagram showing system management interrupt redirection, according to one embodiment of the present invention.[0013]
• FIG. 6 is a schematic diagram of an exemplary microprocessor system adapted to support the software environment of FIG. 2, according to another embodiment of the present invention.[0014]
• FIG. 7 is diagram showing system management interrupt redirection, according to another embodiment of the present invention.[0015]
DETAILED DESCRIPTION
• The following description describes techniques for permitting the execution of certain system management mode code in a trusted or secured environment in a microprocessor system. In the following description, numerous specific details such as logic implementations, software module allocation, encryption techniques, bus signaling techniques, and details of operation are set forth in order to provide a more thorough understanding of the present invention. It will be appreciated, however, by one skilled in the art that the invention may be practiced without such specific details. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the invention. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation. The invention is disclosed in the form of a microprocessor system. However, the invention may be practiced in other forms of processor such as a digital signal processor, a minicomputer, or a mainframe computer.[0016]
• In order to permit limited sub operating system mode code execution within a secure or trusted environment, the sub operating system mode interrupt may be first directed to a handler in a trusted code that controls virtual machine access to system resources. This direction to the handler may be accomplished by allowing the trusted code to read and write to the interrupt service register in the processor containing the location of the code required to service such a sub operating system mode interrupt. (An interrupt service register may generally be defined as a register that is used to determine that code that should be executed on receipt of an interrupt.) The sub operating system mode interrupt will then be re-directed to sub operating system mode code, located in another virtual machine that is under the security control of the above trusted code, for interrupt servicing. Alternatively, a microprocessor's virtualization architecture may be such that, when trusted code has been established, the sub operating system mode interrupt will no longer use the normal interrupt service register but will instead cause a transition to the trusted code consistent with the virtualization architecture.[0017]
• In an exemplary case where the sub operating system mode is the system management mode (SMM), the SMM code execution within a secure or trusted environment may begin by having the system management interrupt (SMI) first be directed to a handler in a secured virtual machine monitor (SVMM). This direction to the handler may be accomplished by allowing the SVMM to read and write a system management base (SMBASE) register in the processor (PSMBASE). The SMI will then be re-directed to SMM code located in a virtual machine (VM) that is under the security control of the SVMM. Alternatively, the processor's virtualization architecture may disable use of the PSMBASE register and cause redirection of all SMIs to the SVMM directly.[0018]
• In one embodiment, the SMM code may be granted access to all system resources except the protected pages in memory, and the associated system controls that maintain this protection. In order to accomplish this, after the initialization of secured operations the SMIs may be directed to a handler within SVMM first. This handler may establish a suitable virtual machine (VM) container for the SMM code, and re-direct the SMI to that code. By executing the SMM code within the VM container, the SMM code may be prevented from accessing various system resources, such as memory, that the SVMM has deemed protected. In one embodiment, the SMM code may now be written to conform to VM requirements. One such conforming change may be that the SMM code be written in either flat protected mode or in some other page memory access mode.[0019]
• Referring now to FIG. 1, a memory mapping of system management mode (SMM) code in system management random-access memory (SMRAM) is shown in one embodiment. During normal system initialization, a section of system random-access memory (RAM)[0020]110 may be set aside for exclusive use by SMM code. This set aside section is called system management RAM (SMRAM). Specific memory locations within SMRAM may be pointed to by interrupt service registers within the chipset or processor, which in one embodiment are called system management base (SMBASE) registers.
• The chipset SMBASE register's content CSMBASE may define the boundaries of SMRAM. For example, the SMRAM may occupy the space between[0021]CSMBASE120 and CSMBASE+FFFF hex132. In other embodiments, in order to support two or more processors executing SMM code at the same time, each processor may have its own dedicated SMRAM space. The processors' SMBASE register content PSMBASE may define code-entry points and state save locations within SMRAM. For example, within SMRAM a standard code-entry point may be located at CSMBASE+8000hex124. The value of CSMBASE may be written at system initialization to each processor's SMBASE register, thereby allowing each processor to go to the SMM code-entry point upon receipt of an SMI. Prior to entry into SMM code, the processor may in one embodiment store state data in a state save area between an address PSMBASE+FE00 hex128 and the end of SMRAM at location SMBASE+FFFF hex132. In other embodiments, in order to support two or more processors executing SMM code at the same time, each processor's SMBASE register may contain a different value of PSMBASE, permitting differing code-entry points and locations for storing state data.
• The state data may include the values of control registers, flags, an auto halt restart field, an input/output (I/O) instruction restart field, and an SMM revision identifier. Some of the locations within SMRAM may be modified by an SMI handler. Upon completion of SMM code execution, the original program may be re-entered when the processor executes a resume (RSM) instruction. This existing RSM instruction may only be issued within SMM, and it restores the state values previously stored within SMRAM. The use of this existing SMM design is well-known in the art.[0022]
• Referring now to FIG. 2, a diagram of an exemplary trusted or secured software environment is shown, according to one embodiment of the present invention. In the FIG. 2 embodiment, trusted and untrusted software may be loaded simultaneously and may execute simultaneously on a single computer system. A[0023]SVMM250 selectively permits or prevents direct access tohardware resources280 from untrusted operating system240 (or, if multiple untrusted virtual machines are implemented, multiple operating systems) and untrusted applications210 through230. In this context, “untrusted” does not necessarily mean that the operating system or applications are deliberately misbehaving, but that the size and variety of interacting code makes it impractical to reliably assert that the software is behaving as desired, and that there are no viruses or other foreign code interfering with its execution. In a typical embodiment, the untrusted code might consist of the normal operating system and applications found on today's personal computers.
• SVMM[0024]250 also selectively permits or prevents direct access tohardware resources280 from one or more trusted or secure kernels260 and one or more trusted applications270. Such a trusted or secure kernel260 and trusted applications270 may be limited in size and functionality to aid in the ability to perform trust analysis upon it. The trusted application270 may be any software code, program, routine, or set of routines which is executable in a secure environment. Thus, the trusted application270 may be a variety of applications, or code sequences, or may be a relatively small application such as a Java applet.
• Instructions or operations normally performed by[0025]operating system240 or kernel260 that could alter system resource protections or privileges may be trapped bySVMM250, and selectively permitted, partially permitted, or rejected. As an example, in a typical embodiment, instructions that change the processor's page table that would normally be performed byoperating system240 or kernel260 would instead be trapped bySVMM250, which would ensure that the request was not attempting to change page privileges outside the domain of its virtual machine. One way of viewing this system is thatoperating system240, kernel260, andSVMM250 are all virtual machines, withoperating system240 virtual machine and kernel260 virtual machine executing within theSVMM250 virtual machine. Thus a hierarchy of virtual machines is created. Here in one embodiment a virtual machine may be defined as any multi-user shared-resource operating system that gives each user the appearance of having sole control of all the resources of the system, or virtual machine may also be defined as an operating system that is in turn managed by an underlying control program.
• Referring now to FIG. 3, one embodiment of a[0026]microprocessor system300 adapted to support the secured software environment of FIG. 2 is shown.CPU A310,CPU B314,CPU C318, andCPU D322 may be configured with additional microcode or logic circuitry to support the execution of special instructions. In one embodiment, the processors may be Intel® Pentium® class microprocessors with certain special modifications in accordance with an embodiment of the present invention. These special instructions may support the issuance of special bus messages onsystem bus320 that may enable the proper synchronization ofSVMM250 operation in the processors. Similarlychipset330 may support the above-mentioned special cycles onsystem bus320. The number of physical processors may vary upon the implementation of a particular embodiment.
• In the FIG. 3 embodiment, the four[0027]processors CPU A310,CPU B314,CPU C318, andCPU D322 are shown as four separate hardware entities. In other embodiments, the number of processors may differ. Indeed, the processors may be replaced by separate threads, each running on one of the physical processors. In the latter case these threads possess many of the attributes of additional physical processors. In order to have a generic expression to discuss using any mixture of multiple physical processors and multiple threads upon processors, the expression “logical processor” may be used to describe either a physical processor or a thread operating in one of the physical processors. Thus, one single-threaded processor may be considered a logical processor, and multi-threaded or multi-core processors may be considered multiple logical processors.
• Modifications to processors may include, in one embodiment, changes to the behavior of registers and new or modified instructions. For example, in one[0028]embodiment CPU C318 may include a new instruction secure enter (SENTER)324. TheSENTER324 instruction, upon execution, may enable the initiation of secure or trusted operations as shown in FIG. 2 above.SENTER324 may enable multiple logical processors to synchronize their entry into secure or trusted operations. In one embodiment,SENTER324 may also permit writing to the PSMBASE register316 ofCPU C318 in certain circumstances to support secure or trusted SMM operations.
• In one[0029]embodiment CPU C318 may also include a modified resume (RSM)326 instruction. The modifiedRSM326 may permit a return from SMM that supports secure or trusted operations. Ordinarily RSM instructions may only be executed from within SMM. The modifiedRSM326 may be executed from within normal page mode. When invoked with VM extensions enabled, the modifiedRSM326 instruction may perform a special system call, called a VMexit, back to an SVMM handler for SMI.
• The[0030]chipset330 may service read and write requests carried from the CPUs on thesystem bus320, and may then perform the physical read and write operations onphysical memory334. Allocation of SMRAM withinmemory334 may be facilitated by achipset SMBASE register331 containing the value of CSMBASE. Thechipset330 additionally may connect to specialized input/output (I/O) channels, such as an advanced graphics port (AGP)336.Chipset330 may control access to pages of memory withinphysical memory334 fromprocessors CPU A310,CPU B314,CPU C318 andCPU D322, and additionally from I/O devices. Such devices may include mass storage devices such as fixedmedia344 orremovable media348. The fixedmedia344 orremovable media348 may be magnetic disks, magnetic tape, magnetic diskettes, magneto-optical drives, CD-ROM, DVD-ROM, Flash memory cards, or many other forms of mass storage.Fixed media344 orremovable media348 may be connected tochipset330 via peripheral component interconnect (PCI)bus346, or, alternately, via a universal serial bus (USB)342, an integrated controller electronics (IDE) bus (not shown), or a small computer systems interconnect (SCSI) bus (not shown).
• The[0031]SVMM364 may permit or deny the access of a VM to specific pages withinmemory334. The pages of memory that the VM are denied access to may be called “locked” pages, whereas the pages that the VM are permitted access to may be called “unlocked” pages. Within lockedmemory pages360 may be locatedSVMM364 and modules withinSVMM364 to support secure SMM operation. In one embodiment, such modules may include anSVMM SMM handler366 and a virtual machine exit (VMexit)/virtual machine call (VMcall)handler368. In other embodiments the functions of theSVMM SMM handler366 and the VMexit/VMcall handler368 may be combined or may be distributed among other modules. Other pages of memory may remain unlocked, such as unlocked memory pages362. Withinunlocked memory pages362 may be located standard operating systems372. Also withinunlocked memory pages362 may be a SMM virtual machine (SMM VM)370.SMM VM370 may include software code similar to standard SMM code but modified to operate in a virtual machine container. Such modifications inSMM VM370 may include code prepared for execution in page mode rather than normal SMM.
• The memory controller and I/O device controller functions of[0032]chipset330 are shown in the FIG. 3 embodiment as being implemented on a single separate integrated circuit. In alternate embodiments, a separate memory controller integrated circuit may generally implement the memory, controller functions described above forchipset330. Similarly, a separate I/O device controller integrated circuit may generally implement the I/O device controller functions described above forchipset330. In further embodiments, the memory controller functions ofchipset330 may be implemented in circuitry on the CPU integrated circuits, permitting several CPUs to each have direct access to certain amounts of physical memory. In such an embodiment, the memory controller functions ofchipset330 may be divided among the several CPU integrated circuits, or for multiple processors may be included on a single die.
• Referring now to FIG. 4, a diagram of a system management code (SMM) operating in a virtual machine (VM) container is shown, according to one embodiment of the present invention. In the FIG. 4 embodiment,[0033]SVMM450 has two additional modules to support secure or trusted SMM operations. TheSVMM SMM handler452 establishes the SMM code in aSMM VM490 in response to the execution of an SENTER instruction. The VMexit/VMcall handler454 handles entry into and exit from theSMM VM490 due to the intentional lower privilege level ofSMM VM490 within its VM container. In some embodiments, theSVMM SMM handler452 and the VMexit/VMcall handler454 may be the same software module.
• The[0034]SVMM SMM handler452 may perform several functions. During the transition into secure or trusted operations, following the execution of an SENTER command by a processor, theSVMM SMM handler452 loads and initiates theSMM VM490 code in a virtual machine container. In some embodiments,SVMM SMM handler452 would then write an entry location within itself into the modified SMBASE register of each processor in the system. This entry location permits an SMI to be directed first to theSVMM SMM handler452. This may not be necessary for other embodiments that invoke the VMexit/VMcall handler454 directly in response system-management interrupts; for these embodiments, theSVMM SMM handler452 and VMexit/VMcall handler454 would be combined into one software module. TheSVMM SMM handler452 also establishes a space within the locked memory pages to store the state data that needs to be saved upon entry into SMM operations. Examples of this state data are discussed above in connection with FIG. 1. Placing this state data within locked memory pages prevents unauthorized disclosure or manipulation of the state data.
• The VMexit/[0035]VMcall handler454 may perform several functions. VMexit/VMcall handler454 may handle entries into and exits fromSMM VM490 subsequent to the initial entry. VMexit/VMcall handler454 may also handle exceptions raised whenSMM VM490 attempts to read from or write to locked memory pages. Portions of VMexit/VMcall handler454 may determine whether certain of these reads from or writes to locked memory pages should be allowed to proceed depending upon circumstances. In one embodiment, reads from or writes to locked memory pages may be permitted if VMexit/VMcall handler454 determines that the location targeted within the locked memory pages does not contain trusted data.
• The[0036]SMM VM490 contains the desired SMM code, modified from SMM mode format to now execute in a page memory access mode. In general the SMM code in theSMM VM490 executes as written, with the exceptional case of those instructions to create memory reads and writes to the locked memory pages. In those cases, the SMM code may invoke VMexit/VMcall handler454. SMM code may make an explicit call to the VMexit/VMcall handler454, or may make an indirect call by allowing an exception to trap to VMexit/VMcall handler454. In either case VMexit/VMcall handler454 handles these circumstances.
• Referring now to FIG. 5, a diagram of a system management interrupt redirection is shown, according to one embodiment of the present invention. Consider an SMI producing event in[0037]hardware480 subsequent to the initiation of secure or trusted operations. The processor examines its SMBASE register. Since theSVMM SMM handler452 upon initialization wrote an internal memory location into modified SMBASE register within the processor, the processor begins execution ofSVMM SMM handler452.SVMM SMM handler452 stores state data within a locked memory page, and then issues a virtual mode enter (VMenter) call to the actual SMM code withinSMM VM490. In another embodiment, the SMI may cause invocation of the SVMM's VMexit handler.
• The SMM code within[0038]SMM VM490 executes until it attempts to read from or write to a memory location within a locked memory page. Then either by an explicit call, or by an exception causing a trap, a VMexit/VMcall524 may be made to invoke VMexit/VMcall handler454. The VMexit/VMcall handler454 performs those memory accesses that it deems permissible, and then returns toSMM VM490 by anotherVMenter522. This process may repeat several times until the desired SMM code withinSMM VM490 is finished. At this time the SMM code exits via a final VMexit/VMcall524 to VMexit/VMcall handler454. For some embodiments, the VMexit/VMcall handler454 would then exit to theSVMM SMM handler452 through the execution of a modified resume instruction SMMVM code RSM526. This causes theSVMM SMM handler452 to restore the (potentially modified by VMexit/VMcall handler454) state data stored in locked memory pages. For other embodiments, theSVMM SMM handler452 and the VMexit/VMcall handler454 might be combined, and these operations might be carried out in software. Upon the restoration of the state data, the processor resumes its original operation.
• Referring now to FIG. 6, a schematic diagram of an exemplary microprocessor system adapted to support the software environment of FIG. 2 is shown, according to another embodiment of the present invention.[0039]CPU A610,CPU B614,CPU C618, andCPU D622 may be configured with additional microcode or logic circuitry to support the execution of special instructions. Modifications to the processors may include, in one embodiment, changes to the behavior of registers and new or modified instructions. For example, in oneembodiment CPU C618 may include a new instruction “virtual machine monitor initialization” (VMMINIT)624. TheVMMINIT624 instruction, upon execution, may enable the initiation of secure or trusted operations as shown in FIG. 2 above. In one embodiment,VMMINIT624 may also disable normal operations of the PSMBASE register616 ofCPU C618 in certain circumstances to support secure or trusted SMM operations. In such an embodiment,CPU C618 may then redirect an SMI to a code entry point and state save area within VMexit/VMcall handler668 prearranged by the security environment rules.
• In one[0040]embodiment CPU C618 may also include a modified resume (RSM)626 instruction. The modifiedRSM626 may permit a return from SMM that supports secure or trusted operations. Ordinarily RSM instructions may only be executed from within SMM. The modifiedRSM626 may be executed from within normal page mode. When invoked with VM extensions enabled, the modifiedRSM626 instruction may perform a special system call, called a VMexit, back to invoke VMexit/VMcall handler668.
• The[0041]chipset630 may service read and write requests carried from the CPUs on thesystem bus620, and may then perform the physical read and write operations onphysical memory634. Allocation of SMRAM withinmemory634 may be facilitated by achipset SMBASE register631 containing the value of CSMBASE.
• The[0042]SVMM664 may permit or deny the access of a VM to specific pages withinmemory634. The pages of memory that the VM are denied access to may be called “locked” pages, whereas the pages that the VM are permitted access to may be called “unlocked” pages. Within lockedmemory pages660 may be locatedSVMM664 and a module withinSVMM664 to support secure SMM operation. In one embodiment, the module may be VMexit/VMcall handler668. In other embodiments the functions of the VMexit/VMcall handler668 may be combined or may be distributed among other modules. Other pages of memory may remain unlocked, such as unlocked memory pages662. Withinunlocked memory pages662 may be locatedstandard operating systems672. Also withinunlocked memory pages662 may be aSMM VM670.SMM VM670 may include software code similar to standard SMM code but modified to operate in a virtual machine container. Such modifications inSMM VM670 may include code prepared for execution in page mode rather than normal SMM.
• Referring now to FIG. 7, a diagram of system management interrupt redirection is shown, according to another embodiment of the present invention. In the FIG. 7 embodiment,[0043]SVMM750 has two additional modules to support secure or trusted SMM operations. In one embodiment the VMexit/VMcall handler754 establishes the SMM code in aSMM VM790 in response to the execution of an VMMINIT instruction, and additionally handles entry into and exit from theSMM VM790 due to the intentional lower privilege level ofSMM VM790 within its VM container.
• The VMexit/[0044]VMcall handler754 may perform several functions. During the transition into secure or trusted operations, following the execution of a VMMINIT command by a processor, the VMexit/VMcall handler754 loads and initiates theSMM VM790 code in a virtual machine container. The VMexit/VMcall handler754 also establishes a space within the locked memory pages to store the state data that needs to be saved upon entry into SMM operations.
• The VMexit/[0045]VMcall handler754 may perform several additional functions. VMexit/VMcall handler754 may handle entries into and exits fromSMM VM790. VMexit/VMcall handler754 may also handle exceptions raised whenSMM VM790 attempts to read from or write to locked memory pages. Portions of VMexit/VMcall handler754 may determine whether certain of these reads from or writes to locked memory pages should be allowed to proceed depending upon circumstances. In one embodiment, reads from or writes to locked memory pages may be permitted if VMexit/VMcall handler754 determines that the location targeted within the locked memory pages does not contain trusted data.
• The[0046]SMM VM790 contains the desired SMM code, modified in one embodiment from SMM mode format to now execute in a page memory access mode. In general the SMM code in theSMM VM790 executes as written, with the exceptional case of those instructions to create memory reads and writes to the locked memory pages. In those cases, the SMM code may invoke VMexit/VMcall handler754. The SMM code may make an explicit call to the VMexit/VMcall handler754, or may make an indirect call by allowing an exception to trap to VMexit/VMcall handler754. In either case VMexit/VMcall handler754 handles these circumstances.
• Consider an SMI producing event in[0047]hardware780 subsequent to the initiation of secure or trusted operations. The processor examines its SMBASE register. Since the execution of VMMINIT disabled the normal operation of modified SMBASE register within the processor, the processor begins execution of VMexit/VMcall handler754 from a code entry point prearranged by the security environment rules. VMexit/VMcall handler754 stores state data within a locked memory page, and then issues aVMenter call722 to the actual SMM code withinSMM VM790.
• The SMM code within[0048]SMM VM790 executes until it attempts to read from or write to a memory location within a locked memory page. Then either by an explicit call, or by an exception causing a trap, a VMexit/VMcall724 may be made to invoke VMexit/VMcall handler754. The VMexit/VMcall handler754 performs those memory accesses that it deems permissible, and then returns toSMM VM790 by anotherVMenter722. This process may repeat several times until the desired SMM code withinSMM VM790 is finished. At this time the SMM code exits via a final VMexit/VMcall724 to VMexit/VMcall handler754. For some embodiments, the VMexit/VMcall handler454 would then exit tonormal SVMM750 operations by first executing a modified resume instruction. This causes the VMexit/VMcall handler754 to restore the (potentially modified by VMexit/VMcall handler754) state data stored in locked memory pages. Upon the restoration of the state data, the processor resumes its original operation.
• While various embodiments disclosed include two or more processors (either logical or physical processors), it should be understood that such multi-processor and/or multi-threaded systems are described in more detail to explain the added complexity associated with securing a system with multiple logical or physical processors. An embodiment also likely to be advantageous in less complex system may use only one processor. In some cases, the one physical processor may be multi-threading and therefore may include multiple logical processors. In other cases, however, a single-processor, single-threaded system may be used, and still utilize disclosed secure processing techniques. In such cases, the secure processing techniques still operate to reduce the likelihood that data can be stolen or manipulated in an unauthorized manner.[0049]
• In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.[0050]

Claims (43)

What is claimed is:

1. A system, comprising:

a processor to operate in a user mode, a supervisor mode, and a sub operating system mode, to receive a sub operating system mode interrupt;

a first code to be contained within a first virtual machine; and

a first handler to be contained within a trusted code in a second virtual machine to redirect said sub operating system mode interrupt to said first code.

2. The system ofclaim 1, wherein said trusted code is to write an interrupt service register in said processor.

3. The system ofclaim 2, wherein said interrupt service register is a system management base register, and wherein said sub operating system mode interrupt is a system management interrupt.

4. The system ofclaim 1, wherein said first code is to execute in page mode.

5. The system ofclaim 4, wherein said first code is a system management mode code.

6. The system ofclaim 1, further comprising a second handler within said trusted code to be invoked upon access attempts to locked pages of a memory.

7. The system ofclaim 6, wherein said second handler determines if access is allowable to said locked pages of said memory.

8. The system ofclaim 6, wherein said second handler initiates an exit from said first code by issuing a modified resume instruction.

9. The system ofclaim 8, wherein said modified resume instruction is capable of execution in page mode.

10. The system ofclaim 1, wherein said first handler establishes a space within locked pages of a memory to store state data.

11. The system ofclaim 1, wherein said first code is located in unlocked pages of memory.

12. The system ofclaim 1, wherein said system comprises a single processor system.

13. The system ofclaim 1, wherein said trusted code is to disable an interrupt service register in said processor.

14. The system ofclaim 13, wherein said interrupt service register is a system management base register, and wherein said first interrupt is a system management interrupt.

15. The system ofclaim 1, wherein said first handler within said trusted code to be invoked upon access attempts to locked pages of a memory.

16. The system ofclaim 15, wherein said first handler determines if access is allowable to said locked pages of said memory.

17. The system ofclaim 15, wherein said first handler initiates an exit from said first code by issuing a modified resume instruction.

18. The system ofclaim 1, wherein said modified resume instruction is capable of execution in page mode.

19. A method, comprising:

directing a sub operating system mode interrupt to a first handler in a trusted code within a second virtual machine;

storing a state in a locked page in memory; and

entering a first code in a first virtual machine.

20. The method ofclaim 19, further comprising invoking a second handler in said trusted code from said first code.

21. The method ofclaim 20, wherein said invoking is subsequent to said first code accessing said locked page in memory.

22. The method ofclaim 19, wherein said first code is system management mode code.

23. The method ofclaim 19, further comprising invoking a second handler in said trusted code from said first code.

24. The method ofclaim 23, wherein said invoking is subsequent to said first code accessing said locked page in memory.

25. The method ofclaim 19, further comprising executing a modified resume instruction from a page mode.

26. The method ofclaim 19, further comprising determining whether said first code may access said locked page in memory.

27. The method ofclaim 19, wherein said directing includes writing a memory location within said trusted code to an interrupt service register.

28. The method ofclaim 27, wherein said interrupt service register is a system management base register.

29. The method ofclaim 19, wherein said sub operating system mode interrupt is a system management interrupt.

30. The method ofclaim 19, further comprising invoking said first handler in said trusted code from said first code.

31. The method ofclaim 30, wherein said invoking is subsequent to said first code accessing said locked page in memory.

32. A processor, comprising

a first logic to execute a modified resume instruction; and

an interrupt service register capable of being written subsequent to execution of a secure enter instruction.

33. The processor ofclaim 32, wherein said modified resume instruction returns said processor to previous program execution subsequent to execution of a first code.

34. The processor ofclaim 33, wherein said modified resume instruction may be executed from within page mode.

35. The processor ofclaim 33, wherein said execution of said first code occurs within a sub operating system mode.

36. The processor ofclaim 35, wherein said sub operating system mode is a system management mode.

37. The processor ofclaim 32, wherein said interrupt service register is a system management base register.

38. A processor, comprising

a first logic to execute a modified resume instruction; and

an interrupt service register capable of being disabled subsequent to execution of a monitor initialization instruction.

39. The processor ofclaim 38, wherein said modified resume instruction returns said processor to previous program execution subsequent to execution of a first code.

40. The processor ofclaim 39, wherein said modified resume instruction may be executed from within page mode.

41. The processor ofclaim 39, wherein said execution of said first code occurs within a sub operating system mode.

42. The processor ofclaim 41, wherein said sub operating system mode is a system management mode.

43. The processor ofclaim 38, wherein said interrupt service register is a system management base register.

Images