Equipment access method, device and equipment

Abstract

The embodiment of the invention provides an equipment access method and device and equipment, and the method comprises the steps: creating an equipment set corresponding to a first desktop, marking first equipment in the equipment set to a first equipment namespace, and enabling the first desktop to correspond to the first equipment namespace; determining a first process corresponding to the first desktop, and marking the first process to a device namespace; the method comprises the following steps: acquiring a device namespace corresponding to a first process and a first device namespace corresponding to the first device, so that when the first process accesses the first device, if the device namespace corresponding to the first process and the first device namespace corresponding to the first device meet a preset condition, the first process is allowed to access the first device, and the method improves the device isolation capability in a dynamic device scene.

Description

Technical Field

[0001] This application relates to the field of virtual desktop technology, and in particular to a device access method, apparatus, and device. Background Technology

[0002] When building a Virtual Desktop Infrastructure (VDI) service based on a "terminal-Linux container" remote desktop business model, it is necessary to redirect some commonly used external devices on the terminal to the container desktop. This process is achieved by using Linux kernel layer drivers to simulate buses or devices on the server side. Since multiple container desktops run on the same kernel in this method, in order to ensure data security, the redirected devices need to be isolated on a desktop-by-desk basis.

[0003] In related technologies, a pure application layer (host) solution based on the device cgroup mechanism is used to achieve device isolation. Specifically, the application layer space listens for uevent messages. After receiving a device addition message, it adds the device number of this device to the device cgroup whitelist of the container desktop to allow the container desktop to access this device number. Then, it creates the corresponding device file for this device in the / dev directory within the container desktop.

[0004] While this method can restrict application-layer processes from accessing devices based on the device number, the process is time-consuming because uevent messages are asynchronous messages sent by the kernel layer and the application layer needs to operate on the device cgroup whitelist. In redirection scenarios that support dynamic device plugging and unplugging, it is still possible to access devices of other container desktops, thus posing a significant risk to data security. Summary of the Invention

[0005] This application provides a device access method, apparatus, and device to address the problem that device access methods in related technologies cannot meet the needs of device isolation in dynamic device scenarios, and thus pose significant security risks.

[0006] In a first aspect, embodiments of this application provide a device access method, the method comprising:

[0007] Create a device set corresponding to the first desktop, and mark the first device in the device set to the first device namespace, wherein the first desktop corresponds to the first device namespace;

[0008] A first process corresponding to the first desktop is identified, and the first process is marked to the device namespace; so that when the first process accesses the first device, if the device namespace corresponding to the first process and the first device namespace corresponding to the first device meet a preset condition, the first process is allowed to access the first device.

[0009] Secondly, embodiments of this application provide a device access apparatus, the apparatus comprising:

[0010] The first tagging unit is used to create a device set corresponding to the first desktop and tag the first device in the device set to the first device namespace, wherein the first desktop corresponds to the first device namespace;

[0011] The second marking unit is used to determine the first process corresponding to the first desktop and mark the first process to the device namespace; so that when the first process accesses the first device, if the device namespace corresponding to the first process and the first device namespace corresponding to the first device meet the preset conditions, the first process is allowed to access the first device.

[0012] Thirdly, embodiments of this application provide a device access method, the method comprising:

[0013] In response to the target process's access operation to the target device, a second device namespace corresponding to the target process is determined based on a first tagging relationship between the process and the device namespace of the corresponding desktop; the device namespace is the namespace of devices and processes associated with the same desktop; the target process is the process corresponding to any service running on any desktop;

[0014] Based on the second tagging relationship between the preset device and the corresponding desktop device namespace, a third device namespace corresponding to the target device is determined;

[0015] When the second device namespace and the third device namespace meet the preset conditions, the target process is allowed to access the target device.

[0016] Fourthly, embodiments of this application provide a device access apparatus, the apparatus comprising:

[0017] The first determining unit is configured to, in response to an access operation of a target process to a target device, determine a second device namespace corresponding to the target process based on a preset first tagging relationship between the process and the device namespace of the corresponding desktop; the device namespace is: the namespace of devices and processes associated with the same desktop; the target process is: the process corresponding to any service running on any desktop;

[0018] The second determining unit is used to determine the third device namespace corresponding to the target device based on a preset second tagging relationship between the device namespace of the device and the corresponding desktop.

[0019] The access unit is used to allow the target process to access the target device when the second device namespace and the third device namespace meet preset conditions.

[0020] Fifthly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements any step of the device access method described in this application.

[0021] In a sixth aspect, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any step of the device access method described in this application.

[0022] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program stored in a computer-readable storage medium; when a processor of a memory access device reads the computer program from the computer-readable storage medium, the processor executes the computer program, causing the memory access device to perform any step in the device access method described in this application.

[0023] The beneficial effects of this application are as follows:

[0024] By setting up a device namespace corresponding to the desktop and marking the desktop's device set and the processes running on the desktop into the corresponding device namespace, the mapping between processes and device sets on the same desktop is achieved. This ensures that desktop processes can only access devices in their associated device set, improving the problem of incomplete isolation caused by time differences in the isolation process during dynamic device isolation in related technologies, and enhancing the device isolation effect.

[0025] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0026] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments 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.

[0027] Figure 1 A schematic diagram of a tree structure provided in an embodiment of this application;

[0028] Figure 2 A schematic diagram illustrating a possible application scenario provided by an embodiment of this application;

[0029] Figure 3 A schematic diagram illustrating the implementation process of a device access method provided in this application embodiment;

[0030] Figure 4 A schematic diagram illustrating the implementation process of a device access method provided in this application embodiment;

[0031] Figure 5 A schematic diagram illustrating a possible process access device processing flow provided in an embodiment of this application;

[0032] Figure 6 A schematic diagram illustrating a possible process for determining whether an access operation is allowed based on a BPF program, as provided in an embodiment of this application;

