Patent Description:
In an isolated execution (Isolated execution) technology of a Central Processing Unit (CPU), a secure execution area (Enclave) may be created by using the CPU, to execute a security-sensitive application. Privilege codes such as a Virtual Machine Monitor (VMM), an OS (Output System), and a Basic Input/Output System (, BIOS) cannot access content in the enclave, thereby protecting a code and data of the sensitivity-sensitive application against attacks from malicious or buggy low-level code. Memory used for a CPU enclave is referred to as an EPC (Enclave Page Cache, Enclave, Enclave page cache). An application A is used as an example. An enclave of the application A is an execution environment that is created in an address space (address space) of the application A and that is directly protected by the CPU. Some or all codes of the application A may be run in the enclave, and a code run in the enclave is referred to as an enclave code. Running status data such as a data segment, a heap, a stack, and an SSA (State Save Area, state save area) generated by enclave codes of the application A in a running process is stored in an EPC in which the enclave of the application A is located.

In a cloud computing application scenario, some computing entities such as a virtual machine (VM), a container (for example, Docker), and an application may need to be migrated between two different physical hosts. In a migration process, an operating system or a VMM on a source host usually accesses codes and status data of a computing entity in memory, and sends the codes and the status data to a target physical host to reconstruct the computing entity. However, if an application creates or uses the CPU enclave, because only enclave codes of the application are allowed to access codes and data in the enclave while the operating system or the virtual machine monitor on the source host are not, data stored in an EPC of the enclave cannot be migrated to the target physical host, and consequently, running status data of the application before migration is inconsistent with that after migration.

<CIT> relates to processors, methods, systems, and instructions to support live migration of protected containers.

The Article "<NPL> ET AL discloses the migration of SGX enclaves using hardware instructions.

Embodiments of the present invention provide a data migration method and apparatus, to implement migration of an enclave between different hosts.

Various aspects of the present disclosure have been defined in the independent claims. Further technical features of each of these aspects have been defined in the respective dependent claims.

Because a working thread may modify the running status data of the target application in the EPC in a running process, if a local status of any of the N working threads is a busy state, it indicates that the working thread may be modifying running status data of the enclave. In this case, the migration control thread needs to wait until the local status of the working thread becomes a stopped state, and starts a data migration process in the enclave when the migration control thread determines that the local statuses of all the N working threads are a stopped state. In this way, a problem that a running status of the target application before migration is inconsistent with that after migration can be avoided, where the problem occurs when any working thread in the enclave modifies the running status data of the enclave during execution in a migration process of the target application.

After the protected running status data is written into the target memory, the VMM, an OS, and a cloud administrator cannot read and modify the running status data, thereby improving confidentiality and integrity of running status data generated in the enclave in a data migration process.

In the embodiments of the present invention, names of the source host and the destination host do not constitute any limitation to the devices. In actual implementation, the devices may be present in other names. The devices fall within the scope of the following claims of the present invention and their equivalent technologies provided that functions of the devices are similar to functions of the device in the embodiments of the present invention.

In addition, for a technical effect of any design manner in the second aspect to the ninth aspect, refer to technical effects of different design methods in the first aspect.

The terms "first" and "second" mentioned below are merely for a purpose of description, and shall not be understood as an indication or implication of relative importance or implicit indication of the number of indicated technical features. Therefore, a feature limited by "first" or "second" may explicitly or implicitly include one or more features. In the description of embodiments of the present invention, unless otherwise stated, "plurality of" means two or more.

To easily understand the embodiments of the present invention, some terms used in description of the embodiments of the present invention are first described herein.

VM: One or more virtual machines (VM) are one or more virtual computers emulated on one physical host by using virtual machine software. The virtual machines work like real computers. An operating system and an application program may be installed on the virtual machine. The virtual machine may further access a network resource. The virtual machine works like a real computer to the application program running on the virtual machine.

