Microkernel-based container building and runtime system and method

Abstract

This invention provides a microkernel-based container building and running system and method, including: a namespace functional module, a control group functional module, and a fault recovery functional module. The namespace functional module is used to partition static system resources, dividing mount point data, network protocol stack data, and process management data. Different application containers reside in different namespaces and access different system resources, achieving system resource isolation. The control group functional module is used to partition dynamic system resources, statistically analyzing and limiting CPU resources, memory resources, and I / O bandwidth resources. Different application containers reside in different control groups and use limited resources, achieving system resource limitation. The fault recovery functional module is used to handle system service crashes caused by memory errors. This invention achieves enhanced isolation and security while also improving performance.

Description

Technical Field

[0001] This invention relates to the field of virtualization technology, and more specifically, to a microkernel-based container building and running system and method. Background Technology

[0002] Containers provide an isolated environment for operating systems and application execution, and their application has become increasingly widespread in recent years, leading to a corresponding rise in the importance of container security. Container isolation is a crucial aspect of security; a well-designed container system ensures that a failure in one container will not affect other containers or the operating system. Container isolation is key to supporting container reliability and scalability. However, with the continuous development of operating systems, traditional container isolation mechanisms face new problems and challenges. For example, the ever-expanding codebase of operating systems and software leads to numerous undiscovered vulnerabilities in applications, which can be easily exploited by malicious containers. This allows a faulty container to steal data from other containers running on the same kernel or seize resources belonging to other containers. Researchers in industry and academia have proposed a series of technical solutions to enhance container isolation, including using new software architectures to increase isolation, enhancing the isolation of traditional operating systems, using new hardware to enhance isolation, and using operating systems with strong isolation capabilities.

[0003] In traditional Linux operating systems, the isolation of processes is not strong. Different processes share resources such as network, CPU, memory, and disk, making it easy for malicious processes to attack the data flow of other processes and steal their data. Processes with high security requirements need additional protection mechanisms to isolate themselves from other processes. Linux provides namespaces and control groups to help processes achieve isolation. The namespace mechanism provides a resource isolation scheme. Each namespace can specify its own processes, inter-process communication, network, files, and other system resources, which are invisible to other namespaces. By placing different processes in different namespaces, resource isolation between processes can be achieved, preventing malicious processes from directly stealing data from other processes. The control group mechanism can limit the amount of network, CPU, memory, and disk resources used by each process, preventing one process from consuming excessive system resources and affecting the performance of other processes.

[0004] Containers are built upon namespace and control group mechanisms, providing an isolated execution environment for processes running within them. LXC is a typical example of a container. LXC, short for Linux Container, is a container natively supported by Linux. LXC treats each namespace as a container, with each container possessing its own process view, inter-process communication, file system, and network view. Due to the isolation provided by namespaces, different containers cannot access each other's data or affect the control flow of execution within other containers. Its architecture is as follows... Figure 14 As shown. In LXC, each container runs an operating system and corresponding applications. To prevent a single container from consuming excessive system resources and thus affecting the performance of other containers and the kernel, LXC uses a control group mechanism to limit the upper limit of system resources that process groups running in each namespace can use, that is, to limit the amount of network, CPU, memory, disk, and other resources that each container can use.

[0005] Although containers enhance their isolation by using namespace and control group mechanisms, they still have two major isolation problems: security isolation and performance isolation.

[0006] Security isolation refers to whether one container can access data in other containers or affect the security of other containers. Containers are more secure than ordinary processes, but they still have security isolation issues. This is because although containers are isolated by namespace and control group mechanisms, they are still processes running on the same operating system. For a container to function properly, it must trust the entire operating system, using the operating system's code as its Trusted Code Base (TCB). However, the size of the operating system's codebase is expanding rapidly; the Linux kernel's codebase has increased from 150,000 lines in version 1.0 to over 20 million lines in version 4.15, with the TCB expanding more than 100 times. This inevitably leads to a large number of hidden vulnerabilities within Linux. If a container triggers a vulnerability in the operating system, it may have the privilege to access or attack other containers on that operating system or even the operating system itself. For example, the published Shocker attack on the Docker platform exploited a design flaw in system calls related to file handles, allowing containers to access arbitrary files on the operating system, including files in other containers, thus compromising container security isolation.

[0007] Performance isolation refers to whether one container can affect the performance of other containers. In LXC and Docker, a container can by default occupy all CPU resources. If the deployer does not manually set the CPU resource limit for each container, when a CPU-intensive program is running in one container, it will affect the performance of other containers. When CPU usage is high, the efficiency of databases running in LXC executing transactions will decrease by about 10%. Furthermore, due to numerous vulnerabilities inherent in the operating system, a container can not only exploit these vulnerabilities to attack the security of other containers or the operating system, but it can also exploit vulnerabilities to force the operating system to allocate more resources to itself, preempting resources that should belong to other containers or the operating system, thus affecting the performance of other containers. Data shows that when disk I / O resources are fully utilized, the efficiency of databases running in LXC will decrease by about 15%. When memory resources are fully utilized, its efficiency will decrease by nearly 30%.

[0008] It can be seen that although traditional containers enhance process isolation, they still have security isolation and performance isolation issues, leaving much room for improvement. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention provides a microkernel-based container building and running system and method.

[0010] According to the present invention, a microkernel-based container building and running system and method are provided, the solution of which is as follows:

[0011] Firstly, a microkernel-based container building and running system is provided, the system comprising: a namespace function module, a control group function module, and a fault recovery function module;

[0012] The namespace function module is used to divide static system resources; it divides mount point data, network protocol stack data, and process management data, so that different application containers reside in different namespaces and access different system resources, thereby achieving system resource isolation.

[0013] Control group function module: used to divide dynamic system resources, and to count and limit CPU resources, memory resources and I / O bandwidth resources. Different application containers are in different control groups and use limited resources to achieve system resource limitation.

[0014] Fault recovery module: Used to handle system service crashes caused by memory errors;

[0015] The system also includes a system container to enhance resource statistics and fault recovery for system service processes.

[0016] Preferably, the namespace function module includes: creation, joining, leaving, destruction, and use of file system mount point namespaces;

