Container protection method and equipment

Abstract

The invention provides a container protection method and device. A first operating system and a confidential virtual machine are installed in a server. And deploying a partition container in the confidential virtual machine, wherein the partition container is used for running the load of the application. And deploying a shadow container outside the confidential virtual machine, wherein the shadow container does not run the load of the application. A server receives a first request sent by an application on an electronic device for implementing a first function. In response to the request, the server calls a resource to a partition container in the confidential virtual machine through a shadow container outside the confidential virtual machine, and the partition container realizes a first function according to the resource. Therefore, the shadow container outside the confidential virtual machine is used for acting on the partition container in the confidential virtual machine to obtain the resources on the first operating system, program codes used for calling the resources on the first operating system in the partition container can be saved, program codes in the confidential virtual machine are simplified, and the operation efficiency of the confidential virtual machine is improved. The security risk caused by deploying a large number of programs in the confidential virtual machine is effectively reduced, and the system security is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of confidential virtual machines and to a container protection method and device. Background Art

[0002] Software applications often depend on other libraries, configuration files, or services provided by the runtime environment. Traditionally, the runtime environment of software applications is installed in the operating system running on the physical host or virtual machine. The disadvantage is that the dependencies are bound by the runtime environment. The way to resolve these conflicts is usually to package the application and deploy it as a container. A container is a collection of one or more processes isolated from the rest of the system. It is an effective way to provide reusability and portability of hosted applications. It can be easily migrated from one environment to another and is usually temporary.

[0003] In order to ensure the security of containers, container security enhancement technology is usually used. This container security enhancement technology aims to reduce the risk of malicious containers breaking into the host, or to protect the confidentiality and integrity of data in the container when the privileged software or administrator of the cloud platform is malicious. In one application scenario, Kata Containers (Kata-CVM) based on confidential virtual machines uses confidential virtual machine technology to protect the confidentiality and integrity of container data. However, there is still a risk of administrators maliciously stealing data or applications maliciously attacking confidential containers in current confidential virtual machines. Summary of the invention

[0004] A container protection method and device provided in an embodiment of the present application simplifies the program code inside the confidential virtual machine by running a part of the containers (shadow containers) in the confidential container of the confidential virtual machine outside the confidential virtual machine, effectively reduces the security risks brought by deploying a large number of programs inside the confidential virtual machine, and improves system security.

[0005] In order to achieve the above-mentioned purpose, the embodiment of the present application adopts the following technical solution.

[0006] In the first aspect, the present application provides a container protection method, the execution subject of the method may be a device, or a component located in the device (for example, a chip, a chip system or a processor, etc.), and the following description is made by taking the execution subject as an example. The device may refer to a server, on which a confidential virtual machine and a first operating system are deployed, the partition container in the confidential virtual machine corresponds to the shadow container outside the confidential virtual machine, the partition container runs the load of the first application, and the shadow container does not run the load of the first application. The method includes: receiving a first request sent by a first application on an electronic device, the first request being used to implement a first function. In response to the first request, a first resource of the first operating system is obtained through a shadow container outside the confidential virtual machine. The shadow container provides the first resource to the partition container in the confidential virtual machine, the partition container implements the first function based on the first resource, and the first resource is a resource that can be used by the partition container.

[0007] In one example, the confidential container of the confidential virtual machine may include two parts: a shadow container and a partition container corresponding to the shadow container. From a deployment perspective, the shadow container is deployed outside the confidential virtual machine, and the partition container is deployed inside the confidential virtual machine. That is, in terms of layout, the shadow container is deployed outside the confidential virtual machine, and the partition container is deployed inside the confidential virtual machine. In this way, by separating the program code of the shadow container from the inside of the virtual machine, the program code deployed inside the confidential virtual machine is effectively simplified, which can effectively reduce the risk of the program inside the confidential virtual machine being attacked.

[0008] In one example, the first request is used to call a target function, and the target function is used to implement a target function, and the target function is pre-deployed on the server. Exemplarily, in a serverless scenario, the application program of the first application is deployed on the server. When the first application on the electronic device needs to query information, the first application on the electronic device sends a first request to the server, and the first request carries parameters for calling a function for querying information. The server calls the function through the partition container in the confidential virtual machine according to the first request and implements the information query function corresponding to the function. Of course, the confidential container design of the present invention can not only be used in serverless computing scenarios, but also in more scenarios such as microservices.

[0009] In one example, the first function may be determined according to a function. For example, the function is a query function, and the first function may be an information query function. For another example, the function may be a networking function, and the first function may be a network connection function. This is not specifically limited in the present application.

[0010] In one example, the confidential virtual machine can be understood as taking the virtual machine as a protection object, and ensuring that the internal load of the virtual machine is not attacked by the virtual machine monitor or physically attacked through mechanisms such as memory encryption. The partition container is used to run the load of the application, and the shadow container can be used as a scheduling agent for the partition container in the first operating system, such as the shadow container can configure memory resources for the partition container. The shadow container does not run the load of the application.

[0011] In an example, the first operating system may be a Linux system, and of course may also be other systems. In this application, the Linux system is taken as an example for description.

[0012] In one example, the shadow container runs outside the confidential virtual machine, and the shadow container is used to call the resources of the first operating system instead of the partition container in the confidential virtual machine. In this way, the microkernel is used in the confidential virtual machine CVM to provide a partition container for running confidential applications, and the shadow container is used to manage Linux containers outside the confidential virtual machine CVM, reducing the trusted computing base while being compatible with the operation of the container. That is, the confidential virtual machine will separate some programs in the first operating system, effectively reducing the size of the trusted computing base (which is a collection of all software and hardware on which the security of the computer system depends) in the confidential virtual machine, and improving system security.

[0013] In one example, the first resource may include a memory resource of the first operating system. For example, the first resource may be a physical address gPA interval of a confidential virtual machine, which may also be referred to as a client physical address gPA interval. For another example, the first resource may be a virtual central processing unit vCPU.

[0014] In this application, by using a shadow container outside the confidential virtual machine to proxy the partition container inside the confidential virtual machine to obtain resources on the first operating system, the program code in the partition container used to call resources on the first operating system can be saved, the program code inside the confidential virtual machine is simplified, and the security risks caused by deploying a large number of programs inside the confidential virtual machine are effectively reduced. In this way, the data confidentiality of the applications running in each partition container in the confidential virtual machine is effectively protected, and malicious attacks from other containers and malicious acquisition by administrators are effectively prevented, with high security.

[0015] In one design scheme, in response to the first request, a first resource of a first operating system is obtained through a shadow container outside a confidential virtual machine and given to a partition container within the confidential virtual machine, including: in response to the first request, starting the shadow container; the shadow container sends a second request to a kernel module of the first operating system, the second request being used to request allocation of an idle virtual central processing unit vCPU to a partition thread of the partition container; during execution of the vCPU, constructing a partition container corresponding to the shadow container, and executing the partition thread of the partition container.

[0016] Exemplarily, after the shadow container is started, it requests the kernel module to allocate an idle vCPU, and the allocated vCPU is marked as working. The shadow thread enters (VMEnter) the vCPU for execution through the interface provided by the kernel module, and the vCPU builds an isolation container and executes the isolation thread. If the vCPU receives a physical clock interrupt during execution, it sinks to the Linux kernel for processing, and the shadow thread is interrupted at VMEnter, and the Linux scheduler can cut away the current shadow thread. The next time the shadow thread is scheduled, the context is in the kernel module, and the kernel module re-enters the vCPU for execution. After the vCPU completes the execution of the isolation thread, it sinks to the microkernel, and then the CPU control flow switches back to the shadow thread, and the kernel module re-marks the vCPU as idle.

[0017] In some examples, the startup of the shadow container can be optimized through the lightweight container technology adopted in the SOCK system.

[0018] In some design schemes, the method also includes: when the partition container is started, a client physical address gPA interval is allocated to the partition container, the gPA interval is determined based on the memory resources of the shadow thread, and the gPA interval is used as a startup parameter of the partition container; after the partition container is allocated the gPA interval, the shadow thread of the shadow container calls the interface of the kernel module to bind the gPA interval with the host virtual address hVA interval of the shadow container.

[0019] In some design schemes, the method also includes: when a page fault occurs in the gPA interval, intercepting page fault error information; sending a third request to the kernel module, the third request being used to request processing of the page fault error information; according to the third request, querying the hVA interval corresponding to the gPA interval where the gPA position of the page fault is located, and triggering a page fault in the hVA interval of the shadow container; mapping the physical page mapped on the hVA interval to the gPA interval.

[0020] In this application, when a page fault occurs in the gPA interval, the Linux system transfers it to the kernel module for processing, and the kernel module processes the page fault at the corresponding position in the hVA interval; the physical page mapped in the hVA interval is synchronously mapped to the gPA interval. In order to reduce the number of page faults in the gPA space to improve performance, the kernel module pre-maps (pre-fault) a continuous gPA range after a page fault.

[0021] In one example, to defend against malicious attacks by the Linux kernel on the memory mapping of partitioned containers, it is necessary to combine the confidential virtual machine hardware mechanism with the microkernel software mechanism. To defend against memory duplication attacks, the confidential virtual machine hardware ensures that the same physical page cannot be mapped to two different gPAs, while the microkernel ensures that the gPA ranges used by different partitioned containers do not overlap. To defend against memory remapping attacks, the confidential virtual machine hardware requires that the mapping of gPA to physical memory must be confirmed by the microkernel before it can be used, and for the same memory pool, the microkernel confirms the mapping on one gPA at most once.

[0022] In some design schemes, the method also includes: determining the startup mode of the partition container according to the startup parameters of the vCPU corresponding to the partition container, the startup mode including a direct startup mode or a clone startup mode; starting the partition container through the direct startup mode or the clone startup mode to obtain the main thread context and address space of the partition container; wherein the address space maps the C standard library; the main thread entry point is the dynamic loader in the C standard library, and the dynamic loader loads the program according to command line instructions.

[0023] In this application, the address space, thread context, data in the IO stream, etc. of the confidential container are protected from direct access by attackers. However, relevant information of the application in the confidential container may still exist in the host Linux kernel, such as file lock information, IO data volume statistics, etc. It is possible to consider maintaining more information in the confidential virtual machine microkernel to prevent this information from being used by attackers for side-channel attacks.

[0024] In one design scheme, starting the partition container through the direct startup mode includes: providing the address space for the partition container; providing the main thread context for the partition container; and setting the command line instructions according to the startup parameters of the vCPU. In the present application, when the partition container is directly started, the entry point of the partition container is the dynamic loader in the C standard library, which loads the user program according to the command line parameters. The preset digests of the C standard library and template image are embedded in the microkernel image and are verified during the remote authentication of the confidential virtual machine. In this way, in the above-mentioned multi-stage startup and verification process, there is no need to initialize and authenticate the confidential virtual machine, language runtime, and third-party library when the function is started. It is only necessary to clone the template container and load the verification function business logic code.

[0025] In one design, starting the partition container through the clone startup mode includes: searching for the corresponding template container according to the startup parameters of the vCPU; cloning the template container to obtain a function container, which is used to load the function business logic; cloning the address space of the template container in the copy-on-write mode as the address space of the new partition container; cloning the main thread context of the template container as the main thread context of the new partition container. In this application, the startup of the partition container can be optimized by cloning the pre-started template container, saving most of the code loading and verification overhead.

