Virtual machine error recovery method and system for trusted execution environment

Abstract

The application provides a virtual machine error recovery method and system suitable for a trusted execution environment, which first collects parameters and return values of system calls of an application in a normal running process of the application, and arranges the parameters and return values into a form of a system call log, and the log only contains system calls which will modify states. Then, a virtual machine monitor monitors whether the virtual machine is normally running by using a heartbeat packet detection method. If the virtual machine monitor finds that the virtual machine does not respond to the heartbeat packet detection within a certain time, it is considered that an abnormality occurs in the execution of the virtual machine, and an error recovery process is immediately started. In the error recovery process, a recovery module running in the trusted execution environment and the virtual machine monitor work cooperatively, and a new virtual machine is reconstructed into a state consistent with the application by replaying the log. Compared with the prior art, the application has the characteristics of safety, high efficiency, high success rate and easy deployment.

Description

Technical Field

[0001] This invention relates to the technical field of highly available virtual machines, specifically to a virtual machine error recovery method and system suitable for trusted execution environments, and more particularly to a fast virtual machine error recovery method and apparatus suitable for trusted execution environments. Background Technology

[0002] Among cloud computing technologies, Trusted Execution Environment (TEE) technology, which provides tenants with a secure and confidential computing environment, is a crucial one. Based on specific hardware protection and isolation mechanisms, TEE encapsulates these mechanisms at the software level, enabling the protection of the integrity and confidentiality of tenant application data and runtime state. This prevents tenant data and state from being stolen or tampered with by untrusted cloud platforms and third parties. In recent years, a series of TEE solutions, spearheaded by Intel's Software Protection Extensions, have flourished. Currently, TEE is deployed on public cloud platforms such as Alibaba Cloud, Amazon Web Services, Microsoft Azure, and Google Cloud, and has been widely applied in areas such as security sandboxes, databases, blockchain, and artificial intelligence.

[0003] From a system availability perspective, existing Trusted Execution Environment (TEE) solutions do not consider availability issues, and traditional fault tolerance mechanisms are not suitable for direct application in TEE scenarios. Currently, fault tolerance mechanisms can be divided into three categories: The first category is the replicated state machine, which replicates the application state multiple times, running them on different physical machines to avoid the entire application becoming unavailable due to the unavailability of a single physical machine. While replicated state machines achieve high availability through redundant machine resources, their drawback is the potential for fork attacks. Because application state replication is allowed, untrusted cloud platforms can manipulate the application's state, affecting the security of the TEE. The second category is checkpoint rollback, which periodically saves application data and state to specific checkpoints, enabling rapid rollback to the latest checkpoint to recover from errors without restarting the application. While checkpoint rollback maintains application service continuity using continuously saved checkpoints, its drawback is the potential for rollback attacks. Untrusted cloud platforms can use checkpoint rollback to revert the application to an outdated state, similarly compromising the security of the TEE. The third type of mechanism is microrebooting, which avoids restarting the entire system by restarting only the faulty software component. While microrebooting achieves rapid recovery by minimizing the scope of error recovery, its drawback is that it requires the cloud platform to be able to check the application's state to ensure that the state of the restarted component is consistent with the application's state. Trusted Execution Environments (TEEs) protect the confidentiality of application data and state, therefore cloud platforms cannot access the application state, limiting the deployment of microrebooting in TEEs.

[0004] Therefore, a new technical solution is needed to improve the above-mentioned technical problems. Summary of the Invention

[0005] In view of the deficiencies in the prior art, the purpose of this invention is to provide a virtual machine error recovery method and system suitable for trusted execution environments.

[0006] According to the present invention, a virtual machine error recovery method suitable for a trusted execution environment is provided, the method comprising the following steps:

[0007] Step S1: The virtual machine monitor starts a new virtual machine instance;

[0008] Step S2: The virtual machine monitor remaps the secure memory mapping of the trusted execution environment to the new virtual machine instance and enters the recovery module within the trusted execution environment;

[0009] Step S3: The recovery module marks all system calls in the log as "not executed";

[0010] Step S4: If there are "unexecuted" system calls in the log, proceed to step S5; otherwise, proceed to step S8.

