Kernel module processing method, device, storage medium, and program product

Abstract

Embodiments of the present disclosure relate to the technical field of cloud computing and provide a kernel module processing method, a device, a storage medium, and a program product. In the embodiments of the present disclosure, on the basis of fusion virtualization technology, a container runtime component is fused with a running environment of an operating system in a secure container, so that direct interaction can be performed; thus, a loading operation of a kernel module in the secure container is sunk to a host side for completion, thereby reducing the risk of the secure container being maliciously tampered with by an end user, and enhancing the security protection capability of the kernel module of the secure container. Moreover, the kernel module is stripped from a root file system, so that version convergence of the root file system in different application scenarios is facilitated. Further, loading of the kernel module no longer depends on the root file system, and the kernel module can be added or hotfixing can be performed for the kernel at any time during the whole life cycle of the secure container.

Description

Kernel module processing method, device, storage medium and program product

[0001] Cross-reference

[0002] The present disclosure claims priority to the Chinese patent publication with the publication number 202411291290.X and the title "Kernel module processing method, device, storage medium and program product" filed on September 13, 2024 with the China Patent Office, the entire content of which is incorporated herein by reference. TECHNICAL FIELD

[0003] The present disclosure relates to the technical field of cloud computing, and particularly relates to a kernel module processing method, device, storage medium and program product. BACKGROUND

[0004] In a cloud computing environment, containerization technology is used to package application programs and their dependencies into independent containers, ensuring the security and consistency of the application programs. Secure containers, as a branch of container technology, aim to combine the security of virtualization and the convenience of containers to make the isolation between containers more thorough, and to provide higher-level isolation and protection for the application programs in the containers, and therefore are widely used.

[0005] During the startup process of a secure container, a root file system rootfs is loaded, and the rootfs is a carrier of other components. By mounting the rootfs, the components contained in the rootfs can be put into the secure container, and then the initial process and the like load the related components. In actual applications, when the rootfs is constructed, the kernel modules required by the application can also be added to the rootfs to realize the loading of the kernel modules in the secure container. However, the kernel module loading method through the rootfs is easy to expose the kernel modules to the users of the secure container, and there is a security risk. SUMMARY

[0006] The aspects of the present disclosure provide a kernel module processing method, device, storage medium and program product to provide a kernel module loading method independent of a root file system, and improve the security of the kernel modules in the secure container.

[0007] The embodiment of the present disclosure provides a computer device, comprising: a host computer, wherein a management component, a container runtime component and a secure container created and managed by the container runtime component are running on the host computer, and the secure container comprises: a guest operating system; the container runtime component is integrated with the running environment of the guest operating system and can directly interact;

[0008] The management component is configured to receive an operation request initiated for a kernel module, and send the operation request to the container runtime component.

[0009] The container runtime component is configured to, in a case where the operation request is a load request, generate a load task of the guest operating system according to the load request, and add the load task to a work queue of the guest operating system.

[0010] The guest operating system is configured to execute the load task in the work queue, and initiate a system call of loading a kernel module to load the kernel module into the guest operating system.

[0011] Embodiments of the present disclosure provide a kernel module processing method, applied to a container runtime component running on a host machine, the container runtime component creating and managing a secure container, the secure container including a guest operating system, the container runtime component being integrated with a running environment of the guest system and being capable of direct interaction, the method comprising: receiving an operation request sent by a management component on the host machine, the operation request being initiated for a kernel module; in a case where the operation request is a load request, generating a load task of the guest operating system according to the load request; and adding the load task to a work queue of the guest operating system, so as to enable the guest operating system to execute the load task and load the kernel module into the guest operating system.

[0012] Embodiments of the present disclosure also provide a kernel module processing method, applied to a container runtime component running on a host machine, the container runtime component creating and managing a secure container, the secure container including a guest operating system, the container runtime component being integrated with a running environment of the guest system and being capable of direct interaction, the method comprising: receiving an operation request sent by a management component on the host machine, the operation request being initiated for a kernel module; in a case where the operation request is an unload request, generating an unload task of the guest operating system according to the unload request; and adding the unload task to a work queue of the guest operating system, so as to enable the guest operating system to execute the unload task and unload the kernel module from the guest operating system.

[0013] The embodiment of the present disclosure further provides a kernel module processing method, applied to a container runtime component running on a host computer, the container runtime component creates and manages a secure container, the secure container comprises a guest operating system, the container runtime component is integrated with a running environment of the guest system and can directly interact, the method comprises the following steps: receiving an operation request sent by a management component on the host computer, the operation request is initiated for a kernel module; in the case that the operation request is a query request, sending a first reading request to the guest operating system to request detail information of a kernel module to be queried; receiving the detail information of the kernel module to be queried returned by the guest operating system according to the first reading request, and outputting the detail information of the kernel module to be queried through the management component.

[0014] The embodiment of the present disclosure further provides a computer device or a computing unit, comprising a memory and a processor; the memory is configured to store a computer program; the processor is coupled with the memory and is configured to execute the computer program to implement the steps in the various methods provided by the embodiment of the present disclosure.

[0015] The embodiment of the present disclosure further provides a computer readable storage medium storing a computer program, when the computer program is executed by a processor, the processor can implement the steps in the above method.

[0016] The embodiment of the present disclosure further provides a computer program product, the computer program product comprises computer programs / instructions, when the computer programs / instructions are executed by a processor, the processor can implement the steps in the above method embodiment.

[0017] In the embodiment of the present disclosure, the container runtime component is integrated with a running environment of an operating system in the secure container and can directly interact, thereby the loading operation of the kernel module of the secure container can be sunk to the host computer side to be completed, the loading of the kernel module no longer depends on the root system file, the risk of malicious tampering of the kernel module by the user can be reduced, and the security of the kernel module is enhanced.

[0018] Further, in the embodiment of the present disclosure, the kernel module is separated from the root file system, which is conducive to the version convergence of the root file system in different application scenarios; in addition, the loading of the kernel module no longer depends on the root file system, and the kernel module or the kernel can be added at any time or hot repaired during the entire life cycle of the secure container. BRIEF DESCRIPTION OF DRAWINGS

[0019] The accompanying drawings described herein are used to provide further understanding of the present disclosure, and form a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions serve to explain the present disclosure, and do not constitute improper limitations on the present disclosure. In the drawings:

[0020] FIG. 1 is a structural schematic diagram of a computer device according to an example embodiment of the present disclosure;

[0021] FIG. 2 is an interaction flow diagram of a kernel module processing method according to another example embodiment of the present disclosure;

[0022] FIG. 3 is an interaction flow diagram of a kernel module processing method according to another example embodiment of the present disclosure;

[0023] FIG. 4 is a structural schematic diagram of a computer device according to yet another example embodiment of the present disclosure;

[0024] FIG. 5 is a flow schematic diagram of a kernel module processing method according to an example embodiment of the present disclosure;

[0025] FIG. 6 is a flow schematic diagram of another kernel module processing method according to an example embodiment of the present disclosure;

[0026] FIG. 7 is a flow schematic diagram of another kernel module processing method according to an example embodiment of the present disclosure;

[0027] FIG. 8 is a structural schematic diagram of a kernel module processing apparatus according to an example embodiment of the present disclosure;

[0028] FIG. 9 is a structural schematic diagram of an internal implementation of a computer device according to an example embodiment of the present disclosure. DETAILED DESCRIPTION

[0029] To make the objectives, technical solutions, and advantages of the present disclosure clearer, the technical solutions of the present disclosure will be described below in conjunction with specific embodiments of the present disclosure and corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present disclosure, rather than all the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present disclosure.

[0030] It should be noted that, in the case of the present disclosure embodiments involving user information, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in the present disclosure embodiments are all information and data authorized by the user or authorized by all parties, and the collection, use, and processing of related data need to comply with relevant laws, regulations, and standards of relevant countries and regions, and provide corresponding operation portals for users to choose authorization or refusal. In addition, the various models (including but not limited to language models or large models) involved in the present disclosure are in compliance with relevant legal and standard regulations.

[0031] The secure container can support the performance and efficiency of the container while providing the secure isolation for the container. The secure container can have its own operating system and can not share the operating system of the host computer, thus having higher isolation and security. In the field of secure containers, a background developer can add a kernel module that needs to be loaded into the operating system of the secure container into a rootfs file, so that the kernel module can be added in the secure container by mounting the rootfs file when the secure container is started. However, the rootfs file is stored in the user mode of the secure container, and a user (for example, a tenant of a cloud service) of the secure container has the ability to view the rootfs file, and the rootfs file has a risk of exposure, and the user can even maliciously tamper with the rootfs file, thus threatening the security of the kernel module.

[0032] Further, based on the kernel module loading manner of the rootfs file, the kernel module can only be loaded when the secure container is created, and the loading of the kernel module at runtime or the hotfix of the kernel is not supported. In the embodiment of the present disclosure, the hotfix refers to the process of performing emergency repair for a serious error or vulnerability that has been found after the kernel module is loaded.

[0033] In order to solve the above technical problems, in the embodiment of the present disclosure, the container runtime component and the operating system in the secure container are integrated with each other and can directly interact, so that the loading operation of the kernel module of the secure container can be sunk to the host side to be completed, the loading of the kernel module no longer depends on the rootfs file, and the risk of malicious tampering of the kernel module by the user can be reduced, and the security of the kernel module can be enhanced.

[0034] Further, in the embodiment of the present disclosure, the kernel module is separated from the rootfs file, which is beneficial to the version convergence of the rootfs file in different application scenarios. Further, the loading of the kernel module no longer depends on the rootfs file, and the hotfix for the kernel can be performed at any time during the entire life cycle of the secure container.

[0035] The technical solutions provided by the embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0036] FIG. 1 is a structural schematic diagram of a computer device according to an example embodiment of the present disclosure. As shown in FIG. 1, the computer device 100 includes a host 10, which includes various hardware resources 11 including a computing unit 12; and various software programs running on the hardware resources 11, including a host operating system 13 in the kernel mode of the host and programs in the application layer in the user mode of the host. In this embodiment, a management component 14, a container runtime component 15, and a secure container 16 created and managed by the container runtime component 15 are taken as examples, which are all programs in the application layer running on the host. The secure container is used to create an isolated and secure running environment in the user mode of the host. Relative to the host 10, the secure container 16 can be referred to as a guest; as a guest, the secure container also includes a kernel mode and a user mode, and includes a guest operating system 17 in the kernel mode of the secure container and an application program running on the guest operating system 17 in the user mode of the secure container.

[0037] It should be noted that one secure container 16 and one container runtime component 15 are taken as examples in FIG. 1, but the present disclosure is not limited thereto. In this embodiment, the number of secure containers 16 and container runtime components 15 on the host is not limited.