[0033] Figure 7 A schematic diagram illustrating a possible processing flow after the insertion of a new device, provided in an embodiment of this application;

[0034] Figure 8 A schematic diagram illustrating a possible specific example of device access provided in this application embodiment;

[0035] Figure 9 A schematic diagram of the structure of a possible device access device provided in an embodiment of this application;

[0036] Figure 10 A schematic diagram of another possible device access device provided in the embodiments of this application;

[0037] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0038] To address the issue that existing device access methods in related technologies cannot meet the requirements for device isolation in dynamic device scenarios and pose significant security risks, this application provides a device access method, apparatus, and device.

[0039] The following explains the terms used in the embodiments of this application:

[0040] 1. Kernel: The most fundamental part of a computer system, responsible for managing computer resources, including memory, processor, storage devices, and networks. It also provides various operating system services, such as the file system, process management, and network protocol stack. It combines various modules to enable them to work together within the operating system.

[0041] 2. Device Number: A unique (numerical) identifier assigned to a device by the kernel. It serves as an intermediary mechanism for the application layer to access device functionality through the file system. Device numbers can be divided into two categories: character device numbers and block device numbers. It's important to note that device numbers can be reassigned after being released, and not all devices have a device number.

[0042] 3. Device file (or special file): This refers to a special file created in the Linux file system and bound to a device number. It serves as the interface for applications to access device functionality. In practice, the `mknod` command can be used to create device files. It's important to note that when the device instance pointed to by a device number is deleted, the device file itself does not change. That is, the same device number may point to different device instances or may not have a device instance at different times; in other words, the device file and the device instance do not form a strong reference relationship.

[0043] 4. System Filesystem (sysfs): This is a virtual file system used by the kernel to expose internal objects, their attributes, and the relationships between them. In this application, device instance / device driver attributes refer to the sysfs file interface exposed by the device instance / device driver through sysfs, which can be used to view attributes or configure device instance / device driver parameters. Adding new attributes also requires adding corresponding sysfs file interface code to the kernel code.

[0044] 5. Control groups (cgroups): This is a feature of the Linux kernel used to limit, control, and isolate the resources (such as CPU, memory, disk I / O, device access, etc.) of a process set. cgroups have a tree structure and can implement increasingly stringent constraints. They include multiple controllers and sub-cgroups. Cgroups configure limits on corresponding resource types or monitor resource usage through controllers such as CPU, memory, and I / O. For example, the memory controller sets memory limits for tasks within the cgroup and displays memory resource reports. The set of controllers enabled by a cgroup is configurable; for instance, only the CPU controller can be enabled. Each controller may have multiple controller files for configuring various parameters. Cgroups use these control files to configure parameters and view data. Cgroup controllers require application-level enabling to function.

[0045] 6. Device cgroup: The devices controller in cgroup controls a process's ability to access (read / write / mknod) devices through a set of filtering rules based on device number. In cgroup v2, the filtering rules of device cgroup are mainly provided by the Berkeley Packet Filter (BPF) dynamic program inserted into the kernel by the application layer.

[0046] 7. Tree Structure: A tree structure is an abstract data type (ADT) or a data structure that implements this abstract data type, used to simulate a data set with tree-like properties. It consists of a hierarchical set of n (n>0) finite nodes. The basic unit in a tree structure is called a node, and the links between nodes are called branches. Nodes and branches form a tree structure. The beginning of the structure is called the root node, and other nodes are called child nodes. Child nodes include branch nodes and leaf nodes. Leaf nodes are nodes that are not linked to any other child nodes.

[0047] In the kernel, device instances in a device set are typically organized in a tree structure. For example... Figure 1As shown in this example, after driving device 1 (device 1) with the corresponding device driver, device 2 (device 2) and device 3 (device 3) are generated under certain conditions. After driving device 2 with the corresponding device driver, device 4 (device 4) is generated under certain conditions. Devices 3 and 4, once driven, have no sub-devices and can also be left undriven. Figure 1 For example, assume that device 1 is a root node device in the device tree of a real Linux system, device 2 is a branch node, and device 3 and device 4 are leaf nodes. In the following text, the device tree represents multiple devices in a tree structure. It could be a root device tree, a child node in the root device tree and all nodes under that child node, such as the device tree formed by device 2 and device 4, or a leaf node in a complete device tree, such as device 3 or device 4.

[0048] 8. Namespace: A process isolation technology provided by the Linux kernel, used to isolate the runtime environment of a process, including file system mount points, process identifiers, network interfaces, etc. By using namespaces, processes with independent runtime environments can be created, making them invisible to other processes and system resources.

[0049] The preferred embodiments of this application are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0050] The application scenarios described in this application are for the purpose of more clearly illustrating the technical solutions of this application, and do not constitute a limitation on the technical solutions provided in this application. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided in this application are also applicable to similar technical problems. In the description of this application, unless otherwise stated, "multiple" means two or more. Furthermore, in this application, " / " represents an "or" relationship.

[0051] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this application.

[0052] In traditional VDI cloud desktops, a "terminal-remote desktop virtual machine (VM)" remote desktop service model is typically employed. The core of this model is redirecting some commonly used external devices (peripherals) from the terminal to the VM. In practice, peripherals requiring redirection generally include Universal Serial Bus (USB) devices, cameras, serial and parallel ports, and audio input / output devices. After redirection, these peripherals need to be strictly isolated within each VM desktop; that is, terminal users within a VM cannot access devices belonging to other users (desks). The characteristics of VMs meet this requirement.

