Persistent virtual secure processor state

Abstract

The invention relates to persistence of virtual secure processor states. In some examples, a security service module that provides a security service for a virtual computing entity requests a key from a processor. A system encrypts a state of a virtual secure processor using a key to produce an encrypted virtual secure processor state, and the system stores the encrypted virtual secure processor state in a persistent storage.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 708,295 (Attorney General’s File No.: P175802PRV), filed October 17, 2024, entitled “Persisting a State of a Virtual Security Processor”, pursuant to 35 USC § 119(e), which is hereby incorporated by reference. Background Technology

[0002] The program can execute in a computing environment. In some cases, the computing environment may be operated by a service provider, and the program may belong to one or more tenants of the computing environment. A tenant may be part of an organization different from the service provider. Attached Figure Description

[0003] Some embodiments of this disclosure are described with reference to the following figures.

[0004] Figure 1 It is a block diagram of a physical platform based on some examples.

[0005] Figure 2 It is a block diagram based on some examples of permission levels.

[0006] Figure 3 This is a flowchart of the process of deriving the initial Virtual Trusted Platform Module (vTPM) state based on some examples.

[0007] Figure 4 This is a flowchart of the vTPM state recovery process based on some examples.

[0008] Figure 5 It is a block diagram based on some examples of storage media storing machine-readable instructions.

[0009] Figure 6 It is a block diagram of a system based on some examples.

[0010] Figure 7 It is a flowchart based on some examples.

[0011] In all the accompanying drawings, the same reference numerals refer to similar but not necessarily identical elements. The drawings are not necessarily drawn to scale, and the size of some parts may be enlarged to illustrate the examples more clearly. Furthermore, the drawings provide examples and / or embodiments consistent with the description; however, the description is not limited to the examples and / or embodiments provided in the drawings. Detailed Implementation

[0012] A Trusted Execution Environment (TEE) provided by a modern central processing unit (CPU) unlocks the ability to execute trusted code (e.g., trusted software or other trusted machine-readable instructions) on a physical platform belonging to an untrusted party, including both hardware and machine-readable instructions. Trusted code includes code whose data is encrypted and protected against unauthorized access. Due to the use of memory encryption, the owner of the physical platform cannot see the running state of the trusted code, including any confidential data that the trusted code may be processing. Other code running on the same physical platform also cannot see the running state of the trusted code. Therefore, the trusted code of a first entity can run in a virtual machine (VM) on the hardware platform with confidence that the running state of the trusted software is protected against unauthorized access by other entities (such as other tenants using the physical platform, hypervisors, service providers operating the physical platform (e.g., cloud service providers (CSPs)), or any other entity). In other words, other entities' access to the running state of the trusted code will not exceed the extent to which the trusted code would run within the first entity's own premises. A VM protected by a TEE is called a Confidential VM (CVM).

[0013] These security guarantees may come with conditions and limitations. While the trusted code's data is protected, achieving persistence of that data so that it can be accessed later can be difficult. The trusted code's data can be encrypted using a data encryption key, which can be stored in protected storage. In some cases, the data encryption key may be stored in the protected storage of the Virtual Trusted Platform Module (vTPM) within the Secure VM Services Module (SVSM) in the CVM. The SVSM in the CVM provides security services to the various entities within the CVM. The data encryption key stored in the vTPM within the SVSM may be lost due to a hypervisor resetting the CVM (e.g., rebooting or shutting it down).

[0014] According to some embodiments of this disclosure, the state of a virtual security processor (such as vTPM) in a security service module (e.g., SVSM) within a CVM (or another type of virtual computing entity) can be persisted by encrypting the state using a processor-generated key (e.g., a key generated by the CPU). The encrypted state of the virtual security processor can be stored in persistent storage. The processor-generated key can be requested by a security service module such as SVSM and used to encrypt the state of the virtual security processor. The state of the virtual security processor may include a data encryption key used to encrypt data of trusted code in the physical platform. When the CVM (or another type of virtual computing entity) is reset (e.g., rebooted or shut down), the encrypted state of the virtual security processor stored in persistent storage is not lost. After resetting the CVM (or another type of virtual computing entity), the encrypted state of the virtual security processor can be obtained and decrypted using the processor-generated key to produce a decrypted state of the virtual security processor. The data encryption key can then be obtained from the decrypted state of the virtual security processor to enable the decryption of encrypted data of trusted code.

[0015] A CVM is a TEE-protected VM, and before saving the encrypted data to the storage system, the CVM can encrypt the trusted program's data using a data encryption key. The ability to retrieve the encrypted data of the trusted code depends on the availability of the data encryption key. If the data encryption key is lost, for example, due to a reset of the CVM in which the trusted code is executed, the encrypted data of the trusted code cannot be recovered. In some examples, the trusted code's data is stored in a storage volume (also called a "storage disk") of the trusted code. A storage volume (or storage disk) can refer to any data container accessible to the trusted code. Note that the storage disk is a virtual storage disk because the trusted code can be executed by a virtual computing entity (e.g., a CVM). In other examples, the trusted code can be executed by another type of virtual computing entity (such as a container).

[0016] As mentioned above, the encryption keys used to encrypt data in trusted code can be stored in a vTPM. In the example of providing trusted code within a CVM, the encryption keys can be stored in a vTPM provided by an SVSM, which is an entity that provides security services to other higher-level entities within the CVM. Since the SVSM also runs within a TEE, the vTPM within the SVSM also suffers from the same problem: the encryption keys stored in the vTPM are lost when the CVM is shut down.

[0017] TPM is an example of a security processor (sometimes called a secure cryptographic processor) that can perform various hardware-based security functions on a physical platform. The security functions of a security processor can include the management and generation of keys and certificates. For example, a security processor can generate cryptographic keys used in secure operations, where the cryptographic keys can include public-private key pairs, which consist of a public key and an associated private key.

[0018] vTPM is a virtual version of TPM. Physical TPM is a discrete chip that runs a combination of software and firmware (machine-readable instructions) on a discrete chip. vTPM is implemented using machine-readable instructions and runs on processing resources (e.g., CPU or another type of processing resource, such as a management controller) shared with other software or firmware that performs other functions.

