Configuration of instances with instance metadata stored in virtual security processors

Abstract

A non-transitory, machine-readable storage medium that stores machine-executable instructions which, when executed by a machine, cause the machine to: in response to the startup of an instance of a cloud-based computing environment, access metadata stored in a provisioned virtual trusted platform module, vTPM (118, 122), wherein the metadata represents configuration parameters for using the configuration of an operating system image of the instance, with a security credential that enables a user to communicate securely with the instance; and to configure the operating system image based on the metadata to allow the user to use the security credential to communicate securely with the instance, the provision of the vTPM (118, 122) includes: The controller (150) generates the vTPM (118, 122) in response to the controller (150) receiving a request (204) from the cloud orchestrator (170) to generate the vTPM (118, 122), the request including the instance metadata (140); Generating (208) a persistent memory image based on the instance metadata (140), wherein the persistent memory image corresponds to the vTPM (118, 122); Transmission (216) of the persistent storage image to the cloud orchestrator (170) so that the cloud orchestrator (170) retains it as a trusted source; and Creating a cache on the computer platform to store a copy of the persistent storage image.

Description

BACKGROUND

[0001] A computer system can be subject to a security attack in which a malicious organization attempts to access information stored on the computer system or to damage components of the computer system. To prevent security attacks, or at least limit the extent of potential damage from them, the computer system can have various levels of protection. For example, the computer system can have various access restriction mechanisms, such as firewalls, passwords, keys, etc. As another example, a computer system can have a secure cryptographic processor (or "security processor"), such as a Trusted Platform Module (TPM), which can provide a range of security-related functions for the computer system. These security-related features can include, for example, storing secrets (e.g., passwords, passwords, etc.).Keys, passwords, certificates, etc.) are used to ensure that the computer system always behaves as expected and to prove that the computer system is trustworthy.

[0002] US 2016 / 0140343 A1 discloses a method for securely starting a target machine, in which the machine receives encrypted provisioning data from a secure infrastructure to complete the startup process. US 10 579 405 B1 describes a system with parallel virtual machine managers, in which a higher-privileged security VMM manages access to a hardware TPM and provides a virtual TPM (vTPM) for each guest VM. CN 113 485 785 A discloses a method in which a virtual trusted platform module (vTPM) is created within a security processor and uniquely bound to a virtual machine (VM). BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 is a schematic representation of a cloud computing system with a computer platform that includes a virtual trusted platform module (vTPM) that stores instance metadata used to configure a machine instance according to a sample implementation. Fig. 2A is a flowchart that represents a process initiated by a controller of the computer platform of Fig. 1 is executed to create a vTPM, to provide the vTPM with instance metadata, and to attach the vTPM to a machine instance according to a sample implementation. Fig. 2B is a flowchart that represents a process initiated by the control of the computer platform of Fig. 1 is performed to separate a vTPM from a machine instance according to an example implementation. Fig. 2C is a flowchart that represents a process starting from the control of the computer platform of Fig. 1 is performed to move a vTPM from one machine instance to another machine instance and to connect the vTPM to the other machine instance according to an example implementation. Fig. Figure 3 is a schematic diagram of a computer platform with a platform controller that provides vTPMs, connects vTPMs to virtual machine instances, and manages the vTPM lifecycles according to a sample implementation. Fig. Figure 4 is a flowchart that shows a process for configuring an operating system of a machine instance using instance metadata stored in a vTPM, according to an example implementation. Fig. Figure 5 is a schematic diagram of a computer platform with a controller that instantiates a virtual security processor, connects the virtual security processor to a machine instance, and provides the virtual security processor with instance metadata according to an example implementation. Fig. Figure 6 is an illustration of a non-transitory machine-readable storage medium that stores machine-executable instructions which, when executed by a machine, cause the machine to configure an instance of a cloud-based computing environment by accessing metadata stored in a vTPM according to a sample implementation. DETAILED DESCRIPTION

[0003] A cloud computing system can comprise multiple physical server nodes (e.g., blade servers or rack servers) or "computing platforms" managed by a central management subsystem of the cloud computing system. Generally, the central management subsystem manages a software-defined logical infrastructure and services (e.g., software-defined compute services (SDC), software-defined storage services (SDS), and software-defined networking services (SDN)) hosted on the computing platforms. As part of provisioning the logical infrastructure and services, the computing platforms can provision machine instances.

[0004] A "machine instance," as used here, refers to a case or occurrence within a computing environment. The "data processing environment" can refer to an abstraction or virtualization of actual hardware and software resources; that is, the data processing environment can be a virtual data processing environment. The "computer environment" can refer to a set of actual hardware and software resources; that is, the computer environment can be a bare-metal computer environment. The hardware and software resources for a given computer environment might include, for example, an operating system instance, one or more application instances, one or more central processing units (CPUs), one or more graphics processing units (GPUs), memory, network interface controllers, persistent storage, and so on.

[0005] A virtual machine instance is an example of a machine instance that can be considered a case or occurrence within a virtual computing environment. A virtual machine instance (also referred to here as a "virtual guest machine," "virtual machine," "VM instance," "guest VM," or "VM") represents an abstraction of hardware and software resources at the machine level. A virtual machine monitor (VMM), or hypervisor, of a computing platform provides this abstraction of hardware and platform resources for the virtual machine instance, and the hypervisor ensures isolation between multiple virtual machine instances on the computing platform. Furthermore, the hypervisor can manage the lifecycles (e.g., starting and stopping) of the respective virtual machine instances.A virtual machine instance contains a guest operating system, which is an abstraction of the actual host operating system installed on the computer platform. As such, the guest operating system has no direct access to the underlying hardware of the host computer platform. The hardware and software resources available to a given virtual machine instance depend on the specifics of the subscription with the associated cloud provider.

[0006] A bare-metal instance is an example of a machine instance that can be considered a case or occurrence of a bare-metal computing environment, meaning an environment that corresponds to a dedicated set of actual hardware and software components of the host computing platform. The operating system of a bare-metal instance has access to the underlying hardware of the host computing platform. It should be noted that a bare-metal instance may not be able to access all hardware and / or software resources of the host computing platform; rather, the scope of the bare-metal instance may be limited to specific hardware and / or software resources, depending on the specifics of the subscription of the relevant cloud provider.