[0011] Step S5: The recovery module reads and executes the earliest "unexecuted" system call;

[0012] Step S6: The recovery module compares the return value of the system call executed in step S5 with the return value recorded in the log. If they are the same, proceed to step S7; otherwise, notify the virtual machine monitor that the recovery has failed, and then proceed to step S1.

[0013] Step S7: The recovery module marks the system call in step S6 as "executed" and executes step S4;

[0014] Step S8: The recovery module resumes the execution of all application threads, and the virtual machine error recovery process is complete.

[0015] Preferably, in step S1, the virtual machine monitor uses a virtual machine snapshot to launch a new virtual machine instance.

[0016] Preferably, the memory mapping in step S2 is consistent with the memory mapping in the virtual machine instance before the error.

[0017] Preferably, the tagging record in step S3 is recorded in the log, and the tagging record is stored in the secure memory of the trusted execution environment.

[0018] Preferably, the parameter of the earliest "unexecuted" system call executed in step S5 is a log stored in secure memory.

[0019] Preferably, in step S6, the virtual machine monitor is used to call and notify the virtual machine monitor.

[0020] The present invention also provides a virtual machine error recovery system suitable for trusted execution environments, the system comprising the following modules:

[0021] Module M1: The Virtual Machine Monitor starts a new virtual machine instance;

[0022] Module M2: The Virtual Machine Monitor remaps the secure memory mapping of the Trusted Execution Environment to a new virtual machine instance, entering the recovery module within the Trusted Execution Environment;

[0023] Module M3: The recovery module marks all system calls in the log as "not executed";

[0024] Module M4: If there are "unexecuted" system calls in the log, execute module M5; otherwise, execute module M8.

[0025] Module M5: The recovery module reads and executes the earliest "unexecuted" system call;

[0026] Module M6: The recovery module compares the return value of the system call executed in module M5 with the return value recorded in the log. If they are the same, module M7 is executed; otherwise, the virtual machine monitor is notified that the recovery has failed, and then module M1 is entered.

[0027] Module M7: The recovery module marks the system call in module M6 as "executed" and executes module M4;

[0028] Module M8: The recovery module resumes the execution of all application threads, and the virtual machine error recovery process is complete.

[0029] Preferably, in module M1, the virtual machine monitor uses a virtual machine snapshot to launch a new virtual machine instance;

[0030] The memory mapping in module M2 is consistent with the memory mapping in the virtual machine instance before the error.

[0031] Preferably, the tag records in module M3 are recorded in a log, and the tag records are stored in the secure memory of the trusted execution environment;

[0032] The parameters of the earliest "not executed" system call executed in module M5 are logs stored in secure memory.

[0033] Preferably, module M6 uses the virtual machine monitor to call and notify the virtual machine monitor.

[0034] Compared with the prior art, the present invention has the following beneficial effects:

[0035] 1. Compared with the solution of restarting the application or rolling back the application state, the method of the present invention does not require changing the state of the trusted execution environment, eliminating the possibility of fork attacks and rollback attacks, and ensuring the security of the trusted execution environment.

[0036] 2. This invention uses the method of application-initiated log replay to reconstruct the state of the virtual machine operating system kernel, ensuring the correctness of error recovery and the consistency of the state inside and outside the trusted execution environment;

[0037] 3. This invention uses the secure memory of a trusted execution environment to store application logs, avoiding malicious tampering of logs by untrusted virtual machines or unintentional writing of logs when errors occur, ensuring the accuracy of log content and improving the success rate of error recovery.

[0038] 4. The application log of this invention adopts a method that only records system calls that modify the state, and regularly cleans up and removes invalid and redundant log entries, reducing the performance overhead of log recording and reducing the time required for error recovery, thus having the characteristics of low latency;

[0039] 5. This invention uses a method of inserting an error recovery module between the application and the operating system kernel, which does not require modification of either the application or the kernel. It is easy to deploy to existing systems and can be applied to a variety of trusted execution environment technologies.

[0040] 6. The present invention adopts a design in which the error recovery module and the virtual machine monitor work together in the trusted execution environment, which not only solves the difficulty of the virtual machine monitor being unable to access the application state, but also maintains the security of the trusted execution environment. Attached Figure Description