[0019] The TPM state of a TPM (physical TPM or vTPM) can refer to certain information stored in the TPM's memory area. For example, the TPM state may include a seed used to obtain a key. The seed is an initial value from which other secrets, such as the key, can be derived. The TPM state may also include an encryption key used to encrypt data.

[0020] Making the TPM state persistent means making the TPM state permanent so that it is not lost after a CVM reset. The TPM state can be persistently stored in persistent storage and can be restored after a CVM reset.

[0021] In some examples, the key can be provided to the CVM via an external service called a key broker. The key broker identifies the specific TEE running the CVM and verifies the state of that TEE. If the verification is successful, the key broker delivers the CVM's encryption key to the CVM via a secure channel. Using a key broker solves the problem of lost encryption keys when rebooting the CVM.

[0022] While using a key broker is feasible for some systems, others are built to typically use a TPM (Trusted Product Management) specifically for performing cryptographic operations during operating system initialization or boot. For example, the BitLocker feature in Windows operating systems (OS) uses a key stored in the system's TPM to encrypt the entire system volume. Therefore, for a system running a Windows OS to function properly, a TPM with a persistent state must be provided. After the OS boots, the key broker cannot provide the key—the key must be provided during boot to load the OS from the encrypted system volume.

[0023] Although the use of TPM with persistent state in Windows OS is referenced, in other examples, the persistence of TPM state may be expected in other contexts.

[0024] Figure 1 An example physical platform 100 including CVMs 121 and 122 is shown. In other examples, physical platform 100 may include only one CVM or more than two CVMs. Physical platform 100 may be implemented using one or more computers.

[0025] Each CVM includes a TPM loader, a guest operating system (OS), an OS bootloader, Unified Extensible Firmware Interface (UEFI) code (or more generally, system firmware), and an SVSM. Each CVM defines a corresponding TEE (Trusted Execution Environment) in which the components of the CVM execute. Within the TEE, data in memory is encrypted so that nothing outside the TEE (CVM) can decipher the encrypted data.

[0026] CVM 121 includes a TPM loader 123, a guest OS 125, an OS bootloader (not shown), system firmware 127, and SVSM 129. Similarly, CVM 121 includes a TPM loader 124, a guest OS 126, an OS bootloader (not shown), system firmware 128, and SVSM 130.

[0027] like Figure 1 As further shown, SVSM 129 includes vTPM 131, and SVSM 130 includes vTPM 132. The vTPM in the SVSM has information stored in a memory area of ​​the vTPM; this information is part of the vTPM state (referred to as the "vTPM state"). The vTPM state may contain one or more encryption keys used to encrypt data of one or more trusted codes executing in the CVM. The trusted code in the CVM may include application software in the CVM, system firmware in the CVM, or any other code in the CVM.

[0028] In the example, the vTPM state of vTPM 131 may contain one or more encryption keys for encrypting data of one or more trusted codes executing in CVM 121. Similarly, the vTPM state of vTPM 132 may contain one or more encryption keys for encrypting data of one or more trusted codes executing in CVM 122. The vTPM state of vTPM may further include other information.

[0029] The OS bootloader is used to boot the guest OS in the CVM. The TPM loader performs initialization of the vTPM. For example, TPM loader 123 can initialize vTPM 131 in SVSM 129, and TPM loader 124 can initialize vTPM 132 in SVSM 130. In some examples, the TPM loader can be implemented as a lightweight single-purpose service OS, an initrd program for an initial RAM (Random Access Memory) disk, or a firmware component. A single-purpose service OS is an OS configured to perform the target function, in this case, the initialization of the vTPM. The initrd program can mount a RAM disk (or more generally, a storage volume) as a root filesystem and can run programs (e.g., the vTPM) from the RAM disk. If the TPM loader is implemented as a firmware component, the firmware component can include a UEFI application found in the unencrypted EFI system partition of the storage system. If UEFI secure boot is enabled, the UEFI application will be signed by a key added to a list of trusted keys in the firmware.

[0030] CVMs 121 and 122 run on hypervisor 140. Running CVMs "on" hypervisor 140 means running CVMs within an execution environment created by hypervisor 140. Hypervisor 140 creates and manages VMs, including CVMs 121 and 122. Hypervisor 140 executes on CPU 142, which includes one or more hardware processors. CPU 142 is part of the hardware layer of physical platform 100. In some examples, CPU 142 may be a CPU from Advanced Micro Devices (AMD), an Intel CPU, or a CPU from another vendor.

[0031] The SVSM (e.g., 129 or 130) is designed to have minimal interaction with other entities within the CVM in which it is deployed, and the SVSM has no direct interaction with entities outside the CVM. For example, within the CVM, the SVSM is isolated from the guest OS. The SVSM is also isolated from the host OS running on physical platform 100 and outside the CVM. Furthermore, the SVSM is isolated from the hypervisor 140. Due to this isolation, the SVSM does not provide any network services.

[0032] The CPU can define permission levels, such as the OS kernel permission level (ring 0) and user permission levels (ring 3). The permission level at which a program executes limits its access rights (e.g., which resources the program can access, what interactions it is allowed with those resources, or other access rights). Additionally, the CPU can define additional VM permission levels for the TEE. For example, VM permission levels can include VM permission level 0 and other VM permission levels, such as VM permission levels 1, 2, and 3. In further examples, there can be more than four or fewer VM permission levels. VM permission levels limit the access rights of programs running within a VM. SVSM can run at VM permission level 0, which is the highest VM permission level. SVSM is isolated from and protected by the CVM layer above it (including system firmware, guest OS, virtual compute entities, and other programs). Figure 2 The example permission levels are shown in the figure. Other entities of the CVM can run with lower VM permission levels (e.g., 1, 2, or 3) than VM permission level 0.

[0033] According to some embodiments of this disclosure, the state of a virtual security processor (such as vTPM 131 in CVM 121) can be persisted by encrypting the vTPM state using a processor-generated key (e.g., a key generated by CPU 142). The processor-generated key is provided by CPU 142 in response to a request from SVSM 129 in CVM 121.

