Container isolation method, device and equipment for peripheral resources and readable storage medium

Abstract

The invention discloses a container isolation method and device for peripheral resources, equipment and a readable storage medium, and the method comprises the steps that an equipment information subsystem receives an equipment query request of a target process corresponding to a target container, and obtains mounting view information of the target process; obtaining a target node hit by a query path in the equipment query request from an equipment information structure node tree; under the condition that the mounting view information is the initial device namespace or the target node is the initial device namespace, displaying the target node; and under the condition that the mounting view information is not the initial device namespace and the target node is not the initial device namespace, judging whether a second device namespace bound with the target node is consistent with the first device namespace, if so, displaying the target node, and if not, hiding the target node. On the basis of the design of the device namespace, the device can be effectively isolated among different containers in combination with the condition analysis made by the query process.

Description

Technical Field

[0001] This application relates to the field of computer application technology, and in particular to a container isolation method, apparatus, device, and readable storage medium for peripheral resources. Background Technology

[0002] With the popularity and development of container technology, container desktop cloud, which provides remote desktop services through lightweight containers, has become a hot research and engineering direction. The demand for accessing remote virtual USB devices on servers via containers is also growing.

[0003] However, in a container environment, all container tenants share the same server kernel, and the set of devices on the container host is also the set of devices that each container queries through the kernel. Even if the / dev device node could be deployed to be detected by the container host environment and mapped to a specific container, the need for peripheral isolation for each container desktop is far from being met. Specifically, device information in the device information subsystem can be queried by all containers.

[0004] In summary, how to effectively solve the problem of container isolation of peripheral resources is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a container isolation method, apparatus, device, and readable storage medium for peripheral resources, which can achieve container isolation of peripheral resources, that is, ensure that device information is not queried by all containers.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution:

[0007] A container isolation method for peripheral resources, comprising:

[0008] The device information subsystem receives a device query request for the target process corresponding to the target container and obtains the mount view information of the target process; the mount view information has a first device namespace associated with the target process;

[0009] Obtain the target node hit by the query path in the device query request from the device information structure node tree; the device information structure object corresponding to the node in the device information structure node tree has a device namespace member variable to point to the second device namespace bound to the node;

[0010] If the mount view information is the initial device namespace or the target node is bound to the initial device namespace, the target node is displayed.

[0011] If the mounted view information is not the initial device namespace and the target node is not bound to the initial device namespace, determine whether the second device namespace bound to the target node is consistent with the first device namespace. If yes, the target node is displayed; otherwise, the target node is hidden.

[0012] Preferably, it further includes:

[0013] The equipment information subsystem acquires changed equipment nodes;

[0014] Determine the target device namespace to be bound from the device information structure object of the changed device node;

[0015] With the target device namespace being the initial device namespace, all listening sockets are traversed and device change notifications are sent to each of them.

[0016] If the target device namespace is not the initial device namespace, query the network namespace associated with the corresponding device namespace, send the device change notification to the listening socket in the network namespace, and send the device change notification to the listening socket in the default network namespace.

[0017] Preferably, it further includes:

[0018] The device information subsystem dynamically binds a dedicated virtual USB controller to the container based on the device namespace, so that the corresponding device node can listen to and be displayed in its own container or container host environment.

[0019] Preferably, the device information subsystem dynamically binds a dedicated virtual USB controller to the container based on the device namespace, including:

[0020] Create a control device using a virtual USB controller driver, and add a device control interface to the control device;

[0021] Use the container daemon service to generate a unique identifier for the container, start the container, and pass the identifier as an environment variable.

[0022] By utilizing the peripheral listening management service in the container environment, the tag is obtained and the virtual USB controller driver is notified through the device control interface to create a virtual USB device controller with a specified naming format;

[0023] The interface adds a dedicated virtual USB device controller to a specified container by adding device information nodes according to the specified device namespace; wherein, the specified naming format corresponds to the unique identifier of the container.

[0024] Preferably, it further includes:

[0025] In the device node subsystem, the pointer to the device information structure object passed in the / dev node creation / deletion request is saved to a doubly linked list;

[0026] By querying the detailed information of the passed-in device information structure object, the DEV device path associated with the passed-in device information structure object can be obtained;

[0027] If the device namespace of the incoming device information structure object is the initial device namespace, then the / dev node creation / deletion request will be responded to on all dev instances;

[0028] If the device namespace of the incoming device information structure object is not the initial device namespace, respond to the / dev node creation / deletion request on the dev instance bound to the same device namespace.

[0029] Preferably, it further includes:

[0030] After creating a new / dev instance in the device node subsystem, it traverses all device information structure objects stored in the doubly linked list to attempt to add a device response process; the / dev instance only responds to device information structure objects with the same device namespace as its device or device information structure objects associated with the initial device namespace for subsequent operations;

[0031] Query the detailed information of the device information structure object to obtain the DEV device path associated with the device information structure object and execute the / dev node creation request.

[0032] Preferably, it further includes:

[0033] When a container destroys and unmounts the / dev instance it uses, all / dev device nodes in that instance are released.

[0034] Preferably, it further includes:

[0035] By utilizing the peripheral device monitoring management service, a unique container identifier corresponding to the container device namespace is registered with the container host environment device security management service when the container starts.

[0036] The device information subsystem notifies the monitoring service of changes in devices by responding to the addition or deletion of devices associated with the DEV device path.

[0037] By reading the type and major / minor device number of the / dev device node, the container host environment device security management service registers and reports the type and major / minor device number of the / dev device bound to its own container.

