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

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

[0001] The present disclosure relates generally to microprocessor systems, and more specifically to microprocessor systems that may operate in a trusted or secured environment.

BACKGROUND

[0002] 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.

[0003] 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.

[0004] 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.

[0005] 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.

[0006] 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.

[0007] 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.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] 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:

[0009] FIG. 1 is a memory mapping of system management mode code in system management RAM in an existing implementation.

[0010] FIG. 2 is a diagram of an exemplary software environment having trusted and untrusted areas, according to one embodiment.

[0011] 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.

[0012] FIG. 4 is a diagram showing a system management code operating in a virtual machine container, according to one embodiment of the present invention.

[0013] FIG. 5 is diagram showing system management interrupt redirection, according to one embodiment of the present invention.

[0014] 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.

[0015] FIG. 7 is diagram showing system management interrupt redirection, according to another embodiment of the present invention.

DETAILED DESCRIPTION

[0016] 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.

[0017] 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.

[0018] 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.

[0019] 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.

[0020] 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) 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.

[0021] The chipset SMBASE register's content CSMBASE may define the boundaries of SMRAM. For example, the SMRAM may occupy the space between CSMBASE 120 and CSMBASE+FFFF hex 132. 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+8000 hex 124. 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 hex 128 and the end of SMRAM at location SMBASE+FFFF hex 132. 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.

[0022] 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.

[0023] 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 SVMM 250 selectively permits or prevents direct access to hardware resources 280 from untrusted operating system 240 (or, if multiple untrusted virtual machines are implemented, multiple operating systems) and untrusted applications 210 through 230. 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.

[0024] SVMM 250 also selectively permits or prevents direct access to hardware resources 280 from one or more trusted or secure kernels 260 and one or more trusted applications 270. Such a trusted or secure kernel 260 and trusted applications 270 may be limited in size and functionality to aid in the ability to perform trust analysis upon it. The trusted application 270 may be any software code, program, routine, or set of routines which is executable in a secure environment. Thus, the trusted application 270 may be a variety of applications, or code sequences, or may be a relatively small application such as a Java applet.

[0025] Instructions or operations normally performed by operating system 240 or kernel 260 that could alter system resource protections or privileges may be trapped by SVMM 250, 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 by operating system 240 or kernel 260 would instead be trapped by SVMM 250, 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 that operating system 240, kernel 260, and SVMM 250 are all virtual machines, with operating system 240 virtual machine and kernel 260 virtual machine executing within the SVMM 250 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.

[0026] Referring now to FIG. 3, one embodiment of a microprocessor system 300 adapted to support the secured software environment of FIG. 2 is shown. CPU A 310, CPU B 314, CPU C 318, and CPU D 322 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 on system bus 320 that may enable the proper synchronization of SVMM 250 operation in the processors. Similarly chipset 330 may support the above-mentioned special cycles on system bus 320. The number of physical processors may vary upon the implementation of a particular embodiment.

[0027] In the FIG. 3 embodiment, the four processors CPU A 310, CPU B 314, CPU C 318, and CPU D 322 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.

[0028] Modifications to processors may include, in one embodiment, changes to the behavior of registers and new or modified instructions. For example, in one embodiment CPU C 318 may include a new instruction secure enter (SENTER) 324. The SENTER 324 instruction, upon execution, may enable the initiation of secure or trusted operations as shown in FIG. 2 above. SENTER 324 may enable multiple logical processors to synchronize their entry into secure or trusted operations. In one embodiment, SENTER 324 may also permit writing to the PSMBASE register 316 of CPU C 318 in certain circumstances to support secure or trusted SMM operations.

[0029] In one embodiment CPU C 318 may also include a modified resume (RSM) 326 instruction. The modified RSM 326 may permit a return from SMM that supports secure or trusted operations. Ordinarily RSM instructions may only be executed from within SMM. The modified RSM 326 may be executed from within normal page mode. When invoked with VM extensions enabled, the modified RSM 326 instruction may perform a special system call, called a VMexit, back to an SVMM handler for SMI.

[0030] The chipset 330 may service read and write requests carried from the CPUs on the system bus 320, and may then perform the physical read and write operations on physical memory 334. Allocation of SMRAM within memory 334 may be facilitated by a chipset SMBASE register 331 containing the value of CSMBASE. The chipset 330 additionally may connect to specialized input/output (I/O) channels, such as an advanced graphics port (AGP) 336. Chipset 330 may control access to pages of memory within physical memory 334 from processors CPU A 310, CPU B 314, CPU C 318 and CPU D 322, and additionally from I/O devices. Such devices may include mass storage devices such as fixed media 344 or removable media 348. The fixed media 344 or removable media 348 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 media 344 or removable media 348 may be connected to chipset 330 via peripheral component interconnect (PCI) bus 346, 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).