[0007] Deploying a machine instance on a specific computing platform (i.e., a cloud domain node) can involve deploying a generic operating system image to the platform and then running a startup program (such as a cloud init script) when the machine instance first boots up to specifically configure the operating system image. The startup program configures the operating system image with instance-specific and user-specific information. The instance-specific information might include attributes such as identifying the type or category of the machine instance, the identity of a virtual device containing the root file system, the availability zone of the machine instance, the Internet Protocol (IP) address of the machine instance, and so on.The user-specific information includes, among other possible information, a user-chosen credential (e.g., a Secure Shell SSH key) that enables the user to communicate securely (e.g., via an SSH tunnel) with the machine instance.

[0008] The startup program can retrieve metadata (referred to here as "instance metadata") that represents instance-specific and user-specific information, which the startup program uses to configure the operating system image. One approach to retrieving the instance metadata is for the startup program to use the Hypertext Transfer Protocol (HTTP) to retrieve the instance metadata from a specific IP address. As a security measure, the server corresponding to the specified IP address can restrict access to the instance metadata to the machine instance. Because the startup program operates through its machine instance, the server allows the startup program to retrieve the instance metadata.

[0009] Even if access to instance metadata is restricted to the machine instance, a malicious entity can circumvent this security measure by acting through the machine instance to gain access to the instance metadata (and thus sensitive user information). For example, the machine instance might provide a graphical user interface (GUI) that includes a Uniform Resource Locator (URL) field intended for specifying URLs for uploads to the GUI. A fraudulent entity could enter URLs into a URL field of the GUI to cause the GUI to upload and disclose the instance metadata (including sensitive user credentials). Security measures for accessing instance metadata can be further strengthened by requiring access to a token (e.g., a password).A token generated by a client URL (cURL) PUT command is restricted to a specific session. Therefore, retrieving instance metadata is limited to a request (e.g., a request using the cURL GET command) that includes the generated token. However, this approach to securing instance metadata can still be vulnerable because the instance metadata communication occurs over an insecure HTTP connection.

[0010] Another approach to protecting instance metadata involves first booting a machine instance from an operating system installer running on a RAM-based file system. The installer then installs a selected operating system image on the root device and retrieves the instance metadata, using it to configure the image. However, this approach can be very time-consuming to set up a new machine instance. Furthermore, the root device cannot be reattached to other instances without setting up additional operating system images.

[0011] According to example implementations, the startup program is executed on the first boot of a machine instance to configure a generic operating system image of the machine instance with instance-specific and user-specific information. The startup program retrieves instance metadata (containing the instance-specific and user-specific information) from a virtual security processor, such as a virtual Trusted Platform Module (vTPM).

[0012] Specifically, a controller of a computer platform (providing the machine instance) creates a vTPM according to example implementations, populates the vTPM with the instance metadata, and attaches the vTPM to the machine instance. The controller can perform the creation, provisioning, and attachment of the vTPM in accordance with requirements provided by a cloud orchestrator. When the machine instance starts, a startup program (e.g., a script) of the machine instance accesses the attached vTPM to retrieve the instance metadata, and the startup program uses the retrieved instance metadata to set up or configure the operating system image attached to the machine instance.

[0013] In accordance with example implementations, the controller can create a persistent storage image (e.g., an NVRAM image, such as a TPM NVRAM image) for the vTPM. This persistent storage image includes the instance's metadata, among other possible data. The controller can submit the created persistent storage image to the cloud orchestrator, allowing the cloud orchestrator to maintain the persistent storage image as a trusted source. The controller can also maintain a local cache copy of the persistent storage image.

[0014] Because the cloud orchestrator manages the persistent storage image as the trusted source, the local cache copy stored on the computing platform can be deleted when the machine instance is stopped and the vTPM is disconnected from the machine instance. Furthermore, the controller can easily restore the local cache copy from the trusted source when the machine instance restarts and reconnects to the vTPM. Since the persistent storage image is maintained as the trusted source outside the computing platform, user updates (such as additional user-installed keys) to the vTPM can also be maintained throughout the vTPM's entire lifecycle (i.e., from vTPM creation to vTPM deletion, regardless of how many times the vTPM is disconnected from a machine instance).Because the persistent storage image is available from the trusted source, the control unit can easily update the persistent storage image (e.g., update the persistent storage image with new instance metadata) when the vTPM is migrated from one machine instance to another, as described further here.

[0015] As in Fig. As illustrated in Figure 1 as a more specific example, a cloud computing system 99, according to some implementations, comprises one or more computing platforms 100, which form corresponding domain nodes of a cloud computing system 99. In this context, a "computing platform" refers to a modular unit that includes a frame or chassis. Furthermore, this modular unit may contain hardware attached to the frame that can execute machine-executable commands. A blade server is an example of a computing platform 100 according to one example implementation. However, according to other implementations, the computing platform 100 can also be any number of platforms other than a blade server, such as a rack-mounted server, a client, a desktop computer, a smartphone, a laptop, a tablet computer, a modular switch, a storage array, a cluster node, and so on.

[0016] Computer platform 100 has a cloud tenant domain 101 and a cloud operator domain 103, separated by the depicted boundary 120. The cloud tenant software runs within cloud tenant domain 101. In the Fig. In the example implementation shown in Figure 1, the cloud tenant domain 101 comprises one or more machine instances 104 (e.g., virtual machine instances and / or bare-metal instances). According to the example implementations, a machine instance 104 can be associated with a specific cloud tenant and linked to software that runs to provide one or more cloud services to the cloud tenant. In the example implementation shown in Figure 1, the cloud tenant domain 101 comprises one or more machine instances 104 (e.g., virtual machine instances and / or bare-metal instances). Fig. The example implementation shown in Figure 1 includes the machine instance 104, an operating system 116, and applications 114. The software may also include one or more virtual trusted platform modules (vTPMs), application programming interfaces (APIs) 118, and a startup engine 112, which are described in more detail below.

[0017] The cloud operator domain 103 of the computer platform 100 includes a cloud orchestrator 170, which manages hardware and software components of the cloud operator domain 103. The cloud orchestrator 170 may, in accordance with some implementations, include one or more servers, and the cloud orchestrator 170 may be connected via a network structure connection 160 (i.e., a connection 160 to a network structure that may include one or more network components, one or more network protocols, etc.).