[0026] In addition, in serverless computing scenarios, confidential virtual machines are pre-started during the system initialization phase and shared by all confidential containers. Therefore, the initialization of confidential virtual machines is not on the critical path of container startup, shortening the startup delay of confidential virtual machines.

[0027] In some design schemes, the method also includes: the dynamic loader identifies and intercepts the system call for reading the code file from the root file system in the partition container according to the file path; the system call distribution layer in the C standard library queries the file description table; when it is determined that the first file is marked as a code file, the system call distribution layer calculates a hash digest of the read file content and verifies it; when the verification passes, the partition container is authenticated successfully, and the dynamic loader or language runtime returns from the code reading system call.

[0028] In this application, the authentication of the confidential container is completed by the dynamic loader in the partition container C standard library, which identifies and intercepts all system calls that read code files from the root file system in the partition container according to the file path, and calculates the hash digest of the file content during the reading process, and compares it with the file signature (for starting a user function instance from a function image) or the preset digest (for starting a template container from a template image). In this way, a multi-stage startup is adopted, and the confidential virtual machine is shared by all containers after pre-starting. The template container cloning technology is used to pre-load the authentication language runtime and third-party libraries, and the startup overhead of these components is moved out of the critical path of function startup. In other words, only the business logic script needs to be loaded and authenticated when the function starts, and the function startup latency is low. Therefore, in the above multi-stage startup and verification process, there is no need to initialize and authenticate the confidential virtual machine, language runtime, and third-party library when the function starts. It is only necessary to clone the template container and load the verification function business logic code.

[0029] In some designs, the method further includes: when it is determined that the first file is marked as a code file, determining that the partition container authentication is successful, and the dynamic loader or language runtime returns from the code reading system call.

[0030] In some designs, the method further includes: when the verification fails, determining that the compartment container authentication fails, and terminating the compartment container execution.

[0031] In one design scheme, in response to the first request, a first resource of a first operating system is obtained through a shadow container outside a confidential virtual machine and given to a partition container within the confidential virtual machine, including: in response to the first request, starting the partition container, the partition thread of the partition container sending a fourth request for a system call, the fourth request carrying call information, the call information including at least one of the following: a system call number, call parameters, and a file descriptor in the call parameters; determining whether the shadow container agent executes or the microkernel executes according to the call information; when it is determined that the microkernel executes, the microkernel processes the fourth request; when it is determined that the shadow container agent executes, the fourth request is forwarded to the shadow container for processing, and a security check is performed.

[0032] For example, for 229 open source serverless computing function instances, the functions need to use 92 system calls in total, of which 64 are executed by proxy and 28 are processed by the microkernel. The proxy execution mainly includes IO system calls (46) and system calls involving information maintained in the Linux kernel, such as scheduling parameter settings. The system calls executed by the microkernel mainly include system calls that are vulnerable to attacks after being proxied, such as memory mapping, time, inter-thread synchronization, and random number related system calls.

[0033] Among them, for the IO system calls executed by the agent, the confidentiality and integrity of the IO data need to be protected. According to the needs of the serverless computing function, the IO data can include network data, code file data (reading the root file system), and temporary file data (reading and writing the temporary file system). Among them, network data protection depends on the application to encrypt network data. Code file data protection depends on code signature verification. Temporary file data is stored in the memory file system within the confidential virtual machine.

[0034] For example, in a general scenario, the system call proxy mode based on synchronous switching (VMExit) used in this application may cause high overhead, and the use of asynchronous mode for optimization may be considered.

[0035] In this application, a microkernel is deployed in a confidential virtual machine, and the Linux container software stack is reused through the two technologies of resource granting and system call proxy, which is compatible with container operation, thereby effectively reducing the size of the trusted computing base in the confidential virtual machine and improving system security.

[0036] In one design scheme, when it is determined that the shadow container agent is executed, the fourth request is forwarded to the shadow container for processing, including: placing the system call parameters corresponding to the fourth request in the shared memory, and the shared memory is the shared memory of the shadow container and the partition container; according to the fourth request, the shadow thread of the shadow container exits from the kernel module to the user state, the shadow thread executes the system call according to the system call parameters in the shared memory, and places the return value into the shared memory, and the return value includes a memory return value; when the partition thread of the partition container runs, the memory return value is obtained from the shared memory, and the memory return value is copied from the shared memory to the application memory.

[0037] In some designs, the method further includes: after the microkernel or the shadow container agent executes a system call, if the system call generates or clears a file descriptor, updating a file descriptor table in a call dispatch layer of the partition container.

[0038] In one design, the confidential virtual machine includes at least one compartment container and at least one shadow container, and the compartment container corresponds one-to-one to the shadow container. In the present application, at least one compartment container can be deployed in the confidential virtual machine. By designing a microkernel for confidential virtual machines for serverless computing, it supports multiple compartment containers to securely share a single confidential virtual machine, improves container scalability, and supports shared read-only memory and shared memory communication between containers, reducing the memory overhead of functions and the communication latency between functions. At the same time, the number of single-machine containers is not limited by the number of confidential virtual machines, the container memory overhead is reduced, and the communication overhead between containers is reduced.

[0039] In a second aspect, the present application provides a resource granting method, the execution subject of the method may be a device, or a component located in the device (for example, a chip, a chip system or a processor, etc.), and the following description is made by taking the execution subject as an example. The device may refer to a server. The server includes: at least one processor, a confidential virtual machine and a first operating system are deployed on the processor, the partition container in the confidential virtual machine corresponds to the shadow container outside the confidential virtual machine, the partition container runs the load of the first application, and the shadow container does not run the load of the first application. The method includes: the processor starts the shadow container, the shadow container configures memory resources for the partition container, and the memory resources are determined according to the resource control group parameters in the shadow container. The shadow thread of the shadow container sends a first request to the kernel module of the operating system of the electronic device, and the first request is used to request to call the interface of the kernel module. According to the first request, the kernel module sends a second request to the microkernel deployed in the confidential virtual machine, and the second request is used to request to enter the confidential virtual machine, and the virtual central processing unit vCPU corresponding to the partition container in the confidential virtual machine is marked as working. The kernel module reads the memory resources of the shadow thread, allocates the client physical address gPA interval to the shadow thread, and exits to the shadow thread. When the shadow thread exits to the user state, the shadow thread creates the host virtual address hVA interval. The shadow thread calls the interface of the kernel module to bind the gPA interval and the hVA interval.

[0040] In some designs, the method further includes: the microkernel determines the startup mode of the partition container according to the startup parameters of the vCPU, and the startup mode includes a direct startup mode or a clone startup mode. The microkernel starts the partition container through the direct startup mode or the clone startup mode to obtain the main thread context and address space of the partition container; the address space maps the C standard function library; the main thread entry point is the dynamic loader in the C standard library, and the dynamic loader loads the user program according to the command line instruction.

[0041] In one design scheme, the microkernel starts the partition container through the direct startup mode, including: the microkernel provides the address space for the partition container; the microkernel provides the main thread context for the partition container; the microkernel sets the command line instruction according to the startup parameters of the vCPU.

[0042] In one design scheme, the microkernel starts the partition container through the clone startup mode, including: the microkernel searches for the corresponding template container according to the startup parameters of the vCPU; the microkernel clones the template container to obtain a function container, and the function container is used to load function business logic; the microkernel adopts the write-time copy mode to clone the address space of the template container as the address space of the new partition container; the microkernel clones the main thread context of the template container as the main thread context of the new partition container.

[0043] In some designs, the method further includes: the dynamic loader identifies and intercepts a system call in the partition container to read a code file from a root file system according to the file path. The system call distribution layer in the C standard library queries a file description table. When it is determined that the first file is marked as a code file, the system call distribution layer calculates a hash digest of the read file content and verifies it. When the verification passes, the partition container is authenticated successfully, and the dynamic loader or language runtime returns from the code reading system call.

[0044] In some designs, the method further includes: when it is determined that the first file is marked as a code file, the partition container authentication succeeds, and the dynamic loader or language runtime returns from the code reading system call.

[0045] In some designs, the method further includes: when the verification fails, the compartment container authentication fails, and the microkernel terminates the execution of the compartment container.

[0046] In some design schemes, the method further includes: based on the confidential virtual machine hardware mechanism, when a page fault occurs on the gPA, the microkernel intercepts the page fault error information. The microkernel sends a third request to the kernel module of the operating system of the electronic device, and the third request is used to request processing of the page fault error information. According to the third request, the kernel module queries the hVA interval corresponding to the gPA interval where the gPA position of the page fault is located, and triggers a page fault in the hVA interval of the shadow container. The kernel module maps the physical page mapped on the hVA interval to the gPA interval. After the kernel module processes the third request, it enters the vCPU execution, and the microkernel performs mapping verification on the unverified mapping in the gPA interval, and the page fault error processing is completed.

[0047] In a third aspect, the present application provides a method for starting a confidential virtual machine, the execution subject of the method may be a device, or a component located in the device (for example, a chip, a chip system or a processor, etc.), and the following description is made taking the execution subject being a device as an example. The device refers to a server. The server includes: at least one processor, on which a confidential virtual machine and a first operating system are deployed, the partition container in the confidential virtual machine corresponds to the shadow container outside the confidential virtual machine, the partition container runs the load of the first application, and the shadow container does not run the load of the first application. The partition container corresponds to a virtual central processing unit vCPU.

[0048] The method includes: the microkernel determines the startup mode of the partition container according to the startup parameters of the vCPU, and the startup mode includes a direct startup mode or a clone startup mode; the microkernel starts the partition container through the direct startup mode or the clone startup mode to obtain the main thread context and address space of the partition container; the address space maps the C standard function library; the main thread entry point is the dynamic loader in the C standard function library, and the dynamic loader loads the user program according to the command line instruction.

[0049] In one design scheme, the microkernel starts the partition container through the direct startup mode, including: the microkernel provides the address space for the partition container; the microkernel provides the main thread context for the partition container; the microkernel sets the command line instruction according to the startup parameters of the vCPU.

[0050] In one design scheme, the microkernel starts the partition container through the clone startup mode, including: the microkernel searches for the corresponding template container according to the startup parameters of the vCPU; the microkernel clones the template container to obtain a function container, and the function container is used to load function business logic; the microkernel adopts the write-time copy mode to clone the address space of the template container as the address space of the new partition container; the microkernel clones the main thread context of the template container as the main thread context of the new partition container.

[0051] In some designs, the method further includes: the dynamic loader identifies and intercepts a system call in the partition container to read a code file from a root file system according to the file path. The system call distribution layer in the C standard function library queries a file description table. When it is determined that the first file is marked as a code file, the system call distribution layer calculates a hash digest of the read file content and verifies it. When the verification passes, the partition container is authenticated successfully, and the dynamic loader or language runtime returns from the code reading system call.

[0052] In some designs, the method further includes: when it is determined that the first file is marked as a code file, the partition container authentication succeeds, and the dynamic loader or language runtime returns from the code reading system call.

[0053] In some designs, the method further includes: when the verification fails, the compartment container authentication fails, and the microkernel terminates the execution of the compartment container.

