SYSTEM, NON-TRANSITORIAL, MACHINE-READY STORAGE MEDIUM AND METHOD WITH VIRTUAL TRUSTED PLATFORM MODULES

Abstract

System (100) comprising the following: a storage medium (113) for storing a plurality of information elements containing addresses of corresponding virtual Trusted Platform Module, TPM interfaces (306), wherein each respective information element corresponds to the plurality of information elements of a respective virtual machine, VM, (104, 307) of a plurality of VMs (104, 307); a hardware controller (108) to provide virtual TPMs (128, 310) for appropriate security operations; and a processor resource (112) separate from the hardware controller (108) for running the plurality of VMs (104, 307), for using the information elements to access the corresponding virtual TPM interfaces (306) to invoke the security operations of the virtual TPMs (128, 310), wherein the processor resource (112) is designed to run the plurality of VMs (104, 307), an operating system, at least one application program and firmware, and the hardware controller (108) has its own separate processing circuitry designed to run its own firmware. where a first VM (104, 307) of the plurality of VMs (104, 307) is trained to: to access a first information element of the multitude of information elements in order to read an address of a first virtual TPM interface (306) from the virtual TPM interfaces (306); by accessing the first virtual TPM interface (306) by writing a TPM command to the address of the first virtual TPM interface (306) read from the first information element to request the execution of a security operation by a first virtual TPM (128, 310) of the virtual TPMs (128, 310); and to receive a notification that the security operation has been completed, based on an indicator set in the first virtual TPM interface (306).

Description

background

[0001] A computer system comprises various electronic components, such as a processor, memory, persistent storage, a network interface controller, etc. Machine-readable instructions, including software programs and / or firmware programs, can be executed on the processor. A user, a program, or an electronic component can perform a security operation using a Trusted Platform Module (TPM) in the computer system. US 2017 / 0075717 A1 describes a method for implementing a virtual Trusted Platform Module function that runs at an exception level of a processor. An object of the invention is to propose a system, a non-transitory, machine-readable storage medium, and a method using virtual Trusted Platform Modules.This problem is solved by a system according to claim 1, a non-transitory, machine-readable storage medium according to claim 14 and a method according to claim 19. Brief description of the drawings

[0002] Some implementations of the present revelation are described with reference to the following figures. Fig. 1A is a block diagram of a system according to various examples. Fig. 1B is a block diagram of a platform control system according to some examples. Fig. 1C is a block diagram of a memory address space according to some examples. Fig. Figure 2 is a flowchart of a process according to some examples. Fig. Figure 3 is a block diagram of a system, with further examples. Fig. Figure 4 is a block diagram of a storage medium that stores machine-readable instructions according to some examples. Fig. Figure 5 is a flowchart of a procedure, followed by further examples.

[0003] In the drawings, identical reference numbers denote similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated for better illustration of the example shown. Detailed description

[0004] In this disclosure, the use of the term "a", "an", or "the" also includes the plural forms, unless the context clearly indicates otherwise. Similarly, the terms "includes", "including", "comprises", "with", "have", or "with", when used in this disclosure, specify the presence of the indicated elements but do not exclude the presence or addition of other elements.

[0005] Examples of computer systems include: a desktop computer, a notebook, a tablet computer, a server computer, a smartphone, a wearable device (e.g., a smartwatch, smart glasses, a head-worn device, etc.), a gaming device, an Internet of Things (IoT) device, a printing system, a storage device, a communication node, and so on.

[0006] Some computer systems may contain Trusted Platform Modules (TPMs) that perform security operations to make the computer systems more secure against attacks or unauthorized access.

[0007] As used here, a "TPM" can refer to any component that performs specified security operations. In some examples, the TPM operates according to a security specification defined by the Trusted Computing Group (TCG). In other examples, a TPM may operate according to other standards or proprietary protocols.

[0008] A TPM is typically implemented in hardware, such as an integrated circuit (IC) chip. The TPM can perform operations in response to commands issued by machine-readable instructions. Examples of security operations that a TPM can perform include any or a combination of the following: cryptographic key generation to create a key, data encryption (based on the use of an encryption key), data decryption, data signing, key migration between TPMs, random number generation, data hashing, and any other cryptographic or security operations. In some examples, a TPM may also provide secure storage for certain information, such as cryptographic keys.

