Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

A client hosted virtualization system includes a full volume encryption
(FVE) storage device, a processor, and non-volatile memory with BIOS code
and virtualization manager code. The virtualization manager initializes
the client hosted virtualization system, authenticates a virtual machine
image, launches the virtual machine based on the image, receives a
transaction from the virtual machine targeted to the FVE storage device,
sends the transaction to the FVE storage device, receives a response from
the FVE storage device, and sends the first response to the first virtual
machine. The client hosted virtualization system is configurable to
execute the BIOS or the virtualization manager.

Claims:

1. A client hosted virtualization system (CHVS) comprising: a full volume
encryption (FVE) storage device; a processor operable to execute code;
and a non-volatile memory including first code to implement a basic
input/output system to initialize the CHVS, and second code to implement
a virtualization manager operable to: initialize the CHVS; receive a
first transaction from a first virtual machine, a target of the first
transaction being the FVE storage device; send the first transaction to
the FVE storage device; receive a first response to the first transaction
from the FVE storage device; and send the first response to the first
virtual machine; wherein the CHVS is configurable in a first
configuration to execute the first code and not the second code, and is
configurable in a second configuration to execute the second code and not
the first code.

2. The CHVS of claim 1, further comprising a mass storage device, and
wherein the first virtual machine image: is stored on the mass storage
device; and includes an operating system and an application.

3. The CHVS of claim 1, further comprising: a general purpose encryption
(GPE) engine; wherein in sending the first transaction to the FVE storage
device, the virtualization manager is further operable to send the first
transaction to the GPE engine.

4. The CHVS of claim 3, wherein: the first transaction is a write
transaction; and in sending the first transaction to the GPE engine, the
virtualization manager is further operable to direct the GPE engine to
encrypt information associated with the first transaction, and to store
the information on the FVE storage device.

5. The CHVS of claim 3, wherein: the first transaction is a read
transaction; in sending the first transaction to the GPE engine, the
virtualization manager is further operable to direct the GPE retrieve
information associated with the first transaction from the FVE storage
device; and in receiving the first response to the first transaction from
the FVE storage device engine, the virtualization manager is further
operable to direct the GPE engine to decrypt the information.

6. The CHVS of claim 1, wherein the virtualization manager is further
operable to: receive a second transaction from a second virtual machine,
a target of the second transaction being the FVE storage device; send the
second transaction to the FVE storage device; receive a second response
to the first transaction from the FVE storage device; and send the second
response to the second virtual machine.

7. The CHVS of claim 6, further comprising: an unencrypted storage
device; wherein the virtualization manager is further operable to:
receive a third transaction from the first virtual machine, a target of
the third transaction being the unencrypted storage device; send the
third transaction to the unencrypted storage device; receive a third
response to the third transaction from the unencrypted storage device;
and send the third response to the first virtual machine.

8. The CHVS of claim 7, wherein the virtualization manager is further
operable to: receive a fourth transaction from the second virtual
machine, a target of the fourth transaction being the unencrypted storage
device; send the fourth transaction to the unencrypted storage device;
receive a fourth response to the fourth transaction from the unencrypted
storage device; and send the fourth response to the second virtual
machine.

9. A method of providing a client hosted virtualization system (CHVS)
comprising: storing first code in a non-volatile memory of the CHVS to
implement a basic input/output system for the CHVS; storing second code
in the non-volatile memory, the second code being operable to: initialize
the CHVS; receive a first transaction from a first virtual machine, a
target of the first transaction being a full volume encryption (FVE)
storage device of the CHVS; send the first transaction to the FVE storage
device; receive a first response to the first transaction from the FVE
storage device; and send the first response to the first virtual machine;
determining to execute the second code to the exclusion of the first
code; and in response to determining to execute the second code,
executing the second code.

10. The method of claim 9, wherein the first virtual machine image
includes an operating system and an application.

11. The method of claim 9, wherein in sending the first transaction to
the FVE storage device, the second code is further operable to send the
first transaction to a general purpose encryption (GPE) engine of the
CHVS.

12. The method of claim 11, wherein: the first transaction is a write
transaction; and in sending the first transaction to the GPE engine, the
second code is further operable to: direct the GPE engine to encrypt
information associated with the first transaction; and store the
information on the FVE storage device.

13. The method of claim 11, wherein: the first transaction is a read
transaction; in sending the first transaction to the GPE engine, the
second code is further operable to direct the GPE retrieve information
associated with the first transaction from the FVE storage device; and in
receiving the first response to the first transaction from the FVE
storage device engine, the second code is further operable to direct the
GPE engine to decrypt the information.

14. The method of claim 9, the second code being further operable to:
receive a second transaction from a second virtual machine, a target of
the second transaction being the FVE storage device; send the second
transaction to the FVE storage device; receive a second response to the
second transaction from the FVE storage device; and send the second
response to the second virtual machine.

15. The method of claim 14, the second code being further operable to:
receive a third transaction from the first virtual machine, a target of
the third transaction being an unencrypted storage device of the CHVS;
send the third transaction to the unencrypted storage device; receive a
third response to the third transaction from the unencrypted storage
device; and send the third response to the first virtual machine.

16. The method of claim 15, the second code being further operable to:
receive a fourth transaction from the second virtual machine, a target of
the fourth transaction being an unencrypted storage device of the CHV S;
send the fourth transaction to the unencrypted storage device; receive a
fourth response to the fourth transaction from the unencrypted storage
device; and send the fourth response to the second virtual machine.

