A container-oriented Linux kernel virtualization system and method

Abstract

The present invention relates to a container-oriented Linux kernel virtualization system, which at least includes: a virtual kernel construction module, which is configured to provide a virtual kernel customization template to allow users to edit and customize the container virtual kernel, and generate a virtual kernel in the form of a loadable kernel module based on the edited virtual kernel customization template; a virtual kernel instance module, which is configured to reconstruct and isolate the Linux kernel, respond to the kernel request of the corresponding container, and enable the virtual kernel instance to run in an independent address space. The container-oriented Linux kernel virtualization system proposed by the present invention is based on the loadable module technology. The system provides a customizable, high-performance, and highly secure virtual kernel for each container in the Linux kernel. The present invention virtualizes the Linux kernel to provide an independent virtual kernel for the container, supports customizing the virtual kernel for the container in the runtime Linux system, and can not only ensure the high performance of the container, but also greatly enhance the security of the container.

Description

Technical Field

[0001] The present invention relates to the technical field of computer operating systems, and in particular to a container-oriented Linux kernel virtualization system and method. Background Art

[0002] Containers are an emerging lightweight operating system-level virtualization technology that can be deployed and run on the host operating system by only containing the application and its necessary execution environment to run the containerized application. Therefore, a complete guest operating system and virtualized hardware are not required. With the characteristics of sharing the host operating system, containers can effectively utilize cloud servers and efficiently distribute and deploy applications on the cloud, bringing higher resource utilization and operating efficiency. At present, container technology has been widely popularized in the industry, and traditional cloud service providers provide a variety of container services to support the rapid distribution and deployment of cloud applications. However, with the surge in the density of container deployment in cloud environments, container security has become more important. At the same time, due to the explosion of the diversity of containerized applications, the demand for container kernel runtime customization capabilities has become more urgent.

[0003] In the Linux system environment, containers mainly use the namespace and control group (Cgroup) mechanisms provided by the Linux kernel to achieve container isolation and resource restrictions. But in essence, the Linux kernel is still shared by all containers on the same host. While Linux kernel sharing brings high performance, it also limits the ability of different containers to customize the kernel adaptively, and poses a huge challenge to container security. Although the kernel has added many security features for containers, the security features of the kernel layer are still discrete and imperfect and need to be further improved. In the face of frequent container security incidents, secure container solutions represented by gVisor and Kata Container add a complete operating system to the container in the user state and virtual machine layer, isolating the container from the host operating system and avoiding direct access of the container to the host operating system. These solutions provide additional protection layers between containers and hosts and between containers, but they will also introduce huge overhead. In addition, they rely on specific operating system kernels, so they still cannot effectively solve the problem of insufficient container kernel customization capabilities.

[0004] In response to the problem of insufficient security of native containers and poor performance of secure containers, a large number of existing research works have proposed solutions to optimize the shared Linux kernel. For example, the paper "Attack surface metrics and automated compile-time OS kernel tailoring" and the Linux kernel tinification project in the prior art both implement kernel configuration management methods, which can effectively reduce the kernel attack surface. However, the customized minimized shared kernel is difficult to meet the kernel requirements of different containers and lacks customization. In addition, the kernel namespace mechanism isolates some kernel parameters for containers, but operating the Linux kernel namespace involves global privileges and is insecure. In response to this problem, the prior art, such as the Seccomp security mechanism and the paper "Temporal system call specialization for attack surface reduction", proposes a technical solution to enhance security by limiting the system calls accessible to containers, but it still cannot solve the problem of global sharing of system call tables and system calls. The kernel's permission management method can limit the container's access to the kernel, but this permission management is globally shared, and the container process can escape privileges to affect the global system.

[0005] Although the above existing research work has enhanced container security to a certain extent, it still cannot solve the essential problem of global sharing. Due to the lack of virtualization of the Linux kernel, the existing work only optimizes and isolates the shared Linux kernel, so there are still obvious security and design defects. There is still an urgent need for a method to ensure the high performance of containers and solve the problem of global kernel sharing to improve container security.

[0006] In addition, on the one hand, there are differences in understanding among those skilled in the art; on the other hand, the applicant studied a large number of documents and patents when making the present invention, but due to space limitations, not all details and contents are listed in detail. However, this does not mean that the present invention does not have the characteristics of these prior arts. On the contrary, the present invention already has all the characteristics of the prior art, and the applicant reserves the right to add relevant prior art to the background technology. Summary of the invention

[0007] In response to the problem of insufficient native container security and poor performance of secure containers, a large number of existing research works have proposed solutions to optimize the shared Linux kernel. For example, the paper "Attack surface metrics and automated compile-time os kernel tailoring" and the Linux kernel tinification project both implement kernel configuration management methods, which are conducive to reducing the kernel attack surface. The Seccomp security mechanism and the paper "Temporal system call specialization for attack surface reduction" propose a technical solution to enhance security by limiting the system calls accessible to containers. Although the above existing research works have enhanced container security to a certain extent, they still cannot solve the essential problem of global sharing. Due to the lack of virtualization of the Linux kernel, existing work only optimizes and isolates the shared Linux kernel, so there are still obvious security and design defects.

[0008] In this regard, the present application proposes a container-oriented Linux kernel virtualization system based on kernel loadable module technology. By reconstructing various resources in the kernel and allowing the virtual kernel to be customized for the container, the container is provided with independent virtual kernel resources and security policies, which can effectively solve the problem of kernel global sharing. The virtual kernel implemented by the Linux kernel virtualization system proposed in the present application can be loaded and unloaded on demand during the container runtime, and the virtual kernel instance runs in the kernel space, which does not introduce obvious overhead, ensuring the high performance of the container. In addition, the Linux kernel virtualization method proposed in the present application adopts a unified standard to forward and process container requests. Under this setting, the modification of the Linux kernel source code is greatly reduced, and the overall technical architecture is simple and not easy to introduce additional vulnerabilities, which ensures the security of the technical architecture. Furthermore, the Linux kernel virtualization system proposed in the present application reconstructs and isolates the resources, configurations and parameters of the Linux kernel, provides an independent operating address space for the virtual kernel, and locally integrates and optimizes the global security module, significantly improving the security of the container.