[0038] Using the device security management service, a specified container can be exclusively used on a specified device based on the / dev device type and major / minor device number.

[0039] A container isolation device for peripheral resources, comprising:

[0040] The query request receiving module is used by the device information subsystem to receive device query requests from the target process corresponding to the target container, and to obtain the mount view information of the target process; the mount view information has a first device namespace associated with the target process;

[0041] The node query module is used to obtain the target node hit by the query path in the device query request from the device information structure node tree; the device information structure object corresponding to the node in the device information structure node tree has a device namespace member variable to point to the second device namespace bound to the node;

[0042] The node display module is used to display the target node when the mount view information is the initial device namespace or the target node is bound to the initial device namespace; when the mount view information is not the initial device namespace and the target node is not bound to the initial device namespace, it determines whether the second device namespace bound to the target node is consistent with the first device namespace. If so, the target node is displayed; otherwise, the target node is hidden.

[0043] An electronic device, comprising:

[0044] Memory, used to store computer programs;

[0045] A processor, used to implement the container isolation method for the aforementioned peripheral resources when executing the computer program.

[0046] A readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the container isolation method for peripheral resources described above.

[0047] Applying the method provided in the embodiments of this application, the device information subsystem receives a device query request from the target process corresponding to the target container and obtains the mount view information of the target process; the mount view information has a first device namespace associated with the target process; from the device information structure node tree, the target node hit by the query path in the device query request is obtained; the device information structure object corresponding to the node in the device information structure node tree has a device namespace member variable pointing to the second device namespace bound to the node; if the mount view information is the initial device namespace or the target node is bound to the initial device namespace, the target node is displayed; if the mount view information is not the initial device namespace and the target node is not bound to the initial device namespace, it is determined whether the second device namespace bound to the target node is consistent with the first device namespace; if yes, the target node is displayed; if no, the target node is hidden.

[0048] In this application, peripherals can be isolated and managed by defining device namespaces. Specifically, after the device information subsystem receives a device query request from the target process corresponding to the target container, it first clarifies the mount view information of the target process. This mount view information records the first device namespace associated with the target process. The target node in the query path of the device query request can be obtained from the device information structure node tree. The device information structure object corresponding to the node in this device information structure node tree also has a device namespace member variable pointing to the second device namespace bound to the node. If the mount view information is the initial device namespace, it means that the target process being queried is a privileged process of the container host environment. In this case, any path node in the device information structure node tree is allowed to be queried, and the target node can be directly displayed. If the target node is bound to the initial device namespace, it means that the device information node being queried is a public device of the host, and the target node can also be displayed. If the mount view information is not the initial device namespace, it is necessary to further determine whether the second device namespace bound to the target node is consistent with the first device namespace. If they are consistent, the target node is displayed; otherwise, the target node is hidden.

[0049] As can be seen, the device namespace design and the situation analysis based on the query process in this application can achieve effective isolation of devices between different containers.

[0050] Accordingly, embodiments of this application also provide a container isolation device, equipment, and readable storage medium for peripheral resources corresponding to the above-described container isolation method for peripheral resources, which have the above-described technical effects, and will not be repeated here. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments or related technologies of this application, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0052] Figure 1 This is a flowchart illustrating the implementation of a container isolation method for peripheral resources in an embodiment of this application.

[0053] Figure 2 This is a schematic diagram showing the enumeration of directory files under a device information subsystem in an embodiment of this application;

[0054] Figure 3 This is a schematic diagram of a device change notification under a device information subsystem in an embodiment of this application;

[0055] Figure 4 This is a schematic diagram of a container dynamically binding a dedicated virtual USB controller under a device information subsystem in an embodiment of this application;

[0056] Figure 5 This is a schematic diagram of multi-container isolation under a device node subsystem in an embodiment of this application;

[0057] Figure 6 This is a schematic diagram of the device node subsystem's device response process in an embodiment of this application;

[0058] Figure 7 This is a schematic diagram of the device removal response process of a device node subsystem in an embodiment of this application;

[0059] Figure 8 This application provides a device node population response process for creating a new instance under a device node subsystem in one of its embodiments.

[0060] Figure 9 This is a schematic diagram illustrating the implementation of a designated container exclusive device in an embodiment of this application;

[0061] Figure 10 This is a schematic diagram of the structure of a container isolation device for peripheral resources in an embodiment of this application;

[0062] Figure 11 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application;

[0063] Figure 12 This is a schematic diagram of the specific structure of an electronic device according to an embodiment of this application;

[0064] Figure 13This is a schematic diagram of the structure of another container isolation device for peripheral resources in an embodiment of this application. Detailed Implementation

[0065] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some embodiments of the present application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0066] To help those skilled in the art better understand the container isolation method for peripheral resources provided in the embodiments of this application, the technical terms and terminology of the design are explained below.

[0067] LXC: Linux containers, is an operating system-level virtualization technology that uses Linux kernel namespaces and cgroups to isolate processes and resources, allowing multiple independent, lightweight container environments to run on a single host.

[0068] NS: Linux Namespace, a core isolation mechanism provided by the Linux kernel, divides global system resources (such as processes, network, and file systems) into independent virtual environments, allowing processes in different namespaces to have independent resource views and be invisible to each other. In this article, the term "namespace" is used generally.

[0069] CGROUPS: Linux Control Groups, is a resource management mechanism provided by the kernel. It is used to limit, isolate, and monitor the system resources (such as CPU, memory, disk I / O, etc.) of process groups, and can also control the device access permissions of process groups. In this article, cgroups refers to the control group namespace in general.