[0053] When the underlying mechanism for remote desktop services is switched from virtual machines to Linux containers (hereinafter referred to as container desktops or desktops), the redirection of peripherals such as USB devices and cameras on the server side needs to be implemented by using Linux kernel (kernel) level drivers to simulate buses or devices. Specifically, for USB device redirection, multiple remote USB devices can be redirected to one or more local USB virtual buses via the usbip / Virtual Host Controller Interface (VHCI) module in the kernel. In container desktop applications, a set of VHCIs can be assigned to each desktop to redirect the corresponding terminal's USB devices. Because USB device redirection is based on bus-level redirection, the device number (which may be multiple) used by the application layer for USB devices is dynamically generated by one or more device drivers corresponding to the device. Therefore, USB device redirection is the most complex type of peripheral redirection.

[0054] During redirection, multiple container desktops (guests) and the application layer (hosts) share a single kernel, and some devices must be driven by the kernel. For data security, it's necessary to prevent other desktops from accessing the redirected devices. Related technologies use the kernel's device cgroup (i.e., device controller) mechanism to restrict process access to devices based on device numbers. This mechanism can achieve device isolation in scenarios involving static device redirection, but its effectiveness is poor for redirection scenarios involving dynamic devices that support dynamic plugging and unplugging.

[0055] To address the aforementioned issues, this application provides a device access method. By setting a device namespace corresponding to the desktop and marking the desktop's device set and the processes running on the desktop into the desktop's corresponding device namespace, the method establishes a correspondence between processes and device sets on the same desktop. This ensures that desktop processes can only access devices in their associated device set, improving upon the problem of incomplete isolation caused by time differences in the isolation process during dynamic device isolation in related technologies.

[0056] Figure 2 This is a schematic diagram illustrating a possible application scenario provided by an embodiment of this application, such as... Figure 2 As shown, this scenario includes multiple terminals (terminal 1 and terminal 2 as shown) and a server. In this scenario, each terminal is connected to a corresponding external device, and a corresponding virtual desktop is configured in the kernel of the server's Linux system. The external devices connected to the terminal are redirected to the corresponding desktop. Specifically, terminal 1 corresponds to container desktop 1, terminal 2 corresponds to container desktop 2, and the external devices connected to terminal 1 need to be redirected to container desktop 1, while the external devices connected to terminal 2 need to be redirected to container desktop 2.

[0057] It should be noted that the desktop described in this application embodiment is not limited to a container desktop, and can also be extended to other forms of desktop, such as a local desktop, in specific implementations.

[0058] Based on the above application scenarios, the following will refer to the appendix. Figures 3-11 The exemplary embodiments of this application are described in more detail below. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the implementation methods of this application are not limited in any way. On the contrary, the implementation methods of this application can be applied to any applicable scenario.

[0059] like Figure 3The diagram illustrates a possible implementation flow of a device access method provided in this application embodiment. This method is applied to the application layer on the server side and is a pre-configuration process for identifying relationships before accessing the device. This process specifically includes:

[0060] Step S31: Create a device set corresponding to the first desktop, and mark the first device in the device set to the first device namespace. The first desktop corresponds to the first device namespace.

[0061] In some embodiments, this application introduces the concept of a device namespace (devns), which is a specific namespace used to associate processes on the same desktop with a set of devices. Each device namespace corresponds to at least one desktop (typically one), and each desktop corresponds to a unique device namespace. In implementation, the specific correspondence between desktops and namespaces can be configured based on requirements. The aforementioned first desktop refers to any desktop running on the server, and the aforementioned first device namespace refers to the device namespace corresponding to the first desktop.

[0062] In this embodiment, before executing step S31, the application layer needs to create a first device namespace. Specifically, before creating the first device namespace, a device `devnsctl` can be created in the kernel layer. This device is typically implemented as a character device. When the application layer creates the first device namespace, it can use the `devnsctl` interface to drive the application layer device to achieve the creation of the first device namespace. After creating the first device namespace, the application layer can also perform operations such as resetting, viewing, and destroying the created device namespace. These operations are also implemented by driving the application layer device through the aforementioned `devnsctl` interface (e.g., ...). Figure 8 (As shown).

[0063] In some embodiments, the application layer may reference its created devns (distinguishing between different devns) in any of the following ways:

[0064] First, the application layer assigns a unique number to each devns, which can then be referenced based on this number.

[0065] Second, pre-configure each devns to be assigned to a corresponding inode file, which is then referenced via a path, similar to the way process namespace file nodes (such as / proc / self / ns / pid) are referenced in the proc file system.

[0066] In some embodiments, the device set corresponding to the first desktop created in this application includes device instances of each first device corresponding to the first desktop; the process of marking the first devices in the device set to the first device namespace is: marking the device instances of each first device to the first device namespace.

[0067] In this embodiment of the application, the device instances of the first device corresponding to the first desktop (referring to the device obtained after redirection of the peripheral connected to the terminal corresponding to the first desktop) need to be marked in the first devns. It should be noted that the device instances of non-desktop devices do not need to be actually marked, and are regarded as marked to the root devns.

[0068] In some embodiments, the device set is typically a tree structure, i.e., a device tree, including root node devices and non-root node devices (including branch nodes and leaf nodes). In this case, the process of marking any device set corresponding to the first desktop into the first device namespace is as follows: the root node devices in the device set are marked into the first device namespace, and each non-root node device is marked into the device namespace of the corresponding root node device. That is, after the root node device is marked, each non-root node device is automatically marked into the device namespace corresponding to the root node device.

[0069] In some embodiments, since some devices within the root devns need to be shared with container desktops, such as graphics card render devices, this application adds the concept of access sets to devices to add permission settings on the devices. Specifically, in this embodiment, after creating a device set corresponding to the first desktop, an access set corresponding to each first device can be configured. This access set includes the device namespaces corresponding to processes allowed to access the first device. By default, the device namespace to which the device belongs can be automatically added to this access set. The device namespaces in this access set can be set as needed.