[0034] The processor-generated key is in Figure 1 This is represented as Client Key 150. Client Key 150 is sent by CPU 142 to SVSM 129 in CVM 121, bypassing Hypervisor 140. Note that Client Key 150 is part of encrypted data that cannot be deciphered by Hypervisor 140, therefore Hypervisor 140 will not obtain Client Key 150. SVSM 129 uses Client Key 150 as the TPM state key to encrypt the vTPM's memory locations, which are specified as non-volatile by the TPM 2.0 standard. The SVSM uses a certified encryption algorithm to perform this operation to ensure that the vTPM's state is not modified undetected after leaving SVSM 129.

[0035] In response to a request from SVSM 130 in CVM 122, CPU 142 can similarly provide SVSM 130 with a client key 150 to encrypt the vTPM state of vTPM 132 in CVM 122.

[0036] The encrypted state of the security processor (such as the encrypted vTPM state) can be written to persistent storage 144 external to CVM 121. For example, SVSM 129 encrypts the vTPM state of vTPM 131 using client key 150 and sends the encrypted vTPM state (at 102) to client OS 125. Client OS 125 exports the encrypted vTPM state by writing the encrypted vTPM state (at 104) to persistent storage 144. Later (e.g., after resetting CVM 121), TPM loader 123 can import (at 106) the encrypted vTPM state from persistent storage 144 (if available). TPM loader 123 then provides (at 108) the encrypted vTPM state to SVSM 129, which can decrypt the encrypted vTPM state.

[0037] Similar tasks can be performed by SVSM 130 of CVM 122, guest OS 126 and TPM loader 124 to persist the encrypted vTPM state of vTPM 132 to persistent storage device 144, and later load the encrypted vTPM state for SVSM 130 to decrypt.

[0038] In alternative examples, the TPM state key used to encrypt the vTPM state can be based on a combination of client key 150 and other information. For example, the other information may include an external key provided by key broker 146. In some examples, key broker 146 is part of physical platform 100. In other examples, key broker 146 may be located outside of physical platform 100. In examples where key broker 146 is provided, the TPM state key can be obtained based on a combination of client key 150 and an external key from key broker 146.

[0039] The combination of client key 150 and external key can include an XOR operation applied to client key 150 and external key, a hash function applied to client key 150 and external key, or any other combination of client key 150 and external key.

[0040] Key broker 146 may provide external keys to TPM loader 123 (at 110) and / or key broker 146 may provide external keys to guest OS 125 in CVM 121 (at 112). Similarly, key broker 146 may provide external keys to TPM loader 124 and / or guest OS 126 in CVM 122.

[0041] TPM loader 123 can provide an external key (at 114) to SVSM 129 in CVM 121. In some cases, client OS 125 can provide an external key to SVSM 129 (at 116). In CVM 122, TPM loader 124 can provide an external key to SVSM 130, and client OS 125 can also provide an external key to SVSM 130. SVSM 129 or 130 can combine client key 150 and the external key to generate a TPM state key for encrypting the vTPM state.

[0042] In some examples of this disclosure, CVM booting may be performed in two phases: (1) a TPM loading phase performed by the TPM loader, and (2) an OS booting phase performed by the OS bootloader. In other examples, instead of performing two-phase booting of the CVM, the guest OS may send a request to the SVSM to persist the state of the virtual security processor (e.g., vTPM) when it is loaded in the CVM.

[0043] The following discussion will mention an example of using two-stage booting. This discussion refers to CVM 121. A similar task can be performed using other CVM 122 instances. When CVM 121 boots, system firmware 127 boots from the first virtual disk and completes the first stage, then performs a system reset and boots from the second virtual disk to complete the second stage. A "virtual disk" can refer to a storage volume used by a virtual computing entity such as a VM or container.

[0044] In the first phase, TPM loader 123 initializes vTPM 131. TPM loader 123 further initializes CVM 121, preparing for the second phase of booting the guest OS 125 of CVM 121.

[0045] Figure 2 This is a block diagram showing the layout of the hypervisor 140, SVSM 202, and guest OS 204. SVSM 202 and guest OS 204 are part of the CVM, which can be... Figure 1 CVM 121 or 122.

[0046] SVSM 202 runs at VM privilege level 0 (VMPL0), and the guest OS 204 runs at VM privilege level 2 (VMPL2). VM privilege level 2 has lower privileges than VM privilege level 0, and therefore fewer access rights. In other examples, SVSM202 and the guest OS 204 can run at other VM privilege levels, provided that the guest OS 204's VM privilege level is lower than that of SVSM202.

[0047] In some examples, the guest OS 204 can interact with SVSM 202 by issuing a hypercall 206 to SVSM 202. A hypercall is a CPU instruction used to invoke a function running at a higher privilege level. Hypercall 206 invokes the function (on SVSM 202) and switches privilege levels. In other examples, the guest OS 204, at a first VM privilege level, can communicate with an SVSM at a different second VM privilege level using different types of interfaces.

[0048] In some examples, the guest OS 204 has multiple privilege levels, including the OS kernel privilege level (ring 0) and the user privilege level (ring 3). Application software running in the environment defined by the guest OS 204 can execute at the ring 3 privilege level. The kernel of the guest OS 204 executes at the ring 0 privilege level. Application software executing at the ring 3 privilege level can interact with the kernel by issuing system calls, which are system calls used by application software to request services from the kernel.

[0049] In some examples where SVSM 202 is implemented as a single-purpose service OS, SVSM 202 also has multiple permission levels, including ring 3 permission level and ring 0 permission level. In other examples, SVSM 202 is implemented as an initrd program or firmware component, in which case the concepts of ring 3 permission level and ring 0 permission level are not implemented.

[0050] Initial vTPM state export Figure 3 This is a flowchart of an example initial vTPM state export process, involving CPU 142, SVSM 302, TPM loader 304, guest OS 306, persistent storage device 144, and key broker 146. SVSM 302 can be... Figure 1 SVSM129 or 130, TPM loader 304 can be Figure 1 The TPM loader 123 or 124, and the client OS 306 can be Figure 1 The guest OS is 125 or 126. SVSM 302, TPM loader 304, and guest OS 306 are part of CVM 308. In some examples, key broker 146 may be omitted.