Container: A container is a lightweight application running environment, and is configured to isolate applications of a plurality of tenants on a same physical host. A plurality of containers usually share an operating system kernel. Typical containers include Docker, LXC, and the like.

Hardware layer: A hardware layer is a hardware platform on which a virtual environment runs. As shown in <FIG>, the hardware layer may include various hardware. For example, a hardware layer of a physical host may include a CPU, memory, a network adapter, a storage, a high-speed/low-speed input/output (I/O, Input/Output) device, and another device having a specific processing function.

Host: A host (Host), as a management layer, is configured to: manage and allocates hardware resources; present a virtual hardware platform for a virtual machine; and implement scheduling and isolation of virtual machines. For example, as shown in <FIG>, a virtual machine monitor (VMM) may be set in the host. The virtual hardware platform provides various hardware resources to virtual machines running on the virtual hardware platform, for example, provides a virtual central processing unit (VCPU, virtual CPU), virtual memory, a virtual disk, a virtual network adapter, or the like.

It may be understood that the embodiments of the present invention may be applied to virtual computing platforms such as Xen, KVM (Kernel-based Virtual Machine, kernel-based virtual machine), and Docker. This is not limited in the embodiments of the present invention.

An embodiment of the present invention provides a data migration method, applicable to a data migration system shown in <FIG>. The system includes a source host <NUM> and a destination host <NUM>.

An application A runs in the source host <NUM>. The application A is any application created with an enclave (a memory protection area). That is, enclave codes in the application A are run in an EPC of the source host <NUM>. Running status data generated in a running process is stored in the EPC.

Then, when the application A needs to be migrated to the destination host <NUM>, an operating system of the source host <NUM> usually accesses memory of the source host <NUM>, and sends data such as codes and the running status data of the application A that is stored in the memory to the destination host <NUM>. However, only the enclave codes of the application A are allowed to access, by invoking a CPU of the source host <NUM>, the running status data stored in an EPC in the memory. Therefore, data in the EPC cannot be sent to the destination host <NUM>. As a result, a running state of the application A that is restored by the destination host <NUM> based on the data sent by the source host <NUM> may be different from a running state of the application A running in the source host <NUM>.

In view of this, in the data migration method provided in this embodiment of the present invention, in an enclave of each target application created with the enclave, for example, the application A in <FIG>, a migration control thread is created in advance. The migration control thread is located within the enclave of the application A. To be specific, codes of the migration control thread are also the enclave codes of the application A. Therefore, the migration control thread may access running status data of the application A in the EPC, and write the running status data into target memory other than the EPC, namely, memory that can be accessed by the operating system of the source host <NUM>. In addition, after the running status data is migrated to the destination host, the migration control thread may be further used to restore the migrated running status data to an EPC in which the enclave of the application A in the destination host is located.

In this way, after the source host <NUM> obtains a migration instruction (where the migration instruction is used to instruct to migrate a target application created with an enclave, for example, the application A, to the destination host <NUM>), because the migration control thread in the enclave of the application A has access rights of accessing the EPC, the source host <NUM> may invoke the migration control thread, and write the running status data of the application A in the EPC into target memory of the source host <NUM>. The operating system of the source host <NUM> is allowed to access data in the target memory. Therefore, subsequently, the source host <NUM> can follow an existing data migration method to send, to the destination host <NUM>, related data such as the running status data written into the target memory and codes of the application A that are originally stored in the target memory.

After receiving the related data of the application A that is sent by the source host <NUM>, the destination host <NUM> may first restore the enclave of the application A in an EPC of the destination host <NUM> for the application A, and further create a migration control thread of the application A in the enclave. The migration control thread has access rights of accessing the EPC. Therefore, the created migration control thread may replicate the running status data to the EPC in which the enclave of the application A is located, and decrypt and restore a running status of the enclave in the application A.

In this way, according to the method, data migration in the EPC can be implemented in an application migration process, so that data such as running status data of an application before migration is consistent with that after migration.