[0070] In practice, the application layer can add corresponding access sets to the device configuration through the device's exposed interfaces (such as device properties) to expand the range of processes allowed to access the device.

[0071] In some embodiments, the application layer can also obtain relevant information about the corresponding device namespace through processes or devices for data analysis or configuration debugging. Specifically, the application layer can obtain the device's corresponding devns information through sysfs device attributes, or determine the process's corresponding devns information through procfs.

[0072] In some embodiments, when marking the first device in the device set corresponding to the first desktop to the first device namespace, there are two cases: static marking and dynamic marking. Static marking is marking based on a certain configured rule, while dynamic marking refers to modifying the previous marking relationship to generate a new marking relationship.

[0073] In practice, before marking the first device in the device set to the first device namespace, it is necessary to load the first device in the device set corresponding to the first desktop through the process running on the first desktop. Based on this, the above static marking methods include the following two, which will be explained below using any device set as an example:

[0074] 1. Based on the pre-configured tagging relationship between process and device namespaces, determine the first device namespace corresponding to the process that loads the first device, and tag the first device to the determined device namespace (i.e., the first device namespace).

[0075] Specifically, by modifying the device driver source code corresponding to the first device, the process can become aware of the process loading the first device, and thus mark the first device in the device namespace corresponding to the process. In some embodiments, the host process can also mark the first device to a specified devns by passing a devns number.

[0076] In a device set organized and managed using a tree structure, the root node device can be marked to the corresponding desktop's device namespace using the method described above. Non-root node devices can determine their own device namespace by querying the device namespace corresponding to the root node device; they do not need to be directly marked. When marking in this way, some device drivers may create devices with a null parent (i.e., non-root node devices). If these are not marked, they will escape to the root devns (theoretically the device namespace corresponding to the application layer). However, in this case, since no container desktop application can access this device, no security issues arise. This special scenario can be resolved by manually binding devns by modifying the source code.

[0077] 2. Based on the pre-configured correspondence between devices and device namespaces, determine the first device namespace corresponding to the first device, and mark the device set into the determined device namespace (i.e., the first device namespace).

[0078] Specifically, the application layer pre-configures the correspondence between the first device and the corresponding device namespace in the loading parameters corresponding to each first device. When marking the first device to the device namespace of the corresponding desktop, it can be marked to the corresponding device namespace directly according to the correspondence configured in the loading parameters.

[0079] In some embodiments, this application also provides another device tagging method, which systematically adds a device attribute to all devices to tag the devices to a specified devns, for example, by modifying the device tag's devns by writing the devns number. This method can be performed in parallel with the above-described method.

[0080] In some embodiments, the above dynamic labeling method is as follows: the first device in the device set is marked to the first device namespace through the device attribute interface corresponding to the first device; specifically, for each first device in the device set, the first device flag value is assigned to the desktop's devns through the sysfs device attribute interface, or the devns corresponding to the first device is modified from the current devns to other devns.

[0081] Step S32: Determine the first process corresponding to the first desktop and mark the first process to the device namespace; so that when the first process accesses the first device, if the device namespace corresponding to the first process and the first device namespace corresponding to the first device meet the preset conditions, the first process is allowed to access the first device.

[0082] The aforementioned first process refers to the process corresponding to each service running on the first desktop.

[0083] In some embodiments, when marking the first process to the device namespace (the device namespace is the device namespace of the first desktop corresponding to the first process, i.e., the first device namespace), the first process can be marked to the device namespace through cgroup or other namespace technologies (such as PID namespace, network namespace). Other namespace technologies can be: binding the process to the nsproxy structure, which only requires marking the process and making it easy to read.

[0084] In practice, the application layer can enable the controller (cgroup controller) corresponding to the first desktop through its control file and bind the controller to the device namespace, thereby marking the first process corresponding to the controller to the device namespace.

[0085] In this application example, the application layer typically creates cgroups in the following order: Under a cgroup (or root cgroup), a new directory is created (i.e., a new cgroup is created), then the required controller set (including the cgroup devnscontroller) is enabled, and the corresponding control parameters, such as CPU utilization, are configured. At this point, the cgroup devnscontroller's control file is used to bind it to the corresponding desktop's devns. After configuration, the process corresponding to the cgroup devnscontroller (i.e., the process of the corresponding desktop) is placed into the cgroup to mark the process to the devns bound to the controller (e.g., ...). Figure 8 (As shown).

[0086] In practice, the operation of enabling the cgroup devns controller and binding it to devns at the application layer is performed when the container cgroup is created. The kernel needs to provide a user-level interface (i.e., the control file for configuring devns exposed by the cgroup devns controller) for binding the cgroup devns controller to the devns of the corresponding desktop.

[0087] It should be noted that, since the application layer processes in the kernel include not only desktop (or container) processes but also host processes that are not subject to container isolation, this embodiment of the application, in addition to marking the processes corresponding to each desktop to the corresponding desktop's devns (i.e., non-root devns), also needs to mark the host processes to the root devns. Here, root devns refer to the devns corresponding to the host processes, and non-root devns refer to the devns corresponding to each desktop. In some embodiments, host processes may not need to perform actual marking operations; that is, processes not marked to a specific device namespace are considered to correspond to the root devns.

[0088] In some embodiments, the multiple first processes corresponding to the first desktop are typically in a tree structure, i.e., a process tree. In this case, when marking the first processes, the root node process in the process tree can be marked in the first device namespace, and each non-root node process can be marked in the device namespace corresponding to the root node process. In specific implementations, child processes created by the fork function will be configured by default in the cgroup of the corresponding parent node process, i.e., in the namespace corresponding to the marked parent node process.

[0089] It should be noted that this application does not limit the execution order between the above steps S31 and S32 in the embodiments of this application.