[0054] In a fourth aspect, the present application provides a method for a confidential virtual machine to create a child thread. The execution subject of the method may be a device or a component located in the device (for example, a chip, a chip system or a processor, etc.). The following description is made by taking the execution subject being a device as an example. The device refers to a server. The server includes: at least one processor, on which a confidential virtual machine and a first operating system are deployed, a partition container within the confidential virtual machine corresponds to the shadow container outside the confidential virtual machine, the partition container runs the load of the first application, the shadow container does not run the load of the first application, and the partition container corresponds to a virtual central processing unit vCPU.

[0055] The method includes: the partition thread in the partition container sends a third request to the microkernel for creating a child thread. The microkernel sends a fourth request to the kernel module of the operating system of the electronic device, and the fourth request is used to request the kernel module to allocate a new vCPU for the partition thread. The kernel module allocates a new vCPU for the partition thread according to the fourth request. When the microkernel detects that the partition thread is not bound to the new vCPU, the microkernel provides the partition container with a partition thread context and binds the partition thread to the new vCPU. The microkernel sends a fifth request to the kernel module, and the fifth request is used to request the shadow container to create a shadow thread corresponding to the partition thread. The shadow container creates a shadow thread corresponding to the partition thread according to the fifth request.

[0056] In some designs, the method further includes: when the microkernel detects that a partition thread is bound to the new vCPU, the microkernel sends the fourth request to the kernel module.

[0057] In a fifth aspect, the present application provides a system call distribution and proxy method for a confidential virtual machine, the execution subject of the method may be a device, or a component located in the device (for example, a chip, a chip system or a processor, etc.), and the following description is made taking the execution subject as an example of a device. The device refers to a server. The server includes: at least one processor, on which a confidential virtual machine and a first operating system are deployed, the partition container in the confidential virtual machine corresponds to the shadow container outside the confidential virtual machine, the partition container runs the load of the first application, the shadow container does not run the load of the first application, and the partition container corresponds to a virtual central processing unit vCPU.

[0058] The method includes: the partition thread in the partition container initiates a system call, which is intercepted by the system call distribution layer in the C standard library. The system call distribution layer determines the execution mode according to the call information; the call information includes at least one of the following: system call number, call parameters and file descriptors in the call parameters; the execution mode includes proxy execution or microkernel execution. When the system call distribution layer determines that the microkernel is executed, the system call distribution layer processes the system call inside the microkernel. When the system call distribution layer determines that the proxy is executed, the system call distribution layer forwards the system call to the shadow container for processing and performs a security check.

[0059] In one design scheme, the call information includes a system call number; the system call distribution layer determines the execution mode according to the call information, including: the system call distribution layer checks the system call number; when the system call number meets a first preset condition, the system call distribution layer determines the execution mode.

[0060] In one design, the call information may include call parameters; the system call distribution layer determines the execution mode according to the call information, including: the system call distribution layer checks the call parameters; when the call parameters meet a second preset condition, the system call distribution layer determines the execution mode. The second preset condition is that opening a file in a non-tmpfs path requires proxy execution.

[0061] In one design scheme, the call information may include a file descriptor in the call parameters; the system call distribution layer determines the execution mode according to the call information, including: the system call distribution layer checks the file descriptor in the call parameters; when the file descriptor in the call parameters meets a third preset condition, the system call distribution layer determines the execution mode; the third preset condition is that reading the file opened in the shadow container requires proxy execution.

[0062] In one design scheme, the system call distribution layer forwards the system call to the shadow container for processing, including: the partition thread copies memory parameters from the application memory to the shared memory, the shared memory is the shared memory of the shadow container and the partition container, and the shared memory is created when the confidential container is started; the partition thread puts the system call parameters in the shared memory; when the partition thread sends a sixth request for proxying the system call to the kernel module of the operating system of the electronic device through the microkernel, the kernel module exits the shadow thread from the kernel module to the user state according to the sixth request; the shadow thread executes the system call according to the system call parameters in the shared memory, and puts the return value into the shared memory, and the return value includes the memory return value; the shadow thread calls the interface of the kernel module and enters the vCPU to execute the partition thread; the partition thread obtains the memory return value from the shared memory, and copies the memory return value from the shared memory to the application memory.

[0063] In some designs, the method further includes: after the microkernel or the agent executes a system call, if the system call generates or clears a file descriptor, updating a file descriptor table in the call dispatch layer.

[0064] In a sixth aspect, the present application provides a device on which a confidential virtual machine and a first operating system are deployed, the partition container in the confidential virtual machine corresponds to the shadow container outside the confidential virtual machine, the partition container runs the load of the first application, and the shadow container does not run the load of the first application. The device includes: a transceiver module and a processing module, wherein the transceiver module is used to receive a first request sent by a first application on an electronic device, and the first request is used to implement a first function. The processing module is used to obtain a first resource of the first operating system through a shadow container outside the confidential virtual machine in response to the first request. The shadow container provides the first resource to the partition container in the confidential virtual machine, and the partition container implements the first function based on the first resource, and the first resource is a resource that can be used by the partition container.

[0065] In one example, the first request is used to call a target function, and the target function is used to implement a target function, and the target function is pre-deployed on the server. Exemplarily, in a serverless scenario, the application program of the first application is deployed on the server. When the first application on the electronic device needs to query information, the first application on the electronic device sends a first request to the server, and the first request carries parameters for calling a function for querying information. The server calls the function through the partition container in the confidential virtual machine according to the first request and implements the information query function corresponding to the function. Of course, the confidential container design of the present invention can not only be used in serverless computing scenarios, but also in more scenarios such as microservices.

[0066] In one example, the first function may be determined according to a function. For example, the function is a query function, and the first function may be an information query function. For another example, the function may be a networking function, and the first function may be a network connection function. This is not specifically limited in the present application.

[0067] In one example, the confidential virtual machine can be understood as taking the virtual machine as a protection object, and ensuring that the internal load of the virtual machine is not attacked by the virtual machine monitor or physically attacked through mechanisms such as memory encryption. The partition container is used to run the load of the application, and the shadow container can be used as a scheduling agent for the partition container in the first operating system, such as the shadow container can configure memory resources for the partition container. The shadow container does not run the load of the application.

[0068] In an example, the first operating system may be a Linux system, and of course may also be other systems. In this application, the Linux system is taken as an example for description.

[0069] In one example, the shadow container runs outside the confidential virtual machine, and the shadow container is used to call the resources of the first operating system instead of the partition container in the confidential virtual machine. In this way, the microkernel is used in the confidential virtual machine CVM to provide a partition container for running confidential applications, and the shadow container is used to manage Linux containers outside the confidential virtual machine CVM, reducing the trusted computing base while being compatible with the operation of the container. That is, the confidential virtual machine will separate some programs in the first operating system, effectively reducing the size of the trusted computing base (which is a collection of all software and hardware on which the security of the computer system depends) in the confidential virtual machine, and improving system security.

[0070] In one example, the first resource may include a memory resource of the first operating system. For example, the first resource may be a physical address gPA interval of a confidential virtual machine, which may also be referred to as a client physical address gPA interval. For another example, the first resource may be a virtual central processing unit vCPU.

[0071] In this application, by using a shadow container outside the confidential virtual machine to proxy the partition container inside the confidential virtual machine to obtain resources on the first operating system, the program code in the partition container used to call resources on the first operating system can be saved, the program code inside the confidential virtual machine is simplified, and the security risks caused by deploying a large number of programs inside the confidential virtual machine are effectively reduced. In this way, the data confidentiality of the applications running in each partition container in the confidential virtual machine is effectively protected, and malicious attacks from other containers and malicious acquisition by administrators are effectively prevented, with high security.

[0072] In one design scheme, the processing module is used to: start the shadow container in response to the first request; the shadow container sends a second request to the kernel module of the first operating system, and the second request is used to request the allocation of an idle virtual central processing unit vCPU for the partition thread of the partition container; during the execution of the vCPU, construct a partition container corresponding to the shadow container, and execute the partition thread of the partition container.

[0073] Exemplarily, after the shadow container is started, it requests the kernel module to allocate an idle vCPU, and the allocated vCPU is marked as working. The shadow thread enters (VMEnter) the vCPU for execution through the interface provided by the kernel module, and the vCPU builds an isolation container and executes the isolation thread. If the vCPU receives a physical clock interrupt during execution, it sinks to the Linux kernel for processing, and the shadow thread is interrupted at VMEnter, and the Linux scheduler can cut away the current shadow thread. The next time the shadow thread is scheduled, the context is in the kernel module, and the kernel module re-enters the vCPU for execution. After the vCPU completes the execution of the isolation thread, it sinks to the microkernel, and then the CPU control flow switches back to the shadow thread, and the kernel module re-marks the vCPU as idle.

[0074] In some examples, the startup of the shadow container can be optimized through the lightweight container technology adopted in the SOCK system.

[0075] In some design schemes, the processing module is used to: when the partition container is started, allocate a client physical address gPA interval to the partition container, the gPA interval is determined based on the memory resources of the shadow thread, and the gPA interval is used as a startup parameter of the partition container; after the partition container is allocated the gPA interval, the shadow thread of the shadow container calls the interface of the kernel module to bind the gPA interval with the host virtual address hVA interval of the shadow container.

[0076] In some design schemes, the processing module is used to: intercept page fault information when a page fault occurs in the gPA interval; send a third request to the kernel module, the third request being used to request processing of the page fault error information; query the hVA interval corresponding to the gPA interval where the gPA position of the page fault is located according to the third request, and trigger a page fault in the hVA interval of the shadow container; map the physical page mapped on the hVA interval to the gPA interval.

[0077] In this application, when a page fault occurs in the gPA interval, the Linux system transfers it to the kernel module for processing, and the kernel module processes the page fault at the corresponding position in the hVA interval; the physical page mapped in the hVA interval is synchronously mapped to the gPA interval. In order to reduce the number of page faults in the gPA space to improve performance, the kernel module pre-maps (pre-fault) a continuous gPA range after a page fault.

[0078] In one example, to defend against malicious attacks by the Linux kernel on the memory mapping of partitioned containers, it is necessary to combine the confidential virtual machine hardware mechanism with the microkernel software mechanism. To defend against memory duplication attacks, the confidential virtual machine hardware ensures that the same physical page cannot be mapped to two different gPAs, while the microkernel ensures that the gPA ranges used by different partitioned containers do not overlap. To defend against memory remapping attacks, the confidential virtual machine hardware requires that the mapping of gPA to physical memory must be confirmed by the microkernel before it can be used, and for the same memory pool, the microkernel confirms the mapping on one gPA at most once.

[0079] In some design schemes, the processing module is used to: determine the startup mode of the partition container according to the startup parameters of the vCPU corresponding to the partition container, the startup mode including a direct startup mode or a clone startup mode; start the partition container through the direct startup mode or the clone startup mode to obtain the main thread context and address space of the partition container; wherein the address space maps the C standard library; the main thread entry point is the dynamic loader in the C standard library, and the dynamic loader loads the program according to command line instructions.

[0080] In this application, the address space, thread context, data in the IO stream, etc. of the confidential container are protected from direct access by attackers. However, relevant information of the application in the confidential container may still exist in the host Linux kernel, such as file lock information, IO data volume statistics, etc. It is possible to consider maintaining more information in the confidential virtual machine microkernel to prevent this information from being used by attackers for side-channel attacks.