[0038] In this embodiment, the computing unit on the host is logically divided based on a virtualization technology, and the divided virtual computing unit can be used by different guests. Normally, the operating system of the host runs on the computing unit of the host, and the guest operating system 17 of the secure container 16 (i.e., the guest) runs on the virtual computing unit of the guest. In this embodiment, the container runtime component 15 on the host is fused with the running environment of the guest operating system 17 based on a fusion virtualization technology, which breaks the inherent boundary between the host and the guest, so that at least part of the code in the guest operating system 17 can run on the computing unit of the host, i.e., the container runtime can call and run at least part of the code in the guest operating system 17. The computing unit of the host can be any computing unit with computing capability, for example, the computing unit can be but is not limited to a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), or a NPU (Neural Processing Unit), etc. Accordingly, the virtual computing unit can be a vCPU (virtualized CPU), a vGPU (virtualized GPU), or a vNPU (virtualized NPU), etc.

[0039] It should be noted that in some embodiments of the present disclosure, the container runtime component 15 is integrated with the running environment of the client operating system 17, which can be referred to as mutual integration between the container runtime component 15 and the client operating system 17.

[0040] In the present embodiment, the container runtime component 15 is integrated with the client operating system 17, which means that the container runtime component is integrated with the running environment of the client operating system. This will not be introduced in subsequent drawings. Based on the above implementation manner of mutual integration, the container runtime component 15 can directly interact with the client operating system 17. It should be understood that in FIG. 1, one secure container 16 is integrated with one container runtime component 15 as an example, that is, one secure container 16 is integrated with one container runtime component 15 as an example, but it is not limited thereto. One container runtime component 15 can be integrated with the client operating system 17 in one or more secure containers 16.

[0041] Further, the management component 14 is added in the user mode of the host computer. The management component 14 can be used as an interaction interface with external users, allowing users to initiate operation requests for kernel modules. The operation request can be a loading request, an unloading request, or a query request. The kernel module is an important component of the client operating system 17 and is a functional module that can be dynamically loaded and unloaded. Essentially, it is an independent program fragment that can be inserted into the client operating system 17, which can be loaded into the client operating system 17 when needed and unloaded when not needed. Through the mechanism of dynamically loading and unloading the kernel module, on the one hand, the client operating system 17 can remain flexible and lightweight, and on the other hand, the client operating system 17 can support more devices and functions without having to compile all functions into the client operating system 17 at the time of construction.

[0042] The management component 14 can respond to various operation requests initiated by the management user for the kernel module and submit the operation request to the container runtime component 15. The management user here refers to other users different from the use users (such as tenants of cloud services) of the secure container 16, for example, can be a middle office user or a background developer. The management user can analyze the functional requirements of the application program (such as cloud services) in the secure container 16 and convert the functional requirements of the application program into operation requests for the kernel module to send operation requests for the kernel module to the container runtime component 15 through the management component 14.

[0043] For example, as the application program needs more kernel modules to support the upgrade of its functions, the management user can initiate a loading request for the kernel modules; or as the application program optimizes its functions or iterates its version, it can no longer rely on some kernel modules, the management user can initiate an unloading request for the kernel modules; or in order to better develop the application program, it can be necessary to understand the detailed information of the kernel modules in the guest operating system 17 of the secure container 16, the management user can initiate a query request for the kernel modules, and the like.

[0044] When the container runtime component 15 receives the operation request sent by the management component 14, the container runtime component 15 can identify the type of the operation request. If the type of the operation request is a loading request, based on the mutual fusion between the container runtime component 15 and the guest operating system 17 of the secure container 16, the container runtime component 15 can generate a loading task for the guest operating system 17 according to the loading request, and add the loading task to the work queue of the guest operating system 17.

[0045] The work queue is a mechanism for the guest operating system 17 to manage and schedule tasks. By adding tasks to the work queue and assigning the tasks to corresponding virtual computing units for execution, the guest operating system 17 can execute the tasks in the work queue. Optionally, the guest operating system 17 can include one or more work queues, each work queue corresponding to a virtual computing unit. Different work queues can correspond to different virtual computing units, and the virtual computing units can be configured to execute tasks in the work queue.

[0046] Based on this, the guest operating system 17 executes the loading task in the work queue, initiates a system call to load the kernel module into the guest operating system 17. The system call is implemented by a kernel function, and different system calls can correspond to different kernel functions. Initiating a system call can implement operations on the kernel module, such as loading the kernel module.

[0047] In the embodiments of the present disclosure, based on the fusion of the container runtime component 15 and the operating system in the secure container 16, the two can directly interact, so that the loading operation of the kernel module of the secure container 16 can be performed on the host side, and the secure container 16 no longer depends on the rootfs file, thereby bypassing the user mode of the secure container 16, and the risk of malicious tampering of the kernel module by the user of the secure container 16 can be reduced, and the security of the kernel module and the entire guest operating system 17 can be enhanced. Further, the kernel module is separated from the rootfs file, which is conducive to the version convergence of the rootfs file in different application scenarios. In addition, the loading of the kernel module no longer depends on the rootfs file, and is no longer limited by the loading time of the rootfs file, so that the kernel module can be loaded at any time or hot repaired during the entire life cycle of the secure container 16.

[0048] When the kernel module is loaded into the guest operating system 17, the management user can also initiate an operation request of uninstalling the kernel module to the container runtime component 15 through the management component 14. Optionally, when the container runtime component 15 identifies that the operation request is an uninstall request, based on the fusion between the container runtime component 15 and the guest operating system 17 of the secure container 16, the container runtime component 15 can generate an uninstall task for the guest operating system 17 according to the uninstall request, and add the uninstall task to the work queue of the guest operating system 17, so that the guest operating system 17 executes the uninstall task in the work queue, initiates a system call of uninstalling the kernel module, and uninstalls the kernel module from the guest operating system 17.

[0049] Further optionally, the management user can also initiate an operation request of querying the kernel module through the management component 14. When the container runtime component 15 identifies that the operation request is a query request, the container runtime component 15 can send a first read request to the guest operating system 17 to request the detail information of the kernel module to be queried. When the guest operating system 17 receives the first read request, the guest operating system 17 queries the detail information of the corresponding kernel module, and returns the query result to the container runtime component 15. When the container runtime component 15 receives the detail information of the kernel module to be queried, the container runtime component 15 outputs the detail information to the management user through the management component 14.

[0050] In the present embodiment, the manner in which the management component 14 outputs the detail information of the kernel module is not limited. In an optional embodiment, the detail information of the kernel module can be output to a log for the management user to view by querying the log. In another optional embodiment, a UI interface or a command line tool can be provided and set to display the detail information of the kernel module to the management user. In yet another optional embodiment, the detail information of the kernel module can be sent to a terminal device used by the management user by means of an email or a short message, for the management user to view.

[0051] In the above embodiments, it is introduced that the container runtime component 15 can respond to different types of operation requests from the management and control component 14, and generate different interaction behaviors with the client operating system 17 according to different types of operation requests, so as to realize the loading, unloading and querying of the kernel module of the client operating system. In the process of realizing the loading or unloading of the kernel module, the container runtime component 15 generates a corresponding task for the kernel module, and adds the task to the work queue of the client operating system 17, so that the client operating system 17 executes the corresponding task and initiates the corresponding system call to complete the loading or unloading of the kernel module. The process of the container runtime component 15 generating the loading / unloading task and the process of the client operating system 17 executing the loading / unloading task will be introduced below in combination with FIG. 2.

[0052] As shown in FIG. 2, when the container runtime component 15 receives a loading request as the operation request (as shown in S201 in FIG. 2), the container runtime component 15 generates a loading task (as shown in S202 in FIG. 2). Optionally, in the generation process, the first task type and the loading parameter can be determined according to the loading request. The first task type can be a loading type, and the loading parameter at least includes the identification information of the kernel module to be loaded and the loading address of the intermediate state file corresponding to the kernel module to be loaded. The loading address points to the storage position of the intermediate state file in the shared memory between the container runtime component 15 and the client operating system 17. Then, the loading task is generated according to the first task type and the loading parameter.

[0053] Optionally, the shared memory can be disclosed by the container runtime component 15 to the host operating system and shared to the client operating system 17. Wherein, the intermediate state file corresponding to the kernel module can be pre-stored in the shared memory, and the way, timing, etc. of storing the intermediate state file into the shared memory is not limited. The intermediate state file corresponding to the kernel module refers to the intermediate product from the source code to the loadable kernel module, and different kernel modules can correspond to different intermediate state files. In this embodiment, the shared memory technology is used between the container runtime component 15 and the client operating system 17, which can simplify the data transmission process between the two, and is beneficial to improve the loading efficiency of the kernel module.

[0054] Further, as shown in FIG. 2, the container runtime component 15 adds the generated loading task to a work queue of the client operating system 17 (as shown in S203 in FIG. 2). In an optional embodiment, from a plurality of work queues of the client operating system 17, a work queue running on a first virtual computing unit is selected as a first work queue; wherein each work queue of the client corresponds to a virtual computing unit, the virtual computing unit is configured to execute tasks in the work queue corresponding thereto, the plurality of work queues can correspond to different virtual computing units, each virtual computing unit can be responsible for the execution of tasks in one or more work queues; different virtual computing units can have different privilege levels for controlling the execution authority of instructions, the privilege levels include Ring0 and Ring3, Ring0 corresponds to the kernel state of the client operating system 17, and Ring3 corresponds to the user state of the client operating system 17; the types of instructions include privileged instructions and non-privileged instructions, the privileged instructions are instructions executed in the kernel state of the client operating system 17, and the non-privileged instructions are instructions executed in the user state of the client operating system 17. In this embodiment, the first virtual computing unit is a virtual computing unit capable of executing privileged instructions in the client operating system 17. Further, the loading task is added to the first work queue running on the first virtual computing unit, so that the client operating system 17 executes the loading task using the first virtual computing unit in the case of executing the loading task in the first work queue (as shown in S205 in FIG. 2), so as to load the kernel module into the client operating system 17. Further optionally, as shown in FIG. 2, the first virtual computing unit can initiate a system call for loading the kernel module during the execution of the loading task (as shown in S206 in FIG. 2), and the system call returns when the execution of the system call ends. The client operating system 17 returns a loading task execution completion message to the container runtime component 15 in the case of returning the result of the system call (as shown in S207 in FIG. 2), and then the container runtime component 15 returns an operation completion notification to the management user through the management component (as shown in S209 in FIG. 2). In this embodiment, the execution of the loading task depends on the privileged instructions in the client operating system 17, so the loading task is added to the work queue responsible for the virtual computing unit capable of executing the privileged instructions, so as to ensure that the loading task is successfully executed.

[0055] For any kernel module that has been loaded into the client operating system 17, the management user can initiate an uninstall request to the container runtime component 15 through the management component 14. As shown in FIG. 2, the container runtime component 15 can generate a corresponding uninstall task for the client operating system 17 upon identifying the uninstall request. In an optional embodiment, when generating the uninstall task according to the uninstall request, the container runtime component 15 can determine a second task type and uninstall parameters according to the uninstall request; wherein the second task type can be an uninstall type, and the uninstall parameters at least include identification information of the kernel module to be uninstalled and the uninstall type; and further, generate the uninstall task according to the second task type and the uninstall parameters.