[0009] Some computer systems can implement virtualization, which allows multiple virtual machines (VMs) to run within a single computer system (such VMs are also considered hosted by the computer system). The VMs can share the computer system's physical resources (e.g., a processor, memory, persistent storage, a network interface controller, etc.). A "virtual machine" or "VM" can refer to a partition of a computer system where machine-readable instructions (e.g., a guest operating system, an application program, etc.) can be executed while being isolated from machine-readable instructions running in another VM. In some examples, a container can also be considered a VM.

[0010] A computer system that implements virtualization may also include a hypervisor, also known as a virtual machine monitor (VMM). The hypervisor (which contains machine-readable instructions) can create virtual machines (VMs) that run on the computer system, and it can manage the execution of the VMs and their sharing of the computer system's physical resources. The hypervisor can emulate the computer system's physical resources so that a VM can access these emulated resources, and it can provide isolation between VMs.

[0011] In a computer system with VMs, virtual TPMs are used instead of a physical TPM. These virtual TPMs can be provided by the hypervisor through TPM emulation. This TPM emulation consumes physical resources of the computer system, including processor resources. In a computer system with a large number of VMs, TPM emulation can consume processor cycles, which can slow down other operations of the computer system. For example, a malware-infected or malfunctioning VM might make a large number of TPM accesses, which can slow down the computer system if the hypervisor performs TPM emulation to handle these accesses. Each TPM access can cause the virtual TPM to perform processor-intensive operations.

[0012] In accordance with some implementations of this disclosure, TPM emulation is offloaded from the hypervisor to a platform controller that is separate from the hypervisor. The platform controller implements virtual TPMs. As a result, TPM emulation does not consume any of the computer system's processor resources. A "platform controller" can refer to a controller that performs specific tasks in a computer system. In some examples, the platform controller is a bus device on a bus, such as a Peripheral Component Interconnect (PCI) bus. In more specific examples, the PCI bus might be a PCI Express (PCIe) bus. In other examples, the platform controller might be a bus device connected to a different type of bus in a system. A "bus" refers to a communication link that allows multiple devices to communicate with each other.

[0013] The platform controller is separate from the system's main processor, which can execute various machine-readable instructions for the system, such as virtual machines (VMs), an operating system, an application program, firmware (e.g., boot code, hardware initialization code, etc.), and so on. The platform controller may be dedicated to performing specific system tasks, including emulating reset ports, as well as other tasks (e.g., power management, thermal management, system monitoring, etc.). In some examples, the platform controller may be a separate system-on-a-chip (SoC) integrated with the main processor. In more specialized examples, the platform controller may consist of an intelligent network interface controller (NIC) or be part of a baseboard management controller (BMC).The platform controller can have its own processing circuitry (separate from the main processor, which runs the operating system and / or other program code of a computer system) and run its own firmware. A BMC is a specialized service processor that can monitor the physical state of a computer system using sensors and communicates with a management system via an independent out-of-band connection.

[0014] The BMC can also communicate with applications running at the operating system level via an IOCTL (Input / Output Controller) interface driver, a REST (Representational State Transfer) application programming interface (API), or another system software proxy that facilitates communication between the BMC and applications. The BMC can have hardware-level access to hardware components within the computer system. The BMC may be able to directly modify these hardware components. The BMC can operate independently of the operating system of the computer system in which it resides. The BMC can reside on the motherboard or mainboard of the computer system being monitored.The fact that a BMC is mounted on a motherboard of the computer system being monitored, or otherwise connected to or attached to the computer system being monitored, does not prevent the BMC from being considered separate from a processing resource that runs the operating system. A BMC has management functions for administering components of the computer system. Examples of BMC management functions may include one or a combination of the following: power supply control, thermal monitoring and control, fan control, system health monitoring, remote access to the computer system, remote restart of the computer system, system setup, deployment and recovery of operating system images, system security, etc.

[0015] In some examples, a BMC can provide so-called "lights-out" functionality for computer systems. This "lights-out" functionality allows a user, such as a system administrator, to perform administrative operations on the computer system even if no operating system is installed or if the system is not functioning. Furthermore, in some examples, the BMC can be powered by auxiliary energy (e.g., battery power or an auxiliary power rail); therefore, the computer system does not need to be powered on for the BMC to perform its operations. The services provided by the BMC can be considered "out-of-band" services because the operating system may not be running, and in some cases, the computer system may be powered off or malfunctioning (e.g., due to a glitch or hardware failure).