[0081] In one design, the processing module is used to: provide the address space for the compartment container; provide the main thread context for the compartment container; and set the command line instructions according to the startup parameters of the vCPU. In the present application, when the compartment container is started directly, the entry point of the compartment container is the dynamic loader in the C standard library, which loads the user program according to the command line parameters. The preset digests of the C standard library and the template image are embedded in the microkernel image and verified during the remote authentication of the confidential virtual machine. In this way, in the above-mentioned multi-stage startup and verification process, there is no need to initialize and authenticate the confidential virtual machine, language runtime, and third-party library when the function is started. It is only necessary to clone the template container and load the verification function business logic code.

[0082] In one design, the processing module is used to: search for the corresponding template container according to the startup parameters of the vCPU; clone the template container to obtain a function container, the function container is used to load the function business logic; clone the address space of the template container in the copy-on-write mode as the address space of the new partition container; clone the main thread context of the template container as the main thread context of the new partition container. In this application, the startup of the partition container can be optimized by cloning the pre-started template container, saving most of the code loading and verification overhead.

[0083] In addition, in serverless computing scenarios, confidential virtual machines are pre-started during the system initialization phase and shared by all confidential containers. Therefore, the initialization of confidential virtual machines is not on the critical path of container startup, shortening the startup delay of confidential virtual machines.

[0084] In some design schemes, the processing module is used for: the dynamic loader identifies and intercepts the system call for reading the code file from the root file system in the partition container according to the file path; the system call distribution layer in the C standard library queries the file description table; when it is determined that the first file is marked as a code file, the system call distribution layer calculates a hash digest of the read file content and verifies it; when the verification passes, the partition container is authenticated successfully, and the dynamic loader or language runtime returns from the code reading system call.

[0085] In this application, the authentication of the confidential container is completed by the dynamic loader in the partition container C standard library, which identifies and intercepts all system calls that read code files from the root file system in the partition container according to the file path, and calculates the hash digest of the file content during the reading process, and compares it with the file signature (for starting a user function instance from a function image) or the preset digest (for starting a template container from a template image). In this way, a multi-stage startup is adopted, and the confidential virtual machine is shared by all containers after pre-starting. The template container cloning technology is used to pre-load the authentication language runtime and third-party libraries, and the startup overhead of these components is moved out of the critical path of function startup. In other words, only the business logic script needs to be loaded and authenticated when the function starts, and the function startup latency is low. Therefore, in the above multi-stage startup and verification process, there is no need to initialize and authenticate the confidential virtual machine, language runtime, and third-party library when the function starts. It is only necessary to clone the template container and load the verification function business logic code.

[0086] In some designs, the processing module is used to: when it is determined that the first file is marked as a code file, determine that the partition container authentication is successful, and the dynamic loader or language runtime returns from the code reading system call.

[0087] In some designs, the processing module is configured to: when the verification fails, determine that the compartment container authentication fails, and terminate the execution of the compartment container.

[0088] In one design scheme, the processing module is used to: in response to the first request, start the partition container, the partition thread of the partition container sends a fourth request for a system call, the fourth request carries call information, and the call information includes at least one of the following: a system call number, call parameters, and a file descriptor in the call parameters; determine shadow container proxy execution or microkernel execution according to the call information; when it is determined that the microkernel is executed, the fourth request is processed by the microkernel; when it is determined that the shadow container proxy is executed, the fourth request is forwarded to the shadow container for processing, and a security check is performed.

[0089] For example, for 229 open source serverless computing function instances, the functions need to use 92 system calls in total, of which 64 are executed by proxy and 28 are processed by the microkernel. The proxy execution mainly includes IO system calls (46) and system calls involving information maintained in the Linux kernel, such as scheduling parameter settings. The system calls executed by the microkernel mainly include system calls that are vulnerable to attacks after being proxied, such as memory mapping, time, inter-thread synchronization, and random number related system calls.

[0090] Among them, for the IO system calls executed by the agent, the confidentiality and integrity of the IO data need to be protected. According to the needs of the serverless computing function, the IO data can include network data, code file data (reading the root file system), and temporary file data (reading and writing the temporary file system). Among them, network data protection depends on the application to encrypt network data. Code file data protection depends on code signature verification. Temporary file data is stored in the memory file system within the confidential virtual machine.

[0091] For example, in a general scenario, the system call proxy mode based on synchronous switching (VMExit) used in this application may cause high overhead, and the use of asynchronous mode for optimization may be considered.

[0092] In this application, a microkernel is deployed in a confidential virtual machine, and the Linux container software stack is reused through the two technologies of resource granting and system call proxy, which is compatible with container operation, thereby effectively reducing the size of the trusted computing base in the confidential virtual machine and improving system security.

[0093] In one design scheme, the processing module is used to: place the system call parameters corresponding to the fourth request in the shared memory, and the shared memory is the shared memory of the shadow container and the partition container; according to the fourth request, exit the shadow thread of the shadow container from the kernel module to the user state, and the shadow thread executes the system call according to the system call parameters in the shared memory, and places the return value into the shared memory, and the return value includes a memory return value; when the partition thread of the partition container runs, obtain the memory return value from the shared memory, and copy the memory return value from the shared memory to the application memory.

[0094] In some designs, the processing module is used to: after the microkernel or shadow container agent executes a system call, if the system call generates or clears a file descriptor, update a file descriptor table in a call dispatch layer of the partition container.

[0095] In one design, the confidential virtual machine includes at least one compartment container and at least one shadow container, and the compartment container corresponds one-to-one to the shadow container. In the present application, at least one compartment container can be deployed in the confidential virtual machine. By designing a microkernel for confidential virtual machines for serverless computing, it supports multiple compartment containers to securely share a single confidential virtual machine, improves container scalability, and supports shared read-only memory and shared memory communication between containers, reducing the memory overhead of functions and the communication latency between functions. At the same time, the number of single-machine containers is not limited by the number of confidential virtual machines, the container memory overhead is reduced, and the communication overhead between containers is reduced.

[0096] In a seventh aspect, the present application provides a device, comprising: one or more processors; and a memory, wherein the memory stores codes; when the codes are executed by the processors, the device executes the methods described in the first to fifth aspects.

[0097] In an eighth aspect, the present application provides a computer-readable storage medium, which includes computer instructions. When the computer instructions are executed on a device, the device executes the method described in the first to fifth aspects.

[0098] The technical effects corresponding to the second to eighth aspects and any of the implementation methods therein can be referred to the technical effects corresponding to the above-mentioned first and fifth aspects and any of the implementation methods therein, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0099] Figure 1 A schematic diagram of the structure of a device provided in an embodiment of the present application;

[0100] Figure 2 A software architecture diagram for an existing server with a confidential virtual machine;

[0101] Figure 3 A schematic diagram of a software architecture of a server with a confidential virtual machine provided in an embodiment of the present application;

[0102] Figure 4 A schematic diagram of a process for providing a container protection method is provided for an embodiment of the present application;

[0103] Figure 5-1 A flow chart of another container protection method is provided for an embodiment of the present application;

[0104] Figure 5-2 A flow chart of another container protection method is provided for an embodiment of the present application;

[0105] Figure 5-3 A flow chart of another container protection method is provided for an embodiment of the present application;

[0106] Figure 6 A flow chart of another container protection method is provided for an embodiment of the present application;

[0107] Figure 7 A schematic diagram of a process for creating a sub-thread is provided for this application;

[0108] Figure 8 A schematic diagram of the workflow of system call distribution and system call proxy;

[0109] Fig. 9 A flow chart of a gPA page fault error handling method is provided for this application;

[0110] Figure 10-1 Schematic diagram of the total delay of starting a set of empty functions under different schemes;

[0111] Figure 10-2 A schematic diagram of the latency of starting a single Python function with different libraries loaded under different schemes;

[0112] Fig.11 A diagram showing the average memory overhead of launching 20 Python functions with different libraries loaded under different scenarios;

[0113] Fig.12 Schematic diagram of the end-to-end latency of running a single function application under different schemes;

[0114] Fig.13 Schematic diagram of the end-to-end latency of running the FINRA function chain application under different schemes;

[0115] Fig.14 A schematic diagram of the structure of a device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0116] Figure 1 A structural block diagram of a device provided in an embodiment of the present application.

[0117] like Figure 1 As shown, the device 100 may include a processor 110, a memory 120, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, an antenna 1, and a wireless communication module 150, etc.

[0118] It is to be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the electronic device. In other embodiments of the present application, the electronic device may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or arrange the components differently. The components shown in the figure may be implemented in hardware, software, or a combination of software and hardware.

[0119] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processor (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0120] The controller can generate operation control signals according to the instruction operation code and timing signal to complete the control of instruction fetching and execution.

[0121] The processor 110 may also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 is a cache memory. The memory may store instructions or data that the processor 110 has just used or cyclically used. If the processor 110 needs to use the instruction or data again, it may be directly called from the memory. This avoids repeated access, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0122] The charging management module 140 is used to receive charging input from a charger. The charger may be a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 140 may receive charging input from a wired charger through the USB interface 130. In some wireless charging embodiments, the charging management module 140 may receive wireless charging input through a wireless charging coil of an electronic device. While the charging management module 140 is charging the battery 142, it may also power the electronic device through the power management module 141.

[0123] The charging management module 140 and the processor 110. The power management module 141 receives input from the charging management module 140 and supplies power to the processor 110, the memory 120, the wireless communication module 150, etc. In some other embodiments, the power management module 141 may also be disposed in the processor 110. In other embodiments, the power management module 141 and the charging management module 140 may also be disposed in the same device.

[0124] The wireless communication function of the electronic device can be implemented through the antenna 1, the wireless communication module 150, the modem processor and the baseband processor.

[0125] Antenna 1 is used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve the utilization of the antenna. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antenna can be used in combination with a tuning switch.

[0126] The wireless communication module 150 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to electronic devices. The wireless communication module 150 can be one or more devices integrating at least one communication processing module. The wireless communication module 150 receives electromagnetic waves via the antenna 1, modulates the frequency of the electromagnetic wave signal and performs filtering, and sends the processed signal to the processor 110. The wireless communication module 150 can also receive the signal to be sent from the processor 110, modulate the frequency of the signal, amplify it, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, the wireless communication module 150 receives application information sent by the server.

[0127] The memory 120 can be used to store computer executable program codes, which include instructions. The memory 120 may include a program storage area and a data storage area. Among them, the program storage area may store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area may store data created during the use of the electronic device (such as audio data, a phone book, etc.), etc. In addition, the memory 120 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional applications and data processing of the electronic device by running instructions stored in the memory 120, and / or instructions stored in a memory provided in the processor.

[0128] Of course, the electronic device may also include other functional units, which are not limited in the embodiments of the present application.

[0129] In addition, the actions, terms, etc. involved in the various embodiments of the present application can refer to each other without limitation. The names of the messages or parameter names in the messages in the embodiments of the present application are only examples, and other names can also be used in the specific implementation without limitation.