[0009] The present application proposes a container-oriented Linux kernel virtualization system, which at least includes: a virtual kernel construction module, which is configured to provide a virtual kernel customization template to allow a user to edit and customize a container virtual kernel, and generate a virtual kernel in the form of a loadable kernel module based on the edited virtual kernel customization template; a virtual kernel instance module, which is configured to reconstruct and isolate the Linux kernel, respond to the kernel request of the corresponding container, and enable the virtual kernel instance to run in an independent address space.

[0010] According to a preferred embodiment, the system also includes a virtual kernel loading and unloading module, which is used to load the corresponding virtual kernel into the Linux kernel when the container is started, maintain the mapping relationship between the container and the virtual kernel, and / or unload and clear the virtual kernel after the container life cycle ends.

[0011] According to a preferred embodiment, the system further comprises a virtual kernel management module, which is configured to: when a container requests a kernel call, forward the container kernel call request to the virtual kernel instance for processing based on a predefined hook set and a corresponding ftrace callback function.

[0012] According to a preferred embodiment, the virtual kernel instance module is used to create and initialize a virtual kernel instance, and / or provide virtual kernel services for a container, and / or reuse other parts of the Linux kernel.

[0013] According to a preferred embodiment, the virtual kernel instance module includes at least a reconstruction submodule and a security submodule, wherein the reconstruction submodule is used to reconstruct the configuration and parameters in the Linux kernel, and / or call the call table of the reconstructed Linux kernel; the security submodule is used to provide an independent running address space for the virtual kernel and locally integrate and optimize the Linux kernel global security module.

[0014] According to a preferred embodiment, the virtual kernel construction module is also configured to: allow the user to select a virtual kernel customization method; generate a virtual kernel source code by semantically analyzing a customization file edited by the user; output a virtual kernel in the form of a loadable kernel module by compiling the virtual kernel source code; and save the virtual kernel in the form of a loadable kernel module into a warehouse for standby use.

[0015] According to a preferred embodiment, the virtual kernel construction module is also configured to: obtain the virtual kernel configuration, parameters and call table through semantic analysis of custom files and write them into the virtual kernel source code; perform semantic analysis on the call filtering rules, and write the parameter detection obtained by the analysis into the corresponding kernel call source code; perform semantic analysis on the file permission detection rules, and write the file and permission information obtained by the analysis into the virtual kernel source code data structure; integrate the customized source codes of various parts to generate the virtual kernel source code.

[0016] According to a preferred embodiment, the virtual kernel loading and unloading module is also configured to: monitor container operations through runc runtime, wherein: if a container creation operation is monitored, obtain the corresponding virtual kernel from the virtual kernel repository according to the container name; rename the virtual kernel module in combination with the container id and the virtual kernel name; load the virtual kernel module into the Linux kernel; send an initialization request to the virtual kernel instance module; and complete the loading of the corresponding virtual kernel.

[0017] A container-oriented Linux kernel virtualization method at least includes: providing a virtual kernel customization template that allows users to edit and customize; generating a virtual kernel in the form of a loadable kernel module based on the virtual kernel customization template; reconstructing and isolating the Linux kernel, responding to the kernel request of the corresponding container, and making the virtual kernel instance run in an independent address space. The container-oriented Linux kernel virtualization system proposed by the present invention is based on the loadable module technology. The system provides a customizable, high-performance, and highly secure virtual kernel (vkernel) for each container in the Linux kernel. The present invention virtualizes the Linux kernel to provide an independent virtual kernel for the container, supports customizing the virtual kernel for the container in the runtime Linux system, and the customized virtual kernel can not only ensure the high performance of the container, but also greatly enhance the security of the container.

[0018] According to a preferred embodiment, the method further includes: loading the corresponding virtual kernel into the Linux kernel when the container is started, maintaining the mapping relationship between the container and the virtual kernel, and / or unloading and clearing the virtual kernel after the container life cycle ends.

[0019] According to a preferred embodiment, the step of editing the virtual kernel customization template by the user at least includes: the user selecting the virtual kernel customization method; if the user selects the virtual kernel customization method of the custom configuration file, the user edits and sets the configuration, parameters and call table of the virtual kernel, and / or the user edits the virtual call filtering and file permission detection rules; generates the virtual kernel source code by semantically analyzing the customized file edited by the user; outputs the virtual kernel in the form of a loadable kernel module by compiling the virtual kernel source code; and saves the virtual kernel in the form of a loadable kernel module into a warehouse for standby use.

[0020] According to a preferred embodiment, the generation of virtual kernel source code includes at least the following steps: obtaining virtual kernel configuration, parameters and call table and writing them into virtual kernel source code through semantic analysis of custom files; performing semantic analysis on call filtering rules and writing parameter detection obtained from the analysis into corresponding kernel call source code; performing semantic analysis on file permission detection rules and writing file and permission information obtained from the analysis into virtual kernel source code data structure; integrating various parts of custom source code to generate virtual kernel source code.

[0021] According to a preferred implementation, the method further includes monitoring container operations during runc runtime, wherein: if a container creation operation is monitored, obtaining a corresponding virtual kernel from a virtual kernel repository according to the container name; renaming the virtual kernel module in combination with the container ID and the virtual kernel name; loading the virtual kernel module into the Linux kernel; sending an initialization request to the virtual kernel instance module; and completing the loading of the corresponding virtual kernel.

[0022] The present application also proposes a container-oriented Linux kernel virtualization system, which at least includes: a virtual kernel building module, which is configured to provide a virtual kernel customization template to allow a user to edit and customize the container virtual kernel, and generate a virtual kernel in the form of a loadable kernel module based on the edited virtual kernel customization template,

[0023] The virtual kernel instance module is configured to reconstruct and isolate the Linux kernel, respond to the kernel request of the corresponding container, and enable the virtual kernel instance to run in an independent address space.

[0024] According to a preferred embodiment, the system also includes a virtual kernel loading and unloading module, which is used to load the corresponding virtual kernel into the Linux kernel when the container is started, maintain the mapping relationship between the container and the virtual kernel, and / or unload and clear the virtual kernel after the container life cycle ends.

[0025] According to a preferred embodiment, the system further comprises a virtual kernel management module, which is configured to: when a container requests a kernel call, forward the container kernel call request to the virtual kernel instance for processing based on a predefined hook set and a corresponding ftrace callback function.

[0026] According to a preferred embodiment, the virtual kernel instance module is used to create and initialize a virtual kernel instance, and / or provide virtual kernel services for a container, and / or reuse other parts of the Linux kernel.