[0017] The steps for creating a file system mount point namespace are as follows:

[0018] Step 1): Request initiation: The container management program sends a request to the system container via inter-process communication to create a namespace for the file system mount point;

[0019] Step 2): Obtain the working path sent by the container management program and determine whether the path length is less than 255 characters;

[0020] Step 3): Obtain the mount point information of the working path in the original state, and obtain the mount point information from the mount point information of the original state according to the working path;

[0021] Step 4): Send a request to the corresponding file system to create a namespace. The specific process is described in the section on creating a namespace in the file system.

[0022] Step 5): Create a new mount point information linked list;

[0023] Step 6): Initialize a new mount point information linked list, and add the mount point information obtained in Step 3) as the mount point information of the path to the linked list;

[0024] Step 7): Obtain the usable namespace IDs from the array;

[0025] Step 8): Add the new mount point information linked list to the array element of the system container;

[0026] Step 9): Inter-process communication returns, completing the creation of the new namespace.

[0027] Preferably, the steps for adding the file system mount point namespace are as follows:

[0028] Step 1): Initiate a request to join the namespace. The container management program needs to pass the ID of the mount point system container namespace and the system service type to the kernel.

[0029] Step 2): Obtain the mount point system container namespace ID and system service type passed in by the container management program;

[0030] Step 3): Fill the mount point system container namespace ID passed in by the container manager into the location of the mount point system container namespace of the application container process;

[0031] Step 4): Complete the namespace join request and return from kernel mode to user mode.

[0032] Preferably, the steps for exiting the file system mount point namespace are as follows:

[0033] Step 1): Initiate an exit namespace request. The container management program needs to pass the system service type of the mount point system container into the kernel.

[0034] Step 2): Obtain the system service type passed in by the container management program, that is, the system service type of the mount point system container;

[0035] Step 3): Clear the namespace data corresponding to the mount point system container in the kernel;

[0036] Step 4): Complete the namespace exit request and return from kernel mode to user mode.

[0037] Preferably, the steps for destroying the file system mount point namespace are as follows:

[0038] Step 1): Destruction request is initiated. The container management program sends a request to the system container through inter-process communication to destroy the namespace of the file system mount point.

[0039] Step 2): Obtain the namespace ID sent by the container management program;

[0040] Step 3): Check if the namespace ID is 0. If it is 0, it represents the root namespace and cannot be destroyed.

[0041] Step 4): Check if the namespace corresponding to the namespace ID exists. If it does not exist, it cannot be destroyed.

[0042] Step 5): Obtain the mount point information for the path;

[0043] Step 6): Send a request to the corresponding file system to destroy the namespace;

[0044] Step 7): Clear the current mount point information linked list, including releasing memory and assigning the pointer to 0;

[0045] Step 8): Clear the corresponding namespace elements in the array of system containers;

[0046] Step 9): The inter-process communication request returns, completing the destruction of the namespace.

[0047] Preferably, the steps for using a file system mount point namespace are as follows:

[0048] Step 1): The application container initiates a request, sending an inter-process communication request to the mount point system service;

[0049] Step 2): Obtain the namespace ID of the current application container in kernel mode;

[0050] Step 3): Obtain the corresponding system container from the structure related to the inter-process communication request;

[0051] Step 4): Switch the process to the system container process and pass the namespace ID;

[0052] Step 5): Obtain the namespace ID passed by the kernel;

[0053] Step 6): Find the mount point linked list information of the corresponding namespace from the array based on the namespace ID and switch to it;

[0054] Step 7): Execute the specific application container request;

[0055] Step 8): After the request is processed, return to kernel mode;

[0056] Step 9): Complete the request and return to the application container.

[0057] Preferably, the control group functional module includes:

[0058] Statistics and limits on CPU resources: The total number of clock interrupts received by a process is used as the CPU resource usage; when a clock interrupt is triggered, the kernel obtains the process running on the CPU that triggered the clock interrupt and increments the number of clock interrupts received by the process by 1.

[0059] The scheduling policy is modified so that when the time slice of the current process is 0, the scheduling policy is entered. A process is taken out from the waiting queue, and the CPU utilization is calculated, which is the ratio of the number of clock interrupts received by the process to the total number of clock interrupts received by all processes in the waiting queue. The actual CPU utilization is then compared with the CPU utilization set by the user.

[0060] If a process has high CPU utilization, reduce its time slice or even keep it in a waiting state for a long time; if a process has low CPU utilization, increase its time slice.

[0061] By modifying the scheduling policy, the time slice of each process is controlled individually. When each process completes a full scheduling round, it ensures that the CPU utilization of each process meets the user-defined value.

[0062] Statistics and limits on memory resources: When a page fault occurs, the exception is caught, and the allocated physical page size is added to the corresponding application container process and application container, and the usage of physical page memory resources is statistically analyzed.

[0063] If the physical memory usage of the application container exceeds the user-defined value during this process, the application container process that exceeds the memory usage limit must be killed or its operation must be paused.

[0064] Statistics and limitation of I / O bandwidth resources: By adding a rate limiter system service between the system services of the file system and the system services of the device driver, each I / O request will be captured by the rate limiter system service, and the service will determine whether the request is satisfied based on the type and size of the I / O request. If not, the request will be suspended; if so, the request will be sent and the token count in the rate limiter system service will be updated.

[0065] The number of tokens gradually increases as the system runs, and there is a maximum limit to the number of tokens. Once the limit is reached, the number of tokens can no longer be increased.

[0066] Preferably, the fault recovery function module includes: when a fault occurs, capturing the fault, the most common fault being a page fault; after capturing the fault, exiting the system container process that caused the fault and reclaiming all resources;

[0067] Then, a message to restart the system container is sent to the process management system container. Upon receiving the message, the process management system container immediately restarts the system container and rebuilds the contents of the system container and inter-process communication.

[0068] Preferably, the system container is also used to manage system service processes in user space, to collect statistics on the CPU and memory overhead of system service processes, and to manage system service processes in a unified manner.

[0069] The system accelerates the microkernel's I / O speed through direct memory access, manages the data to be transferred using capability, and directly copies data from the device to memory or writes data directly from memory to the device through direct memory access, thereby reducing the amount of inter-process communication and the number of repeated memory copies.