Certainly, the migration control thread may further perform encryption and integrity protection operations on running status data of a target application in an EPC, thereby ensuring confidentiality and integrity of the running status data in a migration process. This is described in detail in subsequent embodiments. Therefore, the details are not described herein again.

In addition, the data migration method provided in this embodiment of the present invention is applicable to a migration process of a virtual machine in a cloud virtualization environment, and is also applicable to a migration process, between any two physical hosts, of an application and a container including an enclave. This is not limited in this embodiment of the present invention. In the subsequent embodiments, the migration process of the virtual machine is used as an example to describe the data migration method provided in this embodiment of the present invention.

<FIG> is a schematic diagram of interaction of a data migration method according to an embodiment of the present invention.

A source host obtains a migration instruction, where the migration instruction is used to instruct the source host to migrate a target application created with an enclave to a destination host.

Migration of a virtual machine is used as an example. A host runs on the source host, at least one virtual machine runs on the host, and at least one application may run in each virtual machine. Then, when a target virtual machine (where the target virtual machine is one of the at least one virtual machine) is migrated to the destination host, an application in the target virtual machine also needs to be migrated to the destination host. The application in the target virtual machine may include the target application created with the enclave.

In this case, as shown in <FIG>, a VMM in the host may send the migration instruction to the target virtual machine, to indicate, to the target virtual machine, that the source host is about to migrate the target application, for example, an application A, to the destination host.

Alternatively, the target virtual machine may periodically query, in a manner of polling monitoring, the VMM whether the VMM generates the migration instruction. If the VMM generates the migration instruction, the target virtual machine obtains the migration instruction from the VMM. This is not limited in this embodiment of the present invention.

The source host invokes an enclave drive, to send a preset migration signal to a migration control thread in the enclave of the target application.

After the target virtual machine obtains the migration instruction, it is checked whether an application including an enclave is created in the target virtual machine. For the application including the enclave, for example, the application A in <FIG>, the application A usually needs to run N (N ≥ <NUM>) working threads in an enclave of the application A. In this embodiment of the present invention, one migration control thread is preset in the enclave of the application A. The migration control thread is specially used for migrating data in an EPC area in which the enclave is located.

Specific codes executed by the migration control thread are compiled in advance in the enclave of the application A. The codes are specially used for migrating running status data that is generated in the enclave and that is in the EPC. Then, after the source host obtains the migration instruction, a new thread may be created to specially execute the codes compiled in advance. In this case, the new thread is the migration control thread. The migration control thread executes corresponding codes after receiving the migration signal, to complete a data migration process of steps <NUM> and <NUM>. The working thread ends running when the data migration process ends.

Then, if the application including an enclave, for example, the application A, is created in the target virtual machine, as shown in <FIG>, the target virtual machine may invoke an enclave drive in an operating system of the target virtual machine, to send a preset migration signal to the migration control thread in the enclave of the application A, to trigger the migration control thread to perform the data migration process.

For example, the migration signal may be a signal predefined by a person skilled in the art based on actual experience. This is not limited in this embodiment of the present invention.

The source host invokes the migration control thread, to obtain running status data of the target application from the EPC.

The running status data may be specifically stack data, heap data, SSA data, and the like that are generated by enclave codes of the target application during running in the enclave of the target application. This is not limited in this embodiment of the present invention.

Specifically, after the migration control thread in the enclave of the application A receives the migration signal, as shown in <FIG>, steps <NUM> to <NUM> may be performed, to access running status data of the application A in the EPC in which the enclave is located.

The source host invokes the migration control thread, to set a global status of the target enclave to a migration state.

Specifically, one global identifier may be set in the enclave of the application A. The global identifier is used to indicate a global status. The global identifier can be found by the N working threads. Then, after the migration control thread in the enclave receives the migration signal, the migration control thread may set the global status of the enclave to a migration state. For example, the global identifier is set to <NUM>, and it indicates that running status data of the enclave currently needs to be migrated.