17. Machine-executable code for an information handling system (IHS),
wherein the machine-executable code is embedded within a non-transitory
medium and includes instructions for carrying out a method, the method
comprising: storing first code in a non-volatile memory of the IHS to
implement a basic input/output system for the IHS; storing second code in
the non-volatile memory, the second code being operable to: initialize
the IHS; receive a first transaction from a first virtual machine, a
target of the first transaction being a full volume encryption (FVE)
storage device of the client hosted virtualization system; send the first
transaction to the FVE storage device; receive a first response to the
first transaction from the FVE storage device; and send the first
response to the first virtual machine; determining to execute the second
code to the exclusion of the first code; and in response to determining
to execute the second code, executing the second code.

18. The machine-executable code of claim 17, wherein: the first
transaction is a write transaction; in sending the first transaction to
the FVE storage device, the second code is further operable to send the
first transaction to a GPE engine of the client hosted virtualization
system; and in sending the first transaction to the GPE engine, the
second code is further operable to: direct the GPE engine to encrypt
information associated with the first transaction; and store the
information on the FVE storage device.

19. The machine-executable code of claim 17, wherein: the first
transaction is a read transaction; in sending the first transaction to
the FVE storage device, the second code is further operable to: send the
first transaction to a GPE engine of the client hosted virtualization
system; and direct the GPE retrieve information associated with the first
transaction from the FVE storage device; and in receiving the first
response to the first transaction from the FVE storage device engine, the
second code is further operable to direct the GPE engine to decrypt the
information.

20. The machine-executable code of claim 17, the second code being
further operable to: receive a second transaction from a second virtual
machine, a target of the second transaction being the FVE storage device;
send the second transaction to the FVE storage device; receive a second
response to the second transaction from the FVE storage device; and send
the second response to the second virtual machine.

Description:

RELATED APPLICATIONS

[0001] This application is a continuation of U.S. patent application Ser.
No. 12/790,547, entitled "System and Method for Supporting Full Volume
Encryption Devices in a Client Hosted Virtualization System," filed on
May 28, 2010, the disclosure of which is hereby expressly incorporated by
reference.

[0002] This application is related to U.S. patent application Ser. No.
12/790,546, entitled "System and Method for Secure Client Hosted
Virtualization in an Information Handling System," by Shree Dandekar et
al., filed on May 28, 2010, which is hereby incorporated by reference.

[0003] This application is related to U.S. patent application Ser. No.
12/790,550, entitled "System and Method for I/O Port Assignment and
Security Policy Application in a Client Hosted Virtualization System," by
Yuan-Chang Lo et al., filed on May 28, 2010, which is hereby incorporated
by reference.

[0004] This application is related to U.S. patent application Ser. No.
12/790,545, entitled "System and Method for Supporting Task Oriented
Devices in a Client Hosted Virtualization System," by David Konetski et
al., filed on May 28, 2010, which is hereby incorporated by reference.

[0005] This application is related to U.S. patent application Ser. No.
12/790,548, entitled "System and Method for Supporting Secure Subsystems
in a Client Hosted Virtualization System," by David Konetski et al.,
filed on May 28, 2010, which is hereby incorporated by reference.

[0007] As the value and use of information continues to increase,
individuals and businesses seek additional ways to process and store
information. One option is an information handling system. An information
handling system generally processes, compiles, stores, or communicates
information or data for business, personal, or other purposes. Technology
and information handling needs and requirements can vary between
different applications. Thus information handling systems can also vary
regarding what information is handled, how the information is handled,
how much information is processed, stored, or communicated, and how
quickly and efficiently the information can be processed, stored, or
communicated. The variations in information handling systems allow
information handling systems to be general or configured for a specific
user or specific use such as financial transaction processing, airline
reservations, enterprise data storage, or global communications. In
addition, information handling systems can include a variety of hardware
and software resources that can be configured to process, store, and
communicate information and can include one or more computer systems,
graphics interface systems, data storage systems, and networking systems.
Information handlings systems can also implement various virtualized
architectures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] It will be appreciated that for simplicity and clarity of
illustration, elements illustrated in the Figures are not necessarily
drawn to scale. For example, the dimensions of some elements may be
exaggerated relative to other elements. Embodiments incorporating
teachings of the present disclosure are shown and described with respect
to the drawings herein, in which:

[0009] FIG. 1 is a functional block diagram illustrating an information
handling system according to an embodiment of the present disclosure;

[0010] FIG. 2 illustrates an embodiment of a client hosted virtualization
system on an information handling system;

[0011] FIG. 3 is a flow chart illustrating an embodiment of a method of
providing a client hosted virtualization system;

[0014] FIG. 7 is a functional block diagram illustrating another
embodiment of a client hosted virtualization system for implementing I/O
port assignment and security policy application;

[0015]FIG. 8 is a flow chart illustrating an embodiment of a method of
implementing I/O policies in a client hosted virtualization system;

[0016] FIG. 9 is a functional block diagram illustrating another
embodiment of a client hosted virtualization system and a method of
providing pre-boot authentication in the client hosted virtualization
system;

[0017] FIG. 10 is a functional block diagram illustrating another
embodiment of a client hosted virtualization system and a method of
providing secure access to a trusted platform module;

[0018] FIG. 11 is a functional block diagram illustrating another
embodiment of a client hosted virtualization system and a method of
supporting task oriented devices in client hosted virtualization system;
and

[0019] FIG. 12 is a functional block diagram illustrating another
embodiment of a client hosted virtualization system and a method of
supporting full volume encryption devices for virtual machines that
access a common storage device in the client hosted virtualization
system.

[0020] The use of the same reference symbols in different drawings
indicates similar or identical items.

DETAILED DESCRIPTION OF THE DRAWINGS

[0021] The following description in combination with the Figures is
provided to assist in understanding the teachings disclosed herein. The
description is focused on specific implementations and embodiments of the
teachings. This focus is provided to assist in describing the teachings,
and should not be interpreted as a limitation on the scope or
applicability of the teachings. Other teachings can be used in this
application. The teachings can also be used in other applications, and
with different types of architectures, such as distributed computing
architectures, client/server architectures, or middleware server
architectures and associated resources.