[0070] Secondly, a microkernel-based container building and running method is provided, the method comprising:

[0071] Namespace functionality steps: Divide static system resources; divide mount point data, network protocol stack data, and process management data into different namespaces, allowing different application containers to access different system resources, thus achieving system resource isolation;

[0072] Control group function steps: Divide dynamic system resources, count and limit CPU resources, memory resources and I / O bandwidth resources, different application containers are in different control groups, use limited resources, and realize the limitation of system resources;

[0073] Fault recovery steps: Handling system service crashes caused by memory errors.

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

[0075] 1. This invention proposes the concept of a system container. A system container means that not only user-run programs are contained in the container, but all system services will run in the container. This can ensure more accurate statistics on the use of system resources.

[0076] 2. This invention uses direct memory access to improve microkernel performance, skipping repeated memory copies and inter-process communication;

[0077] 3. This invention can provide flexible container support in a microkernel environment and can be flexibly ported to various microkernel platforms without relying on the environment support of a specific monolithic kernel. Through flexible interrupt isolation and scheduling algorithm independence, it can further support the real-time requirements within a specific container. The system container used allows for more accurate resource statistics and separate management of the behavior of system services, achieving stronger resource isolation capabilities.

[0078] 4. Compared with the prior art, the present invention can achieve performance improvement while obtaining stronger isolation and security.

[0079] Other beneficial effects of the present invention will be explained in detail through the introduction of specific technical features and technical solutions in specific embodiments. Those skilled in the art should be able to understand the beneficial technical effects brought about by these technical features and technical solutions through the introduction of these technical features and technical solutions. Attached Figure Description

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

[0081] Figure 1 This is a diagram of the architecture of the present invention;

[0082] Figure 2 This is a schematic diagram of the namespace design architecture in this invention;

[0083] Figure 3 This is a schematic diagram illustrating the process of creating a file system mount point namespace in this invention.

[0084] Figure 4 This is a schematic diagram illustrating the process of adding a file system mount point namespace in this invention.

[0085] Figure 5 This is a schematic diagram of the exit process of the file system mount point namespace in this invention;

[0086] Figure 6This is a schematic diagram illustrating the destruction process of the file system mount point namespace in this invention;

[0087] Figure 7 This is a schematic diagram illustrating the usage flow of the file system mount point namespace in this invention;

[0088] Figure 8 This is a schematic diagram of the control group design architecture in this invention;

[0089] Figure 9 This is a schematic diagram of the fault recovery process in this invention;

[0090] Figure 10 This is a schematic diagram of the direct memory access I / O process in this invention;

[0091] Figure 11 CPU resource statistics;

[0092] Figure 12 For memory control group processing flow;

[0093] Figure 13 For I / O control group processing flow;

[0094] Figure 14 It uses the LXC architecture. Detailed Implementation

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

[0096] This invention provides a microkernel-based container building and running system, referring to... Figure 1 As shown, the system includes a namespace function module, a control group function module, and a fault recovery function module.

[0097] This invention also innovatively proposes system containers to enhance resource statistics and fault recovery for system service processes, and proposes direct memory access to accelerate microkernel I / O.

[0098] I. Namespace Functional Module: Refer to Figure 2 As shown, this is used to divide static system resources; mount point data, network protocol stack data, and process management data are divided, and different application containers reside in different namespaces and access different system resources, thereby achieving system resource isolation.

[0099] The main ways to use namespaces include creating, joining, leaving, destroying, and using them.

[0100] Namespace creation is completed in user space, including obtaining user requests, creating and initializing system resources, etc. Different namespaces execute different system resource creation and initialization processes.

[0101] For file system mount point namespaces, it is necessary to obtain the user-provided working path, mount point information linked list creation and initialization, etc.

[0102] For the LwIP network protocol stack namespace, it is necessary to create new contiguous arrays to store network data and new linked lists to store network interfaces.

[0103] For process management namespaces, it is necessary to select a process node in the process tree as the new root node, and as the root node for access.

[0104] The addition of a namespace is completed in kernel mode. The container management program will pass the corresponding namespace ID and the type of the corresponding system container to kernel mode, and then fill the data into the corresponding position in kernel mode, thus completing the addition of the namespace.

[0105] The exit of a namespace is completed in kernel mode. The container manager passes the corresponding system container type to kernel mode, and deletes the data at the corresponding location in kernel mode, thus completing the exit of the namespace.

[0106] The destruction of a namespace is done in user space and requires the destruction of system resources created when the namespace was created.

[0107] The use of namespaces depends on inter-process communication. When inter-process communication is needed, the ID of the corresponding namespace is obtained in kernel mode, and then the ID is passed to the upper-level system container, which then selects the corresponding system resource to use.

[0108] Specifically, refer to Figure 3 As shown, the steps to create a file system mount point namespace are as follows:

[0109] Step 1): Request initiation: The container management program sends a request to the system container via inter-process communication to create a namespace for the file system mount point;

[0110] Step 2): Obtain the working path sent by the container management program and determine whether the path length is less than 255 characters;

[0111] Step 3): Obtain the mount point information of the working path in the original state, and obtain the mount point information from the mount point information of the original state according to the working path;

[0112] Step 4): Send a request to the corresponding file system to create a namespace. The specific process is described in the section on creating a namespace in the file system.

[0113] Step 5): Create a new mount point information linked list;

[0114] Step 6): Initialize a new mount point information linked list, and add the mount point information obtained in Step 3) as the mount point information of the path to the linked list;

[0115] Step 7): Obtain the usable namespace IDs from the array;

[0116] Step 8): Add the new mount point information linked list to the array element of the system container;

[0117] Step 9): Inter-process communication returns, completing the creation of the new namespace.

[0118] Reference Figure 4 As shown, the steps to add a file system mount point namespace are as follows:

[0119] Step 1): Initiate a request to join the namespace. The container management program needs to pass the ID of the mount point system container namespace and the system service type to the kernel.

[0120] Step 2): Obtain the mount point system container namespace ID and system service type passed in by the container management program;