[0031] The SVMM 364 may permit or deny the access of a VM to specific pages within memory 334. 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 locked memory pages 360 may be located SVMM 364 and modules within SVMM 364 to support secure SMM operation. In one embodiment, such modules may include an SVMM SMM handler 366 and a virtual machine exit (VMexit)/virtual machine call (VMcall) handler 368. In other embodiments the functions of the SVMM SMM handler 366 and the VMexit/VMcall handler 368 may be combined or may be distributed among other modules. Other pages of memory may remain unlocked, such as unlocked memory pages 362. Within unlocked memory pages 362 may be located standard operating systems 372. Also within unlocked memory pages 362 may be a SMM virtual machine (SMM VM) 370. SMM VM 370 may include software code similar to standard SMM code but modified to operate in a virtual machine container. Such modifications in SMM VM 370 may include code prepared for execution in page mode rather than normal SMM.

[0032] The memory controller and I/O device controller functions of chipset 330 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 for chipset 330. Similarly, a separate I/O device controller integrated circuit may generally implement the I/O device controller functions described above for chipset 330. In further embodiments, the memory controller functions of chipset 330 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 of chipset 330 may be divided among the several CPU integrated circuits, or for multiple processors may be included on a single die.

[0033] 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, SVMM 450 has two additional modules to support secure or trusted SMM operations. The SVMM SMM handler 452 establishes the SMM code in a SMM VM 490 in response to the execution of an SENTER instruction. The VMexit/VMcall handler 454 handles entry into and exit from the SMM VM 490 due to the intentional lower privilege level of SMM VM 490 within its VM container. In some embodiments, the SVMM SMM handler 452 and the VMexit/VMcall handler 454 may be the same software module.

[0034] The SVMM SMM handler 452 may perform several functions. During the transition into secure or trusted operations, following the execution of an SENTER command by a processor, the SVMM SMM handler 452 loads and initiates the SMM VM 490 code in a virtual machine container. In some embodiments, SVMM SMM handler 452 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 the SVMM SMM handler 452. This may not be necessary for other embodiments that invoke the VMexit/VMcall handler 454 directly in response system-management interrupts; for these embodiments, the SVMM SMM handler 452 and VMexit/VMcall handler 454 would be combined into one software module. The SVMM SMM handler 452 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.

[0035] The VMexit/VMcall handler 454 may perform several functions. VMexit/VMcall handler 454 may handle entries into and exits from SMM VM 490 subsequent to the initial entry. VMexit/VMcall handler 454 may also handle exceptions raised when SMM VM 490 attempts to read from or write to locked memory pages. Portions of VMexit/VMcall handler 454 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 handler 454 determines that the location targeted within the locked memory pages does not contain trusted data.

[0036] The SMM VM 490 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 the SMM VM 490 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 handler 454. SMM code may make an explicit call to the VMexit/VMcall handler 454, or may make an indirect call by allowing an exception to trap to VMexit/VMcall handler 454. In either case VMexit/VMcall handler 454 handles these circumstances.

[0037] 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 hardware 480 subsequent to the initiation of secure or trusted operations. The processor examines its SMBASE register. Since the SVMM SMM handler 452 upon initialization wrote an internal memory location into modified SMBASE register within the processor, the processor begins execution of SVMM SMM handler 452. SVMM SMM handler 452 stores state data within a locked memory page, and then issues a virtual mode enter (VMenter) call to the actual SMM code within SMM VM 490. In another embodiment, the SMI may cause invocation of the SVMM's VMexit handler.

[0038] The SMM code within SMM VM 490 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/VMcall 524 may be made to invoke VMexit/VMcall handler 454. The VMexit/VMcall handler 454 performs those memory accesses that it deems permissible, and then returns to SMM VM 490 by another VMenter 522. This process may repeat several times until the desired SMM code within SMM VM 490 is finished. At this time the SMM code exits via a final VMexit/VMcall 524 to VMexit/VMcall handler 454. For some embodiments, the VMexit/VMcall handler 454 would then exit to the SVMM SMM handler 452 through the execution of a modified resume instruction SMM VM code RSM 526. This causes the SVMM SMM handler 452 to restore the (potentially modified by VMexit/VMcall handler 454) state data stored in locked memory pages. For other embodiments, the SVMM SMM handler 452 and the VMexit/VMcall handler 454 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.

[0039] 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. CPU A 610, CPU B 614, CPU C 618, and CPU D 622 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 one embodiment CPU C 618 may include a new instruction “virtual machine monitor initialization” (VMMINIT) 624. The VMMINIT 624 instruction, upon execution, may enable the initiation of secure or trusted operations as shown in FIG. 2 above. In one embodiment, VMMINIT 624 may also disable normal operations of the PSMBASE register 616 of CPU C 618 in certain circumstances to support secure or trusted SMM operations. In such an embodiment, CPU C 618 may then redirect an SMI to a code entry point and state save area within VMexit/VMcall handler 668 prearranged by the security environment rules.