[0016] The BMC can include a communication interface, such as a network interface, and / or a serial interface, through which an administrator or other entity can communicate with the BMC remotely. An out-of-band service can be provided by the BMC through a dedicated management channel (e.g., the communication interface) and is available regardless of whether the computer system is powered on. In some examples, the BMC is an example of the platform controller.

[0017] The platform controller provides a separate physical processor (separate from the system's main processor) where TPM emulation can be securely deployed. The platform controller is protected against attacks that could affect the main processor's operation, such as malware infecting a system and running on the main processor. In some cases, the platform controller offers a smaller attack surface than the main processor, which runs the hypervisor and other system code, such as firmware and an operating system. The main processor has a larger attack surface because it is designed to execute a variety of machine-readable instructions, including those of an operating system, an application program, a virtual machine, and so on, each of which can be compromised, for example, through malware infection or other forms of damage.In contrast, the platform controller is intended for the execution of specified code, which may be more immune to damage from malware or other types of corruption. Therefore, implementing TPM emulation on the platform controller provides protection against a compromised hypervisor when performing TPM operations.

[0018] Offloading TPM emulation to the platform controller reduces the overhead of processor resource consumption by the hypervisor for performing TPM operations on behalf of a VM.

[0019] One problem with implementing virtual TPMs on the platform controller is that a bus standard like PCIe does not define an interface to a virtual TPM. For example, no PCI function is defined for a device type of TPM. The PCI Code and ID Assignment Specification, as published by the PCI Special Interest Group (PCI-SIG), does not include a class code definition for a TPM. The PCI-SIG is a group that defines standards related to PCIe.

[0020] In accordance with some implementations of this disclosure, ACPI (Advanced Configuration and Power Interface) data structures can be used to provide separate virtual TPM interfaces for corresponding VMs.

[0021] Fig. 1A is a block diagram of a System 100. The System 100 can comprise one or more computer systems.

[0022] System 100 comprises n VMs (VM 1 to VM n in Fig. (shown in Figure 1A), where n ≥ 1. VMs can be started on request by a user or other entity. System 100 can start with zero VMs, and additional VM(s) are started on request. Each VM contains a corresponding guest operating system. VM 1 contains a guest operating system 102-1, and VM n contains a guest operating system 102-n. Examples of guest operating systems include a Linux operating system, a Windows operating system, and / or other types of operating systems. The various guest operating systems 102-1 through 102-n can be of the same type or of different types. Each VM can also contain a corresponding application program (or multiple application programs) that runs within the VM. For example, VM 1 contains an application program 104-1, and VM n contains an application program 104-n. Note that before creating a VM, no guest operating system 102-i (i = 1 to n) and no application program 104-i exist.

[0023] The System 100 also includes a Hypervisor 106, which creates the VMs, manages the execution of the VMs, emulates physical resources of the System 100 that the VMs can access, provides isolation between the VMs, and performs other virtualization tasks.

[0024] According to some implementations of the present disclosure, TPM emulation can be offloaded to a platform controller 108 of the system 100 instead of emulating a TPM using the hypervisor 106. In some examples, the platform controller 108 is a bus device on a bus 110 of the system 100. For example, the bus 110 can be a PCIe bus. In other examples, the bus 110 can be a different type of bus or a different type of communication structure.

[0025] The Platform Controller 108 can be implemented with any type of hardware processing circuit, such as a microcontroller, a programmable integrated circuit (e.g., an application-specific integrated circuit or ASIC), a programmable gate array, a microprocessor, or any other type of hardware processing circuit.

[0026] In some examples, the platform controller 108 is separate and distinct from a processor (or processors) 112 of the system 100. A processor can be a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, a digital signal processor, or other hardware processing circuitry.

[0027] The processor 112 is coupled to the bus 110, either directly or via another device, such as a bridge device. The processor 112 executes machine-readable instructions from the system 100, including the hypervisor 106 and the VMs, a host operating system (if present), and other programs (including software programs and / or firmware programs). The processor 112 can be coupled to system memory 113, which may include one or more memory devices for storing data and machine-readable instructions. A memory device may be a volatile memory device, such as a dynamic random-access memory (DRAM) device, a static random-access memory (SRAM) device, etc. Alternatively, a memory device may be a non-volatile memory device.Although not shown, system memory 113 may contain a memory controller, or alternatively, a memory controller may be connected to the storage device(s) to control access to the data in the storage device(s).

[0028] Other devices can also be connected to bus 110, including a network interface controller (NIC) 140 and persistent storage 142. The NIC 140 is capable of communicating over a network, allowing the components of system 100, including the VMs, to communicate with other units over the network via the NIC 140. In other examples, a physical TPM can also be connected to bus 110.

[0029] The persistent memory 142 can store data that persists even if the power supply to the system 100 or the persistent memory 142 is interrupted. The persistent memory 142 can be implemented with one (or more) non-volatile storage device. A non-volatile storage device can include a flash memory device, a disk-based storage device, etc.

[0030] In some examples, TPM emulation can be performed using PCI functions 114-1 to 114-n, provided by the platform controller 108. The hypervisor 106 can assign one or more PCI functions to each VM.

[0031] In some examples, PCI Functions 114-1 through 114-n may contain virtual functions (VFs) that conform to PCIe Single Root I / O Virtualization (SR-IOV) as defined by the PCI-SIG. PCI Functions 114-1 through 114-n each contain virtual TPMs (vTPMs) 128-1 through 128-n. Instead of implementing physical TPMs, the vTPMs 128-1 through 128-n contained in PCI Functions 114-1 through 114-n are provided by the Platform Controller 108.

[0032] Fig. Figure 1B shows further details of the Platform Controller 108 according to some examples. The Platform Controller 108 may have different implementations in other examples. SR-IOV allows a PCIe device (e.g., a TPM) managed by the Platform Controller 108 to Fig. 1 is implemented), to present itself to a host (e.g., System 100) as several different virtual devices. The PCIe device (e.g., the Platform Controller 108) implements a PCIe Physical Function (PF) 152, which is partitioned into several VFs 150-1 to 150-n to share the resources of the PCIe device in a virtual environment.

[0033] The PF 152 provides control over the creation and allocation of VFs. The PF 152 includes an SR-IOV capability structure and manages SR-IOV functionality. The PF 152 can be detected, managed, and manipulated in System 100 like any other PCIe device.

[0034] In other examples, PCI functions 114-1 to 114-n can be derived from Fig. 1A can be implemented as a different type of function.

[0035] Each VF 150-i (i = 1 to n) contains a corresponding vTPM 128-i. In the example of Fig. VM 1B is assigned to the VF 150-1, VM n to the VF 150-n, and so on. The vTPM 128-1 emulates a serial interface for VM 1, and the vTPM 128-n emulates the serial interface for VM n.

[0036] The Platform Controller 108 from Fig. 1B also includes a processor 154 and a memory 156. The processor 154 of Fig. 1B is used to execute commands from platform controller 108 in order to fulfill tasks of platform controller 108.

[0037] In some examples, the Hypervisor 106 is able to create multiple vTPMs 128-1 to 128-n contained in corresponding VFs 114-1 to 114-n, which are partitioned by the PF 152 implemented by the Platform Controller 108.

[0038] In some examples, Hypervisor 106 creates a vTPM on demand for each VM (i.e., the vTPM is only created for the VM when a VM or other entity requests its creation). In other examples, Hypervisor 106 can create corresponding vTPMs when VMs are created.

[0039] In the example of Fig. vTPM 128-1 is assigned to VM 1 by Hypervisor 106, vTPM 128-n to VM n by Hypervisor 106, and so on. Each vTPM can support a unique and separate data path for I / O-related functions (e.g., TPM read and write operations) within the PCIe hierarchy. vTPM 128-1 emulates a TPM for VM 1, and vTPM 128-n emulates a TPM for VM n.

[0040] The vTPMs 128-1 to 128-n share the underlying hardware of the platform controller and the PCIe interface to the PCI bus 110.

[0041] In accordance with some implementations of this disclosure, SR-IOV allows VMs to access TPMs, bypassing an emulation layer in the Hypervisor 106. VFs according to SR-IOV are lightweight, so a large number of VFs can be implemented on the Platform Controller 108. For example, if System 100 contains a large number of VMs, a correspondingly large number of VFs can be implemented on the Platform Controller 108 to perform TPM emulation for the respective VMs.

[0042] When the hypervisor creates 106 vTPMs (128-1 to 128-n), it assigns control area addresses to the vTPMs. These control areas contain status registers and memory buffer locations for the respective vTPMs. The status registers and memory buffers are used to enable interaction between each VM and its corresponding vTPM. Control areas 118-1 to 118-n are located in Fig. Figure 1C is shown. Control area 118-1 contains the status registers and memory buffer locations for a vTPM 128-1, control area 118-n contains the status registers and memory buffer locations for a vTPM 128-n, etc.

[0043] Control areas 118-1 to 118-n are represented by the platform controller 108. Control areas 118-1 to 118-n can be implemented, for example, using registers in the platform controller 108. Control areas 118-1 to 118-n comprise memory-mapped registers (in an area designated 160) that are mapped to a memory address space 118.

[0044] In some examples, the TPM functionality may correspond to TPM 2.0, as defined in the TCG PC Client Platform Firmware Profile Specification, Family 2.0. In other examples, the TPM functionality may conform to other TPM specifications.

[0045] According to TPM 2.0, a TPM can be accessed by reading from and writing to any specified address. Such read and write operations include reading from and writing to the registers and memory buffers belonging to the control areas of the respective vTPMs.

[0046] In some examples, each VM is associated with a set of ACPI tables and ACPI methods that can be provided by Hypervisor 106. ACPI tables are used to store information related to ACPI operations, including any or a combination of discovering and configuring hardware components, performing power management, monitoring component status, and other operations. An ACPI method refers to a routine containing machine-readable instructions that can be called to perform ACPI operations.

[0047] One of the ACPI tables that can be assigned to each VM is a TPM2 table. Fig. Figure 1 shows TPM2 table 120-1 for vTPM 128-1, TPM2 table 120-n for vTPM 128-n, and so on. TPM2 tables 120-1 through 120-n can be stored in system memory 113 and mapped to memory address space 118. TPM2 table 120-1 contains address 122-1 of control area 118-1, TPM2 table 120-n contains address 122-n of control area 118-n, and so forth. The addresses stored in TPM2 tables 120-1 through 120-n are programmed by hypervisor 106.

[0048] Note that the addresses 122-1 to 122-n contained in the respective TPM2 tables 120-1 to 120-n may be logical addresses (rather than physical addresses) of the respective control areas 118-1 to 118-n. The Hypervisor 106 can provide mapping information (not shown) to map the logical addresses 122-1 to 122-n in the TPM2 tables 120-1 to 120-n to corresponding physical addresses 125-1 to 125-n, which identify the locations of the respective control areas 118-1 to 118-n. For example, physical address 125-1 may identify the base address of control area 118-1, physical address 125-n may identify the base address of control area 118-n, and so on.

[0049] The mapping information for mapping logical addresses 122-1 to 122-n to physical addresses 125-1 to 125-n can, for example, be in the form of a memory management unit (MMU) table assigned to processor 112. In other examples, the mapping information may take other forms.

[0050] Note that logical addresses 122-1 to 122-n can be the same logical address, except that they are mapped to different physical addresses 125-1 to 125-n by the mapping information. Alternatively, logical addresses 122-1 to 122-n can be different logical addresses.

[0051] Each vTPM 128-i can detect write or read accesses from VMs or other entities (whether internal or external to system 100) to the registers / buffers in the respective control area 118-i. Write and read operations are routed to a corresponding vTPM 128-i. In response to a write or read operation, the vTPM 128-i can send an interrupt to processor 154 ( Fig. 1B) signal within the platform controller 108, e.g., using a corresponding TPM indicator 124-i. The TPM indicator 124-i can show which register / buffer of the control area 118-i was written to or read from. The TPM indicator 124-i can contain a signal, an interrupt, an instruction, or any other indication relating to TPM operations. The TPM indicator 124-i can contain information indicating which VF 150-i the TPM indicator 124-i belongs to and which register / buffer was written to or read from.

[0052] In response to the TPM display 124-i, machine-readable instructions (e.g., firmware) running on processor 154 can redirect TPM traffic or synthesize an appropriate response for a TPM operation. In other examples, the vTPM 128-i includes hardware that moves the data or synthesizes a response under the orchestration of machine-readable instructions (e.g., firmware) running on processor 154.

[0053] The memory address space 118, to which the control areas 118-1 to 118-n and the TPM2 tables 120-1 to 120-n are mapped, can be implemented either in the TPM 2.0 device memory or in a memory area reserved by System 100 for the TPM at boot time.

[0054] Memory addresses in memory address space 118 can be mapped to the memory controller and / or a PCIe controller or other device on bus 110. The memory controller is connected to a memory device (or alternatively, multiple memory devices) that is / are part of system memory 113. A PCIe controller is connected to a PCIe device. A PCIe device can support memory accesses, but it cannot actually access memory devices such as DRAMs or SRAMs. Instead, a PCIe device can access memory-mapping registers that are part of the system memory address space.

[0055] The TPM2 tables 120-1 to 120-n (along with other ACPI tables) are part of the respective context of the corresponding VMs.

[0056] As in Fig. As further shown in Figure 1, each guest operating system 102-i (i = 1 to n) of a respective VM i contains a TPM driver 130-i. Each VM i also contains an ACPI method 132-i (which may be part of a set of ACPI methods that can be called by the guest operating system 102-i).

[0057] Fig. Figure 2 shows an example process 200 demonstrating how a VM can invoke a TPM operation according to some implementations of this disclosure. Other examples use a different process.

[0058] A TPM driver 130-i (one of the TPM drivers 130-1 to 130-n from Fig. 1) Determines (at 202) whether to access a TPM to request a TPM operation. This determination can be made in response to a request from an entity (e.g., a user, a program such as the guest operating system 102-i or the application program 104-i, or a machine) indicating that the TPM operation should be performed. In other examples, the determination to access the TPM can be made by the TPM driver 130-i in response to other factors or events.

[0059] In response to the detection that the TPM needs to be accessed, the TPM driver 130-i (at 204) writes a TPM instruction to be executed at the address of the TPM, where the address is 122-i, which was previously read from the TPM2 table 120-i during the initialization of the TPM driver 130-i in VM i. The TPM instruction can be written to control area 118-i, to which address 122-i refers. In some examples, the TPM instruction can contain multiple bytes to be written to control area 118-i (for example, to the memory buffers of control area 118-i). After the TPM command's several bytes are written to control area 118-i, the TPM driver 130-i (at 206) calls an ACPI method (e.g., ACPI method 132-i) to execute the TPM command written to control area 118-i. Note that the called ACPI method is executed in the context of VM i.

[0060] The TPM driver 130-i queries (at 208) a status register (or registers) in control area 118-i to check the completion of the TPM command. When the TPM command execution is complete, the ACPI method that was called to execute the TPM command sets an indicator in the corresponding status register (or registers) of control area 118-i.

[0061] In response to an indication from the indicator(s) set in the status register(s) of control area 118-i that the execution of the TPM command is complete, the TPM driver 130-i (at 210) reads the TPM command response from address 122-i. The TPM command response can be stored in a memory buffer in control area 118-i.

[0062] Fig. Figure 3 is a block diagram of a system 300 that includes a storage medium 302 for storing information elements 304 (e.g., the ACPI-TPM2 tables 120-1 to 120-n of Fig. 1) contains, which relate to corresponding vTPM interfaces 306 (e.g. the control areas 118-1 to 118-n of Fig. 1) refer to. Each respective information element 304 corresponds to a respective VM of several VMs 307 in the system 100.

[0063] Information elements 304 contain addresses (e.g., 122-1 to 122-n from Fig. 1) the corresponding vTPM interfaces 306. The addresses of the corresponding vTPM interfaces 306 are logical addresses that are to be mapped to physical memory addresses that identify the corresponding vTPM interfaces 306.

[0064] The System 300 also includes a Controller 308 (e.g., the Platform Controller 108 from Fig. 1) to provide vTPMs 310 for appropriate security operations.

[0065] The System 300 also includes a processor resource 312 (e.g., processor 112 from Fig. 1) To run the multiple VMs 307, so that they use the information elements 304 to access the corresponding vTPM interfaces 306 to call the security operations of the vTPMs 310. A first VM of the multiple VMs 307 should access a first vTPM interface of the vTPM interfaces 306 to request that a security operation of the respective vTPM be executed.

[0066] In some examples, each vTPM interface of the corresponding vTPM interfaces 306 contains a control area into which a command can be written to request a TPM operation, and from which a result of the TPM operation can be read.

[0067] Fig. Figure 4 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 400 that stores machine-readable instructions which, when executed, cause a system to perform various tasks.

[0068] The machine-readable instructions include TPM-related ACPI information store instructions 402 for storing ACPI information relating to appropriate vTPM interfaces, where the vTPM interfaces are provided by a controller and connected to appropriate VMs.

[0069] The machine-readable instructions also contain VM execution instructions 404 to execute the VMs to use the ACPI information to access the appropriate vTPM interfaces, with a first VM accessing the first vTPM interface of the vTPM interfaces to request a security operation from a respective vTPM.

[0070] Fig. Figure 5 is a flowchart of an example process 500 according to some implementations of the present disclosure.

[0071] The 500 process involves the allocation (at 502) of VFs to respective VMs by a hypervisor, where the VFs represent respective vTPM interfaces and the VFs are provided by a controller separate from the hypervisor.

[0072] The 500 process involves executing (at 504) the VMs to use information specifying the addresses of the respective vTPM interfaces to access the respective vTPM interfaces, with a first VM accessing a first vTPM interface of the vTPM interfaces to request a security operation of a respective vTPM.

[0073] A storage medium (e.g., 302 in Fig. 3 or 400 in Fig.4) may contain any or a combination of the following elements: a semiconductor memory device, such as dynamic or static random-access memory (DRAM or SRAM), erasable and programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), and flash memory; a magnetic disk, such as a hard disk, floppy disk, and removable disk; another magnetic medium, including tape; an optical medium, such as a compact disc (CD) or a digital video disc (DVD); or some other type of storage device. Note that the instructions discussed above may be provided on a single computer- or machine-readable storage medium, or alternatively, on multiple computer- or machine-readable storage media distributed throughout a large system, possibly with multiple nodes.Such a computer-readable or machine-readable storage medium or media are considered part of an article (or manufactured item). An article or manufactured item can refer to any single manufactured component or to multiple components. The storage medium or media can be located either in the machine where the machine-readable instructions are executed or at a remote location from which machine-readable instructions can be downloaded over a network for execution.