[0027] According to a preferred embodiment, the virtual kernel instance module includes at least a reconstruction submodule and a security submodule, wherein the reconstruction submodule is used to reconstruct the configuration and parameters in the Linux kernel, and / or call the call table of the reconstructed Linux kernel; the security submodule is used to provide an independent running address space for the virtual kernel and locally integrate and optimize the Linux kernel global security module.

[0028] The system proposed in this application includes a virtual kernel construction module, a virtual kernel loading and unloading module, a virtual kernel management module, and a virtual kernel instance module. The virtual kernel construction module provides a virtual kernel customization template, allowing users to customize the container virtual kernel, and generate a virtual kernel in the form of a loadable kernel module (LKM) through an automated tool. The virtual kernel loading and unloading module is responsible for loading the corresponding virtual kernel into the Linux kernel when the container is started, maintaining the mapping relationship between the container and the virtual kernel, and unloading and clearing the virtual kernel after the container life cycle ends. The virtual kernel management module is responsible for defining the virtual kernel entry and forwarding the kernel request to the corresponding virtual kernel for processing. The virtual kernel instance module provides a specific implementation of the virtual kernel, including the implementation of a reconstruction submodule and a security submodule. The reconstruction submodule reconstructs the configuration and parameters in the Linux kernel and calls the call table of the reconstructed Linux kernel. The security submodule provides an independent running address space for the virtual kernel and locally integrates and optimizes the Linux kernel global security module (including Capability, Seccomp, and Apparmor). The virtual kernel instance module also reuses other parts of the Linux kernel. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 It is a simplified schematic diagram of the Linux kernel virtualization system proposed by the present invention;

[0030] Figure 2 It is a simplified schematic diagram of data processing steps of a virtual kernel building module in the Linux kernel virtualization system proposed by the present invention;

[0031] Figure 3 It is a simplified schematic diagram of data processing steps of a virtual kernel loading and unloading module in the Linux kernel virtualization system proposed by the present invention;

[0032] Figure 4 It is a simplified schematic diagram of data processing steps of a virtual kernel management module in the Linux kernel virtualization system proposed by the present invention;

[0033] Figure 5 It is a schematic diagram of simplified data processing steps of a virtual kernel instance module in the Linux kernel virtualization system proposed by the present invention.

[0034] Reference numerals list

[0035] 1: Virtual kernel construction module; 2: Virtual kernel loading and unloading module; 3: Virtual kernel management module; 4: Virtual kernel instance module. DETAILED DESCRIPTION

[0036] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0037] For ease of understanding, technical terms of the present invention are explained as follows.

[0038] Containers are an application-layer abstraction used to package code and dependent resources / software into standardized units for development, delivery, and deployment. Container images are lightweight, executable, independent software packages that contain everything needed for software to run: code, runtime environment, system tools, system libraries, and settings. Containerized software is suitable for Linux and Windows-based applications and can run consistently in any environment. Containers give software independence, making it immune to external environmental differences (for example, differences in development and staging environments), thereby helping to reduce conflicts between teams when running different software on the same infrastructure. Containers virtualize the operating system rather than the hardware. Multiple containers can run on the same machine. Containers share the same set of operating system resources, but each runs as an independent process in user space. Containers and virtual machines have similar resource isolation and allocation advantages, but their functions are different. Because containers virtualize the operating system rather than the hardware, containers are easier to port and more efficient. Compared with virtual machines, containers take up less space, and the size of container images is usually only tens of megabytes, and they can be started in an instant. Traditional virtual machine technology virtualizes a set of hardware, runs a complete operating system on it, and then runs the required application processes on the system; while the application processes in the container run directly on the host's kernel, the container does not have its own kernel, and there is no hardware virtualization. Therefore, containers are lighter than traditional virtual machines.

[0039] Operating system-level virtualization, this technology virtualizes multiple servers on top of the operating system, and supports simple isolation of each virtual server on a single operating system. The Linux kernel occupies a single address space, which means that kernel or any driver error can cause the entire operating system to stop working, and multiple operating systems can be run through virtualization. If one of the systems crashes due to an error, the Hypervisor (management program) and other operating systems will not be affected in any way, which is like debugging a user space program for debugging the kernel.

[0040] Linux kernel, operating system is a low-level support software used to interact with hardware and provide a limited set of services for user programs. A computer system is a symbiosis of hardware and software, which are interdependent and inseparable. The hardware of a computer, including peripherals, processors, memory, hard disks and other electronic devices, constitutes the engine of the computer. But without software to operate and control the hardware, the hardware itself cannot work. The software that completes this control work is called an operating system, which is called "kernel" in Linux terminology, or "core". Its role is to pass application requests to the hardware and act as a low-level driver to address various devices and components in the system. The Linux kernel connects to the computer hardware, manages the computer hardware in a unified manner, and then provides a system call interface (API) for user processes to call. The main modules or components of the Linux kernel can be divided into the following parts: 1. Memory management: track how much memory is stored and where it is stored; 2. Process management: determine which processes can use the central processing unit (CPU), when to use it and how long to last; 3. Device driver: act as a mediator / interpreter between hardware and process; 4. System call and security protection: accept service requests from processes. The Linux kernel works in kernel space, where it allocates memory and keeps track of where everything is stored, while what the user sees (such as web browsers and files) is called user space. These applications interact with the kernel through the system call interface (SCI).

[0041] Loadable Kernel Modules (LKM) are a mechanism that supports on-demand loading or unloading of kernel source code. They can be used to provide customized virtual kernels for containers in the Linux kernel, adding an extra layer of protection to containers while ensuring high performance of containers. Linux is a single kernel. In order to make up for the shortcomings of poor scalability and maintainability of a single kernel, Linux introduces dynamic loadable kernel modules, which are used to extend the functions of the Linux kernel. Loadable kernel modules can be loaded into or unloaded from the kernel during system operation. A module is a program with independent functions that can be compiled separately but cannot run independently. It is linked to the kernel at runtime and runs in kernel space as part of the kernel. A module usually consists of a set of functions and data structures to implement a file system, a driver, or other upper-layer functions of the kernel.

[0042] System call (systemcall or syscall), each operating system has some functions embedded in the kernel, which can be used by each operation of the system. These functions used by Linux are called system calls, which correspond to the conversion between the user and the kernel. System calls are a set of "special" interfaces provided by the operating system to user programs for calling. User programs can obtain services provided by the operating system kernel through this set of "special" interfaces. For example, users can request the system to open files, close files, or read and write files through file system related calls; obtain system time or set system time through clock related system calls; create processes, implement process scheduling, process management, etc. through process control related system calls.