[0051] In some examples, the booting of CVM 308 can be performed in two phases: (1) a TPM loading phase (phase 1) performed by TPM loader 304, and (2) an OS booting phase (phase 2) performed by an OS bootloader, which is an OS environment portion that also includes the guest OS 306. In phase 1, a cold boot of CVM 308 is performed (at 310), which causes TPM loader 304 to start. TPM loader 304 checks if its virtual disk has a vTPM state file. If this is the first boot of CVM 308, TPM loader 304 detects (at 312) that an existing vTPM state file does not exist. The vTPM state file (if it exists) indicates that a vTPM state was previously set in vTPM. In response to the detection that an existing vTPM state file does not exist, TPM loader 304 changes (at 313) the firmware boot order to replace the TPM loader's virtual disk with the virtual disk of the guest OS 306, and performs a soft reset of CVM 308. Changing the firmware boot order can be done by updating variables in the CVM 308's system firmware (e.g., EFI variables).

[0052] A soft reset triggers a hot boot of the CVM 308 (at 314), thus initiating Phase 2. In Phase 2, the CVM 308's system firmware (e.g., UEFI firmware) loads the OS bootloader instead of the TPM loader 304. The OS bootloader then boots the guest OS 306.

[0053] SVSM 302 can initialize the vTPM state in SVSM 302, for example, by initializing the vTPM seed. The vTPM provided by SVSM is available to the guest OS 306. The guest OS 306 generates (at 315) a data encryption key (DEK), and uses the DEK to encrypt the storage volume of CVM 308 (at 316). The guest OS 306 saves the DEK (at 318) to the vTPM in SVSM 302. The DEK is saved as part of the vTPM state.

[0054] Note that if the physical platform is rebooted at this time, the vTPM content (vTPM state) will be lost. To resolve this issue, the user (or another entity) can persist the encrypted version of the vTPM state according to some examples in this disclosure (such as by exporting the encrypted vTPM state to persistent storage device 144).

[0055] To persist the encrypted vTPM state, the SVSM driver loaded by the guest OS 306 can issue a vTPM state dump command (at 330) to SVSM 302 (e.g., via a hypercall to SVSM 302). A hypercall is a CPU instruction used to invoke a function that runs at a higher privilege level. For example, the SVSM driver in the guest OS 306 can run at VM privilege level 1, 2, or 3. The vTPM state dump command issued from the guest OS 306 to SVSM 302 invokes a function at a higher privilege level (e.g., VM privilege level 0) on SVSM 302. The hypercall invokes the function (on SVSM 302) and switches the privilege level.

[0056] The vTPM state dump command is a command that requests SVSM 302 to export and persist the vTPM state (or more specifically, the encrypted version of the vTPM state). In response to the vTPM state dump command, SVSM 302 requests (at 332) the client key from CPU 142. CPU 142 obtains the client key from one or more values ​​(at 334), including any one or more combinations of the following: the startup measurement of CVM 308; the cryptographic key associated with CPU 142; the permission level of CVM 308; or other CVM attributes.

[0057] The startup measurement of CVM 308 may include measurements of machine-readable instructions of the CVM image (hash values ​​generated by a cryptographic hash function), which include machine-readable instructions of SVSM 302, vTPM in SVSM 302, and system firmware (e.g., UEFI firmware) in CVM 308 loaded into memory when CVM 308 starts.

[0058] A cryptographic key may include a versioned chip endorsement key (VCEK) used to bind a client key to a specific CPU (e.g., 142). Alternatively, an endorsement key may include a versioned load endorsement key (VLEK) used to bind a client key to a cluster of CPUs. More generally, a cryptographic key may refer to any key used by a CPU (or a group of CPUs) to perform secure operations.

[0059] Setting the client key based on the SVSM 302's permission level (e.g., VM permission level 0) ensures that only the SVSM 302 itself (running at the highest permission level, e.g., VM permission level 0) can regain the client key. Another entity running at a different permission level (e.g., an attacker such as malware) will not be able to obtain the client key.

[0060] CPU 142 sends the client key (at 336) to SVSM 302. In response to receiving the client key from CPU 142, SVSM 302 generates (at 338) a TPM state key for encrypting the vTPM state of the vTPM in SVSM 302.

[0061] In some examples, the generation of the TPM state key involves SVSM 302 using a client key provided by CPU 142 as the TPM state key. In alternative examples, the generation of the TPM state key involves combining the client key provided by CPU 142 with an external key from key broker 146 to generate the TPM state key.

[0062] SVSM 302 encrypts the vTPM state using the TPM state key (at 340), and sends the encrypted vTPM state to the client OS 306 (at 342). In some examples, SVSM 302 returns control of CVM 308 to the client OS 306 while providing the encrypted vTPM state to the client OS 306. The client OS 306 (or another entity) writes the encrypted TPM state to persistent storage 144 (at 344). For example, the encrypted vTPM state is written to a vTPM state file, such as to the virtual disk of the TPM loader 304, or to another storage location that is part of persistent storage 144.

[0063] In the example where the TPM state key is based on a combination of a client key from CPU 142 and an external key from key broker 146, TPM loader 304 obtains the external key from key broker 146 by initiating an interaction with key broker 146. TPM loader 304 requests the external key from key broker 146 (at 322). As part of the request, TPM loader 304 may perform an authentication against key broker 146 to verify its identity. In response to the request, key broker 146 sends the external key to TPM loader 304 (at 324). TPM loader 304 sends the external key to SVSM 302 by issuing a vTPM set key command (e.g., using a hypercall) to SVSM 302 (at 326). The vTPM set key command is a command that requests the use of the external key to generate the TPM state key. SVSM 302 sends an acknowledgment (at 328) to TPM loader 304, confirming that the vTPM set key command has been received and that SVSM 302 will generate the TPM status key using the external key. This acknowledgment may include a message, information element, or any other indicator.

[0064] In some examples, if SVSM 302 receives a vTPM set key command, it combines the client key with the external key to generate the TPM status key. Conversely, if SVSM 302 does not receive a vTPM set key command, it uses the client key as the TPM status key.