[0121] Step 3): Fill the mount point system container namespace ID passed in by the container manager into the location of the mount point system container namespace of the application container process;

[0122] Step 4): Complete the namespace join request and return from kernel mode to user mode.

[0123] Reference Figure 5 As shown, the steps to exit the file system mount point namespace are as follows:

[0124] Step 1): Initiate an exit namespace request. The container management program needs to pass the system service type of the mount point system container into the kernel.

[0125] Step 2): Obtain the system service type passed in by the container management program, that is, the system service type of the mount point system container;

[0126] Step 3): Clear the namespace data corresponding to the mount point system container in the kernel;

[0127] Step 4): Complete the namespace exit request and return from kernel mode to user mode.

[0128] Reference Figure 6As shown, the steps to destroy a file system mount point namespace are as follows:

[0129] Step 1): Destruction request is initiated. The container management program sends a request to the system container through inter-process communication to destroy the namespace of the file system mount point.

[0130] Step 2): Obtain the namespace ID sent by the container management program;

[0131] Step 3): Check if the namespace ID is 0. If it is 0, it represents the root namespace and cannot be destroyed.

[0132] Step 4): Check if the namespace corresponding to the namespace ID exists. If it does not exist, it cannot be destroyed.

[0133] Step 5): Obtain the mount point information for the " / " path;

[0134] Step 6): Send a request to the corresponding file system to destroy the namespace. The specific process will be described in the section on destroying the namespace in the file system.

[0135] Step 7): Clear the current mount point information linked list, including releasing memory and assigning the pointer to 0;

[0136] Step 8): Clear the corresponding namespace elements in the array of system containers;

[0137] Step 9): The inter-process communication request returns, completing the destruction of the namespace.

[0138] Reference Figure 7 As shown, the steps for using a file system mount point namespace are as follows:

[0139] Step 1): The application container initiates a request, sending an inter-process communication request to the mount point system service;

[0140] Step 2): Obtain the namespace ID of the current application container in kernel mode, because the namespace ID has already been written to the corresponding location during the previous process of adding the namespace;

[0141] Step 3): Obtain the corresponding system container from the structure related to the inter-process communication request;

[0142] Step 4): Switch the process to the system container process and pass the namespace ID;

[0143] Step 5): Obtain the namespace ID passed by the kernel;

[0144] Step 6): Find the mount point linked list information of the corresponding namespace from the array based on the namespace ID and switch to it;

[0145] Step 7): Execute the specific application container request;

[0146] Step 8): After the request is processed, return to kernel mode;

[0147] Step 9): Complete the request and return to the application container.

[0148] II. Control Group Functional Modules: Refer to Figure 8 As shown, this method is used to dynamically allocate system resources. It can statistically analyze and limit CPU resources, memory resources, and I / O bandwidth resources. Different application containers are in different control groups and use certain limited resources to achieve system resource limitation.

[0149] The use of control groups mainly includes resource statistics and resource restrictions.

[0150] The methods for monitoring and limiting CPU resources are as follows:

[0151] CPU resource usage is measured by the total number of clock interrupts received by a process. Because clock interrupts are triggered at fixed time intervals, when a clock interrupt is triggered, the kernel can obtain the process currently running on the CPU that triggered the clock interrupt and increment the number of clock interrupts received by the process by 1.

[0152] In order to control the CPU utilization of processes, in addition to the CPU resource statistics mentioned above, the scheduling policy also needs to be modified.

[0153] Once the current process's time slice reaches 0, the scheduling policy is entered. A process is retrieved from the waiting queue, and its CPU utilization is calculated. This utilization is the ratio of the number of clock interrupts received by that process to the total number of clock interrupts received by all processes in the waiting queue. The actual CPU utilization is then compared to the user-defined CPU utilization.

[0154] If a process has high CPU utilization, its time slice will be reduced, or the process may even be kept in a waiting state for a long time; if a process has low CPU utilization, its time slice will be increased.

[0155] With the modified scheduling strategy described above, the time slice of each process can be controlled individually. When each process completes a full scheduling round, it can be ensured that the CPU utilization of each process meets the user-defined value.

[0156] The methods for monitoring and limiting memory resources are as follows:

[0157] The page fault exception is caught, and the allocated physical page size is added to the corresponding application container process and application container to count the amount of physical page memory resources used.

[0158] If the application container's physical memory usage exceeds the user-defined value during this process, the application container process that exceeds the memory usage limit needs to be killed or its operation needs to be paused.

[0159] The memory control group's resource statistics are performed when the kernel allocates physical memory pages. Physical memory data is collected in the functions `get_pages` and `free_pages`, and the data is added to the currently running process.

[0160] To limit the physical memory used by application containers, a judgment needs to be made every time physical memory is measured. The memory measurement is judged on a process group basis. After the memory data of each application container process is processed, the corresponding data is updated to the process group, and it is judged whether the memory of the process group exceeds the user's preset value.

[0161] If the actual physical memory usage of a process group exceeds the user's preset value, there are two options.

[0162] 1. Kill processes in a process group that exceed the memory limit and release the memory for those processes;

[0163] 2. The process remains in a waiting state until the processes in the process group release enough memory to make the waiting process available;

[0164] The methods for calculating and limiting I / O bandwidth resources are as follows:

[0165] The I / O control group limits I / O bandwidth using a rate limiter. It intercepts and parses all I / O requests destined for the device driver system container to obtain the corresponding request and size, and then performs statistical analysis. The logic for controlling bandwidth using the rate limiter primarily relies on the token bucket algorithm. The token bucket algorithm works by maintaining a token bucket. The system generates tokens at a constant rate, and the token bucket has a fixed capacity. When the token bucket is full, no new tokens can be added.

[0166] When a request arrives, the request type and size are parsed, a token bucket is selected based on the type, and the number of tokens in the bucket is checked. If there are enough tokens, the request is issued; otherwise, the request is blocked until there are enough tokens.

[0167] The token bucket algorithm can be used to limit the number of read / write operations and the number of bytes read / written within a certain period of time.

[0168] In order to generate tokens at a constant rate, the rate limiter also maintains a timer that runs once per second to generate a certain number of tokens, while also checking whether there are any blocked I / O requests that have already met the issuance requirements.