[0043] Kernel symbol table, the kernel symbol table is a dynamic, changeable mapping table established to access the corresponding address or pointer of the program body through symbols. It contains the addresses of all global kernel items (functions and variables). When a module is loaded into the kernel, any symbols it exports will become part of the kernel public symbol table. Each entry in the kernel symbol table represents an exported (public) kernel symbol that can be accessed by the LKM.

[0044] Kernel-level virtualization technology: Kernel-based Virtual Machine, referred to as KVM, the Linux kernel occupies a single address space, which means that a failure in the kernel or any driver will cause the entire operating system to crash, and kernel-level virtualization means that multiple operating systems can be run. If one of the systems crashes due to a bug, the system manager and other operating systems can still run normally.

[0045] Namespace, the namespace mechanism simply provides an abstraction of global resources, putting resources in different containers (different namespaces), isolating each container from each other, and is a means used in the Linux kernel to achieve Linux resource isolation. For common PID, IPC, etc., these system resources are no longer global resources, but belong to a certain namespace exclusively. For resources under a namespace, it is transparent and invisible to other namespaces. In other words, at the operating system level, there can be two processes with process numbers 0, 1, and 2 at the same time, because they belong to different namespaces, so there will be no conflict between them. On the Linux kernel, there can be multiple namespaces, and each namespace has its own exclusive processes. For example, if you use the ps command, you can only list the processes under your own namespace, and you will not see the processes under other namespaces. This realizes the isolation of Linux. At present, there are six main types of Linux namespaces, namely MNT Namespace, IPC Namespace, Net Namespace, UTS Namespace, PIDNamespace, and User Namespace. 1. MNT Namespace: used to provide isolation capabilities for disk mount points and file systems; 2. IPC Namespace: used to provide isolation capabilities for inter-process communication; 3. Net Namespace: used to provide network isolation capabilities; 4. UTS Namespace: used to provide host name isolation capabilities; 5. PID Namespace: used to provide process isolation capabilities; 6. User Namespace: used to provide user isolation capabilities. Processes of different users are isolated through pid namespaces, and the same pid can exist in different namespaces.

[0046] Cgroup, Cgroup (control group) is a mechanism provided by the Linux kernel. This mechanism can integrate (or separate) a series of system tasks and their subtasks into different groups divided by resource levels according to specific behaviors, thereby providing a unified framework for system resource management. In simple terms, Cgroup can record, limit, and isolate the resources used by the process group, referring to physical resources such as CPU, memory, IO, etc. This role is of great significance to container technology. It can be said to be the cornerstone of implementing most virtualization tools. Cgroup has the following major functions: 1. Resource Limitation: Cgroup can limit the upper limit of the number of resources used by the process group. For example, once the set memory limit is exceeded, OOM, i.e. Out Of Memory, will be reported. 2. Prioritization: This is mainly to allocate the number of CPU time slices and the bandwidth of hard disk IO. In fact, this is to control the priority of process operation. 3. Resource Statistics: One of the major functions of Cgroup is to count some information, such as memory usage, CPU usage time, etc. This function is very convenient for billing. 4. Process Control: Cgroup can perform operations such as suspending and resuming processes. Cgroup has the following main features: 1. The API implementation of Cgroup is through a pseudo file system, that is, the way users use to organize and manage Cgroup is file operations. 2. The operation unit of Cgroup's organization and management can be as fine as the thread level. For user-mode code, it also has the right to create and destroy Cgroup operations on resources that have been allocated by the system, that is, it can realize resource re-management and re-allocation. 3. The implementation of resource management functions is through "subsystem", and all interfaces are unified. 4. When the child process is just created, it is in the same Cgroup group as the parent process. In essence, Cgroup can be regarded as a series of hooks attached to the program by the Linux kernel. When the program is running, resource scheduling triggers the corresponding hooks, so that resource tracking and restriction can be realized.

[0047] OCI (Open Container Initiative) provides two specifications: runtime specification (runtime-spec), which describes how to run the filesystem bundle (file system bundle, which is used to provide the runtime with the necessary configuration files and file systems to start the container), and defines the state description of the container, as well as the creation, deletion, and viewing of the container; image specification (image-spec), which specifies the image format, operation, etc.

[0048] Container runtime refers to a program that can create and run containers based on images obtained online, and is responsible for starting and stopping containers.

[0049] Runc is a command line tool (CLI tool) that creates and runs containers according to the OCI standard. It is currently the most widely used container runtime. Docker was created based on runc. Runc is the core part of docker. The creation, running, and destruction of containers will eventually be completed by calling runc. Runc also has its own client, which was later extracted as a separate tool and library. It implements the OCI specification, including the config.json file and the root file system of the container.

[0050] Container id, the container id is a property of each devnode and can be specified by a globally unique identifier (GUID) value.

[0051] Ftrace, ftrace (function trace) is the debugging tracing mechanism or tracing framework in the Linux kernel. Ftrace provides Linux with the ability to view and trace things inside the kernel, which can better find problem areas and track errors. Ftrace can track kernel crash events and accurately find the cause of the kernel crash. The entire ftrace framework can be divided into several parts: ftrace core framework, RingBuffer, debugfs, Tracepoint, and various Tracers. The Ftrace framework is the link of the entire ftrace function, including the registration of Tracers, the control of RingBuffer, etc.

[0052] Hook,Hook (container hook) is an event processing mechanism introduced for container lifecycle management. It is responsible for monitoring the management information of the container lifecycle, notifying the container of this information in the form of broadcast, and then executing the corresponding callback function. When a container management hook occurs, the management system will call the registered hook handler in the container. Hook is a special message processing mechanism that can monitor various event messages in the system or process, intercept messages sent to the target window and process them.

[0053] Seccomp, secure congluting mode, is the secure computing mode. Under normal circumstances, the program can use all syscalls, which is unsafe. For example, after the program hijacks the program flow, it uses the execve syscall to get the shell. Through seccomp, we can disable certain syscalls in the program, so that even if the program flow is hijacked, only some syscalls can be called.

[0054] The kernel page table is actually a section of memory in the kernel, stored in the main kernel page global directory init_mm.pgd (swapper_pg_dir), and is not directly used by the hardware.