[0070] SYSFS: Linux Kernel Object File System, is a virtual file system in the Linux kernel used to expose the attributes and hierarchy of kernel objects (such as devices, drivers, buses, modules, etc.) and allow user-space programs (such as udev, lsusb, etc.) to interact with the kernel. It is typically mounted under the / sys directory and is an important tool in Linux system administration and device driver development.

[0071] KERNFS: Kernfs is the core infrastructure in the Linux kernel used to build virtual file systems. It was originally separated from sysfs and was designed to provide a unified file system abstraction layer for kernel subsystems such as sysfs and cgroupfs.

[0072] KOBJECT: Kobject is a device management mechanism introduced in Linux 2.6, represented by the kobject structure in the kernel. This data structure provides a unified interface for all devices at the underlying level. Kobject provides basic object management and is the core structure of the Linux device model, closely associated with the sysfs file system. Each kobject registered in the kernel corresponds to a directory in the sysfs file system. Kobject is the basic structure that makes up the device model, similar to a base class in C++. It is embedded in more complex container objects to implement components describing the device model, such as buses, devices, and drivers, which are typical device container objects. These device container objects are connected through kobjects, forming a tree structure in the sysfs file system.

[0073] DEVTMPFS: Device Temp Filesystem, is a temporary virtual file system provided by the Linux kernel, primarily used for dynamically managing device nodes under the / dev directory. It is the default implementation for device nodes in Linux systems, typically mounted under the / dev directory, replacing earlier mechanisms that relied on udev or static device nodes. TMPFS is a memory-based temporary file system in Linux (e.g., mounted under / tmp), while DEVTMPFS is a variant of TMPFS specifically designed for managing device nodes under the / dev directory.

[0074] eBPF (Extended Berkeley Packet Filter): eBPF allows developers to securely run programs at pre-built execution points within the Linux kernel without writing kernel modules or modifying kernel source code. eBPF provides secure, dynamic, and non-intrusive kernel programmability, primarily used to add capabilities such as network monitoring and filtering, system tracing and performance analysis, security policy enforcement, and device access control to the kernel.

[0075] Device Information Subsystem (SysDevice): This patented solution is named SysDevice, and is comparable to Linux's sysfs / kobject / kernfs.

[0076] Device node subsystem ( / dev or DEV system): This is the device node subsystem used to run the container host operating system. This patented solution is named DEV, and it is comparable to Linux's devtmpfs.

[0077] Virtual USB Device Subsystem (VUSB): A subsystem used to run virtual USB peripherals for the container environment within the container host operating system. It is comparable to Linux's VHCI driver and usbip project.

[0078] TaskDescriptor: The namespace of the device used in this patent scheme is for conceptual description of process information query.

[0079] Container A: is a generic container instance identifier.

[0080] Device Daemon A: This corresponds to the peripheral monitoring and management service in Container A. Essentially, it is a device daemon process running in a specified container. Its core responsibility is to monitor and manage changes in device information nodes bound to the specified container. It serves as an intermediary bridge between device information monitoring in the container and upper-layer host device management.

[0081] Container Device Control (DDC) refers to the security management service for container host environment devices. It has the ability to control the entire process of containers accessing host hardware devices. The core is to enable containers to securely access specified hardware and only access specified hardware through the container engine, host kernel and permission policies. It is the core management mechanism for the interaction between containers and physical devices.

[0082] Please refer to Figure 1 and Figure 2 This method can be applied to container host machines, such as servers providing remote desktop cloud services. These servers can be Linux systems, FreeBSD systems, or other systems that can provide remote desktop cloud services to multiple tenants based on container technology. The method includes the following steps:

[0083] S101. The device information subsystem receives the device query request for the target process corresponding to the target container and obtains the mount view information of the target process.

[0084] The mount view information has the first device namespace associated with the target process.

[0085] First, the kernel needs to implement the dev_namespace (dev_ns) device namespace structure definition.

[0086] Optionally, when implementing device viewing or notification, if network namespace association is required to achieve related isolation effects, the `dev_ns` structure should also include a `net_ns` member (network namespace) variable to record the bound network namespace. That is, considering that the netlink socket for kernel notification technology includes network namespace isolation, the kernel needs to include a `net_ns` member (network namespace) variable to record the bound network namespace. Furthermore, the `dev_namespace` device namespace needs to be registered and initialized after the network namespace. The default device namespace is constructed as `(init_dev_ns)`, and its network namespace is bound to the default network namespace (`init_net`). If further modifications to the netlink socket are made to add support for device namespace isolation, the device namespace parameters can be more self-contained without needing to query its bound network namespace.

[0087] The process information data structure (TaskDescriptor) needs to include a dev_ns member variable. This allows the kernel to obtain the device namespace information of the application and its container from the process TaskDescriptor->dev_ns during the interaction between the application and the kernel.

[0088] The device information subsystem must include a dev_ns member variable in the device information structure object (SysDevice), which points to the device namespace bound to the SysDevice object. This member variable is set to point to init_dev_ns when SysDevice is allocated and initialized.

[0089] The device information subsystem uses a device tree (device information structure node tree) to manage SysDevice nodes (corresponding device information structure objects) and provides two interfaces for adding SysDevice nodes: one adds a SysDevice node without specifying dev_ns, in which case the SysDevice node inherits the parent device's dev_ns when inserted into the device tree; the other adds a SysDevice node with specified dev_ns, in which case the SysDevice node is inserted into the device tree and the specified dev_ns is set.

[0090] The device information subsystem supports multiple instance mountings and shares the same SysDevice node tree. When responding to a virtual file system mount operation, the device information subsystem obtains the dev_ns of the mount request process and stores it in the metadata information of that virtual file system view instance.