[0065] TPM loader 304 or another entity can load system firmware (e.g., UEFI code) from CVM 308, and the system firmware can then load the client OS 306. In some examples, measurements of the system firmware (e.g., hash values ​​based on the system firmware) can be loaded into the vTPM in SVSM 302. Therefore, information associated with the system firmware in CVM 308 can be persisted. In some examples, the information associated with the system firmware is loaded as EFI variables. SVSM 302 can use a firmware state key to encrypt the EFI variables (or more generally, system firmware information), and the encrypted system firmware information can be written to persistent storage device 144 along with the encrypted vTPM state. The encrypted EFI variables can be referred to as the encrypted EFI state. The firmware state key used to encrypt the system firmware information can be based on a client key from CPU 142. For example, the firmware state key can be a client key, or alternatively, the firmware state key can be based on a combination of a client key and other input information, such as information associated with the system firmware.

[0066] Restore vTPM status.

[0067] Figure 4 This is a flowchart of the vTPM state recovery process. During subsequent physical platform resets (e.g., hard reset, reboot, power cycle, etc.), the CVM 308 boot process continues in two phases: Phase 1, which includes a cold boot (at 402); and Phase 2, which includes a hot boot (at 452).

[0068] In Phase 1, SVSM 302 (and the vTPM within SVSM 302) is loaded from scratch. The system firmware in CVM 308 is also loaded from scratch. "Loading from scratch" means starting the process (e.g., SVSM 302, vTPM, and system firmware) to an initial state without using any previous states. The reset of CVM 308 clears any vTPM states in the vTPM; additionally, system firmware information (e.g., EFI variables) is reset to its default state.

[0069] CVM 308 boots TPM loader 304. When TPM loader 304 executes, it detects (at 404) that the vTPM state file exists on its virtual disk. The existence of the vTPM state file indicates the setting of the vTPM state in SVSM 302. The vTPM state file can be stored in a known storage location, such as persistent storage device 144, and TPM loader 304 can check this known storage location to determine if the vTPM state file exists.

[0070] In response to the detection of the existence of the vTPM state file, the TPM loader 304 obtains (at 406) the encrypted vTPM state previously stored by the client OS 306 in persistent storage 144. Figure 3 (At position 344). After obtaining the encrypted vTPM state, the TPM loader 304 issues a vTPM state load command to the SVSM 302 (at position 420) via a hypercall, for example. For example, the TPM loader 304 can provide the contents of the encrypted vTPM state file in a request buffer accessible to the SVSM 302.

[0071] In response to the vTPM state load command, SVSM 302 requests the client key from CPU 142. CPU 142 then retrieves the client key from the CPU. Figure 3 The client key is obtained at position 334 using one or more values ​​that are the same as the client key used at position 424. Then, CPU 142 sends the client key to SVSM 302 at position 426.

[0072] In response to receiving a client key from CPU 142, SVSM 302 generates (at 428) a TPM state key for decrypting the encrypted vTPM state. In some examples, TPM state key generation involves SVSM 302 using the client key provided by CPU 142 as the TPM state key. In alternative examples, TPM state key generation involves combining the client key provided by CPU 142 with an external key from key broker 146 to generate the TPM state key. SVSM 302 can regenerate and... Figure 3 The same TPM state key is used when encrypting and storing vTPM state because the TEE of CVM 308 has not changed.

[0073] SVSM 302 decrypts the encrypted vTPM state using the TPM state key (at 430). SVSM 302 (at 432) loads the decrypted vTPM state into the vTPM of SVSM 302, which includes writing the decrypted vTPM state to the vTPM's memory. SVSM 302 may clear the vTPM's memory before loading the decrypted vTPM state into the vTPM, and after clearing the vTPM's memory, write the decrypted vTPM state to the vTPM's memory. The decrypted vTPM state loaded into the vTPM's memory includes the DEK used by the guest OS 306 to encrypt data against trusted code in CVM 308. The decrypted vTPM state also includes... Figure 3 Export other information about vTPM when the vTPM status is displayed.

[0074] In some examples, SVSM can obtain the public and private key portions of a temporary endorsement key (e-EK) belonging to vTPM and randomly generated upon SVSM 302 startup. The e-EK will be used later. The e-EK is a temporary endorsement key with a relatively short lifespan, such as as long as CVM 308 remains operational. Closing or resetting CVM 308 may result in the loss of the e-EK. It should be noted that the e-EK is different from the long-term EK stored by vTPM for verifying vTPM. The long-term EK is... Figure 3 Part of the persistent vTPM state.

[0075] SVSM 302 loads the e-EK (at position 434) into a predefined memory area of ​​the vTPM's memory. The public and private key portions of the e-EK include the e-EK public and private keys that form a key pair. If a previous e-EK was previously stored in the predefined memory area, the new e-EK overwrites the previous one. Loading the e-EK into the vTPM does not overwrite the vTPM's long-term EK. The e-EK is an additional key that complements the long-term EK.

[0076] Figure 1 The management program 140 can launch multiple CVMs from the same CVM image (code for CVM 308). To distinguish between the multiple CVMs, a corresponding e-EK is assigned to each corresponding CVM when it starts. Different e-EKs are assigned to different CVMs. SVSM 302 writes the e-EK to the vTPM state of the CVM. The e-EK is used for authentication of the CVM. In some examples, SVSM 302 loads the private key portion of the e-EK (e-EK private key) into... This allows the vTPM to later prove ownership of the e-EK, which is unique for each CVM instance. More generally, during the recovery process, the loaded vTPM state retains temporary data (e.g., the e-EK) in the decrypted vTPM state. Each boot of SVSM loads a new e-EK into the vTPM.

[0077] Next, before returning control to the TPM loader 304, the SVSM 302 utilizes the e-EK to extend (at 436) the specific location of the non-volatile memory in the vTPM. The e-EK is measured, for example, hashed using a hash function such as a cryptographic hash function, and the measured value of the e-EK (e.g., the hash value generated by the hash function) is extended into the non-volatile memory in the vTPM. Representations of the previous e-EK and the new e-EK are persisted in a persistent state through a rolling hash (extension operation). The extension operation can compute a hash based on the new e-EK and any previous e-EK.