[0056] Optionally, the uninstall type includes normal uninstall and forced uninstall; the normal uninstall refers to removing the kernel module according to normal procedures and steps, ensuring that the files, configurations and dependencies associated with the kernel module are properly handled; accordingly, the forced uninstall refers to that in some cases, for example, in the case where the normal uninstall cannot be completed (such as being blocked by dependencies), the forced uninstall can be selected, and these blocking factors are ignored. The uninstall parameters include the uninstall type, and when generating the uninstall task according to the uninstall parameters, different uninstall tasks can be generated according to different uninstall types; in the case where the uninstall type is normal uninstall, a normal uninstall task is generated; and in the case where the uninstall type is forced uninstall, a forced uninstall task is generated.

[0057] As shown in FIG. 2, in the case where the uninstall task is generated, the container runtime component 15 can add the uninstall task to the work queue of the client operating system 17. Optionally, from the plurality of work queues of the client operating system 17, a work queue running on a second virtual computing unit is selected as a second work queue; the second virtual computing unit is a virtual computing unit capable of executing privileged instructions in the client operating system 17; the uninstall task is added to the second work queue running on the second virtual computing unit, so that the client operating system 17 executes the uninstall task on the second virtual computing unit to remove the corresponding kernel module. Further optionally, as shown in FIG. 2, during the execution of the uninstall task by the first virtual computing unit, a system call for uninstalling the kernel module can be initiated, and upon the end of the execution of the system call, a return operation of the system call is performed; the client operating system 17 returns a loading task execution completion message to the container runtime component 15 upon the return result of the system call, and then the container runtime component 15 returns an operation completion notification to the management user through the management component. Similarly, in this embodiment, the execution of the uninstall task depends on the privileged instructions in the client operating system 17, so the uninstall task is added to the work queue responsible for the virtual computing unit capable of executing the privileged instructions, to ensure that the uninstall task is successfully executed.

[0058] It should be noted that the first virtual computing unit and the second virtual computing unit can be the same or different virtual computing units; and the first work queue and the second work queue can also be the same or different work queues.

[0059] In the embodiment of the present disclosure, the container runtime component 15 can also receive a query request to query the detail information of the kernel module. As shown in FIG. 3, in the case of receiving the query request, a first read request (as shown in S303 in FIG. 3) is sent to the client operating system 17 to request the detail information of the kernel module to be queried, and after receiving the detail information of the kernel module to be queried returned by the client operating system 17, the management user is output by the management and control component 14. Wherein, the first read request is a kind of read request, in order to distinguish from other read requests, these read requests are respectively called first read request, second read request and so on, the first, second here are all for distinguishing, and there is no time, quantity and order limit. In the embodiment, the number of times of sending the first read request to the client operating system 17 is not limited, and the required various detail information can be obtained by sending the first read request once, or the required various detail information can also be obtained by sending the first read request multiple times. Optionally, as shown in FIG. 3, the container runtime component 15 sends the first read request to the client operating system 17, comprising: according to the number of detail information to be queried, sending one or more first read requests to the client operating system 17 to request to read the detail information of the kernel module to be queried;The number of times of sending the first read request is the same as the number of detail information requested to be queried. Wherein, the detail information of the kernel module to be queried includes at least one of the initialization state, the reference information, the reference count and the module size. The initialization state refers to the stable state that the kernel module is finally reached after being loaded into the client operating system 17;The reference information refers to the information of other modules using the kernel module, the reference depends on the kernel module, which means that these references should be removed before unloading the kernel module;The reference count refers to how many other modules are currently using the kernel module, the reference count can be 0 or an integer greater than 0;The module size refers to the size of the storage space occupied by the module in the memory. Wherein, understanding the initialization state, reference information, reference count and module size and other information of the kernel module is very important for debugging and managing the kernel module.

[0060] Optionally, the details of the kernel module to be queried include multiple types. As shown in FIG. 3, the case where the details of the kernel module to be queried include multiple types is illustrated as shown in S304, S306, S308 and S310 in FIG. 3. The container runtime component 15 can sequentially send a first read request to the client operating system 17 to respectively request different details of the kernel module to be queried. As shown in S305, S307, S309 and S311 in FIG. 3, the client operating system 17 returns the details corresponding to the multiple first read requests upon receiving the multiple first read requests. The target information for identifying the details to be read can be carried in each first read request, and the target information carried in different first read requests is different, so as to request different details.

[0061] In the embodiments of the present disclosure, the manner of determining the kernel module to be queried is not limited. In an optional embodiment, the query parameter is parsed from the query request. In the case where the query parameter is a default parameter, a second read request is sent to the client operating system 17 (as shown in S301 in FIG. 3) to request the directory information of the kernel module. The client operating system 17 returns the directory information of the kernel module upon receiving the second read request (as shown in S302 in FIG. 3), and the directory information at least includes the identification information of the loaded kernel module, and then all the kernel modules in the kernel module directory information are taken as the kernel module to be queried. In this optional embodiment, the details of all the loaded kernel modules are queried by default, which is suitable for full query, simple and efficient. In another optional embodiment, in the case where the query parameter includes the identification information of the kernel module, the kernel module corresponding to the identification information included in the query parameter is taken as the kernel module to be queried. In this embodiment, the identification information of the kernel module is carried in the query parameter, so that the details of the kernel module can be queried on demand, which is more flexible and convenient.

[0062] In the embodiments of the present disclosure, the implementation of the container runtime component 15 and the client operating system 17 is not limited to the fusion mode. Any implementation mode that can fuse the container runtime component 15 and the client operating system 17 is applicable to the embodiments of the present disclosure. Two implementation modes are listed as follows:

[0063] In an optional embodiment, the container runtime component 15 implements mutual fusion between the container runtime component 15 and the guest operating system 17 based on a shared memory technology and a kernel symbol export technology, in the fusion state, the container runtime component 15 and the guest operating system 17 can directly interact. Optionally, before initiating an operation request for a kernel module, the guest operating system 17 corresponding kernel state address space is shared to the container runtime component 15 based on the shared memory technology, and the kernel state function and data in the kernel state address space of the guest operating system 17 are stored; and the kernel symbol table in the guest operating system 17 is exported to the user state address space corresponding to the container runtime component 15 based on the kernel symbol export technology, so as to execute the kernel symbol in the kernel symbol table on the computing unit responsible for running the container runtime component 15 on the host (or understand as: the execution of the kernel symbol in the kernel symbol table by the container runtime component 15). The kernel symbol in the kernel symbol table is an interpretation of the kernel state function and data in the kernel state address space, and the kernel state function or data interpreted by the kernel symbol can be referred to as the kernel state function or data corresponding to the kernel symbol; the kernel symbol table includes the kernel symbol of the guest operating system 17 and the address information of the kernel state function or data corresponding to the kernel symbol, which is the address information of the kernel state function or data in the kernel state address space of the guest operating system 17, wherein the execution of the corresponding kernel symbol in the kernel symbol table, that is, the process of loading and executing the corresponding kernel state function in the kernel state address space according to the address corresponding to the kernel symbol in the kernel symbol table, and the container runtime component 15 can implement loading, unloading and querying operations for the kernel module through the execution of the kernel symbol.

[0064] Because the computing unit responsible for running the container runtime component 15 on the host also runs the code of the host (including but not limited to the container runtime component 15) and the kernel symbol in the kernel symbol table of the guest operating system 17 at the same time, the container runtime component 15 and the guest operating system 17 are mutually fused and can directly interact, the kernel symbol table is exported to the user state address space corresponding to the container runtime component 15 on the host and can be referenced by the container runtime component 15, based on which the container runtime component 15 can generate a loading task or an unloading task for the kernel module for the guest operating system 17, and provide the loading task or the unloading task to the work queue of the guest operating system 17, so that the guest operating system 17 executes the loading task or the unloading task in the work queue by using the virtual computing unit, and completes the loading or unloading of the kernel module.

[0065] Based on the above, in this optional mode, the mutual fusion between the container runtime component 15 and the client operating system 17 can be implemented as follows: storing the kernel symbol table in the user space address space corresponding to the container runtime component 15, and the kernel symbol in the kernel symbol table is an interpretation of the function or data stored in the kernel space address space of the client operating system 17. Further, the mutual fusion between the container runtime component 15 and the client operating system 17 also includes sharing the kernel space address space corresponding to the client operating system 17 with the container runtime component 15. In the following, the loading, unloading and querying processes of the kernel module of the client operating system 17 are introduced in combination with this optional fusion mode.

[0066] When the container runtime component 15 loads the kernel module, it generates a loading task and selects a first work queue from the client operating system 17, and then adds the loading task to the first work queue for the client operating system 17 to execute the loading task in the first work queue to complete the loading of the kernel module. As can be seen, in the kernel module loading process, the container runtime component 15 will involve operations such as generating a loading task, selecting a work queue, and adding a loading task to a work queue, and each operation has a corresponding kernel symbol in the kernel symbol table, and the corresponding kernel symbol is executed to complete the corresponding operation.

[0067] In an optional embodiment, when the container runtime component 15 generates a loading task, it can query a first kernel symbol from the kernel symbol table, and the first kernel symbol is a kernel symbol that interprets the creation function in the client operating system 17; the first task type and the loading parameter are taken as the arguments of the first kernel symbol, and the first kernel symbol is executed to create the loading task.

[0068] Further optionally, the container runtime component 15 selects a work queue running on the first virtual computing unit from the plurality of work queues in the client operating system 17, and in the selection process, a second kernel symbol is queried from the kernel symbol table, and the second kernel symbol is a kernel symbol that interprets the selection function in the client operating system 17; and then the second kernel symbol is executed to select the first work queue from the plurality of work queues of the client operating system 17 and output the queue serial number of the first work queue.

[0069] Further optionally, the container runtime component 15 adds the loading task to the first work queue, including: querying a third kernel symbol from the kernel symbol table, and the third kernel symbol is a kernel symbol that interprets the submission function in the client operating system 17; the loading task and the queue serial number of the first work queue are taken as the arguments of the third kernel symbol, and the third kernel symbol is executed to add the loading task to the first work queue.

[0070] The create function, the selection function, and the submit function are all kernel-level functions in the client operating system 17. Based on the mutual fusion between the container runtime component 15 and the client operating system 17 of the secure container 16, the container runtime component 15 can directly execute the kernel symbols corresponding to the create function, the selection function, and the submit function to generate a loading task required to be executed by the client operating system 17, select a work queue required by the client operating system 17, and submit the loading task to the work queue. It is explained that the container runtime component 15 runs on a computing unit of a host computer, and the execution of the kernel symbols corresponding to the create function, the selection function, and the submit function by the container runtime component 15 means that the create function, the selection function, and the submit function run on the computing unit of the host computer, and the boundary between the host computer and the secure container 16 is broken based on the fusion virtualization technology.