The source host waits based on the global status until local statuses of all the N working threads become a stopped state.

For each of the N working threads, the source host presets one local identifier. The local identifier is used to indicate the local status of the working thread. When the working thread is started, the working thread sets the local status of the working thread to a busy state (busy), and it indicates that the working thread is being run, and the working thread may modify the running status data of the application A in the EPC in a running process.

Therefore, to ensure that a running status of the application A before migration is consistent with that after migration, in this embodiment of the present invention, when the working thread is started, the working thread sets the local status of the working thread to a busy state. Further, the working thread queries a current global identifier. If the global identifier is <NUM> (to be specific, the global status is a migration state), the working thread may set the local status corresponding to the working thread to a stopped state after execution of the working thread is finished or the working thread is forced to exit the enclave, to inform the migration control thread.

The source host determines that the local statuses of all the N working threads are a stopped state.

For example, the source host may determine, by invoking the migration control thread, that the local statuses of all the N working threads are a stopped state. Alternatively, each of the N working threads sets the local status of the working thread to a stopped state. This is not limited in this embodiment of the present invention.

In a possible implementation, for the migration control thread in the enclave, after the migration control thread sets the global status of the enclave to a migration state, the migration control thread monitors the local statuses of the N working threads. If the local status of any of N working threads is a busy state, it indicates that the working thread may be modifying the running status data of the application A in the EPC. In this case, the migration control thread needs to wait until the local status of the working thread becomes a stopped state. When the migration control thread determines that the local statuses of all the N working threads are a stopped state, proceed to steps <NUM> to <NUM>.

In another possible implementation, when the migration control thread in the enclave detects that any one or more of the N working threads (for example, a working thread <NUM>) is in a busy state, if the source host intends to start data migration immediately, all working threads in a busy state may be forced through an interrupt (for example, a clock interrupt) to exit the enclave. After exiting the enclave, each working thread may check whether the global status is <NUM>. If the global status is <NUM>, the working thread quits reentering the enclave and sets the local status of the working thread to a stopped state (free).

Usually, if a working thread in the enclave is interrupted during execution, running status data, for example, a value of a general-purpose register of a CPU, of each working thread in the enclave, is automatically stored by the CPU in the SSA, a stack pointer CSSA (Current State Save Area, current state save area) of the SSA is increased by <NUM>, and the CPU executes an interrupt handler after exiting the enclave.

When the source host forces all the working threads in a busy state through an interrupt to exit the enclave, running status data of the working threads is automatically stored into the SSA. A CSSA of each forcefully interrupted thread is increased by <NUM>. In this case, the source host may record a value of the CSSA of each working thread. In this way, after the source host subsequently migrates a value of a CSSA to the destination host, the destination host may restore a current execution status of the working thread <NUM> based on the value of the CSSA, to ensure that a running status of the target application before migration is consistent with that after migration. In addition, when the target application created with an enclave is migrated between the source host and the migration destination host, the source host does not need to wait until execution of all working threads in the enclave of the target application is finished before performing migration, thereby improving migration efficiency of the target application.

In another implementation method, if the source host can accept a waiting time, the source host may wait until execution of all the working threads is finished, and all the working threads set the local statuses to a stopped state after exiting the enclave. When the local statuses of all the working threads are a stopped state, the source host reads running status data of the enclave.

When the local statuses of all the N working threads are a stopped state, steps <NUM> to <NUM> may continue to be performed.

The source host invokes the migration control thread, to access running status data of the target application in the EPC by using a CPU of the source host.

The migration control thread is located within the enclave of the application A. Therefore, the migration control thread has rights of accessing the EPC in which the enclave is located. Then, the migration control thread may access, by using the CPU of the source host, the running status data of the application A in the EPC in which the enclave is located, and further replicate the running status data of the application A.

A migration control thread in the source host performs an encryption operation on the running status data.

The migration control thread in the source host adds integrity protection to the encrypted running status data.