[0130] Figure 2 The following is a schematic diagram of the software architecture of the existing server based on confidential virtual machines. Figure 2 As shown, the above-mentioned device 100 may refer to a server, and the operating system of the server may be a Linux system. Device 100 is based on KataContainers (Kata-CVM) of confidential virtual machines, and uses confidential virtual machine technology to protect the confidentiality and integrity of container data. The existing Kata-CVM is implemented based on secure encrypted virtualization (SEV) provided in the central processing unit (CPU). Kata-CVM follows the original system architecture of Kata Containers, deploys Linux kernel modules in confidential virtual machines, and runs containers on virtual machine Linux kernel modules. However, due to the limitation of hardware resources of the operating system of electronic devices, the number of confidential virtual machines that can be run simultaneously on a single host is limited. For example, on the AMD (Advanced Micro Devices, AMD) platform, the number is limited to 16 or 509. This number limit will significantly affect the scalability of serverless functions. At the same time, memory sharing between containers is not supported, and the requirements of high-density deployment of functions and fast communication of function chains are not met. In addition, due to the complex initialization process and remote authentication process, the confidential virtual machine starts slowly. For example, a Kata Containers container based on AMD SEV takes about 7 seconds to start. If a new confidential virtual machine needs to be created every time a function is started, the response latency of the function will be seriously affected.

[0131] In order to solve the above technical problems, Figure 3 A software architecture diagram of a server with a confidential virtual machine provided in this application. Figure 3As shown, the above-mentioned device 100 may refer to a server, and the operating system of the server may be a Linux system. The microkernel of the system is deployed inside the confidential virtual machine. The device 100 divides the confidential container of a confidential virtual machine into two parts, such as an enclave container and a corresponding shadow container. Among them, the shadow container runs outside the confidential virtual machine and is a Linux native container started by the original container software stack. The shadow container is configured with a root file system (rootFS), a resource control group (cgroup), and a namespace. However, the application load is not run in the shadow container. The enclave container runs in the confidential virtual machine and is used to run the application load. The address space and thread context are provided by the microkernel. The enclave container runs based on the time slice of the shadow container. The threads in the enclave container (enclave thread) correspond to the threads in the shadow container (shadow thread) one by one, and each enclave thread occupies a vCPU in the confidential virtual machine. To ensure the integrity of the control flow, dynamic increase or decrease of vCPUs during the operation phase of the confidential virtual machine is not supported. It can be seen that in this application, it is supported to run multiple containers in a single confidential virtual machine, support sharing of read-only code and shared memory communication between containers, extract the security protection of confidential containers from complex container functions, and the microkernel of the Linux system provides container protection to improve system security. The kernel module of the Linux system provides the functions required by the container.

[0132] based on Figure 3The architecture shown, an embodiment of the present application provides a container protection method, which is applied to device 100, that is, a server. A first operating system and a confidential virtual machine are installed in the server. The confidential virtual machine and the first operating system are deployed on the server, and the confidential container of the confidential virtual machine includes a partition container, and the partition container corresponds to the shadow container outside the confidential virtual machine. The partition container runs the load of the first application, and the shadow container does not run the load of the first application. The method may include: the server receives a first request sent by a first application on the electronic device, and the first request is used to implement a first function. In response to the first request, the server obtains a first resource of the first operating system through a shadow container outside the confidential virtual machine, and the shadow container provides the first resource to the partition container in the confidential virtual machine. The partition container implements the first function based on the first resource, and the first resource is a resource that can be used by the partition container. In this application, by using a shadow container outside the confidential virtual machine to proxy the partition container inside the confidential virtual machine to obtain resources on the first operating system, the program code in the partition container used to call resources on the first operating system can be saved, the program code inside the confidential virtual machine is simplified, and the security risks brought by deploying a large number of programs inside the confidential virtual machine are effectively reduced, and the system security is improved. In this way, the data confidentiality of the applications running in each partition container in the confidential virtual machine is effectively protected, and malicious attacks from other containers and malicious acquisition by administrators are effectively prevented, with high security. In addition, it supports running multiple partition containers in a single confidential virtual machine, supports sharing read-only code and shared memory communication between partition containers, and uses a microkernel to ensure secure isolation between partition containers, with high security.

[0133] Based on this, Figure 4 A flow chart of a container protection method is provided for an embodiment of the present application, such as Figure 4 As shown, the method is applied to a device 100, i.e., a server, on which a confidential virtual machine and a first operating system are deployed, and a partition container is deployed in the confidential virtual machine, and the partition container is used to run the application load. A shadow container is deployed outside the confidential virtual machine, and the shadow container does not run the application load, and the shadow container is used to proxy the partition container to obtain resources on the first operating system. The method may include:

[0134] S401: A first application on an electronic device sends a first request, where the first request is used to implement a first function. Correspondingly, a server receives the first request.

[0135] In one example, the first request is used to call a target function, and the target function is used to implement a target function, and the target function is pre-deployed on the server. Exemplarily, in a serverless scenario, the application program of the first application is deployed on the server. When the first application on the electronic device needs to query information, the first application on the electronic device sends a first request to the server, and the first request carries parameters for calling a function for querying information. The server calls the function through the partition container in the confidential virtual machine according to the first request and implements the information query function corresponding to the function. Of course, the confidential container design of the present invention can not only be used in serverless computing scenarios, but also in more scenarios such as microservices.

[0136] S402. In response to the first request, the server obtains a first resource of the first operating system through a shadow container outside the confidential virtual machine. The shadow container provides the first resource to a partition container in the confidential virtual machine. The partition container implements a first function based on the first resource. The first resource is a resource that can be used by the partition container.

[0137] In one example, the confidential container of the confidential virtual machine may include two parts: a shadow container and a partition container corresponding to the shadow container. From a deployment perspective, the shadow container is deployed outside the confidential virtual machine, and the partition container is deployed inside the confidential virtual machine. That is, in terms of layout, the shadow container is deployed outside the confidential virtual machine, and the partition container is deployed inside the confidential virtual machine. In this way, by separating the program code of the shadow container from the inside of the virtual machine, the program code deployed inside the confidential virtual machine is effectively simplified, which can effectively reduce the risk of the program inside the confidential virtual machine being attacked.

[0138] In one example, the first function may be determined according to a function. For example, the function is a query function, and the first function may be an information query function. For another example, the function may be a networking function, and the first function may be a network connection function. This is not specifically limited in the present application.

[0139] In an example, the first operating system may be a Linux system, and of course may also be other systems. In this application, the Linux system is taken as an example for description.

[0140] In one example, the first resource may include a memory resource of the first operating system. For example, the first resource may be a physical address gPA interval of a confidential virtual machine, which may also be referred to as a client physical address gPA interval. For another example, the first resource may be a virtual central processing unit vCPU.

[0141] A first operating system and a confidential virtual machine are installed in the server. The first operating system may be a Linux system. The confidential container of the confidential virtual machine includes a partition container. The partition container runs in the confidential virtual machine, and the partition container is used to run the application load. The shadow container runs outside the confidential virtual machine, and the shadow container does not run the application load.

[0142] In one example, the confidential virtual machine can be understood as taking the virtual machine as a protection object, and ensuring that the internal load of the virtual machine is not attacked by the virtual machine monitor or physically attacked through mechanisms such as memory encryption. The partition container is used to run the load of the application, and the shadow container can be used as a scheduling agent for the partition container in the first operating system, such as the shadow container can configure memory resources for the partition container. The shadow container does not run the load of the application.

[0143] In one design, the shadow container belongs to the confidential virtual machine, and the shadow container runs outside the confidential virtual machine. The shadow container is used to replace the partition container in the confidential virtual machine to call the resources of the first operating system. In this way, the microkernel is used in the confidential virtual machine CVM to provide a partition container for running confidential applications, and the shadow container outside the confidential virtual machine CVM is managed by the Linux container, reducing the trusted computing base while being compatible with the operation of the container. That is, the confidential virtual machine will separate some programs in the first operating system, effectively reducing the size of the trusted computing base (which is the collection of all software and hardware on which the security of the computer system depends) in the confidential virtual machine, and improving the security of the system.

[0144] In some examples, the confidential virtual machine includes at least one compartment container and at least one shadow container, and the compartment container corresponds to the shadow container one by one. In the present application, at least one compartment container can be deployed in the confidential virtual machine. By designing a microkernel of a confidential virtual machine for serverless computing, it supports multiple compartment containers to securely share a single confidential virtual machine, improves container scalability, and supports shared read-only memory and shared memory communication between containers, reducing the memory overhead of functions and the communication latency between functions.

[0145] The following is a detailed description of the confidential virtual machine workflow, as follows:

[0146] Figure 5-1 , Figure 5-2 and Figure 5-3 A flow chart of a container protection method is provided for this application. Figure 5-1 , Figure 5-2 and Figure 5-3 As shown, the method may include:

[0147] S501. In the initialization phase of the confidential virtual machine, the kernel module builds a virtual central processing unit (vCPU) pool and initializes the vCPU context, marking each vCPU as being in an idle state.

[0148] S502: The shadow thread in the shadow container is started, and the kernel module interface is called to allocate an idle vCPU, and the allocated vCPU is marked as a working state.

[0149] S503: The kernel module sets startup parameters of the partition container in the shared memory corresponding to the vCPU.

[0150] S504: The shadow thread enters the vCPU for execution through the interface provided by the kernel module.

[0151] Specifically, Figure 5-3 As shown, S504 may specifically include:

[0152] S5041. The shadow thread calls the VMEnter instruction to enter the vCPU, which is allocated by the kernel module.

[0153] S5042, the microkernel determines whether there is a partition thread bound to the current vCPU. If there is a partition thread bound to the current vCPU, execute S5043; otherwise, execute S5044.

[0154] S5043. The microkernel executes the partition thread bound to the current vCPU.

[0155] S5044. The microkernel reads the startup parameters of the current vCPU, creates a partition container, and binds the partition thread in the partition container to the current vCPU.

[0156] S5045, the partition thread is executed and sinks to the microkernel.

[0157] S5046. The microkernel sends a second request for reclaiming the container to the kernel module. The second request may be a Hypercall request, which indicates that the partition thread can be reclaimed after execution.

[0158] S5047: The kernel module re-marks the vCPU as idle according to the second request.

[0159] S505: The kernel module determines the reason for the vCPU to exit. If the reason for the exit is a clock interrupt, S504 is executed; if the reason for the exit is a Hypercall request, S506 is executed.

[0160] S506: The kernel module checks the content of the Hypercall request. If the content of the request is to terminate the partition thread, S508 is executed; otherwise, S507 is executed.

[0161] S507: The kernel module processes the Hypercall request, which may be used to proxy the system call in the partition container, and then executes S504.

[0162] S508. The vCPU is marked as idle again by the kernel module, and the shadow thread exits.

[0163] The container protection method provided by this application may be described in detail below according to different stages of the application operation process. Figure 6 A flow chart of a container protection method is provided for this application. Figure 6 As shown, the details are as follows:

[0164] The first stage is the application startup stage.

[0165] like Figure 6 The process of the memory resource granting method corresponding to the resource configuration stage shown in may specifically include: S601-S603, and specifically S601-S603 may be:

[0166] S601: An electronic device receives an operation on a first application.

[0167] The operation may include a network request for remotely invoking a first application on the electronic device, and the like.

[0168] S602: In response to the operation, the first application of the electronic device sends a third request, where the third request is used to call the target function. Correspondingly, the server receives the third request.