[0169] I / O request blocking is implemented using a notification mechanism. When insufficient tokens are detected, a notification capability is created and the system enters a blocking state. The I / O request and the notification capability are added to a queue, which is checked by a timer to see if there is a suitable I / O request. If so, the blocked I / O request is awakened, and the delivery process is completed.

[0170] III. Fault Recovery Function Module: Refer to Figure 9 As shown, this is used to handle system service crashes caused by memory errors;

[0171] When a fault occurs, it can be caught. The most common fault is a page fault. After catching it, the system container process that caused the fault can be exited and all resources can be reclaimed.

[0172] Then, a message to restart the system container is sent to the process management system container. Upon receiving the message, the process management system container will immediately restart the system container and rebuild the contents of the system container and inter-process communication.

[0173] Specifically, the fault recovery function is mainly divided into two parts: fault capture and fault recovery. When the application container uses the system container function normally, the system container will record the operation of the application container and store it in a memory area of ​​the kernel.

[0174] When an error occurs and causes a page fault, the error is transmitted to the kernel. The kernel then determines whether the error occurred in the system container. If so, it reclaims all inter-process communication and lock resources in the system container and exits the system container. All inter-process communication processes currently executing inside the system container will receive a retry return code.

[0175] Then, the message is sent to the process management system container. After receiving the message, the process management system container will attempt to restart the system container and rebuild the contents of the system container according to the previously recorded operations, as well as rebuild inter-process communication. Once the rebuild is complete, it can be used again.

[0176] To more accurately measure the resource usage of system containers and perform fault recovery for system service processes, this invention includes all system service processes in containers. In this way, the resources of system service processes can also be measured and limited. If the limit is exceeded, the fault recovery function can be triggered to restart and restore the system container.

[0177] IV. System Containers: System service processes located in user space are also managed as containers, which can more accurately count the CPU and memory consumption of system service processes and manage them in a unified manner.

[0178] V. Direct Memory Access: Refer to Figure 10 As shown, direct memory access accelerates the I / O speed of the microkernel. The specific method is to use capabi lity to manage the data that needs to be transferred, and to copy the data directly from the device to memory or write the data directly from memory to the device through direct memory access, thereby reducing the amount of inter-process communication and the number of repeated memory copies.

[0179] This invention also provides a microkernel-based container building and running method. The microkernel-based container building and running system can be implemented by executing the process steps of the microkernel-based container building and running method. That is, those skilled in the art can understand the microkernel-based container building and running method as a preferred embodiment of the microkernel-based container building and running system. The method includes:

[0180] Namespace functionality steps: Divide static system resources; divide mount point data, network protocol stack data, and process management data into different namespaces, allowing different application containers to access different system resources, thus achieving system resource isolation;

[0181] Control group function steps: Divide dynamic system resources, count and limit CPU resources, memory resources and I / O bandwidth resources, different application containers are in different control groups, use limited resources, and realize the limitation of system resources;

[0182] Fault recovery steps: Handling system service crashes caused by memory errors.

[0183] The present invention will now be described in more detail.

[0184] A microkernel-based container building and running system is proposed, which adopts a microkernel architecture and divides the functional design of namespace, control group, and fault recovery.

[0185] Firstly, in terms of namespace functionality design, refer to Figure 2 As shown, the namespace function of the microkernel container in this scheme is mainly located in the EL0 layer, and some implementation code is also deployed in the EL1 layer.

[0186] For a newly started application container, add the corresponding namespace's capability to it and initialize it to 0. 0 means that it uses the default initialization system resources in the corresponding system container.

[0187] When a user sends an inter-process communication request to obtain services from a system container, it first obtains the capability of the corresponding system container's namespace from the kernel and then carries the namespace information to the user-space system container to select different system resources.

[0188] Different system resource allocation methods need to be designed for different system containers in a microkernel.

[0189] For the file system mount point system container, its function is to select different mount points based on the path provided by the user process and return the corresponding ID and inter-process communication capability. The application container sends specific file operations to the corresponding file system system container based on the corresponding ID and capability, and also provides mount and umount operations.

[0190] The system container primarily stores mount point information within the system, so this information needs to be isolated. The system container uses a linked list to maintain a set of mount point information. In order to ensure that new file system mount point namespaces have different mount point information, a new linked list of mount point information needs to be created each time a new file system mount point namespace is created to store the mount point information within the new file system mount point namespace. The application container will select the corresponding linked list of mount point information based on the file system mount point namespace it is in.

[0191] The LwIP network protocol stack system container's function is to provide network support for upper-layer applications and execute network protocol stack operations such as open, close, read, and write according to user requests.

[0192] The system container primarily stores a list of network interfaces and network data. The network interface list is a series of network interfaces organized using a linked list; the network data is a contiguous array used to store the data sent and received by the network interfaces.

[0193] In the LwIP network protocol stack system container, each time a new network protocol stack namespace is created, an empty linked list needs to be created to store the network interfaces in the new network protocol stack namespace, a loopback network interface is initialized for it, and a new contiguous array in memory is created to process the network data in the new network protocol stack namespace.

[0194] For process management system containers, the function of the system container is to provide process ID and process tree support, and to be responsible for operations such as creating new processes and recycling zombie processes.

[0195] The main information stored in this system container is the first process created when the system starts, which is the root node of the process tree.

[0196] In a process management system container, each time a new process management system container is created, a node in the process tree needs to be selected as the new root node of the process tree. Any process created in the process management namespace will be generated downwards according to the tree structure and will not be observed by other process management namespaces.

[0197] The control group's functional design mainly includes CPU, memory, and I / O bandwidth.

[0198] The CPU control group is implemented at the EL1 layer for microkernel application containers. In order to add the functionality of the CPU control group to meet the real-time requirements, a priority-based time-slice round-robin scheduling algorithm is used to support the real-time operation of application containers.

[0199] Priority-based time-slice round-robin scheduling algorithms achieve real-time performance by assigning priorities to processes. Different processes have different priorities, and the specific process to be scheduled is selected based on the process priority during scheduling.

[0200] If a process has a higher priority, it will be scheduled first during scheduling.