For example, the source host may add the integrity protection to the encrypted running status data by using a message authentication code MAC (Message Authentication Code) or a digital signature.

Herein, encryption may be performed before integrity protection is added, or the integrity protection may be added before encryption is performed. To be specific, a sequence of performing steps <NUM> and <NUM> is not limited in this embodiment of the present invention.

In steps <NUM> and <NUM>, the source host may obtain an encryption key and a MAC key by using a remote attestation (remote attestation) technology of the enclave.

Subsequently, after the source host writes encrypted and integrity-protected running status data into target memory, an entity such as an operating system, a virtual monitor, and an administrator without the encryption key cannot read the running status data, and an entity without the MAC key cannot tamper with the data, thereby improving confidentiality and integrity of running status data generated in the enclave in a data migration process.

Herein, steps <NUM> to <NUM> are performed, so that the migration control thread accesses the running status data of the target application in the EPC by invoking the CPU of the source host.

The source host invokes the migration control thread, to write the running status data into the target memory.

The target memory in this embodiment of the present invention is an area other than the EPC in memory of the source host. The area may be accessed by the operating system or the virtual machine monitor of the source host.

Specifically, the migration control thread writes the encrypted and integrity-protected running status data into the target memory. In this way, though the running status data is written into the target memory that can be accessed by the operating system, because the running status data has been encrypted and integrity-protected, security of running status data in the target memory is improved.

The source host sends the running status data of the target application to the destination host.

In the target memory of the source host, related data such as codes of the application A, an enclave create record of the application A (where the enclave create record records a memory address of the enclave created in the application A), and a CSSA of each working thread is further stored. In step <NUM>, the source host may send the data, the running status data of the target application, and the related data of the target virtual machine to the destination host together. The destination host restores the target virtual machine, and restores the application A in the target virtual machine, to implement a migration process of the application A.

Still, <FIG> shows a data migration method according to an embodiment of the present invention.

A destination host obtains running status data of a target application from a source host.

The destination host obtains an enclave create record of the target application and a CSSA of each working thread from the source host, where the enclave create record records a memory address of an enclave of the target application.

Specifically, the source host may send, to the destination host, related information such as codes of the target application (including enclave codes run inside the enclave and codes run outside the enclave), the running status data, the enclave create record, and the CSSA of each working thread in the target virtual machine.

Optionally, the running status data is encrypted and integrity-protected running status data.

The destination host restores the enclave of the target application in an EPC of memory of the destination host based on the memory address.

The destination host creates a migration control thread of the target application in the enclave of the target application.

The destination host invokes the migration control thread, to write the running status data into the EPC.

After the destination host receives the related information of the target virtual machine, a target virtual machine may be first created on a host of the destination host. Further, an initial target application is created in the newly created target virtual machine based on the received codes of the target application. In this case, a running status of the target application may be a preset initial value.

In addition, some codes in the target application may not be run within the enclave of the target application. Therefore, an operating system of the destination host has access rights to running status data generated during running of the codes. Then, the destination host may invoke the operating system of the destination host to first restore the running status data in the initial target application.

Only the enclave codes located within the enclave of the target application have access rights to running status data generated by enclave codes run in the enclave of the target application. Therefore, the destination host may first create the enclave, namely, the enclave of the target application, for the target application in the EPC of the memory of the destination host.

Specifically, in step <NUM>, the destination host may create a new enclave in the EPC of the destination host based on the memory address recorded in the enclave create record of the target application, and load enclave codes of the target application into the new enclave to be used as an enclave of the target application after restoration.

However, a running status of the enclave of the target application has not been restored yet. Therefore, in step <NUM>, the destination host creates a migration control thread for the target application in the enclave of the target application. Further, in step <NUM>, the migration control thread writes the running status data generated by the enclave codes and obtained in step <NUM> into an EPC in which the enclave is located, and further restore a running status of the entire target application.