[0018] According to example implementations, the Cloud Orchestrator 170 includes a lifecycle management engine 172 that manages the lifecycles of machine instances 104, which can be deployed on domain nodes of the Cloud Computing System 99, such as the computer platform 100. In this context, managing the lifecycle of a machine instance 104 involves managing or controlling the lifecycle phases of the machine instance 104. For example, under the management of the lifecycle management engine 172, a given machine instance 104 can go through several lifecycle phases, such as a provisioning phase (i.e., a phase of resource allocation for the machine instance 104) and a deployment phase (i.e., a phase in which the machine instance 104 prepares for its first power-up or startup).The lifecycle phases of the machine instance can also include an operating phase, a halt phase (in which the machine instance 104 is currently halted), a termination phase, and so on. According to example implementations, the lifecycle management engine 172 consists of one or more computing cores (e.g., CPU cores or GPU cores) on one or more servers that execute machine-readable instructions (or "software").

[0019] According to example implementations, the lifecycle management engine 172 can manage the lifecycles of vTPMs, such as vTPM 122, created on compute platforms. vTPM 122 resides in the cloud operator domain 103. As further described here, the vTPM lifecycle can include a provisioning phase to create a vTPM, such as vTPM 122, including the allocation of resources from the cloud orchestrator 170 and the compute platform 100. The vTPM lifecycle can include an attachment phase, in which a vTPM is attached to a machine instance, such as machine instance 104. Additionally, the vTPM lifecycle can include a detachment phase, in which the vTPM is detached from a machine instance and the resources on compute platform 100 are released (e.g., deleted or cleared) for the vTPM.The vTPM lifecycle may also include a deletion phase, in which all resources are released for the vTPM in order to delete it (e.g., resources on Cloud Orchestrator 170 are deleted or erased). The vTPM lifecycle may also include a migration phase, in which a vTPM is moved or migrated from one machine instance (e.g., a virtual machine instance that has failed or is located on a primary computing platform) to another machine instance (e.g., a virtual machine instance on the same primary computing platform or a different computing platform).

[0020] According to example implementations, the Lifecycle Management Engine 172 communicates with a Controller 150 of the Computer Platform 100 to create machine instances (such as the example machine instance 104) on the Computer Platform 100 and manage the lifecycles of the machine instances. Furthermore, in accordance with example implementations, the Lifecycle Management Engine 172 can communicate with the Controller 150 to create vTPMs (such as vTPM 122) and connect or link the vTPMs to the machine instances. In the Fig. In the example implementation shown in Figure 1, vTPM 122 is attached to machine instance 104 (as shown with reference number 119). In this context, "attaching" a vTPM to a specific machine instance means that the vTPM is accessible to entities of that machine instance (as controlled by access policies, as described further below).

[0021] The following discussion refers specifically to vTPM 122 and machine instance 104, which are in Fig. Figure 1 is shown, although it is understood that the computer platform 100, according to the example implementations, can have multiple machine instances and multiple vTPMs. Furthermore, in the following discussion, the term "Cloud Orchestrator 170 performing an action" generally refers to the action performed by a component of the Cloud Orchestrator 170 (e.g., the Lifecycle Management Engine 172).

[0022] The following assumes that Controller 150 manages the lifecycles of vTPM 122 in response to requests from Cloud Orchestrator 170. Furthermore, in accordance with example implementations, Controller 150 manages the lifecycle of Machine Instance 104 in response to requests from Cloud Orchestrator 170. In accordance with some implementations, as described further herein, Controller 150 may comprise more than one component, such as a hypervisor for managing the lifecycles of Machine Instances and a platform controller for managing the lifecycles of vTPMs. In accordance with other example implementations, Controller 150 may be a single entity, such as a hypervisor that manages both the lifecycles of Machine Instances and the lifecycles of vTPMs.