[0055] The present application proposes a container-oriented Linux kernel virtualization system, which at least includes a virtual kernel construction module, a virtual kernel loading and unloading module, a virtual kernel management module and a virtual kernel instance module. Preferably, the Linux kernel virtualization system of the present invention is, for example: a computer, a server, etc., and other devices or systems using the Linux kernel virtualization system. According to an embodiment of the present invention, in addition to the virtual kernel construction module, the virtual kernel loading and unloading module, the virtual kernel management module and the virtual kernel instance module, etc., the Linux kernel virtualization system may also include other components such as a central processing unit, a communication unit, a storage unit, and an I / O unit. For example, the virtual kernel construction module, the virtual kernel loading and unloading module, the virtual kernel management module and the virtual kernel instance module are respectively connected to the central processing unit, and all interact with the central processing unit for information. Or for example, the virtual kernel construction module, the virtual kernel loading and unloading module, the virtual kernel management module and the virtual kernel instance module are connected to each other in sequence for information interaction.

[0056] As an example, various exemplary logic blocks, modules and circuits described in conjunction with the present disclosure may be implemented or executed with a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components or any combination thereof for performing the functions described herein. A general-purpose processor may be a microprocessor, or a processor may be any common processor, controller, microcontroller or state machine. A processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, a combination of one or more microprocessors and a DSP core, or any other such structure. As an example, embodiments of the present disclosure may be described in the context of machine executable instructions, such as program modules executed in a device on a real or virtual processor of a target. In general, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., which perform specific tasks or implement specific abstract data structures. In various embodiments, the functions of program modules may be merged or split between the described program modules. Machine executable instructions for program modules may be executed in local or distributed devices. In a distributed device, program modules may be located in both local and remote storage media.

[0057] The virtual kernel building module is used to customize and generate virtual kernels for different containers.

[0058] To achieve private customization of the virtual kernel, the virtual kernel building module is configured to provide users with customized templates for kernel configuration, parameters, call tables, and security features. Users can edit and customize the templates based on container requirements to obtain virtual kernel customization files. The templates include the kernel configuration, parameters, call tables, and security features of the virtual kernel.

[0059] The virtual kernel building module includes an automated building tool. The automated building tool obtains the virtual kernel customization file, performs intelligent semantic analysis on it, and generates customized virtual kernel source code. The automated building tool automatically compiles the virtual kernel source code and outputs the virtual kernel in the form of a loadable kernel module.

[0060] The present invention provides users with a one-stop container virtual kernel customization service by configuring virtual kernel building modules. Users only need to edit the provided template to generate a virtual kernel in the form of a loadable module through an automated tool, which is simple and easy to operate and meets the customization requirements of different containers.

[0061] The virtual kernel loading and unloading module is used to load and unload the customized virtual kernel of the container based on the life cycle of the container. The virtual kernel loading and unloading module monitors the container operation based on the runc container runtime of the open container solution standard.

[0062] For container creation, the virtual kernel loading and unloading module loads the virtual kernel into the Linux kernel before the container is started. For container destruction, the virtual kernel loading and unloading module immediately unloads and clears the virtual kernel of the container.

[0063] In order to avoid conflicts in the Linux kernel when different containers use kernel loadable modules with the same name, in this application, the virtual kernel loading and unloading module implements a virtual kernel renaming mechanism based on container id in the Linux kernel. After resolving the renaming conflict for the virtual kernel, the PID namespace of the container is finally linked to the virtual kernel to achieve the mapping between the container and the virtual kernel. The virtual kernel renaming mechanism based on container id refers to renaming the loadable virtual kernel module based on the container id, which can effectively avoid the generation of duplicate name conflicts in the Linux kernel to support loading an independent virtual kernel for each container.

[0064] The present invention realizes adaptive virtual kernel loading and unloading management based on the container life cycle by configuring a virtual kernel loading and unloading module. The container operation is monitored by the runc runtime and automatic loading and unloading of the virtual kernel is realized. Since the runc runtime has versatility and universality, the present invention can be quickly integrated into a wide range of container management tools, and at the same time, a mapping relationship between the container and the virtual kernel is realized based on the container PID namespace to support forwarding container requests to the corresponding virtual kernel for processing.

[0065] The virtual kernel management module is configured to manage the virtual kernel entry and forward kernel requests to the virtual kernel. The virtual kernel management module runs in the Linux kernel, predefines a hook set for generating virtual kernel entry, obtains the address of the corresponding call in the kernel through the kernel symbol table (kallsyms), and generates a virtual kernel entry for the kernel call in the hook set by enabling the ftrace mechanism. The ftrace callback function of the kernel call in the hook set forwards the kernel call request of the container to the virtual kernel for processing.

[0066] The kernel symbol table refers to the symbol table of functions and variables in the kernel's internal functions or variables that can be referenced externally. The kernel symbol table is created during the kernel startup process and updated in real time. It reflects the current status of the system and also contains the names of functions and variables exported by the kernel or loaded modules.

[0067] When a container requests a kernel call, the virtual kernel management module forwards the container kernel call request to the virtual kernel instance for processing based on a predefined set of hooks and the corresponding ftrace callback function.

[0068] The present invention realizes the overall management of the virtual kernel entrance by configuring the virtual kernel management module, and effectively enhances the robustness and scalability of the system. This effectively decouples the system from the Linux kernel, can avoid the modification of the Linux source code, and avoids the Linux kernel update caused by the system update. In addition, the virtual kernel management module runs in the Linux kernel, effectively ensuring the efficiency of kernel call forwarding to the virtual kernel, and does not introduce additional overhead.

[0069] The virtual kernel instance module is a specific implementation of the virtual kernel, which includes a reconstruction submodule and a security submodule. The virtual kernel instance module is used to create and initialize a virtual kernel instance and provide virtual kernel services for containers.

[0070] The reconstruction submodule is used to reconstruct the virtual kernel configuration, parameters and call table, and the security submodule is used to provide an independent address space and locally integrate and optimize the global security module.

[0071] The reconstruction submodule reconstructs the Linux kernel configuration, provides independent virtual kernel configuration for the container and takes effect in the corresponding virtual kernel call. The reconstruction submodule creates a configuration structure to reconstruct the kernel configuration so that each container can enjoy an independent virtual kernel configuration. In the process of loading the virtual kernel into the Linux kernel, the configuration structure will be initialized according to the user's customization. During the operation of the virtual kernel instance, the container kernel request involving the kernel configuration will be forwarded to the virtual kernel instance, and then the virtual kernel configuration in the configuration structure will be obtained, and finally the reconstruction configuration will take effect in the kernel.