[0201] If processes have the same priority, then time-slice round-robin scheduling will be used to schedule processes with the same priority.

[0202] CPU control groups cannot be used for processes of different priorities because process preemption can occur, making it impossible to accurately measure CPU utilization. However, CPU control groups can be used for processes of the same priority. When processes with the same priority are scheduled, the CPU utilization of the process will be measured during scheduling, and the CPU control group will be used for control.

[0203] Reference Figure 11 As shown, CPU resource usage is measured by the number of clock interrupts received by a process. Because clock interrupts are triggered at fixed time intervals, when a clock interrupt is triggered, the kernel can obtain the process currently running on the CPU that triggered the clock interrupt and increment the number of clock interrupts received by the process by 1.

[0204] Because of inter-process communication (IPC) in a microkernel architecture, it's necessary to consider situations where IPC behavior causes changes in the process's ownership. IPC can lead to a switch in process execution. When an application container's process requests services from the system container via IPC, it is no longer the original process but has switched to the system container's process. However, this portion of runtime still belongs to the application container's process.

[0205] To address this issue, we focus on the invariants in the inter-process communication (IPC) process within the application container: the scheduling context. IPC passes the scheduling context of the application container process to the system container process, so we store CPU resource statistics in the scheduling context. Even if the application container process switches to the system container process via IPC, we can still accurately track the execution time of the application container process.

[0206] In order to control the CPU utilization of a process, in addition to the CPU resource statistics mentioned above, the scheduling policy also needs to be modified to adjust the CPU utilization of the process by adjusting the process's time budget.

[0207] Once the current process's time slice reaches 0, the scheduling policy is entered. A process is retrieved from the waiting queue, and its CPU utilization is calculated. This is the ratio of the number of clock interrupts received by the process to the total number of clock interrupts received by all processes in the waiting queue. The actual CPU utilization is then compared with the user-defined CPU utilization.

[0208] If a process has high CPU utilization, its time slice will be reduced, or the process may even be kept in a waiting state for a long time; if a process has low CPU utilization, its time slice will be increased.

[0209] The above scheduling strategy allows for individual control of the time slice of each process. When each process completes a full scheduling round, the CPU utilization of each process will meet the user's set value.

[0210] The memory control group is also implemented at the EL1 layer. The memory control group limits the amount of physical memory used by the application container, including all anonymous memory pages that have already been mapped to page tables; for shared memory, this portion of physical memory is allocated to the process that uses this portion of memory pages for the first time.

[0211] Reference Figure 12 The diagram shows the processing flow of the memory control group.

[0212] Similarly, inter-process communication needs to be considered. Therefore, the same approach is used here to count the corresponding data in the process execution body. This ensures that even after inter-process communication occurs, the physical memory pages used can still be correctly counted in the application container.

[0213] I / O bandwidth resources are statistically analyzed above the driver layer. In a microkernel architecture, the block device I / O call flow is: application container -> file system container -> driver system container. To statistically analyze all block device I / O requests, a new system container called a rate limiter is added between the file system container and the driver system container to control I / O bandwidth. All data inflows and outflows pass through the rate limiter.

[0214] Reference Figure 13 The diagram shows the processing flow of the I / O control group.

[0215] The logic for controlling I / O bandwidth in a rate limiter primarily relies on the token bucket algorithm. The token bucket algorithm works by maintaining a token bucket, where the system continuously generates tokens at a constant rate, and the token bucket has an upper limit. When the token bucket is full, newly generated tokens cannot be added to it.

[0216] When an I / O request arrives, the type and size of the I / O request are parsed. Based on the type, the system selects to read the token bucket or write the token bucket, checks whether there are enough tokens in the token bucket, and if so, subtracts the specified number of tokens and issues the request. If there are not enough tokens, the request is blocked and the system waits for a sufficient number of tokens to arrive.

[0217] The token bucket algorithm can be used to limit the number of I / O read / write operations and the I / O read / write bandwidth.

[0218] In order to continuously generate tokens at a constant rate, the rate limiter maintains a timer that runs once per second to generate a certain number of tokens, while also checking whether there are any blocking I / O requests that have already met the issuance requirements.

[0219] The blocking and waking of I / O requests adopts a notification mechanism. When the number of tokens is insufficient, a notification capability is created and the system enters a blocking state. The I / O request and the notification capability are added to a queue. This queue is checked in a timer to see if there is an I / O request that meets the requirements. If so, the blocked I / O request is woken up, and the I / O request issuance process is completed.

[0220] To ensure high system reliability, we have designed a fault recovery function for errors inside the system container. This function can ensure that when an internal error occurs and the system container crashes, the crash error can be captured, the system container can be restarted, the critical data within it can be recovered, and the application container's requests can be re-executed.

[0221] Reference Figure 9 The diagram shows the fault recovery process.

[0222] When a page fault occurs in the system container process, the system can catch the error at the point of the page fault and analyze whether the error originated from the system container process. If the error originated from the system container process, it means that there is an error in the logic or memory inside the system container process, and it needs to be restarted.

[0223] First, because it is a page fault, we can obtain all inter-process communication data managed by the current system container process through the system container process data, release all inter-process communication locks, set the return value of the application container process, set the inter-process communication connection to be unusable, and finally exit the system container process. When the system container exits, it will send a message to the process management system container. After receiving the message, the process management system container will attempt to restart the system container and restore the internal data.

[0224] Traditionally, containers wrap user-space applications within them. However, in microkernel scenarios, system services that were originally in kernel space are moved up to user space. Therefore, system service processes can also be included in containers, allowing all system resources to be managed by the containers. In this way, the resources of system service processes can be monitored more granularly. Combined with the fault recovery capabilities mentioned in point 1, when errors occur in the system containers, they can be captured and restarted without affecting the normal operation of the system.

[0225] The management scope of system containers differs from that of application containers. Application containers manage namespaces and control groups, while system containers manage control groups and fault recovery.

[0226] Application containers need to manage the system resources they can access and limit the total amount of resources they can access. Therefore, namespaces are used to manage the system resources they can access, and control groups are used to limit the total amount of resources that application containers can access.