[0090] like Figure 4 The diagram illustrates a possible implementation flow of a device access method provided in this application embodiment. This method is applied to the kernel layer on the server side. After a tagging relationship is established, when a desktop or host process accesses a device, the process determines whether its access is permitted. It should be noted that the following only describes the access process of a desktop process to the device; the access process of a host process to the device is the same. The process specifically includes:

[0091] Step S41: In response to the target process's access operation to the target device, based on the preset first tag relationship between the process and the device namespace of the corresponding desktop, determine the second device namespace corresponding to the target process;

[0092] Among them, the device namespace is the namespace of devices and processes associated with the same desktop; the target process is the process corresponding to any service running on any desktop.

[0093] In this embodiment of the application, the process of establishing the first marker relationship described above can be found in the above description.

[0094] Step S42: Based on the preset second tag relationship between the device and the corresponding desktop device namespace, determine the third device namespace corresponding to the target device;

[0095] In some embodiments, the second tagging relationship between the aforementioned device and the device namespace of the corresponding desktop is essentially the second tagging relationship between the device instance of the device and the device namespace of the corresponding desktop. In this application, a mapping table recording the correspondence between the device number and the device instance of each device is pre-stored. When the target process accesses the target device, the device number of the target device can be obtained, and the corresponding device instance can be determined based on the device number through the mapping table, and then the third device namespace corresponding to the target device can be determined based on the second tagging relationship.

[0096] In this embodiment, the devices can be divided into two categories: character devices and block devices. The relevant code in the syscall of a block device can locate the device instance based on the device number, that is, the block device itself has a corresponding mapping table, so there is no need to create a mapping table separately; however, the character device itself does not have a corresponding mapping table, so it is necessary to create a mapping table from the device number to the device instance separately.

[0097] In this embodiment of the application, the process of establishing the second marker relationship described above can be found in the description above.

[0098] Step S43: When the second device namespace and the third device namespace meet the preset conditions, the target process is allowed to access the target device.

[0099] In some embodiments, the aforementioned preset conditions include: the relationship between processes allowed to access the device and the device. This relationship may include one or more, and can be specifically set based on business needs. For example, the relationship may be set as: the device is a device with a tag relationship in the device namespace corresponding to the current process. Optionally, this isolation policy is implemented at the device access interface, and the corresponding isolation policy is invoked through the interface each time a process accesses the device.

[0100] At this point, the step of determining whether the second device namespace and the third device namespace meet the preset conditions specifically includes: determining the relationship between the target device and the target process based on the second device namespace and the third device namespace; and determining whether the first device namespace and the second device namespace meet the preset conditions based on whether the relationship between the target device and the target process belongs to the relationships included in the preset conditions.

[0101] In one possible embodiment, the above-mentioned preset conditions may include at least one of the following:

[0102] Processes belonging to non-root devns are allowed to access the devices associated with their respective devns, meaning processes are allowed to access devices on the same desktop.

[0103] Processes corresponding to non-root devns are not allowed to access devices corresponding to other non-root devns, meaning processes are not allowed to access devices that are not on the same desktop.

[0104] The root devns process determines whether to allow access to devices corresponding to non-root devns based on the configuration (pre-configured to allow or disallow). In other words, the host process can determine whether to allow access to desktop devices based on the configuration.

[0105] The process corresponding to the non-root devns determines whether to allow access to the device corresponding to the root devns based on the configuration (pre-configured to allow or disallow). In other words, desktop processes can determine whether to allow access to non-desktop devices based on the configuration.

[0106] In some embodiments, the aforementioned preset conditions are included in an isolation policy, which is a bpf program configured at the application layer. When the kernel layer needs to use it for access verification, the bpf program is called to perform subsequent operations based on the isolation policy to determine whether the process is allowed to access the device.

[0107] Optionally, in this embodiment, input parameters corresponding to the BPF program can be added based on the relevant technologies. That is, characteristic parameters of device access behavior in terms of device namespace (referred to as devns characteristic parameters) can be added to the device cgroup BPF context. Specifically, in the relevant technologies, the isolation strategy of "device number - access method (read / write / mknod) - device type" is used to determine whether to allow access to the device. Since the concept of device namespace is introduced in this embodiment, input parameters related to device namespace (i.e., devns characteristic parameters) can be added. That is, the input parameters are modified to "device number - access method - device type - devns characteristic parameters" to allow container processes to access devices in their associated device namespace. This method improves flexibility while being compatible with the original device cgroup mechanism ecosystem.

[0108] like Figure 5 The diagram illustrates the process flow for a process accessing a device after adding the `devns` feature parameter. This process includes the following steps:

[0109] Step S51: In response to the target process's access operation to the target device, determine the second devns corresponding to the current process through the current cgroup devnscontroller;

[0110] Step S52: Determine the device instance corresponding to the device number of the target device through the mapping table, and find the third devns corresponding to the device set where the device instance is located;

[0111] Step S53: Generate devns feature information corresponding to the devns feature parameters through the second devns and the third devns; in some embodiments, the devns feature parameters can be the relationship between the target device and the target process.

[0112] Step S54: Generate the context parameter (i.e., device cgroup bpfcontext) with the above devns feature information added;

[0113] Step S55: Call the bpf program from the application layer to determine whether the target process is allowed to access the application based on the context parameter.

[0114] like Figure 6 The diagram shows a flowchart illustrating the process of determining whether an access operation is allowed based on a BPF program. This process includes the following steps:

[0115] Step S61, obtain the context parameter;

[0116] Step S62: Determine whether the above context parameter meets the preset conditions in the BPF program. If yes, proceed to step S63; otherwise, proceed to step S64.