[0091] The target container can be any container in the server that provides remote desktop cloud services, and the target process can be any process within the scope of the target container.

[0092] S102. Obtain the target node that the query path in the device query request hits from the device information structure node tree.

[0093] In the device information structure node tree (SysDevice node tree), the corresponding device information structure object (SysDevice) of each node has a device namespace member variable that points to the second device namespace to which the node is bound.

[0094] It is important to note that both the first device namespace and the second device namespace refer to device namespaces. The difference between "first" and "second" is only to distinguish their different affiliations. In practical applications, the first device namespace and the second device namespace may or may not have the same specific parameters. Different parameters correspond to different devices (including USB peripherals).

[0095] S103. If the mount view information is the initial device namespace or the target node is bound to the initial device namespace, display the target node.

[0096] When the mounted view information is the initial device namespace init_dev_ns, it indicates that the current query process is a privileged process in the container host environment. At this time, any node found in the SysDevice node tree can be effectively displayed. That is, the target node can be displayed directly.

[0097] If the SysDevice node (i.e., the target node) matched by the query path is init_dev_ns (indicating that the device is a public device on the host), it can also be displayed directly. That is, even if the mounted view information is not in the initial device namespace, if the target node is init_dev_ns, consistency checks can be performed directly without needing to display it.

[0098] S104. If the mounted view information is not the initial device namespace and the target node is not bound to the initial device namespace, determine whether the second device namespace bound to the target node is consistent with the first device namespace. If yes, display the target node; otherwise, hide the target node.

[0099] When the mount view information is not the initial device namespace init_dev_ns, it means that the target process of the current query is a normal process inside the container. At this time, the SysDevice nodes that are matched with the dev_ns associated with the mount view information in the query path can be displayed, while the SysDevice nodes matched by other query paths will be filtered and hidden and not presented.

[0100] Applying the method provided in the embodiments of this application, the device information subsystem receives a device query request from the target process corresponding to the target container and obtains the mount view information of the target process; the mount view information has a first device namespace associated with the target process; from the device information structure node tree, the target node hit by the query path in the device query request is obtained; the device information structure object corresponding to the node in the device information structure node tree has a device namespace member variable pointing to the second device namespace bound to the node; if the mount view information is the initial device namespace or the target node is bound to the initial device namespace, the target node is displayed; if the mount view information is not the initial device namespace and the target node is not bound to the initial device namespace, it is determined whether the second device namespace bound to the target node is consistent with the first device namespace; if yes, the target node is displayed; if no, the target node is hidden.

[0101] In this application, peripherals can be isolated and managed by defining device namespaces. Specifically, after the device information subsystem receives a device query request from the target process corresponding to the target container, it first clarifies the mount view information of the target process. This mount view information records the first device namespace associated with the target process. The target node in the query path of the device query request can be obtained from the device information structure node tree. The device information structure object corresponding to the node in this device information structure node tree also has a device namespace member variable pointing to the second device namespace bound to the node. If the mount view information is the initial device namespace, it means that the target process being queried is a privileged process of the container host environment. In this case, any path node in the device information structure node tree is allowed to be queried, and the target node can be displayed directly. If the target node is bound to the initial device namespace, it means that the device information node being queried is a host public device, and the target node can also be displayed. If the mounted view information is not the initial device namespace and the target node is not the initial device namespace, it is necessary to further determine whether the second device namespace bound to the target node is consistent with the first device namespace. If so, the target node is displayed; otherwise, the target node is hidden.

[0102] As can be seen, the device namespace design and the situation analysis based on the query process in this application can achieve effective isolation of devices between different containers.

[0103] It should be noted that, based on the above embodiments, the embodiments of this application also provide corresponding improvement schemes. In the preferred / improved embodiments, the same or corresponding steps as in the above embodiments can be referred to each other, and the corresponding beneficial effects can also be referred to each other; however, these will not be elaborated upon in the preferred / improved embodiments herein.

[0104] In one specific embodiment of this application, it further includes:

[0105] The equipment information subsystem acquires information about changed equipment nodes;

[0106] Determine the target device namespace to be bound from the device information structure object of the changed device node;

[0107] With the target device namespace being the initial device namespace, traverse all listening sockets and send device change notifications to each;

[0108] If the target device namespace is not the initial device namespace, query the network namespace associated with and bound to the corresponding device namespace, send device change notifications to the listening sockets in that network namespace, and send device change notifications to the listening sockets in the default network namespace.

[0109] like Figure 3 As shown, the Device Notification mechanism in the Device Information Subsystem should also synchronize with the previous step of the virtual file system query directory hiding and showing effect to achieve a matching notification isolation effect.

[0110] The device change notification response process in the device information subsystem is as follows: Retrieve `dev_ns` from the changed device node `SysDevice`. If the namespace of the notification device node is the initial device namespace `init_dev_ns`, it indicates that the changed device is a shared basic device between the container and the host. In this case, all netlink listening sockets should be traversed, and a device change notification should be sent. If the namespace of the notification device node is not the initial device namespace `init_dev_ns`, it indicates that the changed device is a container-bound private device. In this case, it is necessary to query the network namespace associated with the corresponding device namespace, send notifications to the netlink listening sockets in that network namespace, and send notifications to the netlink listening sockets in the default network namespace `init_net` (indicating that the device change listening is privileged listening on the host). No notifications are sent to the netlink listening sockets in other network namespaces.

[0111] In one specific embodiment of this application, it further includes:

[0112] The device information subsystem dynamically binds dedicated virtual USB controllers to containers based on device namespaces, enabling the corresponding device nodes to listen to and be displayed in their respective container or container host environments.

[0113] The device information subsystem dynamically binds a dedicated virtual USB controller to the container based on the device namespace, including:

[0114] Create a control device using a virtual USB controller driver and add a device control interface to the control device;

[0115] Use the container daemon service to generate a unique identifier for the container, start the container and pass the identifier as an environment variable;

[0116] By utilizing the peripheral listening management service in the container environment, a tag is obtained and the virtual USB controller driver is notified through the device control interface to create a virtual USB device controller with a specified naming format.

[0117] The interface adds a dedicated virtual USB device controller to a specified container by adding a device information node according to the specified device namespace; where the specified naming format corresponds to the container's unique identifier.

[0118] Please refer to Figure 4 The virtual USB device subsystem allows for the dynamic creation of dedicated virtual USB controllers for each container, using a device namespace binding. Specifically, when the virtual USB controller driver starts, it creates the control device ` / dev / vusb_dyn_ctl` and adds custom device control interfaces `VUSB_DYN_IOCTL_ADD` and `VUSB_DYN_IOCTL_DEL` to support the dynamic creation and deletion of the corresponding virtual USB controller. The container daemon generates a unique container identifier `CONTAINER_GUID`, starts container A, and passes this identifier as an environment variable. During initialization, the peripheral listening management service in the container environment obtains the `CONTAINER_GUID` parameter and notifies the virtual USB controller driver through the `VUSB_DYN_IOCTL_ADD` interface. The virtual USB controller driver then creates a virtual USB device controller with the naming format `vusb_hcd.{CONTAINER_GUID}` and uses the aforementioned device information subsystem to specify the interface for adding SysDevice nodes to `dev_ns` to add a dedicated virtual USB device controller to the specified container. Since the virtual USB controller is already a device namespace bound to a specified container, its child virtual USB devices and other types of descendant devices will inherit the corresponding device namespace. As a result, these SysDevice device nodes can only be listened to and displayed in their respective working container or container host environment (with isolation and restrictions).

[0119] The above describes how to achieve isolation of peripherals in different containers within the device information subsystem. In a real-world server system environment, the / dev device node is managed by mounting devtmpfs in the container host environment. If containers use tmpfs mode to implement / dev, the container host environment needs to continuously identify and query the container ownership of any changing device, and then synchronously create the corresponding device in the corresponding container, making container peripheral management a very cumbersome process. If containers use a shared host environment devtmpfs mode to mount devtmpfs to implement / dev, all containers will have the same view of the device nodes, without any isolation.

[0120] To address this issue, the following solution is proposed in this application.

[0121] Please refer to Figure 5 If the server needs to support a device node subsystem, this subsystem must be designed and implemented to support multi-instance mounting. Each instance uses an independent memory file system to record the / dev device node, while sharing the same list of associated SysDevice nodes. When responding to a virtual file system mount operation, the device node subsystem obtains the dev_ns of the mount request process and stores it in the metadata information of that virtual file system view instance.

[0122] More specific implementations of the device node subsystem include: handle_create() adds a device response process;

[0123] handle_remove() removes the device response process; handle_populate() creates a new instance of the device node subsystem and populates the device node response process.

[0124] In one specific embodiment of this application, it further includes:

[0125] In the device node subsystem, the pointer to the device information structure object passed in the / dev node creation / deletion request is saved to a doubly linked list;

[0126] By querying the detailed information of the passed-in device information structure object, the DEV device path associated with the passed-in device information structure object can be obtained;

[0127] If the device namespace of the passed-in device information structure object is the initial device namespace, then the / dev node creation / deletion request will be responded to on all dev instances;

[0128] If the device namespace of the passed-in device information structure object is not the initial device namespace, respond to the / dev node creation / deletion request on the dev instance bound to the same device namespace.

[0129] Specifically, the device node subsystem uses the global variable sysdev_list, a doubly linked list, to store the SysDevice device list associated with the / dev node.

[0130] Please refer to Figure 6 The `handle_create()` process involves saving the pointer to the passed-in `SysDevice` device object to a doubly linked list `sysdev_list`, querying the detailed information of the `SysDevice` device object to obtain its associated DEV device path, and then iterating through all ` / dev` instances to attempt to add a device response. If the namespace of the passed-in `SysDevice` device object is the initial device namespace `init_dev_ns`, it indicates that the currently created ` / dev` node device is a shared infrastructure device for the container host. In this case, the ` / dev` node creation request should be responded to on all ` / dev` instances. If the namespace of the passed-in `SysDevice` device object is not the initial device namespace `init_dev_ns`, it indicates that the currently created ` / dev` node device is a container-bound private device. In this case, the ` / dev` node creation request only needs to be responded to on ` / dev` instances bound to the same device namespace.

[0131] Please refer to Figure 7 The handle_remove() process is the same as the deletion process that handle_create() mentioned earlier.

[0132] In one specific embodiment of this application, it further includes:

[0133] After creating a new / dev instance in the device node subsystem, it traverses all device information structure objects stored in the doubly linked list to attempt to add a device response process; the / dev instance only responds to device information structure objects with the same device namespace as its device or device information structure objects associated with the initial device namespace for subsequent operations;

[0134] Query the detailed information of the device information structure object to obtain the DEV device path associated with the device information structure object and execute the / dev node creation request.