[0227] The failure at the application container is caused by the user's own code, so the system is not responsible for recovering from the user's error. However, the failure of the system container is the responsibility of the system. In order to better isolate performance and to ensure that the CPU and memory usage of the system container does not exceed the specified limits, the system container will track the CPU and memory usage. If the CPU and memory resource usage exceeds the rated limits, the failure recovery will be triggered, and the system container will be restarted and restored to ensure that the application container can be served normally.

[0228] This invention innovatively proposes using direct memory access to accelerate the I / O speed of microkernels. For common microkernels, since different system containers are in different address spaces, and the amount of memory used for inter-process communication between address spaces is limited, it is necessary to divide a request into multiple requests and complete a complete request through continuous memory copying and a large amount of inter-process communication.

[0229] There exists a scenario where a user wants to read a 1MB file, but the shared memory is only 4KB. Therefore, the user needs to divide one request into multiple requests. As the request travels from the file system to the driver, other metadata needs to be carried, so the amount of memory actually available to store the file content becomes smaller and smaller. This results in about a thousand inter-process communications from the user to the file system, and as many as two thousand inter-process communications from the file system to the driver. This situation will worsen as the inter-process communication chain lengthens, causing the number of inter-process communications to increase exponentially throughout the entire request.

[0230] To address the two problems mentioned above, this invention proposes a scheme to accelerate microkernel I / O using direct memory access. (See also...) Figure 10 The diagram shows the flow of direct memory access (DMI) operations.

[0231] When an application container sends a request, if it's a read request, the application container will pre-allocate a memory space of a specified size and pass this memory space as a capability to the file system container and the device driver system container. After receiving this capability, the device driver system container first checks whether the physical address corresponding to the capability has been mapped. If the memory is not mapped, it will first map the physical memory. Then, it can directly perform direct memory access operations on the physical memory contained in the capability, writing data directly from the device to the corresponding physical memory space. Because this part is asynchronous, the application container's inter-process communication can return directly without carrying any data back, eliminating memory copying and unnecessary inter-process communication operations.

[0232] If it is a write request, the application container will take the physical memory space corresponding to the data to be written as a capability, and send this capability along with other request data to the file system container and the device driver system container. After the device driver system container gets this capability, it can directly write the data from memory to the specified location of the driver through direct memory access. After the execution request is issued, it can return.

[0233] Once a read or write request is completed, an interrupt is triggered, informing the system that the current request has been completed.

[0234] This invention provides a microkernel-based container building and running system and method, which can provide flexible container support in a microkernel environment and can be flexibly ported to various microkernel platforms without relying on the environment support of a specific monolithic kernel. This invention further supports the real-time requirements within specific containers through flexible interrupt isolation and scheduling algorithm independence. The system containers used in this invention allow for more accurate resource statistics and separate management of system service behavior, achieving stronger resource isolation capabilities. Compared with existing technologies, this invention achieves performance improvements while obtaining stronger isolation and security.

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

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

Claims

1. A microkernel-based container building and running system, characterized in that, include: Namespace function module, control group function module, and fault recovery function module; The namespace function module is used to divide static system resources; it divides mount point data, network protocol stack data, and process management data, so that different application containers reside in different namespaces and access different system resources, thereby achieving system resource isolation. Control group function module: used to divide dynamic system resources, and to count and limit CPU resources, memory resources and I / O bandwidth resources. Different application containers are in different control groups and use limited resources to achieve system resource limitation. Fault recovery module: Used to handle system service crashes caused by memory errors; The system also includes a system container to enhance resource statistics and fault recovery for system service processes; The control group functional modules include: Statistics and limits on CPU resources: The total number of clock interrupts received by a process is used as the CPU resource usage; when a clock interrupt is triggered, the kernel obtains the process running on the CPU that triggered the clock interrupt and increments the number of clock interrupts received by the process by 1. The scheduling policy is modified so that when the time slice of the current process is 0, the scheduling policy is entered. A process is taken out from the waiting queue, and the CPU utilization is calculated, which is the ratio of the number of clock interrupts received by the process to the total number of clock interrupts received by all processes in the waiting queue. The actual CPU utilization is then compared with the CPU utilization set by the user. If a process's CPU utilization is higher than the user-defined CPU utilization, the time slice is reduced, or the process is made to wait for a long time; if a process's CPU utilization is lower than the user-defined CPU utilization, the time slice is increased. By modifying the scheduling policy, the time slice of each process is controlled individually. When each process completes a full scheduling round, it ensures that the CPU utilization of each process meets the user-defined value. Statistics and limits on memory resources: When a page fault occurs, the exception is caught, and the allocated physical page size is added to the corresponding application container process and application container, and the usage of physical page memory resources is statistically analyzed. If the physical memory usage of the application container exceeds the user-defined value during this process, the application container process that exceeds the memory usage limit must be killed or its operation must be paused. Statistics and limitation of I / O bandwidth resources: By adding a rate limiter system service between the system services of the file system and the system services of the device driver, each I / O request will be captured by the rate limiter system service, and the service will determine whether the request is satisfied based on the type and size of the I / O request. If not, the request will be suspended; if satisfied, the request will be sent and the token count in the rate limiter system service will be updated. The number of tokens gradually increases as the system runs, and there is a maximum limit to the number of tokens. Once the limit is reached, the number of tokens can no longer be increased. The system container is located in user space. System service processes are also managed as containers. The CPU and memory overhead of system service processes are statistically analyzed, and system service processes are managed in a unified manner. The system accelerates the microkernel's I / O speed through direct memory access, manages the data to be transferred using capability, and directly copies data from the device to memory or writes data directly from memory to the device through direct memory access, thereby reducing the amount of inter-process communication and the number of repeated memory copies.