[0023] As specified under reference number 153, Controller 150 performs the platform-internal lifecycle management of machine instance 104 (as instructed by Cloud Orchestrator 170), in accordance with example implementations. Furthermore, as specified under reference number 151, Controller 150 performs the platform-internal lifecycle management of vTPM 122 (as instructed by Cloud Orchestrator 170), in accordance with example implementations. Cloud Orchestrator 170 communicates with Controller 150 as part of a process to configure machine instance 104 and create vTPM 122, as described in the example implementations. As part of the creation of the vTPM 122, the controller 150 provides the vTPM 122 with instance metadata 140. As further described herein, the cloud orchestrator 170 can receive user-defined data 180 from a cloud tenant for the purpose of creating the vTPM 122 (e.g.,(the data 180 is received via a graphical user interface connected to the cloud orchestrator 170, or the data 180 is received via a file communicated to the cloud orchestrator 170 by the tenant), and the user-defined data 180 may contain data that represents parameters or attributes of the instance metadata 140.

[0024] In accordance with example implementations, the instance metadata 140 contains user-specific metadata 142 and instance-specific metadata 144. When the machine instance 104 starts for the first time, the startup engine 112 (e.g., a script, such as a cloud init script, executed by a processing kernel of the compute platform 100) accesses the vTPM 122 to retrieve the instance metadata 140. The startup engine 112 then configures an operating system image 116 for the machine instance 104 based on the instance metadata 140. For example, based on the instance metadata 140, the startup engine 112 can configure the operating system image with instance-specific information, such as...an identifier of machine instance 104, an identity of a virtual device containing the root file system, a hostname of machine instance 104, an IP address of machine instance 104, the availability zone of machine instance 104, and so on. Based on the instance metadata 140, the startup engine 112 can configure the operating system image with user-specific information, such as an SSH key or other user permissions that allow a user to communicate securely with machine instance 104.

[0025] The vTPM 122 is an example of a virtual secure cryptographic processor, or "virtual security processor." In general, a security processor (whether an actual physical security processor or a virtual one) can provide trusted computing operations for a computer platform to ensure that the platform behaves consistently as expected. Examples of trusted computing operations include generating cryptographic keys; storing security artifacts (e.g.,cryptographic keys and certificates); access security artifacts; delete security artifacts; store integrity measure dumps; provide signed integrity measure dumps for remote attestation; encrypt data; decrypt data; bind cryptographic keys to specific integrity measure dump states (e.g., binding a storage device's encryption key (KEK) to a set of integrity measures); unseal cryptographic keys; provide nonces for cryptographic communications; sign certificates; provide random or pseudorandom numbers; and so on. Trusted computational operations may also include security processor configuration operations and security processor ownership operations. A Trusted Platform Module (TPM) is an example of a security processor.

[0026] The security processor, as shown in example implementations, can have non-volatile or persistent memory, such as random-accessible non-volatile memory (NVRAM), in which two types of data are stored: predefined data structures (e.g., structures corresponding to an attestation key (AC), a credential key (AC), seeds, authorization values, etc.) and unstructured data. The data stored in the NVRAM can be referred to as an "NVRAM image" (or "persistent memory image"). The structured data can be defined by an architectural standard for the security processor, and the unstructured data corresponds to user objects (e.g., cryptographic keys, passwords, seeds, sensitive data, etc.) that a tenant can access (read or write) if they comply with the appropriate access control policies for the user objects.

[0027] A specific user object might be, for example, a disk encryption key for which the following access control policy applies. Access to the disk encryption key can be restricted to tenants with the appropriate privilege level. Furthermore, access can be restricted to tenants who know the associated handle or "NV index" of the user object. In addition to the requirement that the tenant has the appropriate privilege level and the NV index, the access control policy can specify further criteria. For example, the disk encryption key can be sealed with a metric digest, such as a metric digest represented by platform configuration registers (PCRs) of the computer platform, according to the associated access control policy. Here, the term "sealed" disk encryption key refers to the key to be encrypted.The disk encryption key can be sealed with a specific state of the computer platform (or another state) so that the security processor does not unseal or decrypt the disk encryption key and make the disk encryption key available to the requesting tenant if the current measurement evaluation (e.g., the evaluation represented by the current PCR values) does not match the measurement evaluation with which the disk encryption key is sealed.

[0028] In accordance with some implementations, a security processor generally refers to any component that performs specific security operations. According to example implementations, the security processor may be a TPM operating according to a security specification defined by the Trusted Computing Group (TCG), such as the Trusted Platform Module Library Specification, Family 2.0, Level 00, Revision 01.59 (November 2019), published by the Trusted Computing Group (hereinafter referred to as the "TPM 2.0 Specification"). According to some implementations, a security processor may be a TPM operating according to a different security specification than the TPM 2.0 Specification. According to other examples, the security processor may not operate according to a TCG specification.

[0029] A physical or actual security processor can be implemented as a physical device using hardware, such as an integrated circuit (IC) or a "chip." A "virtual security processor" (e.g., a vTPM as per the example implementations) refers to the emulation of a physical security processor by having a hardware processor (e.g., a hardware processor consisting of one or more processing cores such as CPU or GPU cores) execute machine-readable instructions. Depending on the implementation, the machine-readable instructions can be firmware instructions or non-firmware instructions. Regardless of its specific form, a virtual security processor, as per the example implementations, has associated secure memory that can be configured to hold secret or sensitive information, including instance metadata.

[0030] According to example implementations, the features of the vTPM 122 include machine-readable instructions 128 that can be executed by a hardware processor (e.g., a hardware processor consisting of one or more processor cores, such as CPU or GPU cores of computer platform 100) to emulate a physical TPM. As part of this emulation, the vTPM 122 has an emulated TPM interface 124, and the vTPM 122 has NVRAM. In accordance with example implementations, the NVRAM corresponds to a persistent local cache 132 of the computer platform 100 and a persistent trust source 174 of the cloud orchestrator 170. The local cache 132 stores an NVRAM image 136 for the vTPM 122, and the NVRAM image 136 contains the instance metadata 140, structured data 147 (e.g., data representing structured data provided by the TPM 2).(defined by the 0 specification) and unstructured data representing one or more other user objects 145 (e.g., objects stored by the machine instance 104, such as seeds, keys, passwords, certificates). In accordance with some implementations, the instance metadata 140 can be considered unstructured data.

[0031] In accordance with some implementations, access to instance metadata 140 can be protected by an access control policy. For example, in some implementations, the access control policy for instance metadata 140 can prevent any entity other than the attached machine instance 104 from accessing instance metadata 140. Furthermore, according to some implementations, instance metadata 140 can be sealed for a specific PCR state, and access to instance metadata 140 may require the use of (and knowledge of) an NV index corresponding to instance metadata 140.

[0032] In accordance with other implementations, some instance metadata 140 may have a different access control policy than other instance metadata. For example, in some implementations, user-specific metadata 142 may be sealed in a specific PCR state, but instance-specific metadata 144 may have a less restrictive access control policy that does not include sealing the metadata 144. In other implementations, all instance metadata 140 may have the same access control policy.

[0033] As the name suggests, the local cache 132, in accordance with the example implementations, is a temporary storage location for the NVRAM image 136. Because the local cache 132 resides locally on computer platform 100, it speeds up access to the NVRAM data. The local cache 132 can be deleted when the vTPM 122 is detached from machine instance 104. Deletion can be beneficial for security purposes, as sensitive data relating to machine instance 104 can be removed from computer platform 100 when machine instance 104 is stopped. It should be noted that a specific cloud tenant may repeatedly stop and start a machine instance to reduce cloud costs.Since the corresponding NVRAM image 178 is managed by the cloud orchestrator 170 as a trusted source 174, when a stopped machine instance 104 is restarted, the local copy of the platform's NVRAM image can be restored from NVRAM image 178. Furthermore, as described below, NVRAM image 178 can be updated with new instance metadata 140 to move or migrate a vTPM to a different machine instance 104.

[0034] To access the vTPM 122, the operating system 116 may contain a TPM driver (in Fig. (1 not shown). The vTPM APIs 118 can be used by components of the machine instance 104, e.g., the applications 114 and the start-up engine 112, to make requests to the vTPM 122 and to receive responses from the vTPM 122.

[0035] Fig. Figure 2A shows a process 200, performed by the control unit 150, to create a vTPM 122, to equip the vTPM 122 with instance metadata 140, and to attach the vTPM 122 to a machine instance 104 according to an example implementation. With reference to Fig. 2A in conjunction with Fig. 1. Controller 150 receives a "Create vTPM Request" (Block 204) from Cloud Orchestrator 170 to create a vTPM 122. The "Create vTPM Request" contains the instance metadata 140 or data from which the instance metadata 140 can be derived. According to Block 204, in response to the "Create vTPM Request," Controller 150 creates an NVRAM image and submits the NVRAM image to Cloud Orchestrator 170 so that Cloud Orchestrator 170 can manage the NVRAM image as a trusted source 174.

[0036] As shown in block 210, as part of process 200, controller 150 receives an "Attach vTPM Request" from the cloud orchestrator to start a machine instance 104. The "Attach vTPM Request" contains a reference to the NVRAM image 178. In response to the Attach vTPM Request, controller 150 instantiates vTPM 122 from the NVRAM image 178 and attaches vTPM 122 to machine instance 104. With vTPM 122 deployed, the startup engine 112 of machine instance 104 can then access vTPM 122 to retrieve the instance metadata 140 and configure the image for the operating system 116 based on the instance metadata 140, as shown in block 216.

[0037] Fig. Figure 2B shows a process 240, performed by the control unit 150, to disconnect a vTPM 122 from a machine instance 104 according to an example implementation. With reference to Fig. 2B in conjunction with Fig. 1. According to block 244, controller 150 receives a "Detach vTPM Request" from cloud orchestrator 170. The Detach vTPM Request can contain a reference to the specific machine instance 104 and a reference to the vTPM 122. In response to the "Detach vTPM Request," controller 150 stops machine instance 104 (block 248) and deletes the NVRAM image 136 from the local cache 132.

[0038] Fig. Figure 2C shows a process 260, performed by the control unit 150, to migrate a vTPM 122 from one machine instance 104 to another machine instance 104, according to an example implementation. With reference to Fig. 2C in conjunction with Fig. According to process 260, controller 150 receives a "Move vTPM Request" from cloud orchestrator 170 to move a vTPM to a machine instance 104 (block 264). The "Move vTPM Request" contains instance metadata 140 (or data from which the instance metadata 140 can be derived) and a reference to an NVRAM image 178. According to block 268, controller 150 creates a new NVRAM image in response to the Move vTPM request. The new NVRAM image contains the instance metadata 140 associated with the Move vTPM request; that is, this new instance metadata 140 replaces the instance metadata 140 of the old NVRAM image 178. The new NVRAM image contains the user data from the old NVRAM image 178. According to block 272, the controller 150 then submits the new NVRAM image to the cloud orchestrator 170 so that the cloud orchestrator 170 manages it as NVRAM image 178 in a trusted source 174.

[0039] In Fig. Figure 3 shows a computer platform 302 according to an exemplary embodiment. Fig. 3. Similar reference numbers are used to refer to similar components described above. As in Fig. As shown in Figure 3, the computer platform 302 can be connected via a network structure 384 to the cloud orchestrator 170 and to one or more clients 380 (e.g., client computer platforms connected to one or more cloud tenants). In general, the network structure 384 can be connected to one or more types of communication networks, such as (for example) Fibre Channel networks, Gen Z fabrics, dedicated management networks, local area networks (LANs), wide area networks (WANs), global networks (e.g., the Internet), wireless networks, or any combination thereof.

[0040] At the in Fig. In the example implementation shown in Figure 3, the controller 150 comprises a platform controller 350, and the machine instance is a virtual machine instance 104. A "platform controller" can refer to a controller that performs specific tasks in a computer system. In some examples, the platform controller 350 might be a peripheral bus device, such as a bus device connected to a Peripheral Component Interconnect 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. As in Fig. As shown in Figure 3, the platform controller 350 can be connected to a bus / bridge architecture 330. In this case, the "bus / bridge architecture" represents one or more buses and possibly one or more bridges that establish communication between the buses.

[0041] The Platform Controller 350 performs TPM emulation, as described in example implementations, to provision one or more vTPMs 368. In this context, vTPM provisioning refers to managing the vTPM lifecycles. As per example implementations, the Platform Controller 350 can manage the vTPM lifecycles. Examples of vTPM lifecycle management include managing each aspect of the lifecycle, such as creating a vTPM 368, provisioning a vTPM 368 with instance metadata, attaching a vTPM 368 to a machine instance (such as a virtual machine instance 104), detaching a vTPM 368 from a machine instance, deleting a vTPM 368, migrating a vTPM 368 to another machine instance, and so on.

[0042] At the in Fig. In the example implementation shown in Figure 3, the computer platform 302 includes a hypervisor 326 for managing the lifecycles of the virtual machine instances 104. In this way, the hypervisor 326 can, for example, create virtual machine instances 104, manage the execution of the virtual machine instances 104, emulate physical resources of the computer platform 302 that the virtual machine instances 104 can access, provide isolation between the virtual machine instances 104, and perform other virtualization tasks.

[0043] According to example implementations, the Platform Controller 350 can be part of the Hypervisor 326 and provide vTPMs as an emulation device. According to other example implementations, the Platform Controller 350 can be separate from and distinct from a Hardware Processor 304 of the Computer Platform 302. In this context, a "hardware processor" refers to one of several processor cores that execute machine-readable instructions. The hardware processor can include one or more microprocessors, one or more processing cores of a multi-core microprocessor, a microcontroller, a digital signal processor, and so on.

[0044] The hardware processor 304 is connected to the bridge / bus architecture 330. The hardware processor 304 executes machine-readable instructions 342, which may be stored in the system memory 340 of the computer platform 302, which is connected to the hardware processor 304. The execution of the machine-readable instructions 342 can be carried out by software components of the computer platform 302, such as the hypervisor 326, the virtual machine instances 104, a host operating system (if present), and other programs (including software programs and / or firmware programs). The system memory 340 can include one or more storage devices to store data and machine-readable instructions. A storage device can be a volatile storage device, such as dynamic random-access memory (DRAM), static random-access memory (SRAM), etc. Alternatively, a storage device can also be a non-volatile storage device.Although not shown, the system memory 340 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).

[0045] Other devices, including a network interface controller (NIC) 334 and persistent memory 378, can also be connected to the 330 bus architecture. The NIC 334 is capable of communicating over a network, allowing the components of the 302 computer platform, including the virtual machine instances 104, to communicate with other units over the network through the NIC 334. In other examples, a physical TPM can also be connected to the 330 bus architecture. According to example implementations, the NIC 334 can be a "smart I / O peripheral" (e.g., a smart network interface controller or "smart NIC"), which refers to a peripheral device that offloads processing operations traditionally performed by the main processing cores of older computer systems. For example, a particular smart I / O peripheral can provide backend I / O services to the 302 computer platform.I / O services can include, for example, network virtualization services (e.g., overlay network services, virtual switchboard services, virtual routing services, and network function virtualization services), network storage services, network monitoring services, storage acceleration services (e.g., NVMe-based services), security services (e.g., cryptography services and network firewall services), and so on. In accordance with example implementations, the Platform Controller 350 can be a smart network interface card (e.g., a PCIe-based smart network interface card).

[0046] The persistent memory 378 can store data that is retained even when the computer platform 100 or the persistent memory 378 is disconnected from the power supply. The persistent memory 378 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. In accordance with example implementations, the persistent memory 378 stores a vTPM state file 370, which corresponds to the NVRAM image 136 (see Fig. 1) corresponds to a specific vTPM.

[0047] In accordance with example implementations, the Platform Controller 350 can emulate a vTPM 368 using a PCI Feature 360 ​​provided by the Platform Controller 350. Note that a hardware TPM is a non-PCI device. When a hypervisor creates an emulated virtual TPM device, the hypervisor emulates a hardware TPM device as a non-PCI device. As described herein, in accordance with example implementations, the Platform Controller 350 can create multiple emulated hardware TPM devices to provide corresponding vTPMs 368 (or "vTPM devices") using PCI Single Root I / O Virtualization (SR-IOV), as defined by the PCI Special Interest Group (PCI-SIG). According to implementation examples, the hypervisor 326 can assign a PCI function 360 (or multiple PCI functions 360) to a specific virtual machine instance 104 to connect the vTPM 368 to the virtual machine instance 104.

[0048] In accordance with example implementations, the PCI Function 360 can be a virtual function (VF) corresponding to the PCI SR-IOV. The SR-IOV allows a PCIe device (e.g., a vTPM 368 provided by the Platform Controller 350) to present itself to a host (e.g., the Computer Platform 100) as multiple distinct virtual devices. In accordance with example implementations, the Platform Controller 350 implements a PCIe Physical Function (PF) that is divided into multiple VFs, each VF potentially corresponding to a different vTPM 368. The PF provides control over the creation and allocation of VFs. The PF contains an SR-IOV capability structure and manages the SR-IOV functionality. The PF can be discovered, managed, and manipulated in the Computer Platform 100 just like any other PCIe device.

[0049] In accordance with other implementations, function 360 can be a function other than a VF. In some implementations, each VF contains a corresponding vTPM 368.

[0050] Among other features, the Platform Controller 350 can include a hardware processor and memory. This allows the Platform Controller 350's processor to execute machine-readable instructions stored in memory to perform the tasks of the Platform Controller 350 described here.

[0051] In accordance with some implementations, the Hypervisor 326 can create multiple vTPMs 368 contained in corresponding VFs partitioned by the PF implemented by the Platform Controller 350.

[0052] In some examples, Hypervisor 326 creates a vTPM 368 on demand for a corresponding instance of Virtual Machine 104 (i.e., the vTPM 368 is only created for the instance of Virtual Machine 104 when an instance of Virtual Machine 104 or another entity, such as Cloud Orchestrator 170, requests the creation of the vTPM 368). In other examples, Hypervisor 326 creates the corresponding vTPMs when the instances of Virtual Machine 104 are created.

[0053] In accordance with example implementations, each vTPM 368 can support its own separate data path for I / O-related functions (e.g., TPM read and write operations) within the PCIe hierarchy. Furthermore, the vTPMs 368 share the underlying platform controller hardware and the PCIe interface to the PCI bus.

[0054] According to the example implementations, SR-IOV enables TPM access by instances of virtual machines 104, bypassing an emulation layer in the hypervisor 326. VFs according to SR-IOV are lightweight, so a large number of VFs can be implemented in the platform controller 350. For example, if the computer platform 100 contains a large number of instances of virtual machines 104, a correspondingly large number of VFs can be implemented on the platform controller 350 to perform TPM emulation for the respective instances of virtual machines 104.

[0055] The platform controller 350, in accordance with example implementations, provides a control area 348 for each vTPM 368, mapped to the address space of system memory 340. Control area 348 corresponds to the control and status registers used for interaction between a virtual machine instance 104 and the vTPM 368. According to the TPM 2.0 specification, access to a TPM can be performed by reading and writing operations at arbitrarily specified addresses. These read and write operations include read and write operations to the registers and memory buffers associated with control area 348 of the vTPM 368.

[0056] The instance of virtual machine 104 can be connected to a set of ACPI (Advanced Configuration and Power Interface) tables and to one or more ACPI methods 322, which can be provided by the hypervisor 326. ACPI tables are used to store information about ACPI operations, including one or more combinations of hardware component discovery and configuration, power management, component status monitoring, and other operations. An ACPI method refers to a routine with machine-readable instructions that can be called to perform ACPI operations.

[0057] One of the ACPI tables that can be associated with a virtual machine instance 104 is a TPM2 table 344. Fig. Figure 3 shows the TPM2 tables 344 for the respective vTPMs 368 according to the example implementations. As in Fig. As shown in Figure 3, the TPM2 tables 344 can be stored in system memory 340. Furthermore, the TPM2 tables 344 can be mapped into the memory address space of the respective control areas 348. The addresses stored in the TPM2 tables 344 can be programmed by the hypervisor 326.

[0058] Note that the addresses contained in the respective TPM2 tables 344 may be logical addresses (rather than physical addresses) of the respective control areas 348. The hypervisor 326 can provide mapping information (not shown) to map the logical addresses in the TPM2 tables 348 to corresponding physical addresses that identify the locations of the respective control areas 348. The mapping information for connecting the logical addresses to the physical addresses may, for example, be in the form of a memory management unit (MMU) table associated with the processor 304. In other examples, the mapping information may take other forms.

[0059] It should be noted that the logical addresses can be the same logical address, only that they are mapped to different physical addresses by the mapping information. Alternatively, the logical addresses can also be different logical addresses.

[0060] In accordance with example implementations, the platform controller can emulate 350 vTPMs, as described in US patent application no. 2021 / 0271502 entitled “VIRTUAL TRUSTED PLATFORM MODULES”.

[0061] According to other implementations, the Platform Controller 350 can be constructed from hardware other than that of a PCIe peripheral device. For example, according to some implementations, the Platform Controller 350 can be a chassis management controller.

[0062] As another example, the Platform Controller 350, in accordance with other implementations, can be a Baseboard Management Controller, or "BMC." A Baseboard Management Controller is a specialized service processor that monitors the physical state of a server or other hardware using sensors and communicates with a management system over a management network. The Baseboard Management Controller can also communicate with applications running at the operating system level through an IOCTL (Input / Output Controller) interface driver, a REST (Representational State Transfer) API, or another system software proxy that facilitates communication between the Baseboard Management Controller and the applications. The Baseboard Management Controller can access hardware devices located within a server chassis, including system memory, at the hardware level.The baseboard management controller may be able to directly modify the hardware devices. The baseboard management controller can operate independently of the operating system of the system in which it is located. The baseboard management controller may be located on the motherboard of the server or other device being monitored. The fact that a baseboard management controller is mounted on the motherboard of the server / hardware being monitored, or otherwise connected or attached to it, does not prevent the baseboard management controller from being considered "separate" from the server / hardware being monitored.As used herein, a baseboard management controller has management functions for subsystems of a computer device and is separate from a processing resource that runs a computer device's operating system. The baseboard management controller is separate from a processor, such as a central processing unit, that runs a high-level operating system or hypervisor on a system.

[0063] According to further example implementations, the Controller 150 can be a software component formed from general main processing kernels of the computer platform that execute machine-readable instructions. As mentioned above, in some implementations the Controller 150 can, for example, be a hypervisor, such as the Hypervisor 360, which is used in Fig. 3 is shown.

[0064] Referring to Fig. 4. A 400 process, in accordance with example implementations, involves the provisioning (block 404) of a virtual trusted platform module (vTPM) on the computer platform by a computer platform controller. Provisioning includes supplying the vTPM with instance data provided by a cloud orchestrator. The 400 process includes the association (block 408) of the vTPM with a machine instance by the controller. The 400 process includes starting (block 412) the machine instance. According to block 416, in response to the machine instance starting, the 400 process includes accessing the instance metadata from the vTPM and configuring an operating system image of the machine instance based on the instance metadata.

[0065] As in Fig. As shown in Figure 5, a computer platform 500, according to example implementations, comprises a controller 504, a processor 512, and memory 540. The controller 504 receives a request 506 from a cloud orchestrator to attach a virtual security processor 520 to a machine instance 522. The request 506 contains a reference 508 to a persistent image managed by a trusted source, and the persistent image contains instance metadata 510. In response to the request 506, the controller 504 instantiates the virtual security processor 520 based on the reference 508 and attaches the virtual security processor 520 to the machine instance 522. The instantiation of the virtual security processor 520 involves deploying the virtual security processor 520 with the instance metadata 510.Memory 540 stores instructions 544 which, when executed by processor 512, cause processor 512 to access the instance metadata 510 of the virtual security processor 520 and configure the machine instance 522 based on the instance metadata 510.

[0066] Referring to Fig.6 stores machine-executable instructions 604 on a non-transient, machine-readable storage medium 600 according to example implementations. When executed by a machine, these instructions cause the machine, in response to the startup of an instance of a cloud-based computing environment, to access metadata stored in a virtual trusted platform module (vTPM). The metadata represents configuration parameters for the instance, and these parameters include a security credential. Furthermore, when executed by the machine, the instructions 604 cause the machine to configure the instance based on the metadata. This configuration includes configuring access control for the instance using the security credential.

[0067] According to example implementations, configuring the operating system image includes configuring the operating system image with user permissions, represented by the metadata, and configuring the operating system image with information specific to the machine instance. A particular advantage is that the sensitive information in the instance metadata is highly resilient against security attacks.

[0068] According to example implementations, vTPM provisioning involves the controller creating the vTPM in response to a request from the cloud orchestrator to generate it. This request contains data representing the instance metadata. vTPM provisioning further involves creating an image of the persistent storage based on the instance metadata. This persistent storage image corresponds to the vTPM. vTPM provisioning also includes submitting the persistent storage image to the cloud orchestrator so that the cloud orchestrator can maintain it as a trusted source, and creating a cache on the computing platform to store a copy of the persistent storage image. A key advantage is that the sensitive information contained in the instance metadata is highly resilient against security attacks.

[0069] According to example implementations, in response to a request from the cloud orchestrator to stop the machine instance, the controller halts the machine instance and clears the cache. A particular advantage is that sensitive information in the instance metadata is highly resistant to security attacks.

[0070] In accordance with example implementations, the vTPM deployment involves the controller moving the vTPM from another machine instance, and the deployment involves the controller updating a persistent storage image associated with the vTPM. A particular advantage is that the sensitive information in the instance metadata is highly resilient against security attacks.

[0071] In accordance with example implementations, deploying vTPM with instance metadata also includes setting up at least one access control or access policy for accessing the instance metadata. A particular advantage is that the sensitive information in the instance metadata is highly resilient against security attacks.

[0072] In accordance with example implementations, defining access control and / or access policy involves mapping instance metadata to an index value and sealing the instance metadata with a platform configuration registry state. A particular advantage is that the sensitive information in the instance metadata is highly resilient against security attacks.

[0073] In accordance with example implementations, the controller can be a platform controller, a hypervisor, or a baseboard management controller. A particular advantage is that the sensitive information in the instance metadata is highly resistant to security attacks.

[0074] In accordance with example implementations, the machine instance can be a virtual machine instance or a bare-metal instance. A particular advantage is that the sensitive information in the instance's metadata is highly resistant to security attacks.

[0075] In accordance with example implementations, a startup script is executed in response to the machine instance starting up. This script accesses the instance metadata from the vTPM and configures an operating system image of the machine instance based on that metadata. A particular advantage is that the sensitive information in the instance metadata is highly resistant to security attacks.

[0076] In accordance with example implementations, the controller receives a request from the cloud orchestrator to start the machine instance. The request includes a reference to a trusted source, and the trusted source contains a persistent image that includes the instance metadata. In response to the request, the controller instantiates the vTPM, equips the vTPM with the persistent image, and attaches the vTPM to the machine instance. A key advantage is that the sensitive information in the instance metadata is highly resilient against security attacks.

[0077] Although the present disclosure has been described with respect to a limited number of implementations, those skilled in the art who have the advantages of this disclosure will appreciate numerous modifications and variations thereof. It is intended that the appended claims cover all such modifications and variations.

Claims

[1] A non-transitory, machine-readable storage medium that stores machine-executable instructions which, when executed by a machine, cause the machine to: in response to the startup of an instance of a cloud-based computing environment, access metadata stored in a provisioned virtual trusted platform module, vTPM (118, 122), wherein the metadata represents configuration parameters for using the configuration of an operating system image of the instance, with a security credential that enables a user to communicate securely with the instance; and to configure the operating system image based on the metadata to allow the user to use the security credential to communicate securely with the instance, the provision of the vTPM (118, 122) includes: The controller (150) generates the vTPM (118, 122) in response to the controller (150) receiving a request (204) from the cloud orchestrator (170) to generate the vTPM (118, 122), the request including the instance metadata (140); Generating (208) a persistent memory image based on the instance metadata (140), wherein the persistent memory image corresponds to the vTPM (118, 122); Transmission (216) of the persistent storage image to the cloud orchestrator (170) so that the cloud orchestrator (170) retains it as a trusted source; and Creating a cache on the computer platform to store a copy of the persistent storage image. [2] Storage medium according to claim 1, wherein the instructions, when executed by the machine, also cause the machine to communicate with a cloud orchestrator (170) to manage the vTPM (118, 122). [3] Storage medium according to claim 2, wherein the management of the vTPM (118, 122) comprises at least one of the following elements: creating the vTPM (118, 122), attaching the vTPM (118, 122) to the instance, detaching the vTPM (118, 122) from the instance, deleting the vTPM (118, 122) or moving the vTPM (118, 122) to another instance. [4] A procedure that includes the following: Provisioning, by a controller (150) of a computer platform, a virtual trusted platform module, vTPM (118, 122) on the computer platform, wherein the provisioning includes providing the vTPM (118, 122) with instance metadata (140) provided by a cloud orchestrator (170), wherein the instance metadata (140) is used to configure an operating system image of a machine instance (104) with user-specific information that enables a user to communicate securely with the machine instance (104); Assignment of the vTPM (118, 122) to the machine instance (104) by the controller (150); Starting the machine instance (104) by the controller (150); and in response to the starting of the machine instance (104), accessing the instance metadata (140) from the vTPM (118, 122) and configuring the operating system image based on the instance metadata (140) to enable the user to communicate securely with the machine instance (104); the provision of the vTPM (118, 122) includes: The controller (150) generates the vTPM (118, 122) in response to the controller (150) receiving a request (204) from the cloud orchestrator (170) to generate the vTPM (118, 122), the request including the instance metadata (140); Generating (208) a persistent memory image based on the instance metadata (140), wherein the persistent memory image corresponds to the vTPM (118, 122); Transmission (216) of the persistent storage image to the cloud orchestrator (170) so that the cloud orchestrator (170) retains it as a trusted source; and Creating a cache on the computer platform to store a copy of the persistent storage image. [5] Method according to claim 4, wherein the user-specific information includes a user authorization, and the configuration of the operating system image includes configuring the operating system image with the user authorization and configuring the operating system image with information specific to the machine instance (104). [6] The method of claim 4, further comprising: In response to a request from the cloud orchestrator (170) to stop the machine instance (104), the control stops the machine instance (104) and the controller (150) clears the cache. [7] Method according to claim 4, wherein the provisioning of the vTPM (118, 122) consists in the controller (150) moving the vTPM (118, 122) from another machine instance (104), and the provisioning consists in the controller (150) updating an image of the persistent memory associated with the vTPM (118, 122). [8] Method according to claim 4, wherein providing the vTPM (118, 122) with the instance metadata (140) further comprises setting up at least one access control or access policy for accessing the instance metadata (140). [9] Method according to claim 8, wherein the setup comprises at least one of the following steps: mapping the instance metadata (140) to an index value and sealing the instance metadata (140) with a platform configuration register state. [10] Method according to claim 4, wherein the controller (150) comprises a platform controller, a hypervisor (326) or a baseboard management controller. [11] Method according to claim 4, wherein the machine instance (104) comprises a virtual machine instance (104) or a bare-metal instance. [12] Method according to claim 4, further comprising that, in response to the starting of the machine instance (104), a startup script of the computer platform is executed to access the instance metadata (140) from the vTPM (118, 122) and to configure an operating system image of the machine instance (104) based on the instance metadata (140). [13] The method of claim 4, further comprising: Receiving a request from the cloud orchestrator (170) to start the machine instance (104) by the controller (150), wherein the request includes a reference to a trusted source and the trusted source includes a persistent image containing the instance metadata (140); and In response to the request, the controller (150) instantiates the vTPM (118, 122), deploys the vTPM (118, 122) with the persistent image, and attaches the vTPM (118, 122) to the machine instance (104). [14] A computer system (100), comprising: a controller (150), designed to: to receive a request from a cloud orchestrator (170) to attach a virtual security processor (122) to a machine instance (104), wherein the request includes a reference to a persistent image maintained by a trusted source, and the persistent image contains instance metadata (140), wherein the instance metadata (140) is used to configure an operating system image of a machine instance (104) with user-specific information that enables a user to communicate securely with the machine instance (104); and In response to the request, instantiate the virtual security processor (122) based on the reference and connect the virtual security processor (122) to the machine instance (104), wherein the instantiation of the virtual security processor (122) includes the provisioning of the virtual security processor (122) with the instance metadata (140); a hardware processor; and a memory for storing instructions which, when executed by the hardware processor, cause the hardware processor to: to access the instance metadata (140) from the virtual security processor (122); and to configure the operating system image based on the instance metadata (140) to enable the user to communicate securely with the machine instance (104); the provision of the virtual security processor (122) includes: The controller (150) creates the virtual security processor (122) in response to the controller (150) receiving a request from the cloud orchestrator (170) to create the virtual security processor (122), the request including the instance metadata (140); Generating a persistent memory image based on the instance metadata (140), wherein the persistent memory image corresponds to the virtual security processor (122); Transmission of the persistent storage image to the cloud orchestrator (170) so that the cloud orchestrator (170) retains it as a trusted source; and Creating a cache on the computer platform to store a copy of the persistent storage image. [15] Computer system (100) according to claim 14, wherein the controller (150) comprises at least one hypervisor (326), a platform controller or a baseboard management controller. [16] Computer system (100) according to claim 14, wherein the controller (150) is designed to: Receiving a request from the cloud orchestrator (170) to create the virtual security processor (122), wherein the request includes the instance metadata (140); and in response to the request to create the virtual security processor (122) by the controller (150), creating the persistent image based on the instance metadata (140) and submitting the reference to the cloud orchestrator (170). [17] Computer system (100) according to claim 14, wherein the machine instance (104) comprises a second machine instance, and the controller (150) is designed to: Receiving a request from the cloud orchestrator (170) to move the virtual security processor (122) from a first machine instance (104) to the second machine instance (104), wherein the request includes the reference and instance metadata (140) corresponding to the second machine instance (104); and In response to the request, the controller (150) creates a second persistent image corresponding to the second machine instance (104) and submits the second persistent image to the cloud orchestrator (170) to maintain it in the source of trust, the second persistent image containing the instance metadata (140) corresponding to the second machine instance (104). [18] Computer system (100) according to claim 17, wherein the second persistent image comprises user data (180) that was stored by the first machine instance (104) in the virtual security processor (122).

Images