[0072] The reconstruction submodule reconstructs the Linux kernel parameters and provides local virtual kernel parameters for the container, allowing the container to set its parameters independently and take effect in the virtual kernel call. The reconstruction submodule creates a parameter structure to reconstruct the kernel parameters so that each container can enjoy independent virtual kernel parameters. The virtual kernel management module is used to intercept kernel functions that need to access parameters and turn to access the corresponding parameters in the parameter structure in the virtual kernel to make the virtual kernel parameters effective.

[0073] The reconstruction submodule also reconstructs the Linux kernel call table, providing an independent virtual kernel call table and isolated virtual kernel calls for each container. The reconstruction submodule generates a virtual kernel private system call table for the container, shields some system call table entries, and modifies some system calls to point to the reconstructed kernel system call function. The virtual kernel management module is used to intercept the kernel system call entry, from the system call in the directed container to the virtual kernel private system call table, and jumps to the corresponding system call for processing.

[0074] The security submodule uses an independent page table to limit the virtual kernel addressing range of the container, realizing an isolated virtual kernel address space. Specifically, based on the kernel page table isolation mechanism, the system generates an independent page table for the kernel loadable module. The kernel address space mapped on the page table includes the kernel text area, CPU entry area, current process data and other core kernel areas, as well as the memory area of ​​the current kernel module and the memory area allocated by the independent page table. When running to the virtual kernel code, the page table is switched to the independent page table generated by this system, so that the virtual kernel addressing range is limited to the independent page table.

[0075] The security submodule maintains the permissions of the container and implements permission detection at the virtual kernel layer. The container permissions mentioned here include kernel function permissions, system call access permissions, and file access permissions. The security submodule creates an independent function permission structure to maintain the Capability of the container layer. When checking the kernel function permissions, it reads the function permission structure in the virtual kernel for checking, effectively preventing the privilege escape of the container process. The security submodule uses static writing technology to implement the Seccomp system call filtering mechanism in the virtual kernel source code, generates the corresponding virtual kernel source code based on the system call filtering rules configured by the user, clears the table entries of the virtual kernel system call table corresponding to the shielded system call, and encapsulates the parameter filtering outside the corresponding system call. The security submodule implements Apparmor's file permission detection based on the index node virtualization technology, maintains a set of index node numbers and permission information in the virtual kernel according to the custom file permission rules, and triggers the file permission detection in the virtual kernel by identifying the corresponding index node, avoiding unnecessary detection of all files. When the container accesses a file, it first determines the flag bit of the corresponding index node. If it is not set, no permission detection is performed. Otherwise, the permission requirement maintained in the virtual kernel instance is obtained according to the index node number for permission detection.

[0076] The static writing technology mentioned in this application refers to the technology of writing configuration information into source code, specifically including automatic analysis of user configuration, extracting configuration content and filling it into source code template, and finally outputting synthesized source code.

[0077] The Capability mentioned in this application refers to the kernel subdividing root privileges into different functional groups. The same functional group maintains a set of similar kernel function permissions. Only processes with functional groups can access the corresponding kernel functions.

[0078] The call filtering mechanism mentioned in this application refers to the kernel checking the filter rules corresponding to the request source before processing the system call. If the system call is not in the whitelist or the parameters do not meet the requirements, the request will be filtered and returned directly. Otherwise, the kernel will enter the system call for processing.

[0079] The index node virtualization technology mentioned in this application refers to adding a virtualization flag bit in the structure of the index node. If the bit is non-zero, it means that its permission information is independently maintained in the virtual kernel.

[0080] Apparmor mentioned in this application refers to a Linux security mechanism based on mandatory access control, which is mainly used for mandatory access control of container file requests.

[0081] The file permission detection mentioned in this application refers to the need to detect the permissions of the request source during the file operation process. If the request source has the necessary permissions for the file operation, the file operation of the request source is allowed, otherwise the file operation will be rejected due to insufficient permissions. File permission detection can prevent malicious file access by malicious containers.

[0082] The present invention configures the virtual kernel instance module, creates and manages private virtual kernel configuration, parameters and kernel call table for the container in the reconstruction submodule, and makes the private settings effective in the corresponding virtual kernel call process. The components of the reconstruction submodule work together to provide a private virtual kernel environment for the container and take effect in the kernel request processing process. The security submodule enables the virtual kernel instance to run in an independent address space, and implements the container layer permission detection mechanism, the efficient call filtering mechanism based on static write technology, and the file permission detection mechanism based on index node virtualization. The Linux kernel global security module (including Capability, Seccomp, and Apparmor) is partially integrated and optimized to realize virtual kernel permission detection and access control, and further ensure the security of the container.

[0083] The present application also proposes a container-oriented Linux kernel virtualization method, which includes at least steps S1 to S8. Although the Linux kernel virtualization method in the specific implementation of the present invention is depicted in a specific order, this should not be understood as requiring such operations to be completed in the specific order shown or in a sequential order, or to perform all illustrated operations to obtain the desired results. In some cases, multitasking or parallel processing can be beneficial. Similarly, although the above discussion contains certain specific implementation details, this should not be interpreted as limiting the scope of any invention or claim, but should be interpreted as a description of a specific embodiment that can be directed to a specific invention. Certain features described in the context of separate embodiments in this specification may also be integrated and implemented in a single embodiment. Conversely, the various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination.

[0084] S1: The user selects a virtual kernel customization method. If the user selects a custom configuration file method, the process goes to S2; otherwise, the process goes to S3.

[0085] S2: The user edits and sets the configuration, parameters and call table of the virtual kernel.

[0086] S3: Users edit virtual call filtering and file permission detection rules.

[0087] S4: The custom file edited by the user is semantically analyzed to obtain the virtual kernel configuration, parameters and call table and write them into the virtual kernel source code.

[0088] S5: Perform semantic analysis on the call filtering rules and write the obtained parameter detection into the corresponding kernel call source code.

[0089] S6: Perform semantic analysis on the file permission detection rules, and write the obtained file and permission information into the virtual kernel source code data structure.

[0090] S7: Integrate the customized source codes of various parts into the virtual kernel source code.

[0091] S8: compile the virtual kernel source code to output the virtual kernel in the form of a loadable kernel module, and save it into a warehouse for use, and then end.