[0169] S603. In response to the third request, the server obtains resources of the first operating system through the shadow container outside the confidential virtual machine, and gives the resources to the partition container in the confidential virtual machine. The partition container implements the first function according to the resources.

[0170] The first resource is a resource that can be used by the partition container.

[0171] The server may include a confidential virtual machine microkernel for running the partition container, a Linux kernel module for communication between the shadow container and the partition container, a stub program running in the shadow container, and a C standard library used in the partition container (including a dynamic loader and a system call distribution layer).

[0172] Among them, the compartment container runs based on the time slice of the shadow container. The threads in the compartment container (compartment thread) correspond to the threads in the shadow container (shadow thread) one by one, and each compartment thread occupies a vCPU in the confidential virtual machine. To ensure the integrity of the control flow, dynamic increase or decrease of vCPUs is not supported during the operation phase of the confidential virtual machine. During the initialization phase of the confidential virtual machine, the kernel module builds a vCPU pool and initializes the vCPU context, marking each vCPU as idle. After the shadow container is started, it requests the kernel module to allocate an idle vCPU, and the allocated vCPU is marked as working. The shadow thread enters (VMEnter) the vCPU for execution through the interface provided by the kernel module, and the vCPU builds the compartment container and executes the compartment thread. If the vCPU receives a physical clock interrupt during execution and sinks to the Linux kernel for processing, the shadow thread is interrupted at VMEnter, and the Linux scheduler can cut away the current shadow thread. The next time the shadow thread is scheduled, the context is in the kernel module, and the kernel module re-enters the vCPU for execution. After the vCPU completes the execution of the compartment thread, it sinks to the microkernel, and then the CPU control flow switches back to the shadow thread, and the kernel module re-marks the vCPU as idle.

[0173] In a specific implementation manner, S603 may include S6031-S6033, and specifically S6031-S6033 may be:

[0174] S6031. In response to the third request, the server configures memory resources for the first application, where the application thread of the first application is the main thread, and part of the main thread is a shadow thread and part of it is a partition thread.

[0175] Specifically, S6031 may be specifically as follows: S60311. In response to the third request, the server starts a shadow container. The shadow container configures memory pool parameters for the partition container. The memory pool parameters may include the capacity of the memory pool. The capacity of the memory pool may be determined according to the resource control group parameters in the shadow container.

[0176] That is, when a partitioned container is started, the microkernel will allocate a range in the confidential virtual machine physical address (gPA) space as its memory pool. The size of the memory pool is determined by the shadow container according to the memory resource control group parameters and passed to the microkernel as the partitioned container startup parameters. The memory allocation of the partitioned container is completed in this memory pool.

[0177] S6032. The shadow container initializes the memory resources of the partition container.

[0178] Specifically, S6032 may include S60321-S60324, and specifically S60321-S60324 may be:

[0179] Specifically, it can be:

[0180] S60321. The shadow thread on the processor sends a third request to the kernel module, where the third request is used to request to call the kernel module interface. The kernel module generates a fourth request based on the third request, and sends the fourth request to the microkernel, where the fourth request may include an instruction to enter a confidential virtual machine. The vCPU executes the microkernel. At this point, the vCPU enters a working state, and the microkernel reads the capacity of the shadow thread's memory pool.

[0181] S60322: The microkernel allocates a guest physical address (gPA) interval for the shadow thread according to the capacity of the memory pool, and sends a fifth request to the kernel module, the fifth request being used to request exit to the shadow thread. Afterwards, the kernel module exits to the shadow thread according to the fifth request.

[0182] S60323. The shadow thread exits to user mode and creates a host virtual address (hVA) interval.

[0183] S60324. The shadow thread calls the kernel module interface to establish a binding between the gPA interval and the hVA interval.

[0184] That is, the shadow container calls the interface provided by the kernel module to bind an interval of the same size in its own virtual address (hVA) space to the gPA interval.

[0185] In simple terms, memory allocation in a compartment container is converted to memory allocation in a shadow container. When a compartment container is started, the microkernel allocates a range in the confidential virtual machine physical address (gPA) space as its memory pool. The size of the memory pool is determined by the shadow container based on the memory resource control group parameters and passed to the microkernel as the compartment container startup parameters. The memory allocation of the compartment container is completed in this memory pool. The shadow container calls the interface provided by the kernel module to bind a range of the same size in its own virtual address (hVA) space to the gPA range.

[0186] After the binding between the gPA interval and the hVA interval is established at S60324, the granting of resources is completed, so there are memory resources for starting the partition container. The electronic device starts the partition container. The specific process is as follows:

[0187] like Figure 6 The process of the method for starting the partition container corresponding to the startup phase shown in may specifically include:

[0188] S6033. The server starts the partition container corresponding to the shadow thread.

[0189] Specifically, S6033 may include S60331-S60339, wherein S60331-S60339 may specifically be: S60331, the microkernel determines the startup mode of the partition container according to the vCPU startup parameter, and the startup mode may include a direct startup mode or a clone startup mode. The following startup process is as follows:

[0190] First, for direct boot mode:

[0191] S60332. The microkernel provides an address space for the partition container, and the address space maps the C standard function library (Cstandard library).

[0192] S60333. The microkernel provides a main thread context for the partition container. The main thread entry point is the dynamic loader in the C standard function library. The dynamic loader loads the user program according to the command line parameters.

[0193] S60334. The microkernel sets the startup parameters on the main thread stack according to the vCPU startup parameters, that is, the program command line instructions.

[0194] In this application, when the compartment container is started directly, the compartment container entry point is the dynamic loader in the C standard library, which loads the user program according to the command line parameters. The preset digests of the C standard library and the template image are embedded in the microkernel image and verified during the remote authentication of the confidential virtual machine. In this way, in the above multi-stage startup and verification process, when the function is started, there is no need to initialize and authenticate the confidential virtual machine, language runtime, and third-party library. It only needs to clone the template container and load the verification function business logic code.

[0195] Second, for the clone startup mode.

[0196] S60335. The microkernel searches for the corresponding template container according to the vCPU startup parameters.

[0197] For example, the code of a template container is represented as follows:

[0198] # / scripts / main.py

[0199] import numpy

[0200] import cofunc

[0201] import serverless_sdk

[0202] #Become a template container, waiting to be cloned

[0203] Cofunc.zyqote_create('zyqote_numpy')

[0204] S60336. The microkernel clones the template container to obtain the function container and loads the function business logic.

[0205] For example, the code of a function container is represented as follows:

[0206] #The template container is cloned to obtain the function container, and the function business logic is loaded

[0207]

[0208] S60337. Use the copy-on-write mode to clone the address space of the template container as the address space of the new partition container.

[0209] S60338. Clone the main thread context of the template container and use it as the main thread context of the new partition container.

[0210] The above S60335-S60338 can be understood as: after the template container completes library loading, it calls the microkernel interface (such as the zygote_create interface) to register it as a template container. The microkernel clones the template container to obtain the function container. When the function container is started, the shadow container can specify a template container as the basis for cloning and starting. The cloned partition container can be restored from the zygote_create interface, load the function business logic code and start receiving call requests. In this application, the startup of the partition container can be optimized by cloning the pre-started template container, eliminating most of the code loading and verification overhead.

[0211] S6034: After obtaining the main thread context and address space of the partition container through direct startup mode or clone startup mode, execute the main thread.

[0212] In the embodiment of the present application, in the serverless computing scenario, the confidential virtual machine is pre-started during the system initialization phase and shared by all confidential containers, so the initialization of the confidential virtual machine is not on the critical path of container startup, thereby reducing startup delay.

[0213] In addition, the startup of the shadow container can optimize the startup of the partition container by cloning the pre-started template container, eliminating most of the code loading and verification overhead. The microkernel provides two startup modes: direct startup and clone startup. The template (partition) container is a partition container that runs a special type of function. The function of this type of function is to load the language runtime and third-party libraries. You can get the template container by starting the template image in direct startup mode.

[0214] In addition, in serverless computing scenarios, confidential virtual machines are pre-started during the system initialization phase and shared by all confidential containers. Therefore, the initialization of confidential virtual machines is not on the critical path of container startup, shortening the startup delay of confidential virtual machines.

[0215] After the compartment container is started, it needs to be authenticated. The specific process is as follows:

[0216] like Figure 6 The process of the authentication method for the compartment container corresponding to the authentication stage shown in may specifically include:

[0217] S6035. The dynamic loader in the C standard library of the partition container identifies and intercepts all system calls in the partition container that read code files from the root file system according to the file path.

[0218] S6036. The system calls the distribution layer to query the file description table and check whether the current file is marked as a code file.

[0219] Specifically, the preset digests of the C standard library and template images are embedded in the microkernel image. During the reading process, the file content hash digest is calculated and compared with the file signature (for launching a user function instance from a function image) or the preset digest (for launching a template container from a template image) to determine whether the current file is marked as a code file.

[0220] S6037: If the current file is marked as a code file, the hash digest of the read file content is calculated and verified, and if the verification passes, S6038 is executed. If the verification fails, S6040 is executed.

[0221] S6038. If the current file is not marked as a code file, the authentication is successful, and the dynamic loader or language runtime returns from the code reading system call.

[0222] Among them, for files read from the template image, a summary is preset in the microkernel. For files read from the function image, the user embeds the signature in it during construction. The user key used for the signature is stored in the microkernel, and the key is obtained from the key management service when the confidential virtual machine is started.

[0223] S6039, Authentication failed, calling the microkernel system call to terminate the partition container execution.

[0224] In this application, the confidential container authentication is completed by the dynamic loader in the partition container C standard library, which identifies and intercepts all system calls that read code files from the root file system in the partition container according to the file path, and calculates the file content hash digest during the reading process, and compares it with the file signature (for starting a user function instance from a function image) or the preset digest (for starting a template container from a template image). In this way, in the above multi-stage startup and verification process, there is no need to initialize and authenticate the confidential virtual machine, language runtime, and third-party library when the function is started. It only needs to clone the template container and load the verification function business logic code.

[0225] The second stage is the application running stage.

[0226] For different application services, electronic devices can trigger different processing flows, as follows:

[0227] First, create a sub-thread process.

[0228] New threads can be created during the execution of the shadow container. First, a new vCPU is allocated to the kernel module, then a partition thread is created and bound to the vCPU, and finally the shadow container is requested to create the corresponding shadow thread. Threads in the same partition container can call the interface provided by the microkernel for synchronization operations. The partition thread waiting for the synchronization event is marked as a waiting state by the microkernel, and is restored to the execution state after the synchronization event arrives. When the shadow thread enters the vCPU, if the corresponding partition thread is in a waiting state, the vCPU will switch the control flow back to the shadow thread and ask the shadow thread to give up the CPU. The specific process is as follows:

[0229] Figure 7 The present application provides a flowchart of a method for creating a child thread. Figure 7 As shown, the method may include: S701-S709, wherein S701-S708 may specifically be:

[0230] S701. The partition thread in the partition container sends a sixth request for creating a child thread to the microkernel.

[0231] S702: The microkernel sends a seventh request to the kernel module for requesting the kernel module to allocate an idle vCPU to the partition thread. The request may be a Hypercall request.