Claims

[1] System (100) comprising: a storage medium (113) for storing a plurality of information items containing addresses of corresponding virtual Trusted Platform Module, TPM interfaces (306), wherein each respective information item of the plurality of information items corresponds to a respective virtual machine, VM, (104, 307) of a plurality of VMs (104, 307); a hardware controller (108) to provide virtual TPMs (128, 310) for corresponding security operations; and a processor resource (112) separate from the hardware controller (108) for executing the plurality of VMs (104, 307) to use the information elements to access the corresponding virtual TPM interfaces (306) to invoke the security operations of the virtual TPMs (128, 310), wherein the processor resource (112) is configured to execute the plurality of VMs (104, 307), an operating system, at least one application program, and firmware, and the hardware controller (108) has its own separate processing circuitry configured to execute its own firmware, wherein a first VM (104, 307) of the plurality of VMs (104, 307) is configured to: access a first information element of the plurality of information elements to read an address of a first virtual TPM interface (306) from the virtual TPM interfaces (306); accessing the first virtual TPM interface (306) by writing a TPM command to the address of the first virtual TPM interface (306) read from the first information element to request performance of a security operation of a first virtual TPM (128, 310) of the virtual TPMs (128, 310); and receive an indication that the security operation has been completed based on an indicator set in the first virtual TPM interface (306). [2] The system (100) of claim 1, wherein the plurality of information elements are contained in Advanced Configuration and Power Interface (ACPI) tables. [3] The system (100) of claim 2, wherein the ACPI tables comprise ACPI TPM tables (120). [4] The system (100) of claim 1 to 3, wherein the first VM (104, 307) calls an ACPI method to execute the TPM command written to the address of the first virtual TPM interface (306). [5] The system (100) of any one of claims 1 to 4, wherein the addresses of the corresponding virtual TPM interfaces (306) are logical addresses mapped by mapping information to physical memory addresses that identify the corresponding virtual TPM interfaces (306). [6] The system (100) of any one of claims 1 to 5, wherein each of the respective virtual TPM interfaces (306) comprises a control area into which a command can be written to request a TPM operation and from which a result of the TPM operation can be read; and wherein the indicator is set in the control section of the first virtual TPM interface (306). [7] The system (100) of claim 6, wherein the control portion comprises a memory buffer and a register; and wherein the addresses contained in the plurality of information elements map to an address portion of the memory containing the control portions for the virtual TPMs (128, 310). [8] The system (100) of any one of claims 1 to 7, wherein the virtual TPMs (128, 310) comprise virtual functions, VFs, (114). [9] The system (100) of claim 8, wherein the VFs (114) comprise Single Root I / O Virtualization, SR-IOV, VFs. [10] The system (100) of any one of claims 1 to 9, further comprising a hypervisor (106) to generate the plurality of information items for the plurality of VMs (104, 307). [11] The system (100) of claim 10, wherein the hypervisor (106) is to associate the virtual TPMs (128, 310) with the respective VMs (104, 307). [12] The system (100) of claim 11, wherein the hypervisor (106) is to: to assign the addresses for the respective virtual TPM interfaces (306) and to include the addresses in the information elements. [13] The system (100) of claim 10, wherein the security operations of the virtual TPMs (128, 310) are executable without performing TPM emulation on the hypervisor (106). [14] Non-transitory, machine-readable storage medium containing instructions that, when executed, cause a system to: to store ACPI information, Advanced Configuration and Power Interface, containing memory addresses of corresponding virtual TPM interfaces, Trusted Platform Module, (306), wherein the virtual TPM interfaces (306) correspond to virtual TPMs (128, 310) provided by a hardware controller (108) and associated with respective virtual machines, VMs, (104, 307) of a plurality of VMs (104, 307); Executing, by a processor resource (112) separate from the hardware controller (108), the plurality of VMs (104, 307) to use the ACPI information to access the corresponding virtual TPM interfaces (306), wherein the processor resource (112) is configured to execute the plurality of VMs (104, 307), an operating system, at least one application program, and firmware, and the hardware controller (108) has its own separate processing circuitry configured to execute its own firmware, Accessing, by a first VM (104, 307) of the plurality of VMs (104, 307), the ACPI information to read a memory address of a first virtual TPM interface (306) of the virtual TPM interfaces (306); Accessing, by the first VM (104, 307), the first virtual TPM interface (306) by writing a TPM command to the memory address of the first virtual TPM interface read from the ACPI information to request performance of a security operation of a first virtual TPM (128, 310) of the virtual TPMs (128, 310); and Receiving an indication that the security operation has been completed based on an indicator set in the first virtual TPM interface (306). [15] The non-transitory machine-readable storage medium of claim 14, wherein the ACPI information comprises ACPI TPM tables (120), and the memory address of the first virtual TPM interface (306) is read from a first ACPI TPM table of the ACPI TPM tables (120). [16] The non-transitory machine-readable storage medium of claim 14, wherein writing the TPM command to the memory address of the first virtual TPM interface (306) comprises writing the TPM command to a buffer memory of the first virtual TPM interface (306). [17] The non-transitory machine-readable storage medium of any one of claims 14 to 16, wherein each virtual TPM interface (306) of the respective virtual TPM interfaces (306) comprises a control area that can be used by a respective VM (104, 307) to issue a TPM command and can be used by the respective VM (104, 307) to read a result of a TPM operation. [18] The non-transitory machine-readable storage medium of any of claims 14 to 17, wherein the virtual TPMs (128, 310) comprise virtual functions, VFs, (114). [19] Procedure comprising: Assigning (502), by a hypervisor in a system comprising a processor resource, virtual functions to a respective virtual machine, VM, of a plurality of VMs, wherein the VMs represent respective virtual Trusted Platform Modules, TPMs, and the VMs are provided by a hardware controller separate from the hypervisor and the processor resource; Executing (504), by the processor resource, the plurality of VMs to use information items containing addresses of respective TPM virtual interfaces to access the respective TPM virtual interfaces, wherein the processor resource is configured to execute the plurality of VMs, an operating system, at least one application program, and firmware, and the hardware controller has its own separate processing circuitry configured to execute its own firmware; Accessing, by a first VM of the plurality of VMs, the ACPI information to read a memory address of a first virtual TPM interface of the virtual TPM interfaces; Accessing, by the first VM, the first virtual TPM interface by writing a TPM command to the memory address of the first virtual TPM interface read from the ACPI information to request performance of a security operation of a first virtual TPM of the virtual TPMs; and Receive an indication that the security operation has completed based on an indicator set in the first virtual TPM interface. [20] The method of claim 19, wherein the information elements comprise Advanced Configuration and Power Interface, ACPI tables.

Images