[0071] Similar to the loading task, the container runtime component 15 generates an unloading task in the case of unloading a kernel module, selects a second work queue from the client operating system 17, and then adds the unloading task to the second work queue for the client operating system 17 to execute the unloading task in the second work queue to complete the unloading of the kernel module.

[0072] In an optional embodiment, when the container runtime component 15 generates the unloading task, the container runtime component 15 can query a first kernel symbol from the kernel symbol table, the first kernel symbol is a kernel symbol that interprets the create function in the client operating system 17, takes the second task type and the unloading parameter as the input parameters of the first kernel symbol, and executes the first kernel symbol to create the unloading task.

[0073] Further optionally, the container runtime component 15 selects a work queue running on the second virtual computing unit from a plurality of work queues in the client operating system 17, and in the selection process, queries a second kernel symbol from the kernel symbol table, the second kernel symbol is a kernel symbol that interprets the selection function in the client operating system 17, and then executes the second kernel symbol to select the second work queue from the plurality of work queues in the client operating system 17 and output the queue serial number of the second work queue.

[0074] Further optionally, the container runtime component 15 adds the loading task to the second work queue, including: querying a third kernel symbol from the kernel symbol table, the third kernel symbol is a kernel symbol that interprets the submit function in the client operating system 17, taking the unloading task and the queue serial number of the second work queue as the input parameters of the third kernel symbol, and executing the third kernel symbol to add the unloading task to the second work queue.

[0075] The create function, the select function, and the submit function are all kernel-level functions in the client operating system 17. Based on the mutual fusion between the container runtime component 15 and the client operating system 17 of the secure container 16, the container runtime component 15 can directly execute the kernel symbols corresponding to the create function, the select function, and the submit function to generate an unload task required by the client operating system 17, select a work queue required by the client operating system 17, and submit the unload task to the work queue. It is explained that the container runtime component 15 runs on a computing unit of a host computer, and the container runtime component 15 executes the kernel symbols corresponding to the create function, the select function, and the submit function, which means that the create function, the select function, and the submit function run on the computing unit of the host computer, and the boundary between the host computer and the secure container 16 is broken based on the fusion virtualization technology.

[0076] Different from the loading and unloading of the kernel module is the querying of the kernel module. In the case where the management user initiates a query request for the kernel module, since the kernel symbol table in the client operating system 17 has been exported to the user-level address space corresponding to the container runtime component 15, the kernel symbol corresponding to the query operation can be directly executed from the user-level address space corresponding to the container runtime component 15 to initiate a corresponding read request to the client operating system 17 without creating and submitting the related task.

[0077] Based on this, in an optional embodiment, in the case where the container runtime component 15 identifies that the operation request is a query request, the fourth kernel symbol can be queried from the kernel symbol table, the fourth kernel symbol being a kernel symbol for interpreting the query function in the client operating system 17; and the fourth kernel symbol is executed to send a read request to the client operating system 17 to request the detail information of the kernel module to be queried, and output to the management user through the management component 14.

[0078] The query function is a kernel-level function in the client operating system 17. Based on the mutual fusion between the container runtime component 15 and the client operating system 17 of the secure container 16, the container runtime component 15 can directly execute the kernel symbol corresponding to the query function to initiate a query request to the client operating system 17, and then obtain the detail information of the kernel module to be queried from the kernel-level address space corresponding to the client operating system 17.

[0079] It should be understood that the above-mentioned fusion manner based on the shared memory technology and the kernel symbol table export technology is an optional implementation. In the embodiments of the present disclosure, another optional fusion manner is also provided, in which, based on the development of the client operating system 17 code, a server module is implemented in the kernel state of the client operating system 17 for interaction with the container runtime component 15, thereby realizing a communication link based on the kernel state of the client operating system 17 and the user state of the host operating system. In this optional implementation, based on TTRPC (a communication protocol based on gRPC), the server module can be created in the kernel state of the client operating system 17 at the start of the secure container 16 for receiving TTRPC requests sent by the container runtime component 15. In turn, the container runtime component 15 can convert the functional requirements sent by the management user through the management component 14 into corresponding TTRPC requests, and send the TTRPC requests to the server module, so that the server module performs the operations of loading, unloading or querying the kernel module according to the TTRPC requests.

[0080] Further in this optional manner, when the server module receives the TTRPC request, it identifies the type of the TTRPC request, initiates the system call of loading or unloading the kernel module according to the type of the TTRPC request; or, in the case that the TTRPC request is of the query type, executes the TTRPC request to query the detail information of the kernel module, and returns the queried detail information of the kernel module to the container runtime component 15, so that the container runtime component 15 provides the detail information of the kernel module to the management user.

[0081] Among them, the structure of the container runtime component 15 implemented in different fusion manners will be different. Next, an example of the structure of the container runtime component 15 will be given in combination with the computer device shown in FIG. 1.

[0082] FIG. 4 is a structural schematic diagram of a computer device according to an example embodiment of the present disclosure. As shown in FIG. 4, the computer device 400 includes a host computer 10, the host computer 10 includes various hardware resources 11 including a computing unit 12, and various software programs run on the hardware resources 11, including a host operating system 13 in the kernel mode of the host computer and programs in the application layer in the user mode of the host computer. In this embodiment, the programs in the application layer running on the host computer include a management component 14, a container runtime component 15, and a secure container 16 created and managed by the container runtime component 15, all of which run in the user mode of the host computer. The secure container 16 is configured to create an isolated and secure running environment in the user mode of the host computer. Relative to the host computer 10, the secure container 16 can be referred to as a guest computer; the secure container as the guest computer also includes a kernel mode and a user mode, and includes a guest operating system 17 in the kernel mode of the secure container and application programs running on the guest operating system 17 in the user mode of the secure container.

[0083] As shown in FIG. 4, an implementation structure of the container runtime component 15 includes a converged virtualization component 151, a kernel module operation component 152, and a management interface 153.

[0084] In this embodiment, the converged virtualization component 151 is configured to realize the mutual convergence between the container runtime component 15 and the guest operating system 17 based on the shared memory technology and the kernel symbol export technology; further, the management interface 153 can be configured to receive an operation request sent by the management component 14, and in a case where it is identified that the operation request is an operation request for a kernel module of the guest operating system 17, send the operation request to the kernel module operation component 152; further, the kernel module operation component 152 can be configured to identify the type of the operation request, and in a case where the operation request is a loading request, generate a loading task of the guest operating system 17 according to the loading request, add the loading task to a work queue of the guest operating system 17, so that the guest operating system 17 executes the loading task in the work queue to complete the loading of the kernel module.

[0085] Further, the kernel module operation component 152 is further configured to, in a case where the operation request is an uninstall request, generate an uninstall task of the guest operating system 17 according to the uninstall request, add the uninstall task to a work queue of the guest operating system 17, and enable the guest operating system 17 to execute the uninstall task in the work queue to complete uninstallation of the kernel module; and further configured to, in a case where it is identified that the operation request is a query request, send a first read request to the guest operating system 17 to request details of the kernel module to be queried, and output to the management user through the management and control component 14.

[0086] As shown in FIG. 4, in an optional embodiment, the kernel module operation component 152 includes a loading module 154, an uninstalling module 155, and a querying module 156, which are respectively configured to receive a loading request, an uninstall request, and a query request, and perform operations corresponding to the types of the operation requests. For example, in a case where it is identified that the operation request is a loading request, the loading request is provided to the loading module 154, which generates a loading task of the guest operating system 17 according to the loading request, and adds the loading task to a work queue of the guest operating system 17; the querying module 156 is configured to, in a case where it receives the query request, send a first read request to the guest operating system 17 to request details of the kernel module to be queried, and output to the management user through the management and control component 14; and the uninstalling module 155 is configured to generate an uninstall task of the guest operating system 17 according to the uninstall request, and add the uninstall task to a work queue of the guest operating system 17.

[0087] The specific implementation of the operation steps corresponding to the modules included in the container runtime component 15 can refer to the foregoing embodiments, which will not be described herein again.

[0088] FIG. 5 is a flowchart of a kernel module processing method provided in an embodiment of the present disclosure. The kernel module processing method provided in the embodiment of the present disclosure can be applied to the computer device provided in the foregoing embodiments, the computer device running the management and control component, the container runtime component, and the secure container created and managed by the container runtime component. The detailed implementation structure of the computer device and the detailed functions of the modules therein can refer to the foregoing embodiments, which will not be described herein again. Specifically, the embodiment can describe the method from the perspective of the container runtime component running on the computer device. As shown in FIG. 5, the method includes the following steps:

[0089] 501. Receive an operation request sent by the management and control component on the host computer, the operation request being initiated for a kernel module;

[0090] 502. In a case where the operation request is a loading request, generate a loading task of the guest operating system according to the loading request;

[0091] 503、add the loading task to a work queue of the guest operating system for the guest operating system to execute the loading task to load the kernel module into the guest operating system.

[0092] In the embodiment, the kernel module is an important component in the guest operating system, is a functional module that is allowed to be dynamically loaded and unloaded, and is essentially an independent program fragment that can be inserted into the guest operating system, which can be loaded into the guest operating system when needed and unloaded when not needed. Through the mechanism of dynamically loading and unloading the kernel module, on the one hand, the guest operating system can remain flexible and lightweight, and on the other hand, the guest operating system can support more devices and functions without the need to compile all functions into the guest operating system at the time of construction.

[0093] In the embodiment, the container runtime component is running in the user mode of the host computer, and the container runtime component can create and manage a secure container, which is set to create an isolated and secure running environment in the user mode of the host computer. With respect to the host computer, the secure container can be implemented as a guest of the host computer, and the secure container has its own operating system. In order to distinguish from the operating system of the host computer, the operating system of the secure container is referred to as the guest operating system.

[0094] In the embodiment, by means of virtualization fusion technology, the running environment of the host computer (specifically, the container runtime component on the host computer) and the secure container are fused, which can also be referred to as mutual fusion between the container runtime component and the secure container, that is, the boundary between the host computer and the secure container is broken, so that the code (referred to as kernel code for short) in the guest operating system of the secure container can run on the computing unit (such as CPU) of the host computer. Before mutual fusion between the host computer and the secure container, the kernel code and the user code in the secure container can only run on the virtual computing resource (such as vCPU) of the secure container; correspondingly, the computing unit of the host computer can only run the user code and the kernel code of the host computer.

[0095] Further, a management component is added in the user mode of the host computer, the management component can serve as an interaction interface with the external user, allowing the user to initiate an operation request for the kernel module, which can be a loading request, an unloading request or a query request; the management component submits the operation request to the container runtime component, which, in the case of determining that the operation request is a loading request, based on the mutual fusion between the container runtime component and the guest operating system of the secure container, can generate a loading task of the guest operating system, and add the loading task to the work queue of the guest operating system, and the guest operating system is responsible for executing the loading task to realize the loading of the kernel module. As can be seen, under the mutual cooperation of the management component, the container runtime component and the secure container, the user mode of the secure container can be bypassed to load the kernel module into the guest operating system of the secure container.