[0232] S703: The kernel module allocates a new vCPU to the partition thread according to the seventh request.

[0233] S704, the microkernel checks whether the partition thread has been bound to the new vCPU. If the partition thread has been bound to the new vCPU, S702 is executed; if the partition thread has not been bound to the new vCPU, S705 is executed.

[0234] S705. The microkernel provides a partition thread context for the partition container and binds the partition thread to the new vCPU.

[0235] S706: The microkernel sends an eighth request to the kernel module for requesting the shadow container to create a shadow thread corresponding to the partition thread. The request may be a Hypercall request.

[0236] S707: The shadow container creates a shadow thread corresponding to the partition thread according to the eighth request.

[0237] S708. After the child thread is created, the partition thread returns from the microkernel system call.

[0238] Second, the system call distribution process.

[0239] Figure 8 The workflow of system call distribution and system call proxy is shown. Figure 8 As shown: S801-S806, wherein S801-S806 may specifically be:

[0240] S801. The partition thread in the partition container initiates a system call, which is intercepted by the system call dispatch layer in the C standard library.

[0241] S802: The system call distribution layer determines the execution mode according to the call information. The call information may include the system call number, call parameters and file descriptors in the call parameters. The execution mode may include proxy execution or microkernel execution.

[0242] The call information includes a system call number; S802 may be specifically implemented as follows: S8021, the system call distribution layer checks the system call number, and determines the execution mode when the system call number meets the first preset condition.

[0243] In another specific implementation, the call information may include call parameters. S8022: The system call distribution layer checks the call parameters, and when the call parameters meet the second preset condition, determines the execution mode. For example, the second preset condition may be: opening a file in a non-tmpfs path requires proxy execution.

[0244] In another specific implementation, the call information may include a file descriptor in the call parameter. S8023. The system call distribution layer checks the file descriptor in the call parameter. When the file descriptor in the call parameter satisfies the third preset condition, the execution mode is determined. For example, the third preset condition may be that reading the file opened in the shadow container requires proxy execution.

[0245] S803: When the system call dispatching layer determines that the microkernel is to be executed, the system call is processed inside the microkernel.

[0246] S804: When the system call distribution layer determines that the proxy is executed, the system call is forwarded to the shadow container for processing and a security check is performed.

[0247] Among them, security checks may include file integrity checks, etc.

[0248] In a specific implementation manner, S804 may include S8041-S8046, wherein S8041-S8046 may specifically be:

[0249] S8041. The partition thread copies memory parameters from the application memory to the shared memory. The shared memory is the shared memory of the shadow container and the partition container. The shared memory is created when the confidential container is started.

[0250] S8042. The partition thread puts the system call parameters into the shared memory.

[0251] S8043. When the partition thread sends a request for a proxy system call to the kernel module via the microkernel, the kernel module exits the shadow thread from the kernel module to the user state according to the request.

[0252] S8044: The shadow thread executes the system call according to the system call parameters in the shared memory, and puts the return value into the shared memory. The return value may include a memory return value.

[0253] S8045: The shadow thread calls the kernel module interface and enters the vCPU for execution. That is, the shadow thread calls the kernel module interface to resume execution of the partition thread.

[0254] S8046. The partition thread obtains the memory return value from the shared memory, and copies the memory return value from the shared memory to the application memory.

[0255] After the microkernel or agent executes the system call, S805 is executed, which is as follows:

[0256] S805: If the system call generates or clears a file descriptor, the file descriptor table in the call distribution layer is updated.

[0257] S806: After the system call is completed, the partition thread returns from the system call dispatching layer of the microkernel.

[0258] In the embodiment of the present application, according to the survey of 229 open source serverless computing function instances, the function needs to use 92 system calls in total, of which 64 are executed by proxy and 28 are processed by the microkernel. The proxy mainly executes IO system calls (46) and system calls involving information maintained in the Linux kernel, such as scheduling parameter settings. The microkernel mainly processes system calls that have attack risks after the proxy, such as memory mapping, time, inter-thread synchronization, and random number related system calls. For IO system calls executed by the proxy, it is necessary to protect the confidentiality and integrity of IO data. According to the needs of the serverless computing function, IO data is divided into network data, code file data (reading the root file system), and temporary file data (reading and writing temporary file system). Network data protection depends on application encryption of network data. Code file data protection depends on code signature verification. Temporary file data is stored in the memory file system in the confidential virtual machine.

[0259] 3. gPA page fault handling process.

[0260] Fig. 9 A flow chart of a gPA page fault error handling method is provided for this application. Fig. 9 As shown, the method may include: S901-S905, wherein S901-S905 may specifically be:

[0261] S901. Based on the confidential virtual machine hardware mechanism, when a page fault occurs on the gPA, the microkernel intercepts the page fault information.

[0262] S902: The microkernel sends a ninth request for requesting to process page fault error information to the kernel module. The request may be a Hypercall request.

[0263] S903. The kernel module queries the hVA interval corresponding to the gPA interval where the gPA position of the page fault is located according to the ninth request, and triggers a page fault in the hVA interval of the shadow container. Processing one gPA interval each time is to reduce the number of gPA page faults.

[0264] S904: The kernel module maps the physical page mapped on the hVA interval to the gPA interval.

[0265] S905. After the kernel module processes the ninth request, it enters the vCPU for execution. The microkernel performs mapping verification on the unverified mappings in the gPA interval, and the page fault processing is completed.

[0266] In summary, when a page fault occurs in the gPA range, Linux transfers it to the kernel module for processing, and the kernel module handles the page fault at the corresponding position in the hVA range; the physical page mapped in the hVA range is synchronously mapped to the gPA range. In order to reduce the number of page faults in the gPA space and improve performance, the kernel module pre-maps (pre-fault) a continuous gPA range after a page fault.

[0267] To defend against malicious attacks by the Linux kernel on the memory mapping of partitioned containers, it is necessary to combine the confidential virtual machine hardware mechanism with the microkernel software mechanism. To defend against memory duplication attacks, the confidential virtual machine hardware ensures that the same physical page cannot be mapped to two different gPAs, while the microkernel ensures that the gPA ranges used by different partitioned containers do not overlap. To defend against memory remapping attacks, the confidential virtual machine hardware requires that the mapping of gPA to physical memory must be confirmed by the microkernel before it can be used. For the same memory pool, the microkernel can confirm the mapping on one gPA at most once.

[0268] In practical applications, the method provided in the embodiments of the present application is used for verification, and the verification results described in the following embodiments are obtained, which are as follows:

[0269] In Example 1, a confidential container based on a confidential virtual machine is used in a microbenchmark test. The test uses a confidential container to run an empty function or a Python function, and measures the startup delay and memory overhead of the confidential container. The empty function is written in C language and does not contain business logic. Various third-party libraries are loaded in the Python function, but no business logic is included. For Python functions, the effects of this application and SOCK in direct startup and clone startup modes were tested respectively. The template container in clone mode pre-loaded the Python runtime and third-party libraries. In terms of startup delay, in addition to Kata-CVM, RunC, and SOCK, this test is also compared with the virtual machine sandbox container Kata-QEMU (using QEMU monitor), Kata-FC (using Firecracker monitor) and Kata-Template (using virtual machine snapshot optimized startup).

[0270] Figure 10-1The total latency of concurrently starting a group of empty functions under different schemes is shown. Due to the complex CVM initialization process, Kata-CVM has the highest startup latency. Kata-FC also has a high startup latency due to the overhead of concurrently creating a virtual block device root file system. Kata-QEMU has a high startup latency because it needs to initialize the Linux kernel at startup. Kata-Template uses virtual machine snapshot technology to avoid Linux kernel initialization, but this technology cannot be applied to confidential virtual machines. RunC and SOCK have low startup latency, among which SOCK has the lowest latency due to the use of lightweight container technology. Due to the startup of the shadow container, the startup latency of this application is close to that of SOCK, and it only takes 11.8ms to start a single empty function, which is 606 times lower than the startup latency of Kata-CVM.

[0271] Figure 10-2 The delay of starting a single Python function with different libraries loaded under different schemes is shown. In direct startup mode, the startup delay of this application is higher than that of SOCK. For example, for the OpenCV case that needs to load a 250M dynamic link library, the startup delay of this application is 7 times that of SOCK. This is because this application needs to read the library file from the root file system to the confidential virtual machine memory and calculate the hash summary during the library loading process, while SOCK only needs to map the library file to the address space. Using clone startup can significantly reduce the startup delay of this application. In clone startup mode, the startup delay of this application in all test cases is within 12ms, which is 736 to 869 times lower than Kata-CVM. Using clone startup only requires loading and verifying the business logic script of the function during function startup. After testing, the loading and verification of Python and NodeJS (mainstream serverless computing language) function scripts in the open source function set can be completed within 1ms.

[0272] Due to the overhead of QEMU and the Linux kernel, the average memory overhead of starting 100 Kata-CVM empty function containers is 242MB. The average memory overhead of this application when starting 1000 empty function containers is 3.6MB, which is close to RunC. Fig.11 The average memory overhead of starting 20 Python functions loaded with different libraries under different schemes is shown. In direct startup mode, the memory overhead of this application is higher than that of RunC. This is because this application needs to read all library files into the confidential virtual machine memory, and RunC supports on-demand loading and page cache sharing because it uses file mapping technology. In clone startup mode, since each partition container shares memory through copy-on-write, the memory overhead of this application is significantly reduced. By eliminating Linux / QEMU overhead and supporting shared memory between containers, the memory consumption of this application is reduced by 19 to 56 times compared to Kata-CVM.

[0273] For empty functions and Python functions based on clone startup optimization, this application significantly outperforms the existing confidential virtual machine container technology Kata-CVM in terms of startup latency and memory consumption.

[0274] In the second embodiment, confidential containers based on confidential virtual machines are applied to serverless computing applications, including single-function applications and function chain applications. Single-function applications come from the open source serverless computing test sets FunctionBench, SeBS and PIE Benchmark. These applications involve various application scenarios, including privacy-related scenarios such as user authentication, face recognition, data encryption, and sentiment analysis. These applications are written in Python or NodeJS. The function chain application uses the financial audit application FINRA, which mainly includes two functions: a data download function and a data audit function, which are written in Python. First, the data download function downloads financial data from a remote server and saves it to the local Redis storage, and then a set of data audit functions concurrently audits and calculates the data. Using this application, data is transmitted based on shared memory between functions without using Redis storage. For the Python functions in the above applications, this application uses the clone startup mode with SOCK, and assumes that all required third-party libraries are pre-loaded in the template container. For NodeJS functions, since cloning of multi-threaded NodeJS runtimes is not yet supported, the direct startup mode is adopted.