[0135] Please refer to Figure 8The handle_populate() process needs to be called after creating a new / dev instance and setting the corresponding device namespace in the / dev mount interface response. The handle_populate() process needs to traverse all SysDevice device objects stored in sysdev_list for the newly created / dev instance and try to add device response processes. The / dev instance only responds to SysDevice device objects with the same device namespace as its own, as well as SysDevice devices associated with the initial device namespace init_dev_ns. Then, it queries the detailed information of the SysDevice device object to obtain its associated DEV device path and executes the / dev node creation request.

[0136] In one specific embodiment of this application, it further includes:

[0137] When a container destroys and unmounts the / dev instance it uses, all / dev device nodes in that instance are released.

[0138] That is, when a container destroys and unmounts the / dev instance it uses, it will automatically release all / dev nodes of that instance based on its common memory file system characteristics.

[0139] The preceding text explained how peripheral isolation can be achieved based on device namespaces in servers supporting multiple containers. However, in practical applications, each container can independently specify its primary and secondary device numbers (mknod) to create device node entry points for access without any restrictions. This allows for the theft or corruption of peripheral information data from other container tenants by querying or brute-forcing their peripheral numbers.

[0140] To address this issue, this application proposes the following solution.

[0141] In one specific embodiment of this application, it further includes:

[0142] By utilizing the peripheral device monitoring management service, a unique container identifier corresponding to the container device namespace is registered with the container host environment device security management service when the container starts.

[0143] The device information subsystem notifies the monitoring service of changes in devices by responding to the addition or deletion of devices associated with the DEV device path.

[0144] By reading the type and major / minor device number of the / dev device node, the container host environment device security management service registers and reports the type and major / minor device number of the / dev device bound to its own container.

[0145] Using the device security management service, a specified container can be exclusively used on a specified device based on the / dev device type and major / minor device number.

[0146] Through several innovative designs, such as adding device namespace identifiers to the kernel and modifying various device subsystems, it is now possible to enable the device guardian service in each container to independently negotiate and take effect remote USB device mapping. After mapping, the virtual device information node and device DEV node can achieve a relatively ideal isolation effect between containers.

[0147] In this embodiment, the security device access restriction interface of the container can also be connected to further ensure that the DEV device used by the specified container is bound to the corresponding container.

[0148] Please refer to Figure 9 Isolation restrictions for container peripheral devices require the container to be used in a mode that enables the device restriction capabilities supported by its system. The peripheral device listening and management service designed earlier in the container environment registers the container's unique identifier (CONTAINER_GUID) corresponding to the container device namespace with the device security management service of the container host environment when the container starts. It also notifies the listening service of device changes via the device information subsystem, responding to any additions or deletions of devices associated with the DEV device path. Furthermore, by reading the type and major / minor device number of the / dev device node, it registers and reports the type and major / minor device number of the / dev device bound to its own container with the device security management service of the container host environment. The device security management service then uses the container device control interface to restrict the exclusive use of a specified device by a specified container.

[0149] For example, Linux Docker containers can use CGROUP configuration rules to specify which containers can access a particular device number, while other containers are prohibited from accessing that device number. More complex CGROUP-based device access restriction filtering effects can also be achieved through a custom-implemented eBPF kernel extension of type BPF_PROG_TYPE_CGROUP_DEVICE.

[0150] For example, FreeBSD's Jail container only supports allowing access to container devices with specified DEV node names through devfs rule sets. Container users generally do not have permission to modify specified DEV device nodes or create device nodes using mknod.

[0151] Corresponding to the above method embodiments, this application also provides a container isolation device for peripheral resources. The container isolation device for peripheral resources described below and the container isolation method for peripheral resources described above can be referred to in correspondence.

[0152] See Figure 10 As shown, the device includes the following modules:

[0153] The query request receiving module 101 is used by the device information subsystem to receive the device query request of the target process corresponding to the target container and obtain the mount view information of the target process; the mount view information has the first device namespace associated with the target process;

[0154] The node query module 102 is used to obtain the target node hit by the query path in the device query request from the device information structure node tree; the device information structure object corresponding to the node in the device information structure node tree has a device namespace member variable to point to the second device namespace bound to the node;

[0155] The node display module 103 is used to display the target node when the mounted view information is the initial device namespace or the target node is bound to the initial device namespace; when the mounted view information is not the initial device namespace and the target node is not bound to the initial device namespace, it determines whether the second device namespace bound to the target node is consistent with the first device namespace. If so, the target node is displayed; otherwise, the target node is hidden.

[0156] Using the apparatus provided in the embodiments of this application, the device information subsystem receives a device query request from the target process corresponding to the target container and obtains the mount view information of the target process; the mount view information has a first device namespace associated with the target process; from the device information structure node tree, the target node hit by the query path in the device query request is obtained; the device information structure object corresponding to the node in the device information structure node tree has a device namespace member variable pointing to the second device namespace bound to the node; if the mount view information is the initial device namespace or the target node is bound to the initial device namespace, the target node is displayed; if the mount view information is not the initial device namespace and the target node is not bound to the initial device namespace, it is determined whether the second device namespace bound to the target node is consistent with the first device namespace. If yes, the target node is displayed; if no, the target node is hidden.

[0157] In this application, peripherals can be isolated and managed by defining device namespaces. Specifically, after the device information subsystem receives a device query request from the target process corresponding to the target container, it first clarifies the mount view information of the target process. This mount view information records the first device namespace associated with the target process. The target node in the query path of the device query request can be obtained from the device information structure node tree. The device information structure object corresponding to the node in this device information structure node tree also has a device namespace member variable pointing to the second device namespace bound to the node. If the mount view information is the initial device namespace, it means that the target process being queried is a privileged process of the container host environment. In this case, any path node in the device information structure node tree is allowed to be queried, and the target node can be directly displayed. If the target node is bound to the initial device namespace, it means that the device information node being queried is a public device of the host, and the target node can also be displayed. If the mount view information is not the initial device namespace, it is necessary to further determine whether the second device namespace bound to the target node is consistent with the first device namespace. If they are consistent, the target node is displayed; otherwise, the target node is hidden.