[0041] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0042] Figure 1 This is a flowchart of the error recovery software of the present invention;

[0043] Figure 2 This is a schematic diagram of the hardware and software device structure of the present invention. Detailed Implementation

[0044] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0045] Example 1:

[0046] According to the present invention, a virtual machine error recovery method suitable for a trusted execution environment is provided, the method comprising the following steps:

[0047] Step S1: The Virtual Machine Monitor starts a new virtual machine instance; the Virtual Machine Monitor starts a new virtual machine instance using a virtual machine snapshot.

[0048] Step S2: The virtual machine monitor remaps the secure memory mapping of the Trusted Execution Environment to the new virtual machine instance and enters the recovery module within the Trusted Execution Environment; the memory mapping is consistent with the memory mapping in the virtual machine instance before the error.

[0049] Step S3: The recovery module marks all system calls in the log as "not executed"; the marking is recorded in the log and stored in the secure memory of the trusted execution environment.

[0050] Step S4: If there are "unexecuted" system calls in the log, proceed to step S5; otherwise, proceed to step S8.

[0051] Step S5: The recovery module reads and executes the earliest "unexecuted" system call; the parameter for executing the earliest "unexecuted" system call is the log stored in safe memory.

[0052] Step S6: The recovery module compares the return value of the system call executed in step S5 with the return value recorded in the log. If they are the same, proceed to step S7; otherwise, notify the virtual machine monitor that the recovery has failed and then proceed to step S1; use the virtual machine monitor to call and notify the virtual machine monitor.

[0053] Step S7: The recovery module marks the system call in step S6 as "executed" and executes step S4;

[0054] Step S8: The recovery module resumes the execution of all application threads, and the virtual machine error recovery process is complete.

[0055] Example 2:

[0056] Example 2 is a preferred embodiment of Example 1, and is used to illustrate the present invention in more detail.

[0057] This invention also provides a virtual machine error recovery system suitable for trusted execution environments, the system comprising the following modules:

[0058] Module M1: The Virtual Machine Monitor starts a new virtual machine instance; the Virtual Machine Monitor uses a virtual machine snapshot to start a new virtual machine instance.

[0059] Module M2: The Virtual Machine Monitor remaps the secure memory mapping of the Trusted Execution Environment (TEE) to a new virtual machine instance, entering the recovery module within the TEE; the memory mapping is consistent with the memory mapping in the virtual machine instance before the error.

[0060] Module M3: The recovery module marks all system calls in the log as "not executed"; the marking is recorded in the log and stored in the secure memory of the trusted execution environment;

[0061] Module M4: If there are "unexecuted" system calls in the log, execute module M5; otherwise, execute module M8.

[0062] Module M5: The recovery module reads and executes the earliest "unexecuted" system call; the parameter for executing the earliest "unexecuted" system call is the log stored in safe memory.

[0063] Module M6: The recovery module compares the return value of the system call executed in module M5 with the return value recorded in the log. If they are the same, module M7 is executed; otherwise, the virtual machine monitor is notified that the recovery has failed, and then module M1 is entered; the virtual machine monitor is used to call and notify the virtual machine monitor.

[0064] Module M7: The recovery module marks the system call in module M6 as "executed" and executes module M4;

[0065] Module M8: The recovery module resumes the execution of all application threads, and the virtual machine error recovery process is complete.

[0066] Example 3:

[0067] Example 3 is a preferred example of Example 1, and is used to illustrate the present invention in more detail.

[0068] The purpose of this invention is to overcome the shortcomings of the existing technology and provide a method and apparatus for fast error recovery of virtual machines that support trusted execution environments.

[0069] The objective of this invention can be achieved through the following technical solutions:

[0070] A fast error recovery method for virtual machines suitable for trusted execution environments (TEEs) is disclosed. This method first collects the parameters and return values ​​of system calls during normal application operation and organizes them into a system call log. The log only contains system calls that modify the state. The key feature is that the log is stored in secure memory protected by the TEE, ensuring that it is not tampered with by untrusted virtual machines and is unaffected by virtual machine errors. Then, the virtual machine monitor monitors the virtual machine's normal operation using heartbeat detection. If the virtual machine monitor detects that the virtual machine does not respond to the heartbeat detection within a certain period, it considers the virtual machine's execution to be abnormal and immediately initiates the error recovery process. During the error recovery process, the recovery module running within the TEE and the virtual machine monitor work together to reconstruct the virtual machine to a state consistent with the application by replaying the logs. The error recovery process includes the following steps:

[0071] Step (1): The virtual machine monitor starts a new virtual machine instance;

[0072] Step (2): The virtual machine monitor remaps the secure memory of the trusted execution environment to the new virtual machine instance, and then enters the recovery module within the trusted execution environment;

[0073] Step (3): The recovery module marks all system calls in the log as "not executed";

[0074] Step (4): If there are "unexecuted" system calls in the log, proceed to step (5); otherwise, proceed to step (8).

[0075] Step (5): The recovery module reads and executes the earliest "unexecuted" system call;

[0076] Step (6): The recovery module compares the return value of the system call executed in step (5) with the return value recorded in the log. If they are the same, it executes step (7); otherwise, it notifies the virtual machine monitor that the recovery has failed and then proceeds to step (1).

[0077] Step (7): The recovery module marks the system call in step (6) as "executed" and executes step (4);

[0078] Step (8) The recovery module resumes the execution of all application threads, at which point the virtual machine error recovery process is complete.

[0079] In step (1), the virtual machine monitor uses a pre-saved virtual machine snapshot to start a new virtual machine instance.

[0080] The memory mapping in step (2) is consistent with the memory mapping in the virtual machine instance before the error.

[0081] The markers in step (3) are recorded in the log, and therefore are also stored in the secure memory of the trusted execution environment.

[0082] The parameters for the system call executed in step (5) are from the log stored in secure memory.

[0083] In step (6), a virtual machine monitor call is used to notify the virtual machine monitor.

[0084] A fast error recovery device for virtual machines suitable for trusted execution environments is characterized by comprising an application, a recovery module, a virtual machine, a virtual machine monitor, and a physical machine. The application and recovery module run within the trusted execution environment; the virtual machine runs on the virtual machine monitor, and the virtual machine's operating system kernel is responsible for interacting with hardware devices; the physical machine provides hardware devices such as file storage and network connectivity for the application.

[0085] like Figure 1 The diagram illustrates the specific process for rapid error recovery in a virtual machine according to this invention. The following section uses two applications as examples, combined with... Figure 1 The following error recovery steps are described in detail:

[0086] In step 401, the virtual machine monitor starts a new virtual machine instance, and then proceeds to step 402;

[0087] In step 402, the virtual machine monitor maps the trusted execution environment secure memory corresponding to the two applications to a new virtual machine instance, and then executes step 403;

[0088] In step 403, the recovery module sets the flag of all system calls in the log to "not executed", and then executes step 404;

[0089] In step 404, it is determined whether there are still "unexecuted" system calls in the log. If yes, then step 405 is executed; otherwise, step 408 is executed.

[0090] In step 405, the recovery module reads the call parameters of the earliest system call marked as "not executed" from the log, executes the corresponding system call with the read parameters, obtains the system call return value, and then executes step 406.

[0091] In step 406, it is determined whether the return value of the system call is the same as the return value recorded in the log. If yes, step 407 is executed; otherwise, step 401 is executed.

[0092] In step 407, the system call executed in step 405 is marked as "executed" in the log, and then step 404 is executed;

[0093] In step 408, the running of all threads of the application is resumed, completing a virtual machine error recovery.

[0094] like Figure 2 As shown, this invention runs multiple applications within a trusted execution environment of a virtual machine. Through the cooperation of a recovery module and a virtual machine monitor, it achieves rapid error recovery of the virtual machine. This invention consists of applications, a recovery module, a virtual machine, a virtual machine monitor, and a physical machine. The virtual machine operating system kernel is responsible for interacting with hardware devices, and the recovery module, in conjunction with the virtual machine monitor, is responsible for achieving rapid error recovery of the virtual machine.

[0095] Those skilled in the art can understand this embodiment as a more specific description of Embodiment 1 and Embodiment 2.