[0096] In the embodiments of the present disclosure, since the user mode of the secure container is bypassed, the kernel module is not placed in the root file system of the secure container for loading, but is loaded into the guest operating system of the secure container through the host computer, and the whole process can be achieved without the awareness of the user of the secure container, thereby avoiding the risk of exposing the kernel module to the user of the secure container, and further reducing the risk of malicious tampering of the kernel module by the user of the secure container, which is conducive to improving the security of the kernel module and even the entire guest operating system.

[0097] In addition, in the embodiments of the present disclosure, the kernel module is not placed in the root file system of the secure container for loading, which is conducive to reducing the size of the root file system and facilitating the convergence of the root file system. Furthermore, in the embodiments of the present disclosure, the kernel module is not placed in the root file system of the secure container for loading, so it is no longer limited by the loading time of the root file system, and the kernel module can be added to the guest operating system at any time during the running of the secure container or the kernel can be hot repaired.

[0098] In an optional embodiment, generating the loading task of the guest operating system according to the loading request comprises: determining a first task type and loading parameters according to the loading request, the loading parameters at least including identification information of the kernel module to be loaded and a loading address of the intermediate state file corresponding to the kernel module to be loaded; and generating the loading task according to the first task type and the loading parameters, the loading address pointing to a storage location of the intermediate state file in the shared memory between the container runtime component and the guest operating system. In the present embodiment, the shared memory technology is used between the container runtime component and the guest operating system, which can simplify the data transmission process between the two, and is conducive to improving the loading efficiency of the kernel module.

[0099] In an optional embodiment, adding the loading task to the work queue of the guest operating system comprises: selecting a work queue running on the first virtual computing unit from at least one work queue of the guest operating system as the first work queue, the first virtual computing unit being a virtual computing unit capable of executing privileged instructions in the guest operating system; and adding the loading task to the first work queue. In this optional embodiment, considering that the guest operating system can have multiple work queues, different work queues are configured to carry different types of tasks, and different work queues run on different virtual computing units, different types of tasks have different dependencies on privileged instructions in the guest operating system, and accordingly, the virtual computing units of the guest operating system are divided into two types, one being a virtual computing unit capable of executing privileged instructions, and the other being a virtual computing unit incapable of executing privileged instructions. In this embodiment, the execution of the loading task depends on privileged instructions in the guest operating system, and therefore, the loading task is added to the work queue responsible for the virtual computing unit capable of executing privileged instructions, to ensure that the loading task is successfully executed.

[0100] In an optional embodiment, the mutual fusion between the container runtime component and the guest operating system is implemented by: storing a kernel symbol table in the guest operating system in the user space address space corresponding to the container runtime component, the kernel symbol in the kernel symbol table being an interpretation of a function and / or data stored in the kernel space address space of the guest operating system by the guest operating system.

[0101] Further optionally, based on the above implementation of mutual fusion, the loading task is generated according to the first task type and the loading parameter, comprising: querying a first kernel symbol from the kernel symbol table, the first kernel symbol being a kernel symbol that interprets a creation function in the guest operating system; and executing the first kernel symbol with the first task type and the loading parameter as input parameters of the first kernel symbol, to create the loading task.

[0102] Further, based on the above implementation of mutual fusion, selecting a work queue running on the first virtual computing unit from at least one work queue of the guest operating system as the first work queue comprises: querying a second kernel symbol from the kernel symbol table, the second kernel symbol being a kernel symbol that interprets a selection function in the guest operating system; and executing the second kernel symbol to select the first work queue from at least one work queue of the guest operating system and output the queue number of the first work queue.

[0103] Further, based on the above-mentioned implementation manner of mutual fusion, the loading task is added to the first work queue, including: querying a third kernel symbol from a kernel symbol table, the third kernel symbol being a kernel symbol for interpreting the submission function in the guest operating system; taking the loading task and the queue number of the first work queue as input parameters of the third kernel symbol, and executing the third kernel symbol to add the loading task to the first work queue.

[0104] The creation function, the selection function, and the submission function are all kernel-mode functions in the guest operating system. Based on the mutual fusion between the container runtime component and the guest operating system of the secure container, the container runtime component can directly execute the kernel symbols corresponding to the creation function, the selection function, and the submission function to generate a loading task required to be executed by the guest operating system, select a work queue required by the guest operating system, and submit the loading task to the work queue. It is noted that the container runtime component runs on a computing unit of a host machine, and the execution of the kernel symbols corresponding to the creation function, the selection function, and the submission function by the container runtime component means that the creation function, the selection function, and the submission function run on the computing unit of the host machine, and the boundary between the host machine and the secure container is broken based on the fusion virtualization technology.

[0105] In an optional embodiment, the method of the present disclosure further includes: in the case that the operation request is an uninstallation request, generating an uninstallation task of the guest operating system according to the uninstallation request; and adding the uninstallation task to a work queue of the guest operating system for the guest operating system to execute the uninstallation task to uninstall the kernel module from the guest operating system.

[0106] Therefore, under the mutual cooperation of the management component, the container runtime component, and the secure container, the kernel module can be uninstalled from the guest operating system of the secure container by the host machine without passing through the user mode of the secure container, the whole process can be completely transparent to the user of the secure container, and the security of the kernel module and even the entire guest operating system can be improved.

[0107] In an optional embodiment, the generation of the uninstallation task of the guest operating system according to the uninstallation request includes: determining a second task type and uninstallation parameters according to the uninstallation request, the uninstallation parameters at least including identification information of the kernel module to be uninstalled and an uninstallation type; and generating the uninstallation task according to the second task type and the uninstallation parameters.

[0108] In an optional embodiment, the addition of the uninstallation task to the work queue of the guest operating system includes: selecting a work queue running on a second virtual computing unit from at least one work queue of the guest operating system as a second work queue; and adding the uninstallation task to the second work queue, the second virtual computing unit being a virtual computing unit capable of executing privileged instructions in the guest operating system.

[0109] Further optionally, based on the above-mentioned implementation manner of mutual fusion, the generating the offloading task according to the second task type and the offloading parameter comprises: querying a first kernel symbol from a kernel symbol table, the first kernel symbol being a kernel symbol for interpreting a creating function in the guest operating system; taking the second task type and the offloading parameter as arguments of the first kernel symbol, and executing the first kernel symbol to create the offloading task.

[0110] Further, based on the above-mentioned implementation manner of mutual fusion, the selecting the work queue running on the second virtual computing unit as the second work queue from the at least one work queue of the guest operating system comprises: querying a second kernel symbol from a kernel symbol table, the second kernel symbol being a kernel symbol for interpreting a selecting function in the guest operating system; and executing the second kernel symbol to select the second work queue from the at least one work queue of the guest operating system and output a queue serial number of the second work queue.

[0111] Further, based on the above-mentioned implementation manner of mutual fusion, the adding the offloading task to the second work queue comprises: querying a third kernel symbol from a kernel symbol table, the third kernel symbol being a kernel symbol for interpreting a submitting function in the guest operating system; taking the offloading task and the queue serial number of the second work queue as arguments of the third kernel symbol, and executing the third kernel symbol to add the offloading task to the second work queue.

[0112] The creating function, the selecting function and the submitting function are all kernel-mode functions in the guest operating system, and based on the mutual fusion between the container runtime component and the guest operating system of the secure container, the container runtime component can directly execute the kernel symbols corresponding to the creating function, the selecting function and the submitting function to generate the offloading task required to be executed by the guest operating system, select the work queue required by the guest operating system, and submit the offloading task to the work queue. It is noted that the container runtime component runs on a computing unit of a host machine, and the execution of the kernel symbols corresponding to the creating function, the selecting function and the submitting function by the container runtime component means that the creating function, the selecting function and the submitting function run on the computing unit of the host machine, and the boundary between the host machine and the secure container is broken based on the fusion virtualization technology.

[0113] In an optional embodiment, the method of the present disclosure further comprises: in the case that the operation request is a query request, sending a first read request to the guest operating system to request the detail information of the kernel module to be queried; receiving the detail information of the kernel module to be queried returned by the guest operating system according to the first read request, and outputting the detail information of the kernel module to be queried through the management component.

[0114] Therefore, under the cooperation of the management component, the container runtime component and the secure container, the user state of the secure container can be bypassed, the details information of the kernel module in the guest operating system of the secure container can be queried by the host, and the use of the secure container can be completely unaware by the user, thereby improving the security of the kernel module and the entire guest operating system.

[0115] In an optional embodiment, the method of the embodiment further includes: parsing the query parameter from the query request; in the case that the query parameter is a default parameter, sending a second read request to the guest operating system to request the kernel module directory information, and taking all the kernel modules in the kernel module directory information as the kernel modules to be queried; or in the case that the query parameter includes the identification information of the kernel module, taking the kernel module corresponding to the identification information included in the query parameter as the kernel module to be queried.

[0116] In an optional embodiment, sending the first read request to the guest operating system includes: sending the first read request to the guest operating system to request the details information of the kernel module to be queried according to the number of the details information to be queried, wherein the details information of the kernel module to be queried includes at least one of the initialization state, the referrer information, the reference count and the module size.

[0117] Further optionally, if the kernel symbol table includes the kernel symbol that interprets the query function, based on the above-mentioned implementation of mutual fusion, when the first read request is sent to the guest operating system according to the number of the details information to be queried, the fourth kernel symbol that interprets the query function in the guest operating system can be queried from the kernel symbol table; the identification information of the details information to be queried is taken as the input parameter of the fourth kernel symbol, and the fourth kernel symbol is executed to read the details information of the kernel module to be queried. If the kernel symbol table does not include the kernel symbol that interprets the query function, the first read request can be sent to the guest operating system to request the details information of the kernel module to be queried according to the above-mentioned optional embodiment.

[0118] In an optional embodiment, the method of the embodiment further includes: based on the shared memory technology and the kernel symbol export technology, realizing the mutual fusion between the container runtime component and the guest operating system, so that the container runtime component and the guest operating system can directly interact.

[0119] Further optionally, based on the shared memory technology and the kernel symbol export technology, the mutual fusion between the container runtime component and the guest operating system is implemented, including: sharing a kernel mode address space corresponding to the guest operating system to the container runtime component, the kernel mode address space storing functions and data in the guest operating system; exporting a kernel symbol table in the guest operating system to a user mode address space corresponding to the container runtime component, kernel symbols in the kernel symbol table being an interpretation of the functions and / or data in the kernel mode address space, so as to realize the mutual fusion between the container runtime component and the guest operating system.

[0120] FIG. 6 is a flowchart of another kernel module processing method provided by the embodiments of the present disclosure. The kernel module processing method provided by the embodiments of the present disclosure can be applied to the computer device provided by the above embodiments, the computer device running a management component, a container runtime component, and a secure container created and managed by the container runtime component. The detailed implementation structure of the computer device and the detailed functions of each module therein can be referred to the foregoing embodiments, and will not be described here. Specifically, the present embodiment can describe the method from the perspective of the container runtime component running on the computer device. As shown in FIG. 6, the method includes the following steps:

[0121] 601. Receive an operation request sent by the management component on the host, the operation request being initiated for a kernel module;

[0122] 602. In the case that the operation request is an uninstallation request, generate an uninstallation task of the guest operating system according to the uninstallation request;

[0123] 603. Add the uninstallation task to a work queue of the guest operating system, so that the guest operating system executes the uninstallation task to uninstall the kernel module from the guest operating system.

[0124] The related concepts of the host, the container runtime component, the secure container, the kernel module, the guest operating system, and the like can be referred to the description of the foregoing embodiments, and will not be described here.

[0125] In the present embodiment, under the mutual cooperation of the management component, the container runtime component, and the secure container, the kernel module can be uninstalled from the guest operating system of the secure container by the host through the user mode of the secure container, the whole process can be realized without the awareness of the user of the secure container, which is conducive to improving the security of the kernel module and even the whole guest operating system.

[0126] FIG. 7 is a flow diagram of another kernel module processing method provided by an embodiment of the present disclosure. The kernel module processing method provided by an embodiment of the present disclosure can be applied to the computer device provided by the above embodiments, the computer device running a management component, a container runtime component, and a secure container created and managed by the container runtime component. For the detailed implementation structure of the computer device and the detailed functions of each module, refer to the foregoing embodiments, which will not be described here. Specifically, the present embodiment can describe the method from the perspective of the container runtime component running on the computer device. As shown in FIG. 7, the method includes the following steps:

[0127] 701. Receive an operation request sent by the management component on the host computer, the operation request being initiated for a kernel module;

[0128] 702. In the case of an operation request being a query request, send a first read request to the guest operating system to request the detail information of the kernel module to be queried;

[0129] 703. Receive the detail information of the kernel module to be queried returned by the guest operating system according to the first read request, and output the detail information of the kernel module to be queried through the management component.

[0130] For the related concepts of host computer, container runtime component, secure container, kernel module, guest operating system, and the like, refer to the description of the foregoing embodiments, which will not be described here.

[0131] In the present embodiment, under the cooperation of the management component, the container runtime component, and the secure container, the user state of the secure container can be bypassed, the detail information of the kernel module in the guest operating system of the secure container can be queried through the host computer, the whole process can be made to be imperceptible to the user of the secure container, and the security of the kernel module and even the entire guest operating system can be improved.

[0132] For the detailed implementation and beneficial effects of each step in the method of the present embodiment, refer to the foregoing embodiments, which will not be described here.

[0133] It should be noted that in some of the processes described in the above embodiments and accompanying drawings, a plurality of operations are included in a specific order, but it should be clearly understood that these operations can be executed or in parallel, not in the order in which they appear in this paper. The serial numbers of the operations such as 501, 502, etc. are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes can include more or fewer operations, and the operations can be executed in sequence or in parallel. It should be noted that the "first", "second" and the like described herein are used to distinguish different messages, devices, modules, etc., and do not represent the order of precedence. Also, "first" and "second" are not of different types.

[0134] FIG. 8 is a structural schematic diagram of a kernel module processing apparatus provided by an embodiment of the present disclosure. The apparatus can be applied to a container runtime component in a computer device to implement, as shown in FIG. 8, the apparatus includes:

[0135] The receiving module 81 is configured to receive an operation request sent by a management component on a host, the operation request being initiated for a kernel module;

[0136] The generating module 82 is configured to, in a case where the operation request is a loading request, generate a loading task of a guest operating system according to the loading request;

[0137] The adding module 83 is configured to add the loading task to a work queue of the guest operating system, so that the guest operating system executes the loading task to load the kernel module into the guest operating system.

[0138] In an optional embodiment, the generating module 82 is specifically configured to: determine a first task type and loading parameters according to the loading request, the loading parameters at least including identification information of a kernel module to be loaded and a loading address of an intermediate state file corresponding to the kernel module to be loaded, the loading address pointing to a storage location of the intermediate state file in a shared memory between the container runtime component and the guest operating system; and generate the loading task according to the first task type and the loading parameters.

[0139] In an optional embodiment, the adding module 83 is specifically configured to: select, from at least one work queue of the guest operating system, a work queue running on a first virtual computing unit as a first work queue, the first virtual computing unit being a virtual computing unit capable of executing privileged instructions in the guest operating system; and add the loading task to the first work queue.

[0140] In an optional embodiment, the container runtime component is implemented in fusion with the runtime environment of the client operating system by storing a kernel symbol table in the user space address space corresponding to the container runtime component, the kernel symbols in the kernel symbol table being interpretations of functions and / or data stored in the kernel space address space of the client operating system.

[0141] Further optionally, based on the above-mentioned implementation in fusion, the generating module 82, when generating the loading task according to the first task type and the loading parameter, is specifically configured to: query a first kernel symbol from the kernel symbol table, the first kernel symbol being a kernel symbol that is an interpretation of a creation function in the client operating system; and execute the first kernel symbol with the first task type and the loading parameter as input parameters of the first kernel symbol, to create the loading task.

[0142] Further, based on the above-mentioned implementation in fusion, the adding module 83, when selecting a work queue running on the first virtual computing unit as the first work queue from the at least one work queue of the client operating system, is specifically configured to: query a second kernel symbol from the kernel symbol table, the second kernel symbol being a kernel symbol that is an interpretation of a selection function in the client operating system; and execute the second kernel symbol to select the first work queue from the multiple work queues of the client operating system and output a queue serial number of the first work queue.

[0143] Further, based on the above-mentioned implementation in fusion, the adding module 83, when adding the loading task to the first work queue, is specifically configured to: query a third kernel symbol from the kernel symbol table, the third kernel symbol being a kernel symbol that is an interpretation of a submission function in the client operating system; and execute the third kernel symbol with the loading task and the queue serial number of the first work queue as input parameters of the third kernel symbol, to add the loading task to the first work queue.

[0144] In an optional embodiment, the generating module 82 is further configured to: in a case where the operation request is an uninstallation request, generate an uninstallation task of the client operating system according to the uninstallation request. The adding module 83 is further configured to: add the uninstallation task to a work queue of the client operating system, so that the client operating system executes the uninstallation task to uninstall the kernel module from the client operating system.

[0145] In an optional embodiment, the generating module 82 generates the uninstallation task of the client operating system according to the uninstallation request, including: determining a second task type and uninstallation parameters according to the uninstallation request, the uninstallation parameters at least including identification information of the kernel module to be uninstalled and an uninstallation type; and generating the uninstallation task according to the second task type and the uninstallation parameters.

[0146] In an optional embodiment, the adding module 83 is specifically configured to, when adding the offload task into the work queue of the client operating system, select a work queue running on a second virtual computing unit from at least one work queue of the client operating system as a second work queue, the second virtual computing unit being a virtual computing unit capable of executing privileged instructions in the client operating system; and add the offload task into the second work queue.

[0147] Further, based on the above-mentioned implementation manner, the generating module 82 is specifically configured to, when generating the offload task according to the second task type and the offload parameter, query a first kernel symbol from the kernel symbol table, the first kernel symbol being a kernel symbol for interpreting a creation function in the client operating system; and execute the first kernel symbol by taking the second task type and the offload parameter as input parameters of the first kernel symbol, so as to create the offload task.

[0148] Further, based on the above-mentioned implementation manner, the adding module 83 is specifically configured to, when selecting a work queue running on a second virtual computing unit from at least one work queue of the client operating system as a second work queue, query a second kernel symbol from the kernel symbol table, the second kernel symbol being a kernel symbol for interpreting a selection function in the client operating system; and execute the second kernel symbol, so as to select the second work queue from the at least one work queue of the client operating system and output a queue serial number of the second work queue.

[0149] Further, based on the above-mentioned implementation manner, the adding module 83 is specifically configured to, when adding the offload task into the second work queue, query a third kernel symbol from the kernel symbol table, the third kernel symbol being a kernel symbol for interpreting a submission function in the client operating system; and execute the third kernel symbol by taking the offload task and the queue serial number of the second work queue as input parameters of the third kernel symbol, so as to add the offload task into the second work queue.

[0150] In an optional embodiment, the apparatus provided by the embodiments of the present disclosure further includes: a sending module 84, configured to, when the operation request is a query request, send a first reading request to the client operating system to request the detail information of the kernel module to be queried; and a receiving module 85, configured to receive the detail information of the kernel module to be queried returned by the client operating system according to the first reading request; accordingly, the sending module 84 is further configured to output the detail information of the kernel module to be queried to a user through the management component.

[0151] In an optional embodiment, the apparatus provided by the embodiments of the present disclosure further includes a determination module configured to parse the query parameter from the query request; in a case where the query parameter is a default parameter, sending a second read request to the client operating system to request the kernel module directory information, and taking all the kernel modules in the kernel module directory information as the kernel modules to be queried; or in a case where the query parameter includes the identification information of the kernel module, taking the kernel module corresponding to the identification information included in the query parameter as the kernel module to be queried.

[0152] In an optional embodiment, the sending module 84 is specifically configured to send the first read request to the client operating system to request the detail information of the kernel module to be queried according to the number of the detail information to be queried, wherein the detail information of the kernel module to be queried includes at least one of the initialization state, the referrer information, the reference count and the module size.

[0153] Further optionally, based on the above-mentioned implementation mode of mutual fusion, the sending module 84 is specifically configured to query a fourth kernel symbol from the kernel symbol table, the fourth kernel symbol is a kernel symbol for interpreting the query function in the client operating system; take the identification information of the detail information to be queried as the input parameter of the fourth kernel symbol, and execute the fourth kernel symbol to read the detail information of the kernel module to be queried.

[0154] In an optional embodiment, the apparatus provided by the embodiments of the present disclosure further includes a fusion virtualization module configured to implement fusion of the container runtime component and the running environment of the client operating system based on the shared memory technology and the kernel symbol export technology, so that the container runtime component and the client operating system can directly interact.

[0155] Further optionally, the fusion virtualization module is specifically configured to share the kernel address space corresponding to the client operating system to the container runtime component, the kernel address space stores functions and / or data in the client operating system; export the kernel symbol table in the client operating system to the user address space corresponding to the container runtime component, the kernel symbol in the kernel symbol table is an interpretation of the functions and / or data in the kernel address space, so as to implement fusion of the running environment of the container runtime component and the client operating system.

[0156] The embodiments of the present disclosure further provide a computer device or a computing unit. The computing unit comprises a memory configured to store a computer program and a processor coupled to the memory and configured to execute the computer program to implement the steps in the above method embodiments. The computer device comprises a memory configured to store a computer program and a processor coupled to the memory and configured to execute the computer program to implement the steps in the above method embodiments.