[0158] As can be seen, the device namespace design and the situation analysis based on the query process in this application can achieve effective isolation of devices between different containers.

[0159] In one specific embodiment of this application, it further includes:

[0160] The notification isolation module is used by the device information subsystem to obtain information about changed device nodes.

[0161] Determine the target device namespace to be bound from the device information structure object of the changed device node;

[0162] With the target device namespace being the initial device namespace, traverse all listening sockets and send device change notifications to each;

[0163] If the target device namespace is not the initial device namespace, query the network namespace associated with and bound to the corresponding device namespace, send device change notifications to the listening sockets in that network namespace, and send device change notifications to the listening sockets in the default network namespace.

[0164] In one specific embodiment of this application, it further includes:

[0165] The Virtual USB Device Subsystem is used by the Device Information Subsystem to dynamically bind dedicated virtual USB controllers to containers based on device namespaces, so that the corresponding device nodes can listen to and be displayed in their respective container or container host environment.

[0166] In one specific embodiment of this application, the virtual USB device subsystem is specifically used to create a control device using a virtual USB controller driver and to add a device control interface to the control device.

[0167] Use the container daemon service to generate a unique identifier for the container, start the container and pass the identifier as an environment variable;

[0168] By utilizing the peripheral listening management service in the container environment, a tag is obtained and the virtual USB controller driver is notified through the device control interface to create a virtual USB device controller with a specified naming format.

[0169] The interface adds a dedicated virtual USB device controller to a specified container by adding a device information node according to the specified device namespace; where the specified naming format corresponds to the container's unique identifier.

[0170] In one specific embodiment of this application, it further includes:

[0171] The / dev node management module is used in the device node subsystem to save the pointer to the device information structure object passed in the / dev node creation / deletion request to a doubly linked list;

[0172] By querying the detailed information of the passed-in device information structure object, the DEV device path associated with the passed-in device information structure object can be obtained;

[0173] If the device namespace of the passed-in device information structure object is the initial device namespace, then the / dev node creation / deletion request will be responded to on all dev instances;

[0174] If the device namespace of the passed-in device information structure object is not the initial device namespace, respond to the / dev node creation / deletion request on the dev instance bound to the same device namespace.

[0175] In one specific embodiment of this application, it further includes:

[0176] The dev node creation module is used to traverse all device information structure objects stored in the doubly linked list after a new / dev instance is created in the device node subsystem, and attempt to add device response processes. The / dev instance only responds to device information structure objects with the same device namespace as its device or device information structure objects associated with the initial device namespace for subsequent operations.

[0177] Query the detailed information of the device information structure object to obtain the DEV device path associated with the device information structure object and execute the / dev node creation request.

[0178] In one specific embodiment of this application, it further includes:

[0179] The resource release module is used to release all / dev device nodes in the instance when the container is destroyed and the / dev instance it uses is unmounted.

[0180] In one specific embodiment of this application, it further includes:

[0181] The listening isolation module is used to register the container's unique identifier corresponding to the container device namespace with the container host environment device security management service when the container starts.

[0182] The device information subsystem notifies the monitoring service of changes in devices by responding to the addition or deletion of devices associated with the DEV device path.

[0183] By reading the type and major / minor device number of the / dev device node, the container host environment device security management service registers and reports the type and major / minor device number of the / dev device bound to its own container.

[0184] Using the device security management service, a specified container can be exclusively used on a specified device based on the / dev device type and major / minor device number.

[0185] In practical applications, the module partitioning of this peripheral resource container isolation device can also be based on other different functional methods. For example... Figure 13 As shown, it can be divided into a notification isolation module, a listening isolation module, and a device management module. When the server hosting the container isolation device manages the device based on different systems, the specific implementation of the corresponding modules may differ.

[0186] For example, when managing devices based on the device information subsystem, the notification isolation module, monitoring isolation module, and device management module can be referenced. Figures 2 to 4 For specific implementation details, when managing devices based on the device node subsystem, the notification isolation module, the listening isolation module, and the device management module can be referenced. Figures 5 to 8 For specific implementation details, when it is also necessary to interface with the container's security device access restriction interface to further ensure that the DEV device used by a specified container is bound to the corresponding container, please refer to [reference needed]. Figure 9 The specific implementation.

[0187] Corresponding to the above method embodiments, this application also provides an electronic device. The electronic device described below and the container isolation method for peripheral resources described above can be referred to in correspondence.

[0188] See Figure 11 As shown, the electronic device includes:

[0189] Memory 332 is used to store computer programs;

[0190] Processor 322 is configured to implement the steps of the container isolation method for peripheral resources in the above method embodiments when executing a computer program.

[0191] For details, please refer to Figure 12 , Figure 12 This is a schematic diagram of the specific structure of an electronic device provided in this embodiment. The electronic device can vary significantly due to differences in configuration or performance. It may include one or more central processing units (CPUs) (e.g., one or more processors) and a memory 332. The memory 332 stores one or more computer programs 342 or data 344. The memory 332 can be temporary or permanent storage. The program stored in the memory 332 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the data processing device. Furthermore, the processor 322 may be configured to communicate with the memory 332 and execute the series of instruction operations stored in the memory 332 on the electronic device 301.