[0078] SVSM 302 sends an acknowledgment (at 438) to the client OS 306, confirming that the vTPM state loading command has been received and that SVSM 302 has decrypted the encrypted vTPM state.

[0079] In response to this confirmation, TPM loader 304 changes (at 440) the firmware boot order to replace the TPM loader's virtual disk with the virtual disk of the guest OS 306, and performs a soft reset of CVM 308. Changing the firmware boot order can be done by updating system firmware variables (e.g., EFI variables).

[0080] A soft reset triggers a hot boot of the CVM 308 (at 452), thus initiating Phase 2. In Phase 2, the CVM 308's system firmware (e.g., UEFI firmware) loads the OS bootloader instead of the TPM loader 304. The OS bootloader then boots the guest OS 306.

[0081] During the boot process of the guest OS 306, the guest OS 306 can write boot events to the vTPM's Platform Configuration Register (PCR) and, if enabled, use the DEK released from the vTPM to decrypt blocks read from the virtual disk. The DEK is part of the vTPM state decrypted by SVSM 302. The guest OS 306 requests the DEK from the vTPM in SVSM 302 (at 454). In response, SVSM 302 sends the DEK to the guest OS 306 (at 456). The guest OS 306 uses the DEK to decrypt data in the code in CVM 308 (at 458). For example, the guest OS 306 can decrypt storage volumes (such as boot volumes containing boot code and data used to boot CVM 308). The DEK can also be used to decrypt other data in any code within CVM 308.

[0082] In the example where the TPM state key is based on a combination of a client key from CPU 142 and an external key from key broker 146, processes including tasks 412, 414, 416, and 418 are executed. Tasks 412, 414, 416, and 418 are similar to... Figure 1 The corresponding tasks are 322, 324, 326 and 328.