[0157] In the embodiments, the computer device runs the management component, the container runtime component and the secure container created and managed by the container runtime component, and the program codes of these components or containers are stored in the memory of the computer device. Specifically, as shown in FIG. 9, the internal implementation structure of the computer device provided by the embodiments of the present disclosure comprises a memory 91 and a processor 92.

[0158] The memory 91 is configured to store a computer program and can be configured to store other various data to support the operation on the computer device or the computing unit. Examples of these data include instructions of any application program or method for operating on the computing platform, contact data, phonebook data, messages, pictures, videos, etc.

[0159] The processor 92 is coupled to the memory 91 and is configured to execute the computer program in the memory 91 to receive an operation request sent by the management component on the host, the operation request being initiated for the kernel module; in the case that the operation request is a loading request, generate a loading task of the guest operating system according to the loading request; add the loading task to a work queue of the guest operating system for the guest operating system to execute the loading task to load the kernel module into the guest operating system.

[0160] In an optional embodiment, the processor 92 generates the loading task of the guest operating system according to the loading request, comprising: determining a first task type and loading parameters according to the loading request, the loading parameters at least comprising identification information of the kernel module to be loaded and a loading address of the intermediate state file corresponding to the kernel module to be loaded, the loading address pointing to a storage location of the intermediate state file in the shared memory between the container runtime component and the guest operating system; generating the loading task according to the first task type and the loading parameters.

[0161] In an optional embodiment, the processor 92 adds the load task to the work queue of the guest operating system, including: selecting, as the first work queue, a work queue running on a first virtual computing unit from at least one work queue of the guest operating system, the first virtual computing unit being a virtual computing unit capable of executing privileged instructions in the guest operating system; and adding the load task to the first work queue.

[0162] In an optional embodiment, the container runtime component is implemented in fusion with the running environment of the guest operating system by: storing a kernel symbol table in the guest operating system in a user space address space corresponding to the container runtime component, a kernel symbol in the kernel symbol table being an interpretation of a function and / or data stored in a kernel space address space of the guest operating system.

[0163] Further optionally, based on the above-mentioned implementation in fusion, the processor 92 generates the load task according to the first task type and the load parameter, including: querying a first kernel symbol from the kernel symbol table, the first kernel symbol being a kernel symbol that interprets a creation function in the guest operating system; and executing the first kernel symbol with the first task type and the load parameter as input parameters of the first kernel symbol to create the load task.

[0164] Further, based on the above-mentioned implementation in fusion, the processor 92 selects, as the first work queue, a work queue running on a first virtual computing unit from at least one work queue of the guest operating system, including: querying a second kernel symbol from the kernel symbol table, the second kernel symbol being a kernel symbol that interprets a selection function in the guest operating system; and executing the second kernel symbol to select the first work queue from the at least one work queue of the guest operating system and output a queue serial number of the first work queue.

[0165] Further, based on the above-mentioned implementation in fusion, the processor 92 adds the load task to the first work queue, including: querying a third kernel symbol from the kernel symbol table, the third kernel symbol being a kernel symbol that interprets a submission function in the guest operating system; and executing the third kernel symbol with the load task and the queue serial number of the first work queue as input parameters of the third kernel symbol to add the load task to the first work queue.

[0166] In an optional embodiment, the processor 92 is further configured to: in a case where the operation request is an uninstall request, generate an uninstall task of the guest operating system according to the uninstall request; and add the uninstall task to the work queue of the guest operating system for the guest operating system to execute the uninstall task to uninstall the kernel module from the guest operating system.

[0167] In an optional embodiment, the processor 92 generates the unloading task of the guest operating system according to the unloading request, including: determining the second task type and the unloading parameter according to the unloading request, the unloading parameter at least including the identification information of the kernel module to be unloaded and the unloading type; and generating the unloading task according to the second task type and the unloading parameter.

[0168] In an optional embodiment, the processor 92 adds the unloading task to the work queue of the guest operating system, including: selecting the work queue running on the second virtual computing unit from the plurality of work queues of the guest operating system as the second work queue, the second virtual computing unit being the virtual computing unit capable of executing the privileged instruction in the guest operating system; and adding the unloading task to the second work queue.

[0169] Further optionally, based on the above-mentioned mutually integrated implementation manners, the processor 92 generates the unloading task according to the second task type and the unloading parameter, including: querying the first kernel symbol from the kernel symbol table, the first kernel symbol being the kernel symbol for interpreting the creation function in the guest operating system; executing the first kernel symbol with the second task type and the unloading parameter as the input parameters of the first kernel symbol, to create the unloading task.

[0170] Further, based on the above-mentioned mutually integrated implementation manners, the processor 92 selects the work queue running on the second virtual computing unit from the at least one work queue of the guest operating system as the second work queue, including: querying the second kernel symbol from the kernel symbol table, the second kernel symbol being the kernel symbol for interpreting the selection function in the guest operating system; and executing the second kernel symbol to select the second work queue from the at least one work queue of the guest operating system and output the queue serial number of the second work queue.

[0171] Further, based on the above-mentioned mutually integrated implementation manners, the processor 92 adds the unloading task to the second work queue, including: querying the third kernel symbol from the kernel symbol table, the third kernel symbol being the kernel symbol for interpreting the submission function in the guest operating system; executing the third kernel symbol with the unloading task and the queue serial number of the second work queue as the input parameters of the third kernel symbol, to add the unloading task to the second work queue.

[0172] In an optional embodiment, the processor 92 is further configured to: in the case that the operation request is a query request, send a first read request to the guest operating system to request the detail information of the kernel module to be queried; receive the detail information of the kernel module to be queried returned by the guest operating system according to the first read request, and output the detail information of the kernel module to be queried through the management component.

[0173] In an optional embodiment, the processor 92 is further configured to: parse the query parameter from the query request; in a case where the query parameter is a default parameter, send a second read request to the client operating system to request kernel module directory information, and take all kernel modules in the kernel module directory information as the kernel modules to be queried; or in a case where the query parameter includes identification information of a kernel module, take the kernel module corresponding to the identification information included in the query parameter as the kernel module to be queried.

[0174] In an optional embodiment, the processor 92 sends the first read request to the client operating system, including: according to the number of details to be queried, sending the first read request to the client operating system to request reading of the details of the kernel module to be queried; wherein the details of the kernel module to be queried include at least one of the initialization state, the referrer information, the reference count, and the module size.

[0175] Further optionally, based on the above-mentioned implementation mode of mutual fusion, the processor 92 sends the first read request to the client operating system according to the number of details to be queried, including: querying a fourth kernel symbol from the kernel symbol table, the fourth kernel symbol being a kernel symbol for interpreting the query function in the client operating system; taking the identification information of the details to be queried as an input parameter of the fourth kernel symbol, and executing the fourth kernel symbol to read the details of the kernel module to be queried.

[0176] In an optional embodiment, the processor 92 is further configured to: based on the shared memory technology and the kernel symbol export technology, realize fusion of the container runtime component with the running environment of the client operating system, so that the secure container runtime component and the client operating system can directly interact.

[0177] Further optionally, the processor 92 realizes fusion of the container runtime component with the running environment of the client operating system based on the shared memory technology and the kernel symbol export technology, including: sharing the kernel address space corresponding to the client operating system to the container runtime component, the kernel address space storing functions and / or data in the client operating system; exporting a kernel symbol table in the client operating system to a user address space corresponding to the container runtime component, the kernel symbol in the kernel symbol table being an interpretation of the functions and / or data in the kernel address space, so as to realize fusion of the container runtime component with the running environment of the client operating system.

[0178] It is explained above that the processor 92 can have one or more of the above-mentioned functions of loading kernel modules, unloading kernel modules, and querying details of kernel modules, and this is not limited.

[0179] Further, as shown in FIG. 9, the computer device further includes a communication component 93, a display 94, a power supply component 95, an audio component 96, and other components. Only some components are shown in FIG. 9, and it is not meant to indicate that the computer device only includes the components shown in FIG. 9. In addition, the components in the dashed box in FIG. 9 are optional components rather than essential components, and the specific components can be determined according to the product form of the computer device. The computer device in the embodiment can be implemented as a terminal device such as a desktop computer, a notebook computer, a smart phone, or an IOT device, or a server device such as a general server, a cloud server, or a server array. If the computer device in the embodiment is implemented as a terminal device such as a desktop computer, a notebook computer, or a smart phone, it can include the components in the dashed box in FIG. 9; if the computer device in the embodiment is implemented as a server device such as a general server, a cloud server, or a server array, it can not include the components in the dashed box in FIG. 9.

[0180] Accordingly, the embodiment of the present disclosure further provides a computer readable storage medium storing a computer program, which causes the processor to be able to implement each step in the above method embodiment when the computer program is executed by the processor.

[0181] Accordingly, the embodiment of the present disclosure further provides a computer program product, which includes a computer program / instruction, which causes the processor to be able to implement each step in the above method embodiment when the computer program / instruction is executed by the processor.

[0182] The above memory can be implemented by any type of volatile or nonvolatile memory device or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic disk, or an optical disk.

[0183] The communication component is configured to facilitate wired or wireless communication between the device on which the communication component is installed and other devices. The device on which the communication component is installed can access a wireless network based on a communication standard, such as WiFi, a 2G, 3G, 4G / LTE, 5G, or the like cellular communication network, or a combination thereof. In an example embodiment, the communication component receives a broadcast signal or broadcast related information from an external broadcast management system via a broadcast channel. In an example embodiment, the communication component further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wide Band (UWB) technology, BlueTooth (BT) technology, and other technologies.

[0184] The display includes a screen, which can include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense a touch, a slide, and a gesture on the touch panel. The touch sensor can not only sense a boundary of a touch or a slide action, but also detect a duration and a pressure associated with a touch or a slide operation.

[0185] The power supply component provides power to various components of the device on which the power supply component is installed. The power supply component can include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power for the device on which the power supply component is installed.

[0186] The audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) that is configured to receive an external audio signal when the device on which the audio component is installed is in a particular mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal can be further stored in memory or transmitted via the communication component. In some embodiments, the audio component also includes a speaker disposed to output audio signals.

[0187] Those skilled in the art will appreciate that embodiments of the disclosure can be supplied as a method, a system, or a computer program product. Accordingly, the disclosure can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the disclosure can take the form of a computer program product on one or more computer readable storage media (including, but not limited to, disk memory, Compact Disc Read-Only Memory (CD-ROM), optical memory, and the like) embodying computer usable program code.

[0188] The disclosure is described in reference to the flowchart and / or block diagrams of the method, apparatus (system) and computer program product according to embodiments of the disclosure. It should be understood that each flow and / or block in the flowchart and / or block diagram, as well as a combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions, which are executed via the processor of the computer or other programmable data processing apparatus, generate means for implementing the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram.

[0189] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture including instruction means, which implement the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram.

[0190] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus, so that a series of operational steps are performed on the computer or other programmable data processing apparatus to generate a computer implemented process, so that the instructions executed on the computer or other programmable data processing apparatus provide steps for implementing the functions specified in one or more flows in the flowchart and / or one or more blocks in the block diagram.