[0192] Electronic device 301 may also include one or more power supplies 326, one or more wired or wireless network interfaces 350, one or more input / output interfaces 358, and / or one or more operating systems 341.

[0193] The steps in the container isolation method for peripheral resources described above can be implemented by the structure of the electronic device.

[0194] Corresponding to the above method embodiments, this application also provides a readable storage medium. The readable storage medium described below and the container isolation method for peripheral resources described above can be referred to in correspondence.

[0195] A readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the container isolation method for peripheral resources described in the above method embodiments.

[0196] The readable storage medium can specifically be a USB flash drive, external hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, or any other readable storage medium capable of storing program code.

[0197] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0198] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0199] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0200] Finally, it should be noted that in this document, relationships such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "include," "contain," or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus.

[0201] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A container isolation method for peripheral resources, characterized in that, include: The device information subsystem receives a device query request for the target process corresponding to the target container and obtains the mount view information of the target process; The mount view information has a first device namespace associated with the target process; Obtain the target node hit by the query path in the device query request from the device information structure node tree; the device information structure object corresponding to the node in the device information structure node tree has a device namespace member variable to point to the second device namespace bound to the node; If the mount view information is the initial device namespace or the target node is bound to the initial device namespace, the target node is displayed. If the mounted view information is not the initial device namespace and the target node is not bound to the initial device namespace, determine whether the second device namespace bound to the target node is consistent with the first device namespace. If yes, the target node is displayed; otherwise, the target node is hidden.

2. The method according to claim 1, characterized in that, Also includes: The equipment information subsystem acquires changed equipment nodes; Determine the target device namespace to be bound from the device information structure object of the changed device node; With the target device namespace being the initial device namespace, all listening sockets are traversed and device change notifications are sent to each of them. If the target device namespace is not the initial device namespace, query the network namespace associated with the corresponding device namespace, send the device change notification to the listening socket in the network namespace, and send the device change notification to the listening socket in the default network namespace.

3. The method according to claim 1, characterized in that, Also includes: The device information subsystem dynamically binds a dedicated virtual USB controller to the container based on the device namespace, so that the corresponding device node can listen to and be displayed in its own container or container host environment.

4. The method according to claim 3, characterized in that, The device information subsystem dynamically binds a dedicated virtual USB controller to the container based on the device namespace, including: Create a control device using a virtual USB controller driver, and add a device control interface to the control device; Use the container daemon service to generate a unique identifier for the container, start the container, and pass the identifier as an environment variable. By utilizing the peripheral listening management service in the container environment, the tag is obtained and the virtual USB controller driver is notified through the device control interface to create a virtual USB device controller with a specified naming format; The interface adds a dedicated virtual USB device controller to a specified container by adding device information nodes according to the specified device namespace; wherein, the specified naming format corresponds to the unique identifier of the container.

5. The method according to claim 1, characterized in that, Also includes: In the device node subsystem, the pointer to the device information structure object passed in the / dev node creation / deletion request is saved to a doubly linked list; By querying the detailed information of the passed-in device information structure object, the DEV device path associated with the passed-in device information structure object can be obtained; If the device namespace of the incoming device information structure object is the initial device namespace, then the / dev node creation / deletion request will be responded to on all dev instances; If the device namespace of the incoming device information structure object is not the initial device namespace, respond to the / dev node creation / deletion request on the dev instance bound to the same device namespace.

6. The method according to claim 1, characterized in that, Also includes: After creating a new / dev instance in the device node subsystem, traverse all device information structure objects stored in the doubly linked list to attempt to add a device response process; The / dev instance only responds to device information structure objects that are in the same device namespace as its device or to device information structure objects associated with the initial device namespace for subsequent operations; Query the detailed information of the device information structure object to obtain the DEV device path associated with the device information structure object and execute the / dev node creation request.

7. The method according to claim 6, characterized in that, Also includes: When a container destroys and unmounts the / dev instance it uses, all / dev device nodes in that instance are released.

8. The method according to any one of claims 1 to 7, characterized in that, Also includes: By utilizing the peripheral device monitoring management service, a unique container identifier corresponding to the container device namespace is registered with the container host environment device security management service when the container starts. The device information subsystem notifies the monitoring service of changes in devices by responding to the addition or deletion of devices associated with the DEV device path. By reading the type and major / minor device number of the / dev device node, the container host environment device security management service registers and reports the type and major / minor device number of the / dev device bound to its own container. Using the device security management service, a specified container can be exclusively used on a specified device based on the / dev device type and major / minor device number.

9. A container isolation device for peripheral resources, characterized in that, include: The query request receiving module is used by the device information subsystem to receive device query requests from the target process corresponding to the target container and to obtain the mount view information of the target process. The mount view information has a first device namespace associated with the target process; The node query module is used to obtain the target node hit by the query path in the device query request from the device information structure node tree; the device information structure object corresponding to the node in the device information structure node tree has a device namespace member variable to point to the second device namespace bound to the node; The node display module is used to display the target node when the mount view information is the initial device namespace or the target node is bound to the initial device namespace; If the mounted view information is not the initial device namespace and the target node is not bound to the initial device namespace, determine whether the second device namespace bound to the target node is consistent with the first device namespace. If yes, the target node is displayed; otherwise, the target node is hidden.

10. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the container isolation method for peripheral resources as described in any one of claims 1 to 7 when executing the computer program.

11. A readable storage medium, characterized in that, The readable storage medium stores a computer program that, when executed by a processor, implements the steps of the container isolation method for peripheral resources as described in any one of claims 1 to 7.

Images