[0117] In implementation, assuming the devns feature parameter is "whether the device is a device with a tag relationship to the device namespace corresponding to the current process", the devns feature information corresponding to the devns feature parameter included in the context parameter is a first identifier representing "the device is a device with a tag relationship to the device namespace corresponding to the current process", or a second identifier representing "the device is not a device with a tag relationship to the device namespace corresponding to the current process". The above S62 step is to determine that when the devns feature information is the first identifier, the preset condition is satisfied; when the devns feature information is the second identifier, the preset condition is not satisfied.

[0118] Step S63: The return value is set to Allow; that is, the target process is allowed to access the target program.

[0119] Step S64: The return value is set to not allowed; that is, the target process is not allowed to access the target program.

[0120] In some embodiments of this application, when an access set corresponding to the target device is further provided, if the second device namespace and the third device namespace do not meet the preset conditions, it is determined whether the second device namespace is located in the access set corresponding to the target device. If it is located in the access set, the target process is allowed to access the target device. The access set corresponding to the target device includes: the device namespace corresponding to the process that is allowed to access the target device.

[0121] In some embodiments, when the target device is a character device, the aforementioned discrimination process based on preset conditions requires a certain amount of time. During this time, the character device may undergo dynamic plug-in / plug-out operations, causing a change in the relationship between the device number and the device. Therefore, in this embodiment, after allowing the target process to access the target device, the following steps are also required: after the target device starts, determine the device corresponding to the target device's device number, and based on the second tag relationship, determine the fourth device namespace corresponding to the target device; determine whether to close the target device based on whether the second and fourth device namespaces meet preset conditions; specifically, if the second and fourth device namespaces meet the preset conditions, the target device is not closed; otherwise, the target device is closed. Since the relationship between the device number and the device is fixed after the target device starts, checking the device namespace again after the target device starts to further ensure the device isolation effect.

[0122] In some embodiments, the triggering conditions corresponding to the above-mentioned operation of re-checking the device namespace can also be set. That is, before the target device starts, an instruction to start the target device is received. When the target device is determined to be a character device, a matching identifier corresponding to the start operation is generated. The matching identifier is used to identify the verification of the device namespace corresponding to the target device during the startup process of the target device. After the target device starts (specifically, when the open function of the device driver is called), it is checked whether there is a corresponding matching identifier. When a matching identifier corresponding to the startup operation of the target device is found (i.e., the matching identifier is set), the operation of determining the device corresponding to the device number of the target device is triggered.

[0123] In some embodiments, when the kernel layer detects the insertion of a new device and determines that the new device belongs to a non-root node device based on the attribute information of the new device, it determines the root node device corresponding to the new device and marks the new device to the device namespace corresponding to the root node device. Specifically, when a new device is detected to be inserted into the current server, a device instance of the new device is created; when the attribute information of the new device determines that the new device belongs to a non-root node device, it determines the root node device corresponding to the new device and marks the device instance of the new device to the device namespace corresponding to the device instance of the root node device.

[0124] In other words, when a newly inserted device belongs to a non-root node device, the device will be automatically added to the device namespace corresponding to its root node device; when a newly inserted device belongs to a root node device, the method for determining its labeling relationship with the device namespace can be found in the description in S31 above.

[0125] The following combination Figure 7 This document describes the processing flow after the insertion of the new device. This example illustrates the process of adding a USB device based on VHCI.

[0126] In the Figure 7 Before describing the insertion process for non-root node devices, we will first illustrate the marking process for root node devices using a USB device as an example. For a USB device acting as a root node device, the application layer needs to create a VHCI HCD (host controller device) and bind it to the specified devns to mark the USB device to that devns. Specifically, this creation process requires modifying the VHCI driver source code to provide the user layer with an interface for creating and binding the VHCI controller to the specified devns, allowing the application layer to create and bind the VHCI HCD through this interface.

[0127] Based on this, for USB devices that are not root nodes, the marking of new devices is done automatically at the kernel level, and no further operations are required at the application layer. See [link to details] for specific procedures. Figure 7 However, due to Figure 7 The USB enumeration, adding device properties, sending device ADD (add) events to the netlink socket, and asynchronous notifications are all existing processing flows in related technologies, and will not be elaborated here.

[0128] like Figure 7 As shown, when a USB device is redirected to VHCI HCD using usbip (i.e., the aforementioned usbip access device), the kernel layer performs USB device enumeration and then executes the subsequent device addition process. During this process, if the device belongs to a non-root node device of VHCI HCD, the device will be automatically added to the devns of the root node device (this process does not require application layer intervention). In specific implementation, the above-mentioned automatic addition process of devns is executed before adding device attributes.

[0129] After a new device is added, the application layer is notified asynchronously. When the application layer detects the device and has a need to access it, it sends an access request to the kernel layer. The kernel layer determines whether to allow access based on the devns isolation policy (see the description above for the specific implementation of this process).

[0130] Figure 8 This is a schematic diagram illustrating a specific example of device access provided in an embodiment of this application. The following is in conjunction with... Figure 8 The specific example shown illustrates the overall process of the above device access method.

[0131] It should be noted that, in Figure 8 In this context, devns A and devns B represent two device namespaces, and container Aguest (desktop) and container B guest are two different container desktops.

[0132] In this example, devns A corresponds to the container Guest. Device sets A1 and A2 are the device sets corresponding to the container Guest. Device set A1 includes devices A11, A12, and A13. Device A11 is the root node device, and devices A12 and A13 are non-root node devices. Device sets A1 and A2 are marked to devns A. The guest process of container A is indirectly marked to devns A through the devns controller in cgroup A.

[0133] devns B corresponds to container B guest. Device set B1 is the device set corresponding to container B guest. Device set B1 includes device B11. Device set B1 is marked to devns B. Container B guest process is indirectly marked to devns B through devnscontroller in cgroup B.

[0134] When making access, processes in container A are allowed to access devices in devns A (i.e., device sets A1 and A2), but are not allowed to access devices in devns B (device set B1); processes in container B are allowed to access devices in devns B (i.e., device set B1).