Further, if data migrated from the source host includes a CSSA of a working thread (for example, a working thread <NUM>), it indicates that the working thread <NUM> is forced to exit the enclave through an interrupt, to be specific, execution of the working thread <NUM> is not finished on the source host. Therefore, the destination host needs to restore execution progress of the working thread <NUM> on the source host, so that a running status of the target application before migration is kept consistent with that after migration.

Usually, a default initial value of a CSSA that is set in the destination host is different from a value of the CSSA that is recorded in the running status data. For example, the default initial value of the CSSA is <NUM>, while the value of the CSSA that is recorded in the running status data is not <NUM> (to be specific, an interrupt occurs in the enclave during migration). In this case, the destination host may adjust a CSSA of the working thread <NUM> by actively triggering a page fault interrupt until a value of the CSSA of the working thread <NUM> is the same as a value of the CSSA that is recorded in the source host.

In this way, the destination host may restore the execution progress of the working thread <NUM> based on the value of the CSSA and a data segment, stack data, heap data, and SSA data in the enclave that are recorded in the running status data, so that unfinished execution of the working thread <NUM> on the source host may continue on the destination host.

The destination host invokes the migration control thread, to perform an integrity verification operation and a decryption operation on the running status data.

Optionally, if the source host has performed encryption and integrity protection operations on running status data generated by the enclave codes when sending the running status data, the destination host further needs to obtain a key used during encryption and an integrity key (for example, a MAC key or a signature key) used during integrity protection, to restore a running status of the target application.

Herein, a sequence of performing the integrity verification and the decryption operation is opposite to that of performing steps <NUM> and <NUM>. To be specific, if the encryption is performed before the integrity protection in steps <NUM> and <NUM>, herein, the integrity verification needs to be performed before the decryption. If the integrity protection performed before the encryption in steps <NUM> and <NUM>, herein, the decryption needs to performed before the integrity verification.

It may be understood that, to implement the foregoing functions, the source host, the destination host, or the like includes corresponding hardware structures and/or software modules for performing the functions. A person skilled in the art should easily be aware that, in combination with examples of units and algorithms steps described in the embodiments disclosed in this specification, the embodiments of the present invention may be implemented by hardware or a combination of hardware and computer software. Whether a function is performed by hardware or hardware driven by computer software depends on particular applications and design constraints of the technical solutions. A person skilled in the art may use different methods to implement the described functions for each particular application, but it should not be considered that the implementation goes beyond the scope of the embodiments of the present invention.

In the embodiments of the present invention, functional modules of the source host, the destination host, or the like may be divided according to the foregoing method example. For example, functional modules may be divided corresponding to the functions, or two or more functions may be integrated into one processing module. The integrated module may be implemented in a form of hardware, or may be implemented in a form of a software functional module. It should be noted that, in the embodiments of the present invention, module division is exemplary, and is merely a logical function division. In actual implementation, another division manner may be used.

When the functional modules are divided corresponding to the functions, <FIG> is a possible schematic structural diagram of the source host in the embodiments. The source host includes: an obtaining unit <NUM>, an execution unit <NUM>, a sending unit <NUM>, and an encryption unit <NUM>.

The obtaining unit <NUM> is configured to support the source host in performing the process <NUM> in <FIG>. The execution unit <NUM> is configured to support the source host in performing the processes <NUM> and <NUM> in <FIG> and the processes <NUM> to <NUM> in <FIG>. The sending unit <NUM> is configured to support the source host in performing the processes <NUM> and <NUM> in <FIG>. The encryption unit <NUM> is configured to support the source host in performing the processes <NUM> and <NUM> in <FIG>. For all related content of the steps in the foregoing method embodiments, refer to function descriptions of corresponding functional modules, and details are not described herein again.

When the functional modules are divided corresponding to the functions, <FIG> is a possible schematic structural diagram of the destination host in the embodiments. The destination host includes: an obtaining unit <NUM>, a restoration unit <NUM>, a creating unit <NUM>, and a replication unit <NUM>.