[0083] Proof and remote verification TPM-based verification can be performed after the customer OS 306 boots. TPM-based verification can be performed to ensure the correct expected OS installation is performed upon starting CVM 308. When CVM 308 is first started, CVM boot measurements can be performed only on memory pages up to and including the system firmware (e.g., UEFI firmware). CVM boot measurements include measuring the aforementioned memory pages of CVM 308 (e.g., applying hash functions to these memory pages). CVM boot measurements may be insufficient to detect certain attacks performed by authorized entities in physical platform 100. "Authorized entity" refers to physical platform 100 (… Figure 1 An entity that has higher privileges than other entities in physical platform 100.

[0084] For example, management procedure 140 ( Figure 1 If another authorized entity is compromised, it can maliciously clone the CVM, allowing the compromised entity to access the restored vTPM state of the cloned CVM. The restored vTPM state in the cloned CVM can then be used for unauthorized purposes.

[0085] According to some examples of this disclosure, the verification entity (e.g., a verification server or any other entity) can obtain a TEE proof report, which is contained in the e-EK generated during the last cold reset of the CVM. The software within the CVM requests the TEE proof report from the TEE and presents it to the verification entity. The TEE generates a report for the CVM, including information such as SVSM measurements.

[0086] The verification entity can be an entity within physical platform 100 or an entity outside physical platform 100. The verification entity compares the e-EK with the e-EK stored in the non-volatile memory of the vTPM. Furthermore, because the e-EK is recorded in the vTPM using an extension operation, past e-EK records are also retained, making it possible to detect attacks where an compromised privileged entity replaces the current TPM state on the CVM's virtual disk with an older version. As described above, the extension operation can compute a hash value based on the current e-EK and any previous e-EK. If the current e-EK is replaced with a different e-EK (such as a previous e-EK), the computed hash value will not match.

[0087] Pre-guided proof In some examples, the TPM loader 304 can also perform proofs on the CVM at CVM startup. The TPM loader 304 can control the recovery of the vTPM state from the CVM based on the proof result. For example, if the verification entity successfully verifies the e-EK in the vTPM, the verification entity can instruct the key broker 146 to release the verification key to the TPM loader 304. For example, the verification key could be... Figure 3 or Figure 4 The external key. The key can be set by issuing a vTPM command (similar to...). Figure 3 326 places or Figure 4 The command issued at point 416 in the command provides the verification key to the SVSM 302. Note that additional vTPM setting key commands will not be accepted until the next hard reset of the physical platform 100.

[0088] Subsequently, in response to a vTPM state dump command (e.g., similar to in...), Figure 3 The command issued at position 330 in the command prompt) or the vTPM status loading command (e.g., similar to the one in the command prompt) Figure 4 (As indicated by the command issued at position 420 in the command), SVSM 302 can combine the authentication key with the client key from CPU 142. This combination may include an XOR operation applied to the client key and the authentication key, a hash function applied to the client key and the authentication key, or any other combination of the client key and the authentication key.

[0089] If the CVM is running on a CPU that does not support generating client keys, SVSM 302 can request an authentication key, and in this case, it will use the authentication key alone as the TPM status key.

[0090] Further examples Figure 5 This is a block diagram of a non-transitory machine-readable or computer-readable storage medium 500 that stores machine-readable instructions that, when executed, cause the system to perform various tasks. An example of this system is... Figure 1 The physical platform 100.

[0091] Machine-readable instructions include processor key request instructions 502, which are used by a security service module providing security services for a virtual computing entity to request a key from the processor. An example of a processor is... Figure 1 CPU142. An example of a security service module is... Figure 1 SVSM 129 or 130 or Figure 3 or Figure 4 The SVSM 302 security service module provides security services for VMs. A "security service module" refers to a module implemented with machine-readable instructions, such as a VM (e.g., Figure 1 Security services are performed by virtual computing entities such as CVM 121 or 122, or by another type of virtual computing entity such as containers. The security service module can be part of a virtual computing entity such as a CVM.

[0092] Machine-readable instructions include virtual security processor state encryption instructions 504, which are used to encrypt the state of the virtual security processor using a key to produce an encrypted virtual security processor state. For example, the virtual security processor includes a vTPM, and the encrypted virtual security processor state is the encrypted vTPM state.

[0093] Machine-readable instructions include encrypted virtual security processor state persistence instructions 506, which are used to store the encrypted virtual security processor state in persistent storage (e.g., ...). Figure 1 In section 144), the persistent, encrypted virtual security processor state becomes available later (e.g., after a virtual computing entity such as CVM has been reset), allowing the virtual security processor state to be restored for use.

[0094] In some examples, the virtual security processor state includes data encryption keys used to encrypt data in trusted code within the system. For instance, the trusted code might be executable within the CVM.

[0095] In some examples, the data of trusted code encrypted with an encryption key includes system firmware information of the system firmware running in the CVM.

[0096] In some examples, system firmware information encrypted with an encryption key includes EFI variables of UEFI code.

[0097] In some examples, the security service module executes at a first privilege level (e.g., VM privilege level 0) that is higher than (i.e., has higher privileges than) the OS kernel's privilege level (e.g., VM privilege level 1, 2, or 3).

[0098] In some examples, the first privilege level and the OS kernel privilege level are the privilege levels in the CVM's TEE.

[0099] In some examples, a module (e.g., a driver) associated with the CVM's OS can issue a hypercall to a security service module, which invokes a function of the security service module while switching the privilege level to a higher privilege level of the CVM.

[0100] In some examples, the key from the processor is the primary key. The security service module can receive the key from a key broker (e.g., Figure 1 The security service module combines the second key with the first key to generate an encryption key, and uses the encryption key to encrypt the state of the virtual security processor.

[0101] In some examples, the key is obtained by the processor based on one or more of the following: information in the program image of the CVM, or measurements of instructions from the security service module and virtual security processor in the CVM, or a cryptographic key associated with the processor (e.g., VCEK or VLEK), or the permission level at which the CVM is executed.

[0102] In some examples, machine-readable instructions can issue a request to load the state of the virtual security processor in response to a reset of the virtual computing entity. The security service module can obtain a key from the processor and decrypt the encrypted virtual security processor state to produce a decrypted virtual security processor state.

[0103] Figure 6 This is a block diagram of a system 600 that can be implemented using one or more computers. System 600 includes a processor 602 (or multiple processors). The processor may include a microprocessor, the core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or other hardware processing circuitry.

[0104] System 600 includes storage medium 604 that stores machine-readable instructions that can be executed on processor 602 to perform various tasks. Machine-readable instructions executable on a hardware processor may refer to instructions that can be executed on a single hardware processor or instructions that can be executed on multiple hardware processors.

[0105] The machine-readable instructions in storage medium 604 include CVM execution instructions 606 for executing a CVM, which includes a security service module at a first VM privilege level and a guest OS at a second VM privilege level lower than the first VM privilege level. The security service module includes a virtual security processor, such as a vTPM.

[0106] The machine-readable instructions in storage medium 604 include processor key command issuance instructions 608, which are used by the guest OS to issue commands to the security service module to obtain processor keys from the processor. For example, this command could be... Figure 3 The vTPM status dump command was sent at position 330.

[0107] The machine-readable instructions in storage medium 604 include state key generation instructions 610, which are used by the security service module to generate state keys based on processor keys. The state key can be the processor key, or a combination of the processor key and another key.

[0108] The machine-readable instructions in storage medium 604 include virtual security processor state encryption instructions 612, which are used by the security service module to encrypt the state of the virtual security processor using a state key.

[0109] The machine-readable instructions in storage medium 604 include cryptographic state persistence instructions 614, which are used to persist the cryptographic state of the virtual security processor in a persistent storage device.

[0110] Figure 7 This is a flowchart of process 700, which can be executed on a physical platform implemented using one or more computers.

[0111] Process 700 includes: the security service module, which provides security services for virtual computing entities such as CVM, requesting a key from the processor (at 702). The key may be a client key, as discussed further above.

[0112] Process 700 includes: encrypting the state of the virtual security processor in the virtual computing entity using a key (at 704) to produce an encrypted virtual security processor state. In some examples, the key from the processor can be used as the encryption key for encrypting the virtual security processor state. In other examples, the key from the processor can be combined with (e.g., from...) Figure 1 Another key combination (from key agent 146 in the middle) is used to generate an encryption key for encrypting the virtual security processor state.

[0113] Process 700 includes: storing the encrypted virtual security processor state (at 706) in persistent storage. Storing the encrypted virtual security processor state makes the virtual security processor state persistent, making it available after the virtual computing entity is reset.

[0114] Procedure 700 includes: after the virtual computing entity is reset, initiating (at 708) the virtual security processor loader. An example of a virtual security processor loader is... Figure 1 TPM loader 123 or 124 or Figure 3 or Figure 4 TPM loader 304.

[0115] Process 700 includes: a request issued by the virtual security processor loader (at 710) for loading the state of the virtual security processor. For example, the request could be... Figure 4 The vTPM status loading command.

[0116] Process 700 includes: the security service module obtaining the key from the processor (at 712).

[0117] Process 700 includes: decrypting the encrypted virtual security processor state (at 714) to produce a decrypted virtual security processor state. Information from the decrypted virtual security processor state can be used, for example, to encrypt data in trusted code.

[0118] In some examples, process 700 includes loading temporary data and retaining a representation of the temporary data as part of loading the state of the virtual security processor. For example, the temporary data may include the e-EK of the vTPM.

[0119] In an example with multiple CVMs, the multiple CVMs can include different e-EKs. Multiple CVMs can be created from the same CVM image.

[0120] As used herein, a “persistent storage device” can be implemented using one or more storage devices that retain stored data even in the event of a power outage in the system including the persistent storage device. Examples of storage devices may include any one or more combinations of disk-based storage devices, solid-state drives, or other types of storage devices.

[0121] Figure 3 , Figure 4 and Figure 7 The corresponding order of tasks is shown. In other examples, tasks can be performed in a different order, some tasks can be omitted, and other tasks can be added.

[0122] Storage media that store machine-readable instructions (e.g., Figure 5 500 or Figure 6 604) may include any one or more combinations of the following: semiconductor storage devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory; disks, such as fixed disks, floppy disks, and removable disks; another magnetic medium, including magnetic tape; optical media, such as optical discs (CDs) or digital video discs (DVDs); or other types of storage devices. Note that the instructions discussed above may be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system having potentially multiple nodes. Such one or more computer-readable or machine-readable storage media are considered part of an article (or article of manufacture). An article or article of manufacture may refer to any single or multiple manufactured components. One or more storage media may be located in a machine that executes the machine-readable instructions or at a remote site from which the machine-readable instructions can be downloaded via a network for execution.

[0123] In this disclosure, unless the context clearly indicates otherwise, the terms “a,” “an,” or “the” are intended to include the plural form as well. Similarly, when used in this disclosure, the terms “includes / including / comprises / comprising” or “have / having” indicate the presence of the said element but do not exclude the presence or addition of other elements.

[0124] In the foregoing description, numerous details have been set forth to facilitate understanding of the subject matter disclosed herein. However, embodiments may be practiced without some of these details. Other embodiments may include modifications and variations of the details discussed above. The appended claims are intended to cover such modifications and variations.

Claims

1. A non-transitory machine-readable storage medium, comprising instructions that, when executed, cause a system to perform the following operations: The security service module, which provides security services for virtual computing entities, requests the key from the processor. The state of the virtual security processor is encrypted using the key to produce an encrypted virtual security processor state; and The encrypted virtual security processor state is stored in persistent storage.

2. The non-transitory machine-readable storage medium as described in claim 1, wherein, The virtual computing entity includes a confidential virtual machine (CVM), and the security service module includes a secure virtual machine (VM) service module (SVSM) that provides security services for the CVM.

3. The non-transitory machine-readable storage medium as described in claim 1, wherein, The state of the virtual security processor includes the state of the virtual trusted platform module (vTPM).

4. The non-transitory machine-readable storage medium as described in claim 1, wherein, The state of the virtual security processor includes an encryption key for encrypting data in trusted code within the system.

5. The non-transitory machine-readable storage medium as described in claim 4, wherein, The trusted code is executed in a confidential virtual machine (CVM).

6. The non-transitory machine-readable storage medium as described in claim 5, wherein, The data of the trusted code encrypted using the encryption key includes system firmware information of the system firmware running in the CVM.

7. The non-transitory machine-readable storage medium as described in claim 6, wherein, The system firmware information encrypted using the encryption key includes Extensible Firmware Interface (EFI) variables of Universal Extensible Firmware Interface (UEFI) code.

8. The non-transitory machine-readable storage medium as described in claim 1, wherein, The security service module executes at the first privilege level, which is higher than the privilege level of the operating system (OS) kernel.

9. The non-transitory machine-readable storage medium as described in claim 8, wherein, The first permission level and the permission level of the OS kernel are permission levels in the Trusted Execution Environment (TEE) of the Confidential VM (CVM).

10. The non-transitory machine-readable storage medium as described in claim 9, wherein, The first permission level is VM permission level 0.

11. The non-transitory machine-readable storage medium of claim 10, wherein, The CVM includes another entity running in the CVM with a VM permission level lower than VM permission level 0.

12. The non-transitory machine-readable storage medium as claimed in claim 1, wherein, The security service module is part of a confidential virtual machine (CVM), and the instructions, when executed, cause the system to: A hypercall is issued by a module associated with the operating system (OS) of the CVM to the security service module, wherein the hypercall invokes a function of the security service module and switches the privilege level to a higher privilege level of the CVM.

13. The non-transitory machine-readable storage medium as claimed in claim 1, wherein, The key from the processor is a first key, and wherein the instructions, when executed, cause the system to: The security service module receives the second key provided by the key broker; The security service module combines the second key with the first key to generate an encryption key. The encryption key is used to encrypt the state of the virtual security processor.

14. The non-transitory machine-readable storage medium of claim 1, wherein, The key is obtained by the processor based on one or more of the following: Information in the program image of the Confidential Virtual Machine (CVM), or The measured values ​​of the instructions of the security service module and the virtual security processor, or The cryptographic key associated with the processor, or The permission level executed by the CVM.

15. The non-transitory machine-readable storage medium as claimed in claim 1, wherein, When the instruction is executed, it causes the system to perform the following operations: A request is issued to load the state of the virtual security processor in response to the reset of the virtual computing entity; The security service module obtains the key from the processor; as well as The encrypted virtual security processor state is decrypted to generate a decrypted virtual security processor state.

16. A method comprising: The security service module, which provides security services for virtual computing entities, requests the key from the processor. The key is used to encrypt the state of the virtual security processor in the virtual computing entity to produce an encrypted virtual security processor state. The encrypted virtual security processor state is stored in a persistent storage device; After resetting the virtual computing entity including the virtual security processor, the virtual security processor loader is started; The virtual security processor loader issues a request to load the state of the virtual security processor; The security service module obtains the key from the processor; as well as The encrypted virtual security processor state is decrypted to generate a decrypted virtual security processor state.

17. The method of claim 16, further comprising: Load temporary data and retain a representation of the temporary data as part of the loading of the state of the virtual security processor.

18. The method of claim 17, wherein, The virtual computing entity includes a confidential virtual machine (CVM), wherein the loaded temporary data includes a temporary endorsement key that is unique to the CVM, and wherein different temporary endorsement keys are assigned to different CVMs created from the same CVM image.

19. A system comprising: processor; A non-transitory storage medium storing instructions that can be executed on the processor to perform the following operations: Execute a confidential virtual machine (CVM), the confidential virtual machine including a security service module at a first VM privilege level and a guest operating system (OS) at a second VM privilege level with privileges lower than the first VM privilege level, wherein the security service module includes a virtual security processor. The client OS issues a command to the security service module to obtain the processor key from the processor. The security service module generates a status key based on the processor key. The security service module uses the state key to encrypt the state of the virtual security processor, and The encrypted state of the virtual security processor is persisted in a persistent storage device.

20. The system of claim 19, wherein, The command is issued to the security service module using a hypercall to trigger a permission level switch from the second VM permission level to the first VM permission level.

Images