[0092] The method further comprises steps S101 to S109, such as Figure 3 Steps S101 to S109 may be executed by the virtual kernel loading and unloading module.

[0093] S101: Monitor container operations through runc runtime, and go to S102 for container creation operations and go to S107 for container destruction operations.

[0094] S102: Obtain a corresponding virtual kernel from a virtual kernel repository according to the container name.

[0095] S103: Rename the virtual kernel module by combining the container ID and the virtual kernel name.

[0096] S104: Load the virtual kernel module into the Linux kernel.

[0097] S105: Send an initialization request to the virtual kernel instance module.

[0098] S106: The virtual kernel is loaded and the process goes to S109.

[0099] S107: Uninstall the virtual kernel from the Linux kernel.

[0100] S108: Clear the virtual kernel instance and go to S109.

[0101] S109: End.

[0102] The method further comprises steps S201 to S207, such as Figure 4 Steps S201 to S207 may be executed by the virtual core management module.

[0103] S201: Define a virtual kernel hook set.

[0104] S202: Obtain the corresponding kernel call address in the kernel symbol table (kallsyms).

[0105] S203: Enable the ftrace mechanism for kernel calls in the hook set.

[0106] S204: intercepting the container kernel call request through the ftrace callback function.

[0107] S205: Obtain the container virtual kernel through the container PID namespace.

[0108] S206: Forward the container request to the virtual kernel for processing.

[0109] S207: End.

[0110] The method further includes steps S301 to S307 , and the virtual kernel instance module is further configured to execute steps S301 to S307 .

[0111] S301: Virtual kernel configuration reconstruction: Create a virtual kernel configuration set and maintain a custom virtual kernel configuration.

[0112] S302: Virtual kernel parameter reconstruction: Create a virtual kernel parameter set and maintain custom virtual kernel parameters.

[0113] S303: Virtual kernel call reconstruction. Create and maintain a virtual kernel call table, initialize supported virtual kernel call table entries, and assign null values ​​to corresponding table entries of shielded virtual kernel calls. Load the reconstructed virtual kernel call, and assign the call address to the table entry of the corresponding virtual kernel call table.

[0114] S304: Virtual kernel address space isolation: Create virtual kernel address space related structures and add Linux kernel core memory mapping to the page table.

[0115] S305: Virtual kernel permission detection: Create a virtual kernel highest permission structure and initialize it as container permission, and perform permission detection at the virtual kernel layer.

[0116] S306: Virtual kernel call filtering: Integrate kernel call filtering rules into the virtual kernel call table, and perform parameter detection in the virtual kernel call source code.

[0117] S307: Virtual kernel file permission detection. Initialize the permission hash table and save the custom file permissions, and set the virtualization flag of the corresponding file index node. Virtual kernel file permission detection process: first determine the virtualization flag of the index node, and then read the file permissions in the hash table for detection.

[0118] The method further comprises steps S401 to S4013, such as Figure 5 Steps S401 to S4013 may be executed by a virtual kernel instance module.

[0119] S401: The virtual kernel instance module receives a virtual kernel loading and unloading module request, creates a virtual kernel instance, and initializes it.

[0120] S402: The virtual kernel instance receives the forwarded kernel call request, switches the page table to the virtual kernel page table, and executes the kernel call on the isolated page table. The virtual kernel page table and the isolated page table mentioned in this application both refer to independent page tables.

[0121] S403: Filter the call request through the private system call table in the virtual kernel generated according to the user configuration. If the table entry of the corresponding call is not a null value, go to S404; otherwise, reject the unsupported call request and go to step S4013.

[0122] S404: Enter the call pointed to by the virtual kernel call table entry and determine whether parameter detection is required. If required, go to step S405; otherwise, go to step S406.

[0123] S405: Check the system call parameters according to the system call parameter rules configured by the user. If they pass, go to step S406. Otherwise, reject the illegal parameter step and go to S4013.

[0124] S406: redirecting the kernel function accessing the global kernel configuration to the function re-implemented in the virtual kernel, and obtaining the virtual kernel configuration information from the virtual kernel.

[0125] S407: redirecting the kernel function accessing the global kernel parameters to the function re-implemented in the virtual kernel, and obtaining virtual kernel parameter information from the virtual kernel.

[0126] S408: redirect the global permission check function to the reconstructed permission check function, obtain the virtual kernel permission in the virtual kernel corresponding to the container and perform permission check. If the permission check passes, go to step S409, otherwise, deny unauthorized access and go to step S4013.

[0127] S409: Determine whether the call needs to access a file. If so, go to step S4010; otherwise, go to step S4012.

[0128] S4010: Obtain file index node information, check the virtualization flag to determine whether the container has enabled the virtual kernel index node permission virtualization function. If the virtualization flag is set, go to step S4011, otherwise go to step S4012.

[0129] S4011: Obtain permissions from the permission hash table according to the index node information and perform permission detection. If the permission detection passes, go to step S4012, otherwise the file operation is rejected due to insufficient permissions and go to step S4013.

[0130] S4012: The system call continues to execute and ends after completion.

[0131] S4013: System call execution is rejected, ending.

[0132] The virtual kernel construction module is further configured to execute steps S501 to S503.

[0133] S501: Virtual kernel customization: According to container requirements, the user edits the configuration, parameters, call table, and security feature templates of the virtual kernel to perform private customization of the virtual kernel.

[0134] S502: Generate virtual kernel source code. Perform intelligent semantic analysis based on the user customized file, and automatically generate customized virtual kernel source code according to the analysis result.

[0135] S503: Virtual kernel compilation: Compile the virtual kernel source code to output a virtual kernel in the form of a loadable kernel module, and save it in a virtual kernel repository for later use.

[0136] The virtual core management module is further configured to execute steps S601 to S604.

[0137] S601: Virtual kernel loading. When runc is running, it detects the container creation operation and triggers the virtual kernel loading. Before the container is started, the corresponding virtual kernel is obtained from the virtual kernel repository and a virtual kernel loading request is sent to the Linux kernel.

[0138] S602: rename the virtual kernel. Before the Linux kernel loads the virtual kernel, rename the virtual kernel by combining the container ID and the virtual kernel name.

[0139] S603: Virtual kernel mapping: After the virtual kernel is loaded, the PID namespace of the container is obtained, and the virtual kernel is assigned to the virtual kernel structure of the container PID namespace.

[0140] S604: Virtual kernel unloading. If runc detects the container destruction operation during runtime, it immediately sends a virtual kernel unloading and clearing request to the Linux kernel.