2. The microkernel-based container building and running system according to claim 1, characterized in that, The namespace function module includes: creation, joining, leaving, destruction, and use of file system mount point namespaces; The steps for creating a file system mount point namespace are as follows: Step 1): Request initiation: The container management program sends a request to the system container via inter-process communication to create a namespace for the file system mount point; Step 2): Obtain the working path sent by the container management program and determine whether the path length is less than 255 characters; Step 3): Obtain the mount point information of the working path in the original state, and retrieve the mount point information from the mount point information of the original state based on the working path; Step 4): Send a request to the corresponding file system to create a namespace. The specific process is described in the section on creating a namespace in the file system. Step 5): Create a new mount point information linked list; Step 6): Initialize a new mount point information linked list, and add the mount point information obtained in Step 3) as the mount point information of the path to the linked list; Step 7): Obtain the usable namespace IDs from the array; Step 8): Add the new mount point information linked list to the array element of the system container; Step 9): Inter-process communication returns, completing the creation of the new namespace.

3. The microkernel-based container building and running system according to claim 2, characterized in that, The steps to add a file system mount point namespace are as follows: Step 1): Initiate a request to join the namespace. The container management program needs to pass the ID of the mount point system container namespace and the system service type to the kernel. Step 2): Obtain the mount point system container namespace ID and system service type passed in by the container management program; Step 3): Fill the mount point system container namespace ID passed in by the container manager into the location of the mount point system container namespace of the application container process; Step 4): Complete the namespace join request and return to user mode from kernel mode.

4. The microkernel-based container building and running system according to claim 2, characterized in that, The steps to exit the file system mount point namespace are as follows: Step 1): Initiate an exit namespace request. The container management program needs to pass the system service type of the mount point system container into the kernel. Step 2): Obtain the system service type passed in by the container management program, i.e., the system service type of the mount point system container; Step 3): Clear the namespace data corresponding to the mount point system container in the kernel; Step 4): Complete the namespace exit request and return from kernel mode to user mode.

5. The microkernel-based container building and running system according to claim 2, characterized in that, The steps to destroy a file system mount point namespace are as follows: Step 1): Destruction request is initiated. The container management program sends a request to the system container through inter-process communication to destroy the namespace of the file system mount point. Step 2): Obtain the namespace ID sent by the container management program; Step 3): Check if the namespace ID is 0. If it is 0, it represents the root namespace and cannot be destroyed. Step 4): Check if the namespace corresponding to the namespace ID exists. If it does not exist, it cannot be destroyed. Step 5): Obtain the mount point information for the path; Step 6): Send a request to the corresponding file system to destroy the namespace; Step 7): Clear the current mount point information linked list, including releasing memory and assigning the pointer to 0; Step 8): Clear the corresponding namespace elements in the array of system containers; Step 9): The inter-process communication request returns, completing the destruction of the namespace.

6. The microkernel-based container building and running system according to claim 2, characterized in that, The steps for using a file system mount point namespace are as follows: Step 1): The application container initiates a request, sending an inter-process communication request to the mount point system service; Step 2): Obtain the namespace ID of the current application container in kernel mode; Step 3): Obtain the corresponding system container from the structure related to the inter-process communication request; Step 4): Switch the process to the system container process and pass the namespace ID; Step 5): Obtain the namespace ID passed by the kernel; Step 6): Find the corresponding namespace mount point list information in the array based on the namespace ID and switch accordingly; Step 7): Execute the specific application container request; Step 8): After the request is processed, return to kernel mode; Step 9): Complete the request and return to the application container.

7. The microkernel-based container building and running system according to claim 1, characterized in that, The fault recovery function module includes: when a fault occurs, the fault is captured, the most common fault is a page fault, and after the capture is completed, the system container process that has the fault exits and all resources are reclaimed; Then, a message to restart the system container is sent to the process management system container. Upon receiving the message, the process management system container immediately restarts the system container and rebuilds the contents of the system container and inter-process communication.

8. A microkernel-based container construction and execution method, characterized in that, include: Namespace functionality steps: Divide static system resources; divide mount point data, network protocol stack data, and process management data into different namespaces, allowing different application containers to access different system resources, thus achieving system resource isolation; Control group function steps: Divide dynamic system resources, count and limit CPU resources, memory resources and I / O bandwidth resources, different application containers are in different control groups, use limited resources, and realize the limitation of system resources; Fault recovery function steps: Handling system service crashes caused by memory errors; The control group function steps include: Statistics and limits on CPU resources: The total number of clock interrupts received by a process is used as the CPU resource usage; when a clock interrupt is triggered, the kernel obtains the process running on the CPU that triggered the clock interrupt and increments the number of clock interrupts received by the process by 1. The scheduling policy is modified so that when the time slice of the current process is 0, the scheduling policy is entered. A process is taken out from the waiting queue, and the CPU utilization is calculated, which is the ratio of the number of clock interrupts received by the process to the total number of clock interrupts received by all processes in the waiting queue. The actual CPU utilization is then compared with the CPU utilization set by the user. If a process's CPU utilization is higher than the user-defined CPU utilization, the time slice is reduced, or the process is made to wait for a long time; if a process's CPU utilization is lower than the user-defined CPU utilization, the time slice is increased. By modifying the scheduling policy, the time slice of each process is controlled individually. When each process completes a full scheduling round, it ensures that the CPU utilization of each process meets the user-defined value. Statistics and limits on memory resources: When a page fault occurs, the exception is caught, and the allocated physical page size is added to the corresponding application container process and application container, and the usage of physical page memory resources is statistically analyzed. If the physical memory usage of the application container exceeds the user-defined value during this process, the application container process that exceeds the memory usage limit must be killed or its operation must be paused. Statistics and limitation of I / O bandwidth resources: By adding a rate limiter system service between the system services of the file system and the system services of the device driver, each I / O request will be captured by the rate limiter system service, and the service will determine whether the request is satisfied based on the type and size of the I / O request. If not, the request will be suspended; if satisfied, the request will be sent and the token count in the rate limiter system service will be updated. The number of tokens gradually increases as the system runs, and there is a maximum limit to the number of tokens. Once the limit is reached, the number of tokens can no longer be increased. The system container is located in user space. System service processes are also managed as containers. The CPU and memory overhead of system service processes are statistically analyzed, and system service processes are managed in a unified manner. The system accelerates the microkernel's I / O speed through direct memory access, manages the data to be transferred using capability, and directly copies data from the device to memory or writes data directly from memory to the device through direct memory access, thereby reducing the amount of inter-process communication and the number of repeated memory copies.

Images