[0191] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0192] The memory can include non-persistent memory in the computer readable medium, Random Access Memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash memory. The memory is an example of computer readable media.

[0193] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital video disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.

[0194] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover non-exclusive inclusion, so that processes, methods, articles or devices that include a series of elements not only include those elements, but also include other elements not explicitly listed, or inherent to such processes, methods, articles or devices. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of other identical elements in the process, method, article or device that includes the element.

[0195] The above is only an embodiment of the present disclosure and is not intended to limit the present disclosure. The present disclosure can have various modifications and changes for those skilled in the art. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present disclosure shall be included in the scope of claims of the present disclosure. Industrial applicability

[0196] In the embodiments of the present disclosure, the container runtime component is integrated with the running environment of the operating system in the secure container and can directly interact, so that the loading operation of the kernel module of the secure container can be performed on the host side, and the loading of the kernel module no longer depends on the root system file, which can reduce the risk of malicious tampering of the kernel module by the user and enhance the security of the kernel module. Further, in the embodiments of the present disclosure, the kernel module is separated from the root file system, which is conducive to the version convergence of the root file system in different application scenarios. In addition, the loading of the kernel module no longer depends on the root file system, and the kernel module or the kernel can be added or hot repaired at any time during the entire life cycle of the secure container.

Claims

1. A computer device comprising: A host machine, wherein a management component, a container runtime component, and a secure container created and managed by the container runtime component are running on the host machine, and the secure container comprises: a guest operating system; the container runtime component is fused with a running environment of the guest operating system and can directly interact; The management component is configured to receive an operation request initiated for a kernel module, and send the operation request to the container runtime component; The container runtime component is configured to, in a case where the operation request is a loading request, generate a loading task of the guest operating system according to the loading request, and add the loading task to a work queue of the guest operating system. The guest operating system is configured to execute the loading task in the work queue, and initiate a system call of loading a kernel module to load the kernel module into the guest operating system.

2. The apparatus of claim 1, wherein, The container runtime component generates the loading task of the guest operating system according to the loading request, comprising: According to the loading request, determining a first task type and loading parameters, the loading parameters at least including identification information of a kernel module to be loaded and a loading address of an intermediate state file corresponding to the kernel module to be loaded, the loading address pointing to a storage location of the intermediate state file in a shared memory between the container runtime component and the guest operating system; According to the first task type and the loading parameters, generating the loading task.

3. The apparatus of claim 2, wherein, The container runtime component adds the loading task to the work queue of the guest operating system, comprising: From at least one work queue of the guest operating system, selecting a work queue running on a first virtual computing unit as a first work queue, the first virtual computing unit being a virtual computing unit capable of executing privileged instructions in the guest operating system; Adding the loading task to the first work queue.

4. The apparatus of claim 3, wherein, The container runtime component is fused with the running environment of the guest operating system, and is implemented by storing a kernel symbol table in the guest operating system in a user state address space corresponding to the container runtime component, wherein a kernel symbol in the kernel symbol table is an interpretation of a function and / or data stored in a kernel state address space of the guest operating system.

5. The apparatus of claim 4, wherein, The container runtime component generates the loading task according to the first task type and the loading parameters, comprising: Querying a first kernel symbol from the kernel symbol table, the first kernel symbol being a kernel symbol that interprets a creation function in the guest operating system; Taking the first task type and the loading parameters as input parameters of the first kernel symbol, executing the first kernel symbol to create the loading task.

6. The apparatus of claim 4, wherein, The container runtime component selects a work queue running on a first virtual computing unit from at least one work queue of the guest operating system as a first work queue, comprising: querying a second kernel symbol from the kernel symbol table, the second kernel symbol being a kernel symbol that interprets a select function in the guest operating system; and executing the second kernel symbol to select the first work queue from at least one work queue of the guest operating system and output a queue number of the first work queue; the container runtime component is further configured to add the load task to the first work queue, including: querying a third kernel symbol from the kernel symbol table, the third kernel symbol being a kernel symbol that interprets a submit function in the guest operating system; and executing the third kernel symbol with the load task and the queue number of the first work queue as input parameters of the third kernel symbol, to add the load task to the first work queue.

7. The device of any one of claims 1-6, wherein the container runtime component is further configured to, in a case that the operation request is an unload request, generate an unload task of the guest operating system according to the unload request, and add the unload task to a work queue of the guest operating system; and the guest operating system is further configured to execute the unload task in the work queue, and initiate a system call of unloading a kernel module to unload the kernel module from the guest operating system.

8. The apparatus of claim 7, wherein, the container runtime component generates the unload task of the guest operating system according to the unload request, including: determining a second task type and an unload parameter according to the unload request, the unload parameter including at least identification information of a kernel module to be unloaded and an unload type; and generating the unload task according to the second task type and the unload parameter.

9. The apparatus of claim 7, wherein, the container runtime component adds the unload task to the work queue of the guest operating system, including: selecting a work queue running on a second virtual computing unit as a second work queue from at least one work queue of the guest operating system, the second virtual computing unit being a virtual computing unit capable of executing privileged instructions in the guest operating system; and adding the unload task to the second work queue.

10. The device of any one of claims 1-6, wherein the container runtime component is further configured to, in a case that the operation request is a query request, send a first read request to the guest operating system to request detail information of a kernel module to be queried, and output the detail information of the kernel module to be queried through the management component; and the guest operating system is further configured to return the detail information of the kernel module to be queried to the container runtime component according to the first read request.

11. The apparatus of any one of claims 1-6, wherein, the container runtime component is further configured to: based on a shared memory technology and a kernel symbol export technology, implement fusion of the container runtime component with a running environment of the guest operating system, so that the container runtime component and the guest operating system can directly interact.

12. The apparatus of claim 11, wherein, the container runtime component is specifically configured to: sharing, to the container runtime component, a kernel address space of the guest operating system, in which functions and / or data in the guest operating system are stored; exporting, to a user address space of the container runtime component, a kernel symbol table in the guest operating system, so as to integrate the container runtime component with a running environment of the guest operating system, wherein kernel symbols in the kernel symbol table are explanations of the functions and / or data in the kernel address space.

13. The apparatus of any one of claims 1-6, wherein, The container runtime component comprises a fusion virtualization component, a kernel module operation component, and a management and control interface. The fusion virtualization component is configured to integrate the container runtime component with the running environment of the guest operating system based on a shared memory technology and a kernel symbol exporting technology. The management and control interface is configured to receive an operation request sent by the management and control component and send the operation request to the kernel module operation component. The kernel module operation component is configured to identify a type of the operation request, and in a case where the operation request is a loading request, generate a loading task of the guest operating system according to the loading request, and add the loading task to a work queue of the guest operating system.

14. A kernel module processing method applied to a container runtime component running on a host, the container runtime component creating and managing a secure container, the secure container comprising a guest operating system, the container runtime component being integrated with a running environment of the guest operating system and being capable of direct interaction, the method comprising: receiving an operation request sent by a management and control component on the host, the operation request being initiated for a kernel module; in a case where the operation request is a loading request, generating a loading task of the guest operating system according to the loading request; adding the loading task to a work queue of the guest operating system, so that the guest operating system executes the loading task to load the kernel module into the guest operating system.

15. The method of claim 14, wherein, Generating the loading task of the guest operating system according to the loading request comprises: determining a first task type and loading parameters according to the loading request, the loading parameters at least comprising identification information of a kernel module to be loaded and a loading address of an intermediate state file corresponding to the kernel module to be loaded; generating the loading task according to the first task type and the loading parameters, the loading address pointing to a storage location of the intermediate state file in shared memory between the container runtime component and the guest operating system.

16. The method of claim 15, wherein, Adding the loading task to the work queue of the guest operating system comprises: selecting, from at least one work queue of the guest operating system, a work queue running on a first virtual computing unit as a first work queue; adding the loading task to the first work queue, the first virtual computing unit being a virtual computing unit capable of executing privileged instructions in the guest operating system.

17. The method of any one of claims 14-16, wherein, Further comprising: In a case where the operation request is an uninstallation request, generating an uninstallation task of the guest operating system according to the uninstallation request; adding the uninstallation task to a work queue of the guest operating system, so that the guest operating system executes the uninstallation task to uninstall the kernel module from the guest operating system.

18. The method of any one of claims 14-16, wherein, Further comprising: In a case where the operation request is a query request, sending a first read request to the guest operating system to request detail information of a kernel module to be queried; receiving the detail information of the kernel module to be queried returned by the guest operating system according to the first read request, and outputting the detail information of the kernel module to be queried through the management component.

19. The method of any one of claims 14-16, wherein, Further comprising: Based on the shared memory technology and the kernel symbol export technology, the container runtime component is integrated with the running environment of the guest operating system, so that the secure container runtime component and the guest operating system can directly interact.

20. The method of claim 19, wherein, Based on the shared memory technology and the kernel symbol export technology, the container runtime component is integrated with the running environment of the guest operating system, including: sharing a kernel mode address space corresponding to the guest operating system to the container runtime component, and the kernel mode address space stores functions and data in the guest operating system; exporting a kernel symbol table in the guest operating system to a user mode address space corresponding to the container runtime component, to integrate the container runtime component with the running environment of the guest operating system, and the kernel symbol in the kernel symbol table is an interpretation of the functions and data in the kernel mode address space.

21. A kernel module processing method applied to a container runtime component running on a host, the container runtime component creating and managing a secure container, the secure container including a guest operating system, the container runtime component being integrated with a running environment of the guest operating system and being capable of directly interacting, the method comprising: receiving an operation request sent by a management component on the host, the operation request being initiated for a kernel module; in a case where the operation request is an uninstallation request, generating an uninstallation task of the guest operating system according to the uninstallation request; adding the uninstallation task to a work queue of the guest operating system, so that the guest operating system executes the uninstallation task to uninstall the kernel module from the guest operating system.

22. A kernel module processing method applied to a container runtime component running on a host, the container runtime component creating and managing a secure container, the secure container including a guest operating system, the container runtime component being integrated with a running environment of the guest operating system and being capable of directly interacting, the method comprising: receiving an operation request sent by a management component on the host, the operation request being initiated for a kernel module; in a case where the operation request is a query request, sending a first read request to the guest operating system to request detail information of a kernel module to be queried; The client operating system receives the detail information of the kernel module to be queried returned according to the first read request, and outputs the detail information of the kernel module to be queried through the management component.

23. A computer device or computing unit comprising: a memory and a processor; The memory is configured to store a computer program. The processor is coupled to the memory and is configured to execute the computer program to implement the steps in the method of any one of claims 14-22.

24. A computer readable storage medium storing a computer program, which, when executed by a processor, causes the processor to implement the steps in the method of any one of claims 14-22.

25. A computer program product, comprising computer programs / instructions, which, when executed by a processor, causes the processor to implement the steps in the method of any one of claims 14-22.

Images