[0141] Through the Linux kernel virtualization method proposed in this application, first the user needs to edit the virtual kernel configuration template in the virtual kernel construction module and generate a virtual kernel in the form of a kernel loadable module; then when the user operates the container, the virtual kernel loading and unloading module will load the virtual kernel into the Linux kernel corresponding to the container creation operation, and clear the corresponding virtual kernel in the Linux kernel when the container is destroyed. During the operation of the container, the virtual kernel management module will intercept the kernel request of the container and forward it to the virtual kernel instance module for processing. The virtual kernel instance module will reconstruct the Linux kernel and integrate and optimize the global security mechanism, and respond to the kernel request of the corresponding container.

[0142] Specifically, the user first edits the virtual kernel's kernel configuration, parameters, call table, and security feature templates according to the container's needs to customize the virtual kernel;

[0143] The automated build tool performs intelligent semantic analysis on the custom files of the virtual kernel to generate the virtual kernel source code, and finally compiles the virtual kernel source code to output the virtual kernel in the form of a loadable kernel module;

[0144] The virtual kernel loading and unloading module monitors container operations based on the runc runtime;

[0145] The virtual kernel loading and unloading module loads the corresponding virtual kernel module before the container is started, and unloads and clears its virtual kernel when the container is destroyed;

[0146] When a container requests a kernel call, the virtual kernel management module forwards the container kernel call request to the virtual kernel instance for processing based on a predefined set of hooks and the corresponding ftrace callback function;

[0147] The virtual kernel instance module creates and initializes the virtual kernel instance and provides virtual kernel services for the container;

[0148] The reconstruction submodule of the virtual kernel instance module reconstructs the virtual kernel configuration, parameters and calls;

[0149] The security submodule of the virtual kernel instance module provides an independent address space and locally integrates and optimizes the global security module.

[0150] It should be noted that the above-mentioned specific embodiments are exemplary, and those skilled in the art can come up with various solutions inspired by the disclosure of the present invention, and these solutions also belong to the disclosure scope of the present invention and fall within the protection scope of the present invention. Those skilled in the art should understand that the present invention specification and its drawings are illustrative and do not constitute a limitation on the claims. The scope of protection of the present invention is defined by the claims and their equivalents. The present invention specification contains multiple inventive concepts, such as "preferably", "according to a preferred embodiment" or "optionally", all of which indicate that the corresponding paragraph discloses an independent concept, and the applicant reserves the right to file a divisional application based on each inventive concept.

Claims

1. A container-oriented Linux kernel virtualization system, characterized in that: At least: A virtual kernel building module is configured to provide a virtual kernel customization template to allow a user to edit and customize the container virtual kernel, and generate a virtual kernel in the form of a loadable kernel module based on the edited virtual kernel customization template; A virtual kernel instance module, which is configured to reconstruct and isolate the Linux kernel, respond to kernel requests of the corresponding container, and enable the virtual kernel instance to run in an independent address space; The virtual kernel building block is also configured to: By semantically analyzing the custom file, the virtual kernel configuration, parameters and call table are obtained and written into the virtual kernel source code; Perform semantic analysis on the call filtering rules and write the parameter detection obtained from the analysis into the corresponding kernel call source code; Perform semantic analysis on the file permission detection rules, and write the analyzed file and permission information into the virtual kernel source code data structure; Integrate each part of the customized source code to generate a virtual kernel source code.

2. The system according to claim 1, characterized in that The system also includes a virtual kernel loading and unloading module, which is used to load the corresponding virtual kernel into the Linux kernel when the container is started, maintain the mapping relationship between the container and the virtual kernel, and / or unload and clear the virtual kernel after the container life cycle ends.

3. The system according to claim 1 or 2, characterized in that: The system also includes a virtual kernel management module, which is configured to: When a container requests a kernel call, based on a predefined set of hooks and the corresponding ftrace callback function, the container kernel call request is forwarded to the virtual kernel instance for processing.

4. The system according to claim 1, characterized in that The virtual kernel instance module is used to create and initialize a virtual kernel instance, and / or provide a virtual kernel service for a container, and / or reuse other parts of the Linux kernel.

5. The system according to claim 1, characterized in that The virtual kernel instance module includes at least a reconstruction submodule and a security submodule, wherein: The reconstruction submodule is used to reconstruct the configuration and parameters in the Linux kernel, and / or call the call table of the reconstructed Linux kernel; The security submodule is used to provide an independent operating address space for the virtual kernel and to locally integrate and optimize the Linux kernel global security module.

6. The system according to claim 1, characterized in that The virtual kernel building block is also configured to: Allow users to choose the virtual kernel customization method; Generate virtual kernel source code by semantically analyzing the customized files edited by the user; By compiling the virtual kernel source code, a virtual kernel in the form of a loadable kernel module is output; Save the virtual kernel in the form of a loadable kernel module into the repository for later use.

7. The system according to claim 2, characterized in that The virtual kernel loading and unloading module is also configured to: Monitor container operations through the runc runtime, where: If a container creation operation is monitored, the corresponding virtual kernel is obtained from the virtual kernel repository according to the container name; Rename the virtual kernel module based on the container ID and the virtual kernel name; Load the virtual kernel module into the Linux kernel; Send an initialization request to the virtual kernel instance module; Complete the loading of the corresponding virtual kernel.

8. A container-oriented Linux kernel virtualization method, characterized in that: At least: Provides custom templates for virtual kernels that allow users to edit and customize; Generate a virtual kernel in the form of a loadable kernel module based on a virtual kernel custom template; Reconstruct and isolate the Linux kernel, respond to kernel requests from the corresponding container, and enable the virtual kernel instance to run in an independent address space; By semantically analyzing the custom file, the virtual kernel configuration, parameters and call table are obtained and written into the virtual kernel source code; Perform semantic analysis on the call filtering rules and write the parameter detection obtained from the analysis into the corresponding kernel call source code; Perform semantic analysis on the file permission detection rules, and write the analyzed file and permission information into the virtual kernel source code data structure; Integrate each part of the customized source code to generate a virtual kernel source code.

9. The method according to claim 8, characterized in that The method further comprises: When the container is started, the corresponding virtual kernel is loaded into the Linux kernel to maintain the mapping relationship between the container and the virtual kernel. and / or After the container lifecycle ends, the virtual kernel is uninstalled and cleared.

Images