[0040] In one embodiment CPU C 618 may also include a modified resume (RSM) 626 instruction. The modified RSM 626 may permit a return from SMM that supports secure or trusted operations. Ordinarily RSM instructions may only be executed from within SMM. The modified RSM 626 may be executed from within normal page mode. When invoked with VM extensions enabled, the modified RSM 626 instruction may perform a special system call, called a VMexit, back to invoke VMexit/VMcall handler 668.

[0041] The chipset 630 may service read and write requests carried from the CPUs on the system bus 620, and may then perform the physical read and write operations on physical memory 634. Allocation of SMRAM within memory 634 may be facilitated by a chipset SMBASE register 631 containing the value of CSMBASE.

[0042] The SVMM 664 may permit or deny the access of a VM to specific pages within memory 634. 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 locked memory pages 660 may be located SVMM 664 and a module within SVMM 664 to support secure SMM operation. In one embodiment, the module may be VMexit/VMcall handler 668. In other embodiments the functions of the VMexit/VMcall handler 668 may be combined or may be distributed among other modules. Other pages of memory may remain unlocked, such as unlocked memory pages 662. Within unlocked memory pages 662 may be located standard operating systems 672. Also within unlocked memory pages 662 may be a SMM VM 670. SMM VM 670 may include software code similar to standard SMM code but modified to operate in a virtual machine container. Such modifications in SMM VM 670 may include code prepared for execution in page mode rather than normal SMM.

[0043] 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, SVMM 750 has two additional modules to support secure or trusted SMM operations. In one embodiment the VMexit/VMcall handler 754 establishes the SMM code in a SMM VM 790 in response to the execution of an VMMINIT instruction, and additionally handles entry into and exit from the SMM VM 790 due to the intentional lower privilege level of SMM VM 790 within its VM container.

[0044] The VMexit/VMcall handler 754 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 handler 754 loads and initiates the SMM VM 790 code in a virtual machine container. The VMexit/VMcall handler 754 also establishes a space within the locked memory pages to store the state data that needs to be saved upon entry into SMM operations.

[0045] The VMexit/VMcall handler 754 may perform several additional functions. VMexit/VMcall handler 754 may handle entries into and exits from SMM VM 790. VMexit/VMcall handler 754 may also handle exceptions raised when SMM VM 790 attempts to read from or write to locked memory pages. Portions of VMexit/VMcall handler 754 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 handler 754 determines that the location targeted within the locked memory pages does not contain trusted data.

[0046] The SMM VM 790 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 the SMM VM 790 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 handler 754. The SMM code may make an explicit call to the VMexit/VMcall handler 754, or may make an indirect call by allowing an exception to trap to VMexit/VMcall handler 754. In either case VMexit/VMcall handler 754 handles these circumstances.

[0047] Consider an SMI producing event in hardware 780 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 handler 754 from a code entry point prearranged by the security environment rules. VMexit/VMcall handler 754 stores state data within a locked memory page, and then issues a VMenter call 722 to the actual SMM code within SMM VM 790.

[0048] The SMM code within SMM VM 790 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/VMcall 724 may be made to invoke VMexit/VMcall handler 754. The VMexit/VMcall handler 754 performs those memory accesses that it deems permissible, and then returns to SMM VM 790 by another VMenter 722. This process may repeat several times until the desired SMM code within SMM VM 790 is finished. At this time the SMM code exits via a final VMexit/VMcall 724 to VMexit/VMcall handler 754. For some embodiments, the VMexit/VMcall handler 454 would then exit to normal SVMM 750 operations by first executing a modified resume instruction. This causes the VMexit/VMcall handler 754 to restore the (potentially modified by VMexit/VMcall handler 754) state data stored in locked memory pages. Upon the restoration of the state data, the processor resumes its original operation.

[0049] 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.

[0050] 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.

Claims

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 of claim 1, wherein said trusted code is to write an interrupt service register in said processor.

3. The system of claim 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 of claim 1, wherein said first code is to execute in page mode.

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

6. The system of claim 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 of claim 6, wherein said second handler determines if access is allowable to said locked pages of said memory.

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

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

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

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

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

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

14. The system of claim 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 of claim 1, wherein said first handler within said trusted code to be invoked upon access attempts to locked pages of a memory.

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

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

18. The system of claim 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 of claim 19, further comprising invoking a second handler in said trusted code from said first code.

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

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

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

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

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

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

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

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

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

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

31. The method of claim 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 of claim 32, wherein said modified resume instruction returns said processor to previous program execution subsequent to execution of a first code.

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

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

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

37. The processor of claim 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 of claim 38, wherein said modified resume instruction returns said processor to previous program execution subsequent to execution of a first code.

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

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

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

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