[0275] Fig.12The end-to-end delay of running a single-function application under different schemes is shown, including function startup delay and function execution delay. Thanks to the significant reduction in function startup delay, the end-to-end delay of this application is reduced by 2 to 522 times compared to Kata-CVM. For Python functions, compared to the native container SOCK, the end-to-end overhead and execution delay overhead of this application are up to 3.5%. The overhead mainly comes from data encryption and decryption when uploading and downloading data and switching in and out of confidential virtual machines. For example, in face recognition applications, it is necessary to download the original image and recognition model from the object storage, and upload the result image with the recognition mark added after the recognition is completed. The proxy system call in this application will have obvious overhead compared to the native system call. The proxy execution of the getpid system call requires 27750 clock cycles, while the native system call only requires 208 clock cycles. In this application, except for the network system call, the remaining proxy system calls are not used frequently (such as sched_getaffinity, getuid), and there are no cases of frequent network access in the tested functions, so the proxy system call does not cause obvious execution delay overhead. This application uses a temporary file system inside a confidential virtual machine, thus eliminating the proxy overhead for temporary file access. If the proxy executes temporary file-related system calls, the end-to-end latency overhead can be up to 6.8% compared to SOCK. For NodeJS functions, since direct startup is used, this application has overhead in code loading and verification, and the end-to-end latency is up to 4 times higher than SOCK.

[0276] Fig.13 The end-to-end latency of running the FINRA function chain application under different schemes is shown. When 50 data audit functions are started concurrently, the end-to-end latency of this application is reduced by 848 times compared to Kata-CVM. Compared with the version that uses Redis to store and transmit data, this application uses shared memory to transmit data, eliminating the network and data encryption and decryption overhead, and reducing the end-to-end latency by 7.3 times.

[0277] For serverless computing applications, compared with the existing confidential virtual machine container technology Kata-CVM, this application significantly reduces the startup delay and does not bring significant execution delay overhead, so the end-to-end delay of this application is significantly lower than Kata-CVM. For functions using clone startup optimization, the end-to-end overhead of this application compared to the native container system SOCK does not exceed 5%.

[0278] Combination of the above Figure 3-Figure 13 The container protection method provided by the embodiment of the present application is described in detail. Fig.14 The device provided in the embodiments of the present application is described in detail.

[0279] In one possible design, Fig.14This is a schematic diagram of the structure of the device provided in the embodiment of the present application. Fig.14 As shown, the device 1400 may include: a transceiver module 1401 and a processing module 1402. The device 1400 may be used to implement the functions of the devices involved in the above method embodiments.

[0280] Optionally, the transceiver module 1401 is used to support the device 1400 to execute Figure 4 S402 in; and / or, for supporting the device 1400 to execute Figure 6 S602 in.

[0281] Optionally, the processing module 1402 is used to support the device 1400 to execute Figure 4 S402 in; and / or, for supporting the device 1400 to execute Figure 5-1 S501-S508 in; and / or, for supporting the device 1400 to execute Figure 6 S603 in; and / or, for supporting the device 1400 to execute Figure 7 S701-S708 in; and / or, for supporting the device 1400 to execute Figure 8 S801-S806 in; and / or, for supporting the device 1400 to execute Fig. 9 S901-S905 in.

[0282] Among them, the transceiver module may include a receiving module and a sending module, and may be implemented by a transceiver or a transceiver-related circuit component, and may be a transceiver or a transceiver module. The operations and / or functions of each module in the device 1400 are respectively to implement the corresponding process of the container protection method described in the above method embodiment. All relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module, and for the sake of brevity, they will not be repeated here.

[0283] Optionally, Fig.14 The device 1400 shown may also include a storage module ( Fig.14 (not shown), the storage module stores a program or instruction. When the transceiver module 1401 and the processing module 1402 execute the program or instruction, Fig.14 The device 1400 shown can execute the container protection method described in the above method embodiment.

[0284] Fig.14 The technical effects of the device 1400 shown can refer to the technical effects of the container protection method described in the above method embodiment, and will not be repeated here.

[0285] In addition to being in the form of device 1400, the technical solution provided in the present application may also be a functional module or chip in the device, or a device used in conjunction with the device.

[0286] It should be noted that all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0287] An embodiment of the present application also provides a computer-readable storage medium, including instructions, which, when executed on a computer, enable the computer to execute any of the above methods.

[0288] The embodiment of the present application also provides a computer program product including instructions, which, when executed on a computer, enables the computer to execute any of the above methods.

[0289] An embodiment of the present application also provides a chip, which includes a processor and an interface circuit, the interface circuit is coupled to the processor, the processor is used to run a computer program or instruction to implement the above method, and the interface circuit is used to communicate with other modules outside the chip.

[0290] All or part of any features or steps in the embodiments of the present application can be freely combined, and the combined technical solutions are also within the scope of the present application.

[0291] In the description of this application, unless otherwise specified, " / " means "or", for example, A / B can mean A or B. "And / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, "at least one" means one or more, and "plurality" means two or more. The words "first", "second", etc. do not limit the quantity and execution order, and the words "first", "second", etc. do not limit them to be different.

[0292] In the description of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0293] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0294] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the modules or units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0295] The units described as separate components may or may not be physically separated, and the components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0296] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0297] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium, including several instructions to enable a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read only memory (ROM), random access memory (RAM), disk or optical disk and other media that can store program code.

[0298] The above contents are only specific implementation methods of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A container protection method, applied to a server, characterized in that: The method comprises: Receiving a first request sent by a first application on an electronic device, where the first request is used to implement a first function; In response to the first request, a first resource of a first operating system is obtained through a shadow container outside the confidential virtual machine; the shadow container provides the first resource to a partition container in the confidential virtual machine, the partition container implements the first function according to the first resource, and the first resource is a resource that can be used by the partition container; Among them, the first operating system and the confidential virtual machine are both installed in the server, the partition container in the confidential virtual machine corresponds to the shadow container outside the confidential virtual machine, the partition container runs the load of the first application, and the shadow container does not run the load of the first application.

2. The method according to claim 1, characterized in that In response to the first request, calling the first resource on the first operating system through the shadow container, and providing the first resource to the partition container by the shadow container, including: In response to the first request, the shadow container is started; the shadow container sends a second request to the kernel module of the first operating system, wherein the second request is used to request allocation of an idle virtual central processing unit vCPU to the partition thread of the partition container; During the execution of the vCPU, a partition container corresponding to the shadow container is constructed, and a partition thread of the partition container is executed.

3. The method according to claim 2, characterized in that Also includes: When the partition container is started, a client physical address gPA interval is allocated to the partition container, the gPA interval is determined according to the memory resources of the shadow thread of the shadow container, and the gPA interval is used as a startup parameter of the partition container; After the partition container is allocated a gPA interval, the shadow thread of the shadow container calls the interface of the kernel module to bind the gPA interval to the host virtual address hVA interval of the shadow container.

4. The method according to claim 3, characterized in that: Also includes: When a page fault occurs in the gPA interval, intercepting page fault information; Sending a third request to the kernel module, wherein the third request is used to request processing of the page fault error information; According to the third request, query the hVA interval corresponding to the gPA interval where the gPA position of the page fault is located, and trigger a page fault in the hVA interval of the shadow container; The physical page mapped on the hVA interval is mapped to the gPA interval.

5. The method according to claim 2, characterized in that: Also includes: Determine a startup mode of the partition container according to a startup parameter of the vCPU corresponding to the partition container, where the startup mode includes a direct startup mode or a clone startup mode; Start the partition container in the direct start mode or the clone start mode to obtain the main thread context and address space of the partition container; The address space maps a C standard library; the entry point of the main thread is a dynamic loader in the C standard library, and the dynamic loader loads the program according to command line instructions.

6. The method according to claim 5, characterized in that The step of starting the partition container in the direct start mode includes: providing the address space for the compartment container; providing the main thread context for the compartment container; The command line instruction is set according to the startup parameters of the vCPU.

7. The method according to claim 5, characterized in that The starting the partition container in the clone startup mode includes: Searching for a corresponding template container according to the startup parameters of the vCPU; Clone the template container to obtain a function container, where the function container is used to load function business logic; Adopting a copy-on-write mode to clone the address space of the template container as the address space of the new partition container; The main thread context of the template container is cloned as the main thread context of the new partition container.

8. The method according to claim 7, characterized in that Also includes: The dynamic loader identifies and intercepts a system call for reading a code file from a root file system in the partition container according to the file path; The system call distribution layer in the C standard library queries the file description table; When it is determined that the first file is marked as a code file, the system calls the distribution layer to calculate a hash digest for the read file content and verify it; When the verification passes, the partition container is authenticated successfully, and the dynamic loader or language runtime returns from the code reading system call.

9. The method according to claim 8, characterized in that Also includes: When it is determined that the first file is marked as a code file, it is determined that the partition container authentication is successful, and the dynamic loader or language runtime returns from the code reading system call.

10. The method according to claim 8, characterized in that Also includes: When the verification fails, it is determined that the partition container authentication fails, and the partition container execution is terminated.

11. The method according to claim 1, characterized in that: In response to the first request, calling the first resource on the first operating system through the shadow container, and providing the first resource to the partition container by the shadow container, including: In response to the first request, the partition container is started, and the partition thread of the partition container sends a fourth request for a system call, wherein the fourth request carries call information, and the call information includes at least one of the following: a system call number, a call parameter, and a file descriptor in the call parameter; Determine, according to the call information, whether the shadow container agent executes or the microkernel executes; When it is determined that the microkernel is executed, the microkernel processes the fourth request; When it is determined that the shadow container proxy is executed, the fourth request is forwarded to the shadow container for processing, and a security check is performed.

12. The method according to claim 11, characterized in that When it is determined that the shadow container proxy is executed, forwarding the fourth request to the shadow container for processing includes: Putting a system call parameter corresponding to the fourth request into a shared memory, wherein the shared memory is a shared memory of the shadow container and the partition container; According to the fourth request, exit the shadow thread of the shadow container from the kernel module of the first operating system to the user state, the shadow thread executes the system call according to the system call parameters in the shared memory, and puts the return value into the shared memory, wherein the return value includes a memory return value; When the partition thread of the partition container runs, the memory return value is obtained from the shared memory, and the memory return value is copied from the shared memory to the application memory.

13. The method according to claim 12, characterized in that The method further includes: after the microkernel or the shadow container agent executes a system call, if the system call generates or clears a file descriptor, updating a file descriptor table in a call dispatch layer of the partition container.

14. The method according to any one of claims 1 to 13, characterized in that The confidential virtual machine includes at least one partition container, and the partition container corresponds to the shadow container one by one.

15. The method according to any one of claims 1 to 14, characterized in that The first request carries parameters of a target function, the target function is used to implement a target function, and the target function is determined by the target function; the partition container is used to run the target function, and the target function is pre-deployed on the server.

16. A device, characterized in that include: The transceiver module and the processing module, wherein: The transceiver module is used to receive a first request sent by a first application on the electronic device, where the first request is used to implement a first function; The processing module is used to obtain a first resource of a first operating system through a shadow container outside the confidential virtual machine; the shadow container provides the first resource to a partition container in the confidential virtual machine, and the partition container implements the first function according to the first resource, and the first resource is a resource that can be used by the partition container; Among them, the first operating system and the confidential virtual machine are both installed in the server, the partition container in the confidential virtual machine corresponds to the shadow container outside the confidential virtual machine, the partition container runs the load of the first application, and the shadow container does not run the load of the first application.

17. A device, characterized in that The device comprises: one or more processors; and a memory, wherein codes are stored in the memory; when the codes are executed by the processors, the device performs the method according to any one of claims 1 to 15.

18. A computer-readable storage medium, characterized in that: The method comprises computer instructions, which, when executed on a device, cause the device to execute the method according to any one of claims 1 to 15.

Images