[0096] Those skilled in the art will understand that, besides implementing the system and its various devices, modules, and units provided by this invention in the form of purely computer-readable program code, the same functions can be achieved entirely through logical programming of the method steps, making the system and its various devices, modules, and units of this invention function in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, the system and its various devices, modules, and units provided by this invention can be considered as a hardware component, and the devices, modules, and units included therein for implementing various functions can also be considered as structures within the hardware component; alternatively, the devices, modules, and units for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0097] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features described in this application can be arbitrarily combined with each other.

Claims

1. A method for virtual machine error recovery for a trusted execution environment, the method comprising: The method includes the following steps: Step S1: The virtual machine monitor starts a new virtual machine instance; Step S2: The virtual machine monitor remaps the secure memory mapping of the trusted execution environment to the new virtual machine instance and enters the recovery module within the trusted execution environment; Step S3: The recovery module marks all system calls in the log as "not executed"; Step S4: If there are "not executed" system calls in the log, proceed to step S5; otherwise, proceed to step S8. Step S5: The recovery module reads and executes the earliest "unexecuted" system call; Step S6: The recovery module compares the return value of the system call executed in step S5 with the return value recorded in the log. If they are the same, proceed to step S7; otherwise, notify the virtual machine monitor that the recovery has failed, and then proceed to step S1. Step S7: The recovery module marks the system call in step S6 as "executed" and executes step S4; Step S8: The recovery module resumes the execution of all application threads, and the virtual machine error recovery process is complete.

2. The virtual machine error recovery method for a trusted execution environment according to claim 1, characterized in that, In step S1, the virtual machine monitor uses a virtual machine snapshot to launch a new virtual machine instance.

3. The virtual machine error recovery method for a trusted execution environment according to claim 1, characterized in that, The memory mapping in step S2 is consistent with the memory mapping in the virtual machine instance before the error occurred.

4. The virtual machine error recovery method for a trusted execution environment according to claim 1, characterized in that, The marking records in step S3 are recorded in the log, and the marking records are stored in the secure memory of the trusted execution environment.

5. The virtual machine error recovery method for a trusted execution environment according to claim 1, characterized in that, The parameters of the earliest "not executed" system call executed in step S5 are logs stored in safe memory.

6. The virtual machine error recovery method for a trusted execution environment according to claim 1, characterized in that, In step S6, the virtual machine monitor is invoked to notify the virtual machine monitor.

7. A virtual machine error recovery system suitable for trusted execution environments, characterized in that, The system includes the following modules: Module M1: The Virtual Machine Monitor starts a new virtual machine instance; Module M2: The Virtual Machine Monitor remaps the secure memory mapping of the Trusted Execution Environment to a new virtual machine instance, entering the recovery module within the Trusted Execution Environment; Module M3: The recovery module marks all system calls in the log as "not executed"; Module M4: If the log contains "not executed" system calls, execute module M5; otherwise, execute module M8. Module M5: The recovery module reads and executes the earliest "unexecuted" system call; Module M6: The recovery module compares the return value of the system call executed in module M5 with the return value recorded in the log. If they are the same, module M7 is executed; otherwise, the virtual machine monitor is notified that the recovery has failed, and then module M1 is entered. Module M7: The recovery module marks the system call in module M6 as "executed" and executes module M4; Module M8: The recovery module resumes the execution of all application threads, and the virtual machine error recovery process is complete.

8. The virtual machine error recovery system for a trusted execution environment according to claim 7, characterized in that, In module M1, the virtual machine monitor uses virtual machine snapshots to launch new virtual machine instances; The memory mapping in module M2 is consistent with the memory mapping in the virtual machine instance before the error.

9. The virtual machine error recovery system for a trusted execution environment according to claim 7, characterized in that, The tag records in module M3 are recorded in the log, and the tag records are stored in the secure memory of the trusted execution environment; The parameters of the earliest "not executed" system call executed in module M5 are logs stored in secure memory.

10. The virtual machine error recovery system for a trusted execution environment according to claim 7, characterized in that, The virtual machine monitor is invoked in module M6 to notify the virtual machine monitor.

Images