[0135] It should be noted that although this application uses a container desktop as an example to illustrate the above device access method, the device access method of this application is a general solution and is not limited to container desktops. When there is a need for dynamic device isolation and the concept of cgroup / namespace is introduced, the above device access method of this application can be used to isolate dynamic devices, such as Linux native multi-session desktops.

[0136] Based on the same technical concept, embodiments of this application also provide a device access device, referring to... Figure 9 As shown, the device access device specifically includes:

[0137] The first marking unit 901 is used to create a device set corresponding to the first desktop and mark the first device in the device set to the first device namespace, wherein the first desktop corresponds to the first device namespace.

[0138] The second marking unit 902 is used to determine the first process corresponding to the first desktop and mark the first process to the device namespace; so that when the first process accesses the first device, if the device namespace corresponding to the first process and the first device namespace corresponding to the first device meet the preset conditions, the first process is allowed to access the first device.

[0139] In some possible implementations, the second marking unit 902 described above is specifically used for:

[0140] By using the control file of the controller corresponding to the first desktop, the controller is enabled and bound to the device namespace, so as to mark the first process corresponding to the controller to the device namespace.

[0141] In some possible implementations, the first marking unit 901 described above is specifically used for:

[0142] Based on the pre-configured tagging relationship between process and device namespaces, the first device namespace corresponding to the process that loads the first device is determined, and the first device is marked in the first device namespace; the process runs on the first desktop and is used to load the device corresponding to the first desktop; or,

[0143] Based on the pre-configured correspondence between devices and device namespaces, the first device namespace corresponding to the first device is determined, and the first device is marked to the first device namespace.

[0144] In some possible implementations, the first marking unit 901 described above is specifically used for:

[0145] By using the device attribute interface corresponding to the first device, the first device in the above device set is marked to the first device namespace.

[0146] In some possible implementations, the device set includes root node devices and non-root node devices, and the first marking unit 901 is specifically used for:

[0147] The root node device in the above device set is marked to the first device namespace, and each non-root node device is marked to the device namespace of the corresponding root node device.

[0148] In some possible implementations, after the first tagging unit 901 creates the device set corresponding to the first desktop, it is further used for:

[0149] For each first device, configure an access set corresponding to the first device, the access set including: the device namespace corresponding to the processes that are allowed to access the first device.

[0150] Based on the same technical concept, this application also provides another device access device, referring to... Figure 10 As shown, the device access device specifically includes:

[0151] The first determining unit 1001 is used to respond to the target process's access operation to the target device, and determine the second device namespace corresponding to the target process based on a preset first tag relationship between the process and the device namespace of the corresponding desktop; the device namespace is: the namespace of the device and process associated with the same desktop; the target process is: the process corresponding to any service running on any of the desktops.

[0152] The second determining unit 1002 is used to determine the third device namespace corresponding to the target device based on the preset second tag relationship between the device namespace of the device and the corresponding desktop.

[0153] Access unit 1003 is used to allow the target process to access the target device when the second device namespace and the third device namespace meet the preset conditions.

[0154] In some possible implementations, the aforementioned preset conditions include: the relationship between the process that allows access to the device and the device; the access unit 1003 is specifically used for:

[0155] Based on the aforementioned second and third device namespaces, the relationship between the aforementioned target device and the aforementioned target process is determined.

[0156] When the relationship between the target device and the target process is determined to be any of the relationships included in the preset conditions, the target process is allowed to access the target device.

[0157] In some possible implementations, if the second device namespace and the third device namespace do not meet the preset conditions, the access unit 1003 is further configured to:

[0158] If the second device namespace is located in the access set corresponding to the target device, then the target process is allowed to access the target device. The access set corresponding to the target device includes the device namespaces corresponding to the processes that are allowed to access the target device.

[0159] In some possible implementations, if the target device is a character device, after the access unit 1003 allows the target process to access the target device, it is further configured to:

[0160] After the target device is started, a fourth device namespace corresponding to the target device is determined based on the second tagging relationship.

[0161] Based on whether the second and fourth device namespaces meet the preset conditions, determine whether to shut down the target device.

[0162] In some possible implementations, the access unit 1003 is further configured to:

[0163] Upon receiving an instruction to start the target device, and determining that the target device is a character device, a matching identifier corresponding to the startup operation is generated; the matching identifier is used to identify the verification of the device namespace corresponding to the target device during the startup process of the target device.

[0164] After the target device is started, and before determining the fourth device namespace corresponding to the target device based on the second tagging relationship, the method further includes:

[0165] A matching identifier corresponding to the startup operation of the aforementioned target device was detected.

[0166] In some possible implementations, the above-described apparatus further includes a creation unit for:

[0167] When a new device inserter is detected, and it is determined that the new device is a non-root node device based on the attribute information of the new device, the root node device corresponding to the new device is determined, and the new device is marked to the device namespace corresponding to the root node device.

[0168] Based on the same technical concept, this application also provides an electronic device 1100, referring to... Figure 11 As shown, the electronic device 1100 is used to implement the device access method described in the above-described method embodiments. The electronic device 1100 in this embodiment may include: a memory 1101, a processor 1102, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the various device access method embodiments described above.

[0169] This application embodiment does not limit the specific connection medium between the memory 1101 and the processor 1102. This application embodiment... Figure 11 The memory 1101 and the processor 1102 are connected via a bus 1103, and the bus 1103 is in Figure 11 The connections between other components are shown in bold lines only and are not intended to be limiting. The aforementioned bus 1103 can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 11 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0170] Memory 1101 may be volatile memory, such as random-access memory (RAM); memory 1101 may also be non-volatile memory, such as read-only memory, flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 1101 may be any other medium capable of carrying or storing desired program code having the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1101 may be a combination of the above-described memories.

