U.S. patent application number 10/165597 was filed with the patent office on 2003-12-11 for system and method for protection against untrusted system management code by redirecting a system management interrupt and creating a virtual machine container.
Invention is credited to Burgess, Bradley G., George, Robert T., Glew, Andrew F., Grawrock, David W., Hall, Clifford D., Kozuch, Michael A., Neiger, Gilbert, Poisner, David I., Smith, Lawrence O. III, Sutton, James A. II, Uhlig, Richard A..
Application Number | 20030229794 10/165597 |
Document ID | / |
Family ID | 29710476 |
Filed Date | 2003-12-11 |
United States Patent
Application |
20030229794 |
Kind Code |
A1 |
Sutton, James A. II ; et
al. |
December 11, 2003 |
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.
Inventors: |
Sutton, James A. II;
(Portland, OR) ; Grawrock, David W.; (Aloha,
OR) ; Uhlig, Richard A.; (Hillsboro, OR) ;
Poisner, David I.; (Folsom, CA) ; Glew, Andrew
F.; (Portland, OR) ; Hall, Clifford D.;
(Orangevale, CA) ; Smith, Lawrence O. III;
(Beaverton, OR) ; Neiger, Gilbert; (Portland,
OR) ; Kozuch, Michael A.; (Export, PA) ;
George, Robert T.; (Austin, TX) ; Burgess, Bradley
G.; (Austin, TX) |
Correspondence
Address: |
Dennis A. Nicholls
BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP
Seventh Floor
12400 Wilshire Boulevard
Los Angeles
CA
90025-1026
US
|
Family ID: |
29710476 |
Appl. No.: |
10/165597 |
Filed: |
June 7, 2002 |
Current U.S.
Class: |
713/189 ;
711/E12.097; 713/164 |
Current CPC
Class: |
G06F 21/57 20130101;
G06F 2221/2105 20130101; G06F 12/1491 20130101; G06F 21/53
20130101 |
Class at
Publication: |
713/189 ;
713/164 |
International
Class: |
G06F 012/14 |
Claims
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 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.
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.RTM.
Pentium.RTM. processor family and compatible processors. (See
Chapter 14 of the Pentium.RTM. 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.RTM. MIPS32.TM. or
MIPS64.TM. architecture processor, in an IBM.RTM. PowerPC.TM.
architecture processor, in a SPARC International.RTM. SPARC.RTM.
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.RTM. Pentium.RTM. 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.
* * * * *