[0022] In the embodiments described below, an information handling system
can include any instrumentality or aggregate of instrumentalities
operable to compute, classify, process, transmit, receive, retrieve,
originate, switch, store, display, manifest, detect, record, reproduce,
handle, or use any form of information, intelligence, or data for
business, scientific, control, entertainment, or other purposes. For
example, an information handling system can be a personal computer, a
PDA, a consumer electronic device, a network server or storage device, a
switch router, wireless router, or other network communication device, or
any other suitable device and can vary in size, shape, performance,
functionality, and price. The information handling system can include
memory (volatile (e.g. random-access memory, etc.), nonvolatile
(read-only memory, flash memory etc.) or any combination thereof), one or
more processing resources, such as a central processing unit (CPU), a
graphics processing unit (GPU), hardware or software control logic, or
any combination thereof. Additional components of the information
handling system can include one or more storage devices, one or more
communications ports for communicating with external devices, as well as,
various input and output (I/O) devices, such as a keyboard, a mouse, a
video/graphic display, or any combination thereof. The information
handling system can also include one or more buses operable to transmit
communications between the various hardware components. Portions of an
information handling system may themselves be considered information
handling systems.

[0023] An information handling system can implement a secure client hosted
virtualization (CHV) architecture with a CHV manager that resides in
secure memory of the information handling system, and that receives
secure updates from a managed backend. The CHV manager can launch one or
more virtual machines on the information handling system. The CHV
architecture can support I/O port assignment and I/O security policy
implementation for the virtual machines. The CHV architecture can also
provide a secure interface to security resources of the information
handling system to provide pre-boot authentication, platform hardware and
software authentication, secure biometric user authentication, and other
trusted computing features for the virtual machines. The CHV manger can
support task oriented devices such that each virtual machine obtains the
functionality of the task oriented devices. The CHV manager also can
support storage using full volume encryption (FVE) mechanisms, and
provide access to common storage devices for multiple virtual machines.

[0024] FIG. 1 is a block diagram illustrating an embodiment of an
information handling system 100, including a processor 110, a chipset
120, a memory 130, a graphics interface 140, an input/output (I/O)
interface 150, a disk controller 160, a network interface 170, and a disk
emulator 180. In a particular embodiment, information handling system 100
is used to carry out one or more of the methods described below. In a
particular embodiment, one or more of the systems described below are
implemented in the form of information handling system 100.

[0025] Chipset 120 is connected to and supports processor 110, allowing
processor 110 to execute machine-executable code. In a particular
embodiment (not illustrated), information handling system 100 includes
one or more additional processors, and chipset 120 supports the multiple
processors, allowing for simultaneous processing by each of the
processors and permitting the exchange of information among the
processors and the other elements of information handling system 100.
Chipset 120 can be connected to processor 110 via a unique channel, or
via a bus that shares information among processor 110, chipset 120, and
other elements of information handling system 100.

[0026] Memory 130 is connected to chipset 120. Memory 130 and chipset 120
can be connected via a unique channel, or via a bus that shares
information among chipset 120, memory 130, and other elements of
information handling system 100. In particular, a bus can share
information among processor 110, chipset 120 and memory 130. In another
embodiment (not illustrated), processor 110 is connected to memory 130
via a unique channel. In another embodiment (not illustrated),
information handling system 100 can include separate memory dedicated to
each of the one or more additional processors. A non-limiting example of
memory 130 includes static random access memory (SRAM), dynamic random
access memory (DRAM), non-volatile random access memory (NVRAM), read
only memory (ROM), flash memory, another type of memory, or any
combination thereof.

[0027] Graphics interface 140 is connected to chipset 120. Graphics
interface 140 and chipset 120 can be connected via a unique channel, or
via a bus that shares information among chipset 120, graphics interface
140, and other elements of information handling system 100. Graphics
interface 140 is connected to a video display 144. Other graphics
interfaces (not illustrated) can also be used in addition to graphics
interface 140 if needed or desired. Video display 144 can include one or
more types of video displays, such as a flat panel display or other type
of display device.

[0028] I/O interface 150 is connected to chipset 120. I/O interface 150
and chipset 120 can be connected via a unique channel, or via a bus that
shares information among chipset 120, I/O interface 150, and other
elements of information handling system 100. Other I/O interfaces (not
illustrated) can also be used in addition to I/O interface 150 if needed
or desired. I/O interface 150 is connected via an I/O interface 152 to
one or more add-on resources 154. Add-on resource 154 is connected to a
storage system 190, and can also include another data storage system, a
graphics interface, a network interface card (NIC), a sound/video
processing card, another suitable add-on resource or any combination
thereof. I/O interface 150 is also connected via I/O interface 152 to one
or more platform fuses 156 and to a security resource 158. Platform fuses
156 function to set or modify the functionality of information handling
system 100 in hardware. Security resource 158 provides a secure
cryptographic functionality and can include secure storage of
cryptographic keys. A non-limiting example of security resource 158
includes a Unified Security Hub (USH), a Trusted Platform Module (TPM), a
General Purpose Encryption (GPE) engine, another security resource, or a
combination thereof.