[0171] Processor 1102 is configured to implement device access methods according to various exemplary embodiments of this application.

[0172] This application also provides a computer-readable storage medium storing computer-executable instructions required to execute the processor, including a program required to execute the processor.

[0173] In some possible implementations, various aspects of the device access method provided in this application may also be implemented as a program product, which includes program code that, when the program product is run on an electronic device, causes the electronic device to perform the steps of the device access method according to the various exemplary embodiments of this application described above.

[0174] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0175] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (devices), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0176] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0177] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0178] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0179] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A device access method, characterized in that, The method includes: Create a device set corresponding to the first desktop, and mark the first device in the device set to the first device namespace, wherein the first desktop corresponds to the first device namespace; A first process corresponding to the first desktop is identified, and the first process is marked to the device namespace; so that when the first process accesses the first device, if the device namespace corresponding to the first process and the device namespace corresponding to the first device meet a preset condition, the first process is allowed to access the first device.

2. The method according to claim 1, characterized in that, The step of marking the first process to the device namespace includes: The controller is enabled through the control file of the controller corresponding to the first desktop, and the controller is bound to the device namespace so as to mark the first process corresponding to the controller to the device namespace.

3. The method according to claim 1, characterized in that, The step of marking the first device in the device set to the first device namespace includes: Based on the pre-configured tagging relationship between process and device namespaces, the first device namespace corresponding to the process loading the first device is determined, and the first device is marked in the first device namespace; the process runs on the first desktop and is used to load the device corresponding to the first desktop; or, Based on the pre-configured correspondence between devices and device namespaces, the first device namespace corresponding to the first device is determined, and the first device is marked to the first device namespace.

4. The method according to claim 1, characterized in that, The step of marking the first device in the device set to the first device namespace includes: The first device in the device set is marked to the first device namespace through the device attribute interface corresponding to the first device.

5. The method according to claim 1, characterized in that, The device set includes root node devices and non-root node devices, and marking the first device in the device set to the first device namespace includes: The root node device in the device set is marked to the first device namespace, and each non-root node device is marked to the device namespace of the corresponding root node device.

6. The method according to any one of claims 1 to 5, characterized in that, After creating the device set corresponding to the first desktop, the method further includes: For each first device, an access set corresponding to the first device is configured, the access set including: the device namespace corresponding to the processes that are allowed to access the first device.

7. A device access method, characterized in that, The method includes: In response to the target process's access operation to the target device, a second device namespace corresponding to the target process is determined based on a first tagging relationship between the process and the device namespace of the corresponding desktop; the device namespace is the namespace of devices and processes associated with the same desktop; the target process is the process corresponding to any service running on any desktop; Based on the second tagging relationship between the preset device and the corresponding desktop device namespace, a third device namespace corresponding to the target device is determined; When the second device namespace and the third device namespace meet the preset conditions, the target process is allowed to access the target device.

8. The method according to claim 7, characterized in that, The preset conditions include: the relationship between the processes allowed to access the device and the device; when the second device namespace and the third device namespace satisfy the preset conditions, allowing the target process to access the target device includes: Based on the second device namespace and the third device namespace, the relationship between the target device and the target process is determined; When the relationship between the target device and the target process is determined to be any of the relationships included in the preset conditions, the target process is allowed to access the target device.

9. The method according to claim 7, characterized in that, If the second device namespace and the third device namespace do not meet the preset conditions, the method further includes: If the second device namespace is located in the access set corresponding to the target device, then the target process is allowed to access the target device. The access set corresponding to the target device includes the device namespaces corresponding to processes that are allowed to access the target device.

10. The method according to claim 7, characterized in that, If the target device is a character device, then after allowing the target process to access the target device, the following steps are also included: After the target device is started, a fourth device namespace corresponding to the target device is determined based on the second tagging relationship; Based on whether the second device namespace and the fourth device namespace meet preset conditions, determine whether to shut down the target device.

11. The method according to claim 10, characterized in that, Before the target device is started, the method further includes: Upon receiving an instruction to start the target device, and determining that the target device is a character device, a matching identifier corresponding to the start operation is generated; the matching identifier is used to identify the verification of the device namespace corresponding to the target device during the start-up process of the target device; After the target device is started, before determining the fourth device namespace corresponding to the target device based on the second tagging relationship, the method further includes: A matching identifier corresponding to the startup operation of the target device was detected.

12. The method according to any one of claims 7 to 11, characterized in that, The method further includes: When a new device inserter is detected, and it is determined that the new device belongs to a non-root node device based on the attribute information of the new device, the root node device corresponding to the new device is determined, and the new device is marked to the device namespace corresponding to the root node device.

13. A device access device, characterized in that, The device includes: The first tagging unit is used to create a device set corresponding to the first desktop and tag the first device in the device set to the first device namespace, wherein the first desktop corresponds to the first device namespace; The second marking unit is used to determine the first process corresponding to the first desktop and mark the first process to the device namespace; so that when the first process accesses the first device, if the device namespace corresponding to the first process and the first device namespace corresponding to the first device meet the preset conditions, the first process is allowed to access the first device.

14. A device access device, characterized in that, The device includes: The first determining unit is configured to, in response to an access operation of a target process to a target device, determine a second device namespace corresponding to the target process based on a preset first tagging relationship between the process and the device namespace of the corresponding desktop; the device namespace is: the namespace of devices and processes associated with the same desktop; the target process is: the process corresponding to any service running on any desktop; The second determining unit is used to determine the third device namespace corresponding to the target device based on a preset second tagging relationship between the device namespace of the device and the corresponding desktop. The access unit is used to allow the target process to access the target device when the second device namespace and the third device namespace meet preset conditions.

15. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the device access method as described in any one of claims 1 to 12.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the device access method as described in any one of claims 1 to 12.

Images