The obtaining unit <NUM> is configured to support the destination host in performing the process <NUM> in <FIG>. The restoration unit <NUM> is configured to support the destination host in performing the processes <NUM> and <NUM> in <FIG>. The creating unit <NUM> is configured to support the destination host in performing the process <NUM> in <FIG>. The replication unit <NUM> is configured to support the destination host in performing the processes <NUM> and <NUM> in <FIG>. For all related content of the steps in the foregoing method embodiments, refer to function descriptions of corresponding functional modules, and details are not described herein again.

When an integrated unit is used, <FIG> is a possible schematic structural diagram of the source host (or the destination host) in the foregoing embodiments. The source host (or the destination host) includes a processing module <NUM> and a communications module <NUM>. The processing module <NUM> is configured to control and manage action of the source host (or the destination host). The communications module <NUM> is configured to support the source host (or the destination host) in communicating with another network entity. The source host (or the destination host) may further include a storage module <NUM>, configured to store program codes and data of the source host (or the destination host).

The processing module <NUM> may be a processor or a controller, such as a central processing unit (Central Processing Unit, CPU), a general purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application-specific integrated circuit (Application-Specific Integrated Circuit, ASIC), a field programmable gate array (Field Programmable Gate Array, FPGA), or another programmable logical device, a transistor logical device, a hardware component, or a combination thereof. The processor/controller may implement or execute various example logical blocks, modules, and circuits described with reference to content disclosed in the embodiments of the present invention. Alternatively, the processor may be a combination of processors implementing a computing function, for example, a combination of one or more microprocessors, or a combination of the DSP and a microprocessor. The communications module <NUM> may be a transceiver, a transceiver circuit, a communications interface, or the like. The storage module <NUM> may be a storage.

When a virtual machine runs in the source host (or the destination host), a schematic architectural diagram of the source host (or the destination host) is shown in <FIG>.

Further, an embodiment of the present invention further provides a data migration system. The system includes the source host <NUM> and the destination host <NUM> shown in <FIG>.

All or some of the foregoing embodiments may be implemented by means of software, hardware, firmware, or any combination thereof. When a software program is used to implement the embodiments, the embodiments may be implemented completely or partially in a form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the procedure or functions according to the embodiments of the present invention are all or partially generated. The computer may be a general-purpose computer, a dedicated computer, a computer network, or other programmable apparatuses. The computer instructions may be stored in a computer readable storage medium or may be transmitted from a computer readable storage medium to another computer readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center to another website, computer, server, or data center in a wired (for example, a coaxial cable, an optical fiber, or a digital subscriber line (DSL)) or wireless (for example, infrared, radio, or microwave) manner. The computer readable storage medium may be any usable medium accessible by a computer, or a data storage device, such as a server or a data center, integrating one or more usable media. The usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, or a magnetic tape), an optical medium (for example, a DVD), a semiconductor medium (for example, a solid state disk Solid State Disk (SSD)), or the like.

Claim 1:
A data migration method, comprising:
obtaining (<NUM>), by a source host, a migration instruction, wherein the migration instruction is used to instruct to migrate a target application created with an enclave to a destination host;
characterized by,
invoking (<NUM>, <NUM>, <NUM>), by the source host, a migration control thread preset in the enclave of the target application, to write running status data of the target application in an enclave page cache EPC into target memory of the source host, wherein the target memory is an area other than the EPC in memory of the source host; and
sending (<NUM>), by the source host, the running status data of the target application in the target memory to the destination host;
wherein the invoking, by the source host, a migration control thread preset in the enclave of the target application, to write running status data of the target application in an enclave page cache EPC into target memory of the source host comprises:
invoking, by the source host, the migration control thread, to obtain running status data of the enclave from the EPC; and
invoking, by the source host, the migration control thread, to write the running status data of the enclave in the EPC into the target memory.