[0029] Disk controller 160 is connected to chipset 120. Disk controller
160 and chipset 120 can be connected via a unique channel, or via a bus
that shares information among chipset 120, disk controller 160, and other
elements of information handling system 100. Other disk controllers (not
illustrated) can also be used in addition to disk controller 160 if
needed or desired. Disk controller 160 can include a disk interface 162.
Disk controller 160 can be connected to one or more disk drives via disk
interface 162. Such disk drives include a hard disk drive (HDD) 164 or an
optical disk drive (ODD) 166 such as a Read/Write Compact Disk (R/W-CD),
a Read/Write Digital Video Disk (R/W-DVD), a Read/Write mini Digital
Video Disk (R/W mini-DVD, another type of optical disk drive, or any
combination thereof. Additionally, disk controller 160 can be connected
to disk emulator 180. Disk emulator 180 can permit a solid-state drive
184 to be coupled to information handling system 100 via an external
interface 182. External interface 182 can include industry standard
busses such as USB or IEEE 1394 (Firewire) or proprietary busses, or any
combination thereof. Alternatively, solid-state drive 184 can be disposed
within information handling system 100.

[0030] Network interface device 170 is connected to I/O interface 150.
Network interface 170 and I/O interface 150 can be coupled via a unique
channel, or via a bus that shares information among I/O interface 150,
network interface 170, and other elements of information handling system
100. Other network interfaces (not illustrated) can also be used in
addition to network interface 170 if needed or desired. Network interface
170 can be a network interface card (NIC) disposed within information
handling system 100, on a main circuit board such as a baseboard, a
motherboard, or any combination thereof, integrated onto another
component such as chipset 120, in another suitable location, or any
combination thereof. Network interface 170 includes a network channel 172
that provide interfaces between information handling system 100 and other
devices (not illustrated) that are external to information handling
system 100. Network interface 170 can also include additional network
channels (not illustrated).

[0031] Information handling system 100 includes one or more application
programs 132, and Basic Input/Output System and Firmware (BIOS/FW) code
134. BIOS/FW code 134 functions to initialize information handling system
100 on power up, to launch an operating system, and to manage input and
output interactions between the operating system and the other elements
of information handling system 100. In a particular embodiment,
application programs 132 and BIOS/FW code 134 reside in memory 130, and
include machine-executable code that is executed by processor 110 to
perform various functions of information handling system 100. In another
embodiment (not illustrated), application programs and BIOS/FW code
reside in another storage medium of information handling system 100. For
example, application programs and BIOS/FW code can reside in HDD 164, in
a ROM (not illustrated) associated with information handling system 100,
in an option-ROM (not illustrated) associated with various devices of
information handling system 100, in storage system 190, in a storage
system (not illustrated) associated with network channel 172, in another
storage medium of information handling system 100, or a combination
thereof. Application programs 132 and BIOS/FW code 134 can each be
implemented as single programs, or as separate programs carrying out the
various features as described herein.

[0032] FIG. 2 illustrates an embodiment of a CHV system 200 including a
client system 210 operating at a platform level 292, an optional virtual
machine hypervisor 250 operating at a protection level 294 that is the
most protected level, virtual machines 260 and 270, and one or more
additional virtual machines 280 operating at a protection level 296 that
is above protection level 294, or less protected than virtual machine
hypervisor 250. At the platform level 292, client system 210 includes
client platform hardware 220, trusted platform firmware 230, and a CHV
manager 240. In a particular embodiment, client system 210 is an
information handling system similar to information handling system 100.
As such, client platform hardware 220 includes a processor (not
illustrated) that operates to execute machine-executable code included in
trusted platform firmware 230 and CHV manager 240 to perform the
functions of CHV system 200. Client platform hardware 220 also includes a
TPM 222, a USH 224, a GPE 226, and a fuse/switch bank 228. Trusted
platform firmware 230 includes a BIOS 232. CHV manager 240 may include
any or all of a service operating system (OS) 242, a stack of drivers
244, a policy manager 246, and an update manager 248. In a particular
embodiment, virtual machine hypervisor 250 is a commercially available
hypervisor such as Microsoft Virtual PC, Xen, VMware, or other such
virtualization systems that may reside in a mass storage device (not
illustrated).

[0033] CHV manager operates from the platform level 292 to initialize CHV
system 200 on power up, to launch virtual machines 260, 270, and 280, and
to manage input and output interactions between virtual machines 260,
270, and 280 and client platform hardware 220. In this respect, CHV
manager 240 functions similarly to a combination of a platform BIOS and a
virtual machine manager or hypervisor. As such, CHV manager 240 is stored
in a non-volatile memory (not illustrated) of client platform hardware
220, such as a firmware ROM embedded on the system board that is separate
from the mass storage device used to store the images for virtual
machines 260, 270, and 280, and that retains the code stored thereon when
client system 210 is powered. In a particular embodiment, CHV manager 240
provides that the launching of virtual machines 260, 270, and 280 is
secure, using digital signatures to verify the authenticity of the
virtual machine images for virtual machines 260, 270, and 280. For
example, client system 210 can include hardware extensions with security
capabilities to ensure secure launch and execution of virtual machines
260, 270, and 280, such as Trusted Execution Technology (TXT) or other
hardware extension technology. In a particular embodiment, CHV manager
240 operates with GPE 226 to fully encrypt virtual machines 260, 270, and
280 in storage. By operating CHV manager from the platform level 292,
client system 210 is secure from malicious software or virus attacks that
might otherwise affect the operations of client system 210. Moreover, by
encrypting virtual machines 260, 270, and 280 at rest, CHV system 200
provides a tamper resistant storage method for the images of virtual
machines 260, 270, and 280.

[0034] In an optional embodiment, virtual machine hypervisor 250 can be
operated at protection level 294 to launch virtual machines 260, 270, and
280. Note that one of CHV manager 240 or virtual machine hypervisor 250
is selected to launch virtual machines 260, 270, and 280, and that where
one of the CHV manager or the virtual machine hypervisor is operating to
manage the virtual machines, the other is not operating to manage the
virtual machines. When launched, virtual machines 260, 270, and 280 each
include associated user data 262, 272, and 282; associated user
preference information 264, 274, and 284; associated applications 266,
276, and 286; and associated operating systems 268, 278, and 288,
respectively. Thus each virtual machine 260, 270, and 280 is isolated
from the others, operates as an individual information handling system on
client system 210, and shares the resources of client platform hardware
220. The operating CHV manager 240 or virtual machine hypervisor 250
functions to manage the access of each of virtual machines 260, 270, and
280 to the resources of client platform hardware 220. Virtual machines
260, 270, and 280 can include anti-virus software (not illustrated) that
is tailored to the associated OSs 268, 278, and 288, thus providing an
additional layer of security to the operations of CHV system 200.

[0035] The configuration of client platform 210 is determined by the
particular devices and architecture of client platform hardware 220 and
the content of trusted platform firmware 230 and CHV manager 240. The
devices and architecture of client platform hardware 220 is determined at
the time of manufacture of client system 210. The content of trusted
platform firmware 230 and CHV manager 240 is installed on a non-volatile
memory storage device (not illustrated) in client platform hardware 220
at the time of manufacture. In a particular embodiment, the manufacturer
or a user of client platform 210 determines that the client platform is
intended for use as a client hosted virtualization platform, and
initiates a hardware function to toggle an element of fuse/switch bank
228 to enable CHV manager 240.

[0036] In a particular embodiment, toggling the element of fuse/switch
bank 228 permanently enables CHV manager 240. Here, each time client
platform 210 is booted, trusted platform firmware 230 performs low level
system boot activities, and then passes control to CHV manager 240. An
example of permanently enabling CHV manager 240 can include blowing a
hardware fuse in fuse/switch bank 228 that permanently provides for a
boot path that passes control to CHV manager 230. Another example can
include providing a particular bit or set of bits in fuse/switch bank 228
in a platform ROM (not illustrated) that is not re-writable. In the case
of blowing a hardware fuse, the hardware fuse can be blown at the time of
manufacture of client system 210, or by a user of client system at a
later date. In the case of providing bits in a platform ROM, the bits can
be provided at the time of manufacture of client system 210.

[0037] In another embodiment, client platform 210 includes a mechanism to
selectably override the permanent enablement of CHV manager 240 such that
when client platform 210 is booted, BIOS 232 performs low level system
boot activities, and then passes control to virtual machine hypervisor
250. For example, the particular bit or set of bits in fuse/switch bank
228 can reside in a re-writeable non-volatile memory, such that client
platform 210 can be reprogrammed to disable CHV manager 240. In another
example, a boot option provided by trusted platform firmware 230 can
prompt a user of client platform 210 as to whether to boot to CHV manager
240 control, or to virtual machine hypervisor 250 control.

[0038] When control of client system 210 is passed to the CHV manager, CHV
manager 242 launches service OS 242 to establish the controlled
virtualization environment, including launching virtual machines 250,
260, and 270, and controlling the elements of client platform hardware
220. Service OS 242 supports I/O port assignment between virtual machines
250, 260, and 270 and client platform hardware 220, and provides a secure
interface to TPM 222, USH 224, and GPE 226 for pre-boot authentication,
platform hardware and software authentication, secure biometric user
authentication, and other trusted computing features for the virtual
machines. Service OS 242 also supports task oriented devices and FVE
storage for virtual machines 250, 260, and 270, and provides access to
common storage devices. Policy manager 246 implements security policies
between virtual machines 250, 260, and 270 and the devices of client
platform hardware 220. Because the content of trusted platform firmware
230 and CHV manager 240 resides on the non-volatile memory storage
device, the trusted platform firmware code and the CHV manager code is
executed securely within platform level 292, and the basic operation of
client system 210 is less susceptible to attack from malicious program
code, viruses, worms, or other corrupting programs, and client system 210
embodies a secure CHV architecture.

[0039] FIG. 3 illustrates an embodiment of a method of providing a CHV
system in a flowchart form, starting at block 300. A CHV platform fuse is
set in an information handling system in block 301. For example, a
manufacturer of client platform 210 can determine that client platform
210 is intended for use as CHV system 200, and can set blow a fuse in
fuse/switch bank 228. In an embodiment (not illustrated), a user or
manufacturer of client platform 210 can write a particular bit or set of
bits to platform ROM to configure client system 210 as CHV system 200.
The information handling system is booted in block 302, and a decision is
made as to whether or not the information handling system has a BIOS boot
option enabled in decision block 303. For example client platform 210 may
or may not include a boot option that permits client platform 210 to boot
with BIOS 232. If the information handling system does not have a BIOS
boot option enabled, the "NO" branch of decision block 303 is taken, the
boot process runs a CHV manager in block 304, and the method ends in
block 314. Thus client platform 210 cannot have a BIOS boot option, and
can launch CHV manager 240 and proceed to launch virtual machines 250,
260, and 270.

[0040] If the information handling system has a BIOS boot option enabled,
the "YES" branch of decision block 303 is taken, and a decision is made
as to whether or not the BIOS boot option has been selected in decision
block 305. If not, the "NO" branch of decision block 305 is taken, the
boot process runs the CHV manager in block 304, and the method ends in
block 307. If the BIOS boot option is selected, the "YES" branch of
decision block 305 is taken, the boot process proceeds to boot in BIOS in
block 306, and the method ends in block 307. For example, a user of
client platform 210 may select a boot option to boot client platform 210
with BIOS 232, and client platform 210 can then boot using BIOS 232, and
can then launch virtual machine hypervisor 250 or another conventional
operating system on the bare system.

[0041] The content of trusted platform firmware 230 and CHV manager 240 is
alterable by reprogramming the non-volatile memory storage device,
permitting revision control of the contents of trusted platform firmware
230 and CHV manager 240. For example, firmware code associated with the
devices of client platform hardware 220, such as drivers, application
programming interfaces (APIs), or user interfaces (UIs) in trusted
platform firmware 230, or the BIOS code associated with BIOS 232 can be
periodically updated or modified. Similarly, CHV manager code associated
with service OS 242, drivers 244 or update manager 248, or policy profile
data associated with policy manager 246 can be periodically updated or
modified. Here, the fact that trusted platform firmware 230 and CHV
manager 240 are stored in the non-volatile memory storage device ensures
a level of security related to the ability to perform updates.

[0042] In another embodiment, update manager 248 functions in cooperation
with TPM 222 to provide an encryption and authentication capability with
regard to updates to trusted platform firmware 230 and CHV manager 240.
Here, the capability to perform an update is enabled by a locked platform
feature, where the key to unlock the feature is associated with a public
key infrastructure (PKI). Updates to trusted platform firmware 230 or to
CHV manager 240 include key information. When update manager 248 receives
an update to trusted platform firmware 230 or to CHV manager 240, update
manager 248 provides the key information to TPM 222 to authenticate the
update. If the update is authenticated, then update manager 248 proceeds
to implement the update. If the update is not authenticated, the update
manager 248 does not implement the update. In a particular embodiment,
updates to trusted platform firmware 230 or to CHV manager 240 are also
encrypted, and TPM 222 decrypts authenticated updates prior to being
implemented by update manager 248.

[0043] FIG. 4 illustrates an embodiment of a CHV update network 400
including a client system 410, a network 420, and a CHV update system
430. CHV update system 430 includes a network interface 435, a client
image database 440, a client image compiler 445, a virtual machine image
database 450, user profile database 455, and a CHV update manager 460,
and can be implemented as a server component of CHV update network 400.
CHV update manager 460 includes a service OS image 462, virus definitions
database 464, a PKI infrastructure 466, and drivers database 468. Client
system 410 is similar to client system 210, and can implement a CHV
system similar to CHV system 200. Client system 410 is connected to
network 420 via a network channel similar to network channel 172 of
information handling system 100. Network 420 represents a network
connection between client system 410 and CHV update system 430, and can
include public networks such as the Internet or other public networks, or
private networks such as private internets or other private networks.

[0044] CHV update system 430 communicates with client system 410 through
network interface 435 which is connected to network 420. In a particular
embodiment, MY update system 430 determines when a trusted platform
firmware 412 or a CHV manager 414 in client system 410 is in need of an
update, and CHV update system 430 pushes the needed update to firmware
412 or to CHV manager 414, and an update manager (not illustrated) in CHV
manager 414 performs the update to client system 410. In another
embodiment, client system 410 periodically polls CHV update system 430 to
determine if updates are available for firmware 412 or for CHV manager
414. If an update is available, then client system 410 pulls the
available update for firmware 412 or for CHV manager 414, and the update
manager performs the update to client system 410.

[0045] CHV update system 430 functions to create and maintain the updates
for client system 410. As such, the components that make up firmware 412
and CHV manager 414 are stored and maintained in a current state in CHV
update manager 460. Thus the operating code for firmware 412 and CHV
manager 414 is maintained and updated with new capabilities, fixes to
defective capabilities, patches to insecure capabilities, other updates,
or a combination thereof For example, a development team (not
illustrated) can maintain the operating code for a service OS, storing
modified images in service OS image 462, can store virus definitions for
an anti-virus capability of the service OS in virus definitions database
464, and can store drivers associated with the various hardware
components of client system 410 in drivers database 468. CHV update
manager 460 combines the contents of service OS image 462, virus
definitions database 464, and drivers database 468 to provide updates for
firmware 412 and CHV manager 414, and encodes the updates with PKI
infrastructure 466 to provide a secure update for client system 410.
Client image compiler 445 receives the secure update from CHV update
manager 460, and combines the secure update with updated virtual machine
images from virtual machine image database 450, and with updated user
profiles from user profile database 455 to create a client image for
client system 410. Client image compiler 445 stores the client image in
client image database 440 to be pushed to or pulled from client system
410.

[0046] FIG. 5 illustrates an embodiment of a method of pushing an update
to a client system in a flowchart form, starting at block 310. A CHV
update system reads a firmware and CHV manager revision level from a
client system in block 311. For example, CHV update system 430 can
determine a revision level for firmware 412 and for CHV manager 414 in
client system 410. A decision is made as to whether or not the firmware
or the CHV manager are in need of updating in decision block 312. If not,
the "NO" branch of decision block 312 is taken, and processing returns to
block 311, where the CHV update system reads a firmware and CHV manager
revision level from the client system. Here, CHV update system 430 can
perform the reads of client system 410 on a periodic basis to ensure that
client system 410 includes current revisions of firmware 412 and CHV
manager 414. If the firmware or the CHV manager are in need of updating,
the "YES" branch of decision block 312 is taken, and the CHV update
manager pushes the update to the client system in block 313. Thus client
image compiler 445 can combine the elements that are in need of updating
from among virtual machine image database 450, user profile database 455,
service OS image 462, virus definitions 464, and drivers 468, and CHV
update system 430 can send the client image to client system 410. An
update manager in the client system installs the update in block 314, and
the method ends in block 315. Here, when client system 410 receives the
update from CHV update system 430, an update manager (not illustrated)
can determine if the update is authentic using a TPM (not illustrated)
and then can install authentic the update if it is determined to be
authentic.

[0047] FIG. 6 illustrates an embodiment of a method of pulling an update
to a CHV update system in a flowchart form, starting at block 320. A
client system polls the CHV update system to determine if an update is
available for a firmware or a CHV manager on the client system in block
321. For example, client system 410 can poll CHV update system 430 to
determine if an update is available for firmware 412 or for CHV manager
414. A decision is made as to whether or not a firmware or CHV manager
update are available in decision block 322. If not, the "NO" branch of
decision block 322 is taken, and processing returns to block 321, where
the client system polls the CHV update system to determine if an update
is available for the firmware or the CHV manager. Here, client system 410
can poll CHV update system 430 on a periodic basis to ensure that client
system 410 includes current revisions of firmware 412 and CHV manager
414. If a firmware or CHV manager update are available, the "YES" branch
of decision block 322 is taken, and the client system pulls the updated
firmware or CHV manager from the CHV update manager in block 323. Thus a
compiled client image can be stored in client image database 440, and
client system 410 can request the client image from CHV update system
430. An update manager in the client system installs the update in block
324, and the method ends in block 325. Here, when client system 410
receives the update from CHV update system 430, the update manager can
determine if the update is authentic using the TPM and then can install
authentic the update if it is determined to be authentic.

[0048] FIG. 7 illustrates an embodiment of a CHV system 500 including
client platform hardware 520, a CHV manager 540, and virtual machines 560
and 570. Client platform hardware 520 includes an Ethernet NIC 521, a
wireless local area network (WiFi) NIC 523, and a USB port 525, and can
include one or more additional I/O resources (not illustrated). CHV
manager 540 includes a policy manager 548. Virtual machines 560 and 570
each include I/O policy information 561 and 571, respectively. In a
particular embodiment, CHV manager 540 is in control of access to
Ethernet NIC 521, WiFi NIC 523, USB port 525, and other I/O resources. As
such, requests for I/O access from virtual machines 560 and 570 are
provided to CHV manager 540, and policy manager 548 determines if the
requested I/O access is permitted, based upon the requesting virtual
machine's 560 or 570 respective I/O policy information 561 or 571. In the
illustrated embodiment, I/O policy information 561 and 571 are included
in CHV manager 540. In another embodiment (not illustrated), I/O policy
information 561 is included in virtual machine 560 and I/O policy
information 571 is included in virtual machine 570. In another embodiment
(not illustrated), a portion of I/O policy information 561 and 571 is
included in CHV manager 540, and another portion of I/O policy
information 561 and 571 is included in virtual machines 560 and 570,
respectively.

[0049] Policy manager 546 enforces granular control of access to Ethernet
NIC 521, WiFi NIC 523, USB port 525, and other I/O resources. Policy
manager 546 permits certain types of access requests and denies other
access requests, and permits conditional access to the various resources
of client platform hardware 520. As such, I/O policy information 561 and
571 can provide for unrestricted access, blocked access, or conditional
access depending on the resource, on the user of the respective virtual
machine 560 or 570, on the content included in the access request, on the
target of the access request, or on other conditions as needed. For
example, I/O policy information 561 may dictate that virtual machine 560
has unrestricted access to Ethernet NIC 521, may not access USB port 525,
and has conditional access to WiFi NIC such that only access to a
corporate WiFi network is permitted. Other examples include permitting
access to USB port 525 only when the device connected to the USB port is
an authenticated storage device, or when the device connected to the USB
port is a human interface device such as a mouse or a keyboard. I/O
policy information 561 and 571 can also provide for user consent each
time a resource is accessed and for logging of file transfers to and from
the resource. The content transferred into and out of the respective
virtual machines 560 and 570 can also be filtered such that inbound
transfers can be checked for malware or viruses, and outbound transfers
can be checked to prevent data leaks.

[0050]FIG. 8 illustrates an embodiment of a method of implementing I/O
policies in a CHV system. Starting at block 330, a CHV manager receives
an I/O access request in block 331. For example, virtual machine 560 can
attempt to initiate a file transfer over Ethernet NIC 521, or a USB
device plugged into USB port 525 can attempt to enumerate itself to
virtual machine 570, and CHV manager 520 can receive the transaction
requests. The CHV manager determines the source and destination of the
I/O access request in block 332, and verifies an I/O access policy for
I/O access requests with the determined source and destination in block
333. Thus CHV manager 520 can identify the source and destination of the
file transfer from virtual machine 560 to Ethernet NIC 521, and can
access I/O policy information 561 to determine if the requested file
transfer is permitted. Here, CHV manager can also determine the user
associated with virtual machine 560, the contents of the file to be
transferred, or other information related to the I/O policy for virtual
machine 560. A decision is made as to whether or not the requested I/O
access is allowed in decision block 334. If so, the "YES" branch of
decision block 334 is taken, the requested I/O access request is executed
in block 335, and the method ends in block 336. For example, CHV manager
520 can determine that the file transfer from virtual machine 560 to
Ethernet NIC 521 is allowed and can execute the file transfer. If the
requested I/O access is not allowed, the "NO" branch of decision block
334 is taken, the requested I/O access request is denied in block 337,
and the method ends in block 336. For example, CHV manager 520 can
determine that virtual machine 570 is to be denied access to USB port 525
and can block the USB device from enumerating itself to virtual machine
570.

[0051] FIG. 9 illustrates an embodiment of a CHV system 600 including
client platform hardware 620, trusted platform firmware 630, a CHV
manager 640, and virtual machines 660 and 670. Client platform hardware
620 includes an authentication device 621 and a system management random
access memory (SMRAM) 623. An example of authentication device 621
includes a keyboard for entering a password, a unified security hub
similar to USH 224 connected to a biometric input device (not
illustrated) or a smart card reader (not illustrated), another type of
authentication device, or a combination thereof. Trusted platform
firmware 630 includes a BIOS 632 and a pre-boot authentication module
634. CHV manager 640 includes a secure post office box module 642.
Virtual machines 660 and 670 include authenticator modules 663 and 673,
respectively. An example of authenticator modules 663 and 673 includes a
graphical identification and authentication (GINA) module, another type
of authenticator interface, or a combination thereof.

[0052] Pre-boot authentication provides a way to authenticate a prior to
the launch of virtual machines 660 and 670 such that only authenticated
users gain access to the devices and resources of CHV system 600. FIG. 9
illustrates an embodiment of a method of providing pre-boot
authentication in CHV system 600. Here, BIOS 632 generates a pre-boot
authentication request 601 to pre-boot authentication module 634.
Pre-boot authentication module 634 includes a sequestered operating
environment that prompts the user for authentication. The user provides
the authentication information via authentication device 621. Pre-boot
authentication module 634 verifies the authenticity of the authentication
information, and if the authentication information is verified, generates
an authentication object and generates a pre-boot authentication response
602 which sends the authentication object to BIOS 632. BIOS 632 generates
an authentication object store 603 which stores the authentication object
in SMRAM 623. Upon completion of the authentication object store 603,
BIOS 632 passes execution to CHV manager 640.

[0055] FIG. 11 illustrates an embodiment of a CHV system 700 including
client platform hardware 720, a CHV manager 440, and virtual machines
760, 770, and 770. Client platform hardware 720 includes a task oriented
device 725. Task oriented device 725 is characterized by the fact that
transactions targeted to task oriented device 725 are not amenable to
time sliced execution, but are atomic, such that a transaction provided
to task oriented device 725 is processed by the task oriented device as a
whole transaction. An example of task oriented device 725 includes a GPE
engine, a deep packet inspection engine, another task oriented device, or
a combination thereof. CHV manager 640 includes a device driver interface
742, a CHV task manager 744, virtual machine transaction queues 746, 748,
and 750, and a CHV device driver 754. Virtual machine transaction queues
746, 748, and 750 are associated with virtual machines 760, 770, and 780,
respectively. Virtual machines 760, 770, and 770 include device drivers
767, 777, and 787, respectively. CHV Manager 740 operates to receive
requests for the services of task oriented device 725, segregate the
requests based upon the issuing virtual machine 760, 770, or 780,
determine a priority for the request and issues the request to task
oriented device 725. When task oriented device 725 responds to the
request, CHV manager 740 returns the response to the requesting virtual
machine 760, 770, or 780.

[0056] When one or more of virtual machines 760, 770 and 780 have need of
the service of task oriented device 725, they generate a task oriented
device transaction 701 from device drivers 767, 777, and 787 that is
received by device driver interface 742. The task oriented device
transaction preferably includes a header and data. The header identifies
the type of transaction, the source of the transaction, other information
about the transaction, instructions for the execution of the transaction,
or a combination thereof. For example, where task oriented device 725 is
an encryption/decryption engine or security processor, the header can
include an encryption key identifier, a decryption algorithm identifier,
an action identifier, other information used by an encryption/decryption
engine or security processor, or a combination thereof. The data includes
the information to be processed by task oriented device 725. Device
driver interface 742 generates a task oriented device request 702 that is
received by CHV task manager 744. The task oriented device request
includes the header and data from the task oriented device transaction.

[0060] When one or more of virtual machines 860, 870 or 880 issue a
storage request, the virtual machine generates a storage transaction 801
from storage drivers 869, 879, or 889 that is received by storage driver
interface 842. Device driver interface 742 determines if the storage
transaction is intended for FVE storage device 827 or for an unencrypted
storage device (not illustrated). If the storage transaction is intended
for FVE storage device 827, device driver interface 742 forwards the
storage request 802 to GPE driver 844, which in turn forwards the storage
request 803 to GPE 826. If the storage request is a write request, then
GPE 826 encrypts a data portion of the storage request in accordance with
information in a header portion of the storage request, and stores the
encrypted data on FVE storage device 827. If the storage request is a
read request, then GPE 826 issues the storage request 804 to FVE storage
device 827, and FVE returns encrypted data 805 to GPE 826. GPE 826
decrypts the encrypted data based upon information in the header portion
of the storage request, and forwards decrypted data 806 to GPE driver
844. GPE driver 844 forwards the decrypted data 807 to storage driver
interface 842 which returns the decrypted data to the requesting virtual
machine 860, 870, or 880.

[0061] When referred to as a "device," a "module," or the like, the
embodiments described above can be configured as hardware. For example, a
portion of an information handling system device may be hardware such as,
for example, an integrated circuit (such as an Application Specific
Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a
structured ASIC, or a device embedded on a larger chip), a card (such as
a Peripheral Component Interface (PCI) card, a PCI-express card, a
Personal Computer Memory Card International Association (PCMCIA) card, or
other such expansion card), or a system (such as a motherboard, a
system-on-a-chip (SoC), or a stand-alone device). The device or module
can include software, including firmware embedded at a device, such as a
Pentium class or PowerPC® brand processor, or other such device, or
software capable of operating a relevant environment of the information
handling system. The device or module can also include a combination of
the foregoing examples of hardware or software. Note that an information
handling system can include an integrated circuit or a board-level
product having portions thereof that can also be any combination of
hardware and software.

[0062] Devices, modules, resources, or programs that are in communication
with one another need not be in continuous communication with each other,
unless expressly specified otherwise. In addition, devices, modules,
resources, or programs that are in communication with one another can
communicate directly or indirectly through one or more intermediaries.

[0063] Although only a few exemplary embodiments have been described in
detail above, those skilled in the art will readily appreciate that many
modifications are possible in the exemplary embodiments without
materially departing from the novel teachings and advantages of the
embodiments of the present disclosure. Accordingly, all such
modifications are intended to be included within the scope of the
embodiments of the present disclosure as defined in the following claims.
In the claims, means-plus-function clauses are intended to cover the
structures described herein as performing the recited function and not
only structural equivalents, but also equivalent structures.