Android cloud phone device isolation method and device based on process namespace

Abstract

This application discloses a method and apparatus for isolating Android cloud mobile phone devices based on process namespaces. The method includes: adding a home namespace field to device objects in the Linux kernel, and controlling the visibility scope of the device objects at multiple levels based on the value of the home namespace field; responding to a system directory traversal request, outputting matching directory entries based on the matching result of the process namespace of the current process and the home namespace field of the device object; responding to a system file access request, executing a matching access request based on the matching result of the process namespace of the current process and the home namespace field of the device object to which the system file belongs; and responding to a device event sending request, sending the device event to the corresponding process namespace based on the home namespace field of the device object. Through the above methods, this application can achieve fine-grained device isolation and dedicated namespace management.

Description

Technical Field

[0001] This application relates to the fields of cloud computing and virtualization, and in particular to an Android cloud mobile device isolation method and apparatus based on process namespaces. Background Technology

[0002] With the rapid development of mobile internet, Android cloud phones, as an emerging cloud service model, are widely used in scenarios such as game testing, application testing, mobile office, and data security. Android cloud phones run a complete Android operating system in the cloud, allowing users to remotely access and use cloud phone instances through various terminal devices (such as mobile phones, tablets, and PCs). To improve resource utilization, the industry commonly uses container technology (such as Docker or LXC) to achieve basic isolation between multiple cloud phone instances running on the same physical machine.

[0003] However, existing Android cloud phone technologies still have limitations in terms of multi-instance isolation and device access control. In traditional container architectures, multiple cloud phone instances on the same host machine can often see the host machine's global device view. This sharing of device information not only makes it easy for cloud phone instances to identify each other's device fingerprints or expose physical machine characteristics, but also exposes sensitive data such as device topology and driver information to leakage risks, increasing the difficulty of security isolation.

[0004] Furthermore, existing device-related file access control and event notification mechanisms are often ill-suited to the isolation requirements of containerization, and cannot flexibly implement isolation policies that are visible only to specific instances. While virtual machine-based solutions can provide strong isolation, they suffer from high resource overhead, significant performance degradation, and slow startup. Summary of the Invention

[0005] This application provides a method and apparatus for isolating Android cloud mobile devices based on process namespaces, in order to solve the technical problems of imperfect device visibility control and coarse isolation granularity in existing isolation methods.

[0006] To address the aforementioned technical problems, this application adopts the following technical solution: providing a method for isolating Android cloud mobile devices based on process namespaces. This method includes: Add a home namespace field to device objects in the Linux kernel, and control the visibility scope of the device objects at multiple levels based on the value of the home namespace field; In response to a system directory traversal request, the matching directory entries are output based on the matching result between the process namespace of the current process and the home namespace field of the device object; In response to a system file access request, the matching access request is executed based on the matching result between the process namespace of the current process and the home namespace field of the device object to which the system file belongs; In response to a device event sending request, the device event is sent to the corresponding process namespace based on the home namespace field of the device object.

[0007] In an optional embodiment of this application, the multi-level control of the visibility range of the device object based on the value of the home namespace field includes: If the namespace field is empty, the device object belongs to the initial process namespace, and the device object is visible in all process namespaces. If the home namespace field points to the initial process namespace, then the device object is made visible in all process namespaces; If the home namespace field points to a specific process namespace, then the device object is controlled to be visible only in that specific process namespace.

[0008] In an optional embodiment of this application, the step of outputting the matched directory entries based on the matching result between the process namespace of the current process and the home namespace field of the device object includes: Get the process namespace to which the current process belongs, and traverse the directory entries under the system directory; If the directory entry is a device directory entry, then obtain the device object corresponding to the directory entry; If the process namespace of the current process matches the namespace field of the device object, then the directory entry is output; If the process namespace to which the current process belongs does not match the namespace field of the device object, then the directory entry is filtered.

[0009] In an optional embodiment of this application, executing a matching access request based on the matching result between the process namespace of the current process and the home namespace field of the device object to which the system file belongs includes: Obtain the directory entries of the system files and the process namespace to which the process that initiated the access request belongs; If the system file is a device-related file, then obtain the device object corresponding to the system file; If the process namespace of the current process matches the namespace field of the device object, then the access request is executed; If the process namespace to which the current process belongs does not match the namespace field of the device object, an error code is returned to the process that initiated the access request, and the access request is rejected.

[0010] In an optional embodiment of this application, sending the device event to the corresponding process namespace based on the home namespace field of the device object includes: Retrieve the namespace field of the device object corresponding to the device event; If the home namespace field points to the specific process namespace, then the device event will only be sent to the specific process namespace; If the home namespace field is empty or points to the initial process namespace, the device event is broadcast to all process namespaces.

[0011] In one optional embodiment of this application, the method further includes: In response to a container creation request, device resources are allocated to the container, and a device object corresponding to the device resources is constructed. Set the namespace field of the device object to the namespace of the process to which the container belongs; Call the kernel interface to register the constructed device object into the kernel.

[0012] In one optional embodiment of this application, the method further includes: In response to a container destruction request, iterate through all the device objects of the container; For each of the device objects, the kernel interface is invoked to unregister the device object in the kernel; Release the reference count and memory resources occupied by the home namespace field in the device object, and clear the home namespace field.

[0013] To address the aforementioned technical problems, another technical solution adopted in this application is: providing an Android cloud mobile device isolation device based on process namespaces, comprising: The field addition module is used to add a home namespace field to device objects in the Linux kernel, and to control the visibility scope of the device object at multiple levels based on the value of the home namespace field; The directory traversal module is used to respond to system directory traversal requests and output the matched directory entries based on the matching result of the process namespace of the current process and the home namespace field of the device object. The file access module is used to respond to system file access requests by executing a matching access request based on the matching result between the process namespace of the current process and the home namespace field of the device object to which the system file belongs. The event sending module is used to respond to a device event sending request and send the device event to the corresponding process namespace based on the home namespace field of the device object.

[0014] To solve the above-mentioned technical problems, another technical solution adopted in this application is: to provide a computer device, characterized in that the computer device includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor invokes the instructions in the memory to cause the computer device to execute the Android cloud phone device isolation method based on process namespaces as described above.

[0015] To solve the above-mentioned technical problems, another technical solution adopted in this application is: to provide a computer-readable storage medium, wherein instructions are stored on the computer-readable storage medium, characterized in that, when the instructions are executed by a processor, they implement the above-described method for isolating Android cloud mobile phone devices based on process namespaces.

[0016] The beneficial effects of this application are as follows: Unlike existing technologies, this application discloses a method and apparatus for isolating Android cloud mobile devices based on process namespaces. This method adds a home namespace field to device objects in the Linux kernel and controls their visibility at multiple levels. Then, based on the matching result between the current process's process namespace and the home namespace field, it filters and controls system directory traversal, system file access, and the sending of device events. While maintaining the lightweight and high-performance advantages of container technology, it avoids information leakage security issues and achieves fine-grained device isolation and dedicated namespace management. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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, wherein: Figure 1 This is a flowchart illustrating an embodiment of the Android cloud mobile device isolation method based on process namespaces provided in this application; Figure 2 This is a schematic diagram of an embodiment of the Android cloud mobile device isolation device based on process namespace provided in this application; Figure 3 This is a schematic diagram of the structure of an embodiment of the storage medium provided in this application; Figure 4 This is a schematic diagram of the structure of an embodiment of the computer device provided in this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0019] The terms "first," "second," and "third" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0020] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0021] This application provides a method for isolating Android cloud mobile devices based on process namespaces. (See attached document.) Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the Android cloud mobile device isolation method based on process namespaces provided in this application. The Android cloud mobile device isolation method based on process namespaces includes: S10: Adds a home namespace field to device objects in the Linux kernel and controls the visibility of device objects at multiple levels based on the value of the home namespace field.

[0022] In this optional embodiment, in order to solve the isolation defects caused by the global visibility of traditional kernel devices, the core data structure of the Linux kernel is first extended to assign ownership to the device object, that is, to explicitly indicate the process namespace to which the device object belongs.

[0023] In the Linux kernel source code, device objects are described using the `struct device` structure. This embodiment introduces a pointer field named "Own Namespace" into this structure to specify the process namespace to which the device belongs. This field stores a memory address pointing to an active process namespace object in the kernel.

[0024] The semantic definition of the "Owner Namespace" field: The "Owner Namespace" field means "device owner namespace". When this pointer is assigned to the address of a namespace, it means that the device belongs to a user within that namespace. This pointer is not just an ID, but also a reference directly pointing to an active namespace object in the kernel. This allows subsequent matching checks to be performed directly through pointer comparison, which is extremely efficient.

[0025] Initialization state of the home namespace field: When the device object is first allocated memory, the home namespace field is initialized to NULL (null pointer), that is, the home namespace field has an empty value, which preserves backward compatibility, that is, by default the device belongs to the traditional global device.

[0026] Since the home namespace field is added to the appropriate position in the structure (e.g., after the standard fields) and only adds a pointer length of memory space, it does not break existing kernel binary interface compatibility or significantly increase memory overhead, which is crucial for servers running hundreds or thousands of cloud phone instances.

[0027] In this optional embodiment, a set of determination logic based on the value of the attribution namespace field is constructed. After adding the attribution namespace field, multi-level control of the visibility scope of the device object can be achieved. This determination logic receives the device object and the process namespace of the current requester as input, and returns a boolean value indicating whether it is visible.

[0028] In an optional embodiment, step S10 above further includes: S11: If the namespace field is empty, the device object belongs to the initial process namespace and the device object is visible in all process namespaces.

[0029] S12: If the home namespace field points to the initial process namespace, then the control device object is visible in all process namespaces.

[0030] S13: If the home namespace field points to a specific process namespace, then the control device object is only visible within that specific process namespace.

[0031] In this optional embodiment, a three-level visibility scope control strategy is defined. When it is necessary to determine whether a device is visible to the current process, a reference to the target device object is first obtained, and a reference to the process namespace to which the process that initiated the request belongs is obtained. Then, the value of the namespace field in the device object is read, and the multi-level control strategy judgment process is entered.

[0032] Level 1 control strategy: Global visibility (default mode), which means that when the field belonging to the namespace is null, the above step S11 is executed.

[0033] Global visibility is the default state for kernel devices. When a physical device is started or registered by a kernel driver, its home namespace field is usually NULL. When the home namespace field is NULL, it means that the device belongs to the initial process namespace and is visible in all namespaces, ensuring normal access to the system's underlying physical devices and backward compatibility.

[0034] Second-level control strategy: Global visibility (explicit marking), that is, when the namespace field of the origin points to the namespace of the initial process, the above step S12 is executed.

[0035] The Linux kernel has a special global variable called "initial process namespace," which represents the host machine's root namespace. When creating certain virtual devices, system administrators or specific kernel modules may explicitly set the home namespace field to point to the initial process namespace. In this case, the device object is visible in all process namespaces.

[0036] While the logical result is the same as Level 1 (globally visible), its semantics differ. Level 2 control policies are typically used to mark shared devices that, although virtually created, are intended to be exposed to all instances (including the host and all containers). For example, for performance reasons, an administrator might want all containers to share access to a specific virtual cryptographic accelerator. By explicitly setting it to the initial namespace, the code logic is clearer, indicating that this is an intentional global sharing, rather than the default behavior.

[0037] The third level of control strategy is dedicated isolation (isolation mode), which means that when the owner namespace field points to a specific process namespace (i.e., a pointer that is not NULL and is not the initial namespace pointer), the above step S13 is executed.

[0038] When a device is created (e.g., a virtual camera for container A), the kernel assigns the address of the process namespace pointer corresponding to container A to the home namespace field. At this point, the device object is only visible within the specific process namespace (the process namespace corresponding to container A). For any other mismatched process namespace, the device is considered "non-existent".

[0039] The third-level control strategy achieves hardware exclusivity. In the Android cloud phone scenario, this means that each cloud phone instance can believe that it has exclusive access to a GPU, an audio device, or a sensor, and cannot see the devices of other instances, thus achieving perfect device fingerprint isolation.

[0040] Unlike existing technologies where multiple cloud phone instances can see all device-related files on the host machine and lack flexible visibility strategies, this embodiment establishes an isolation mechanism at the kernel data structure level by adding an ownership namespace field to the Linux kernel device object and implementing multi-level control based on the field value. This provides a reliable basis for subsequent directory filtering, file access interception, and event filtering. This solution is implemented by adding a pointer field and simple comparison operations, avoiding complex interception in user space and resulting in extremely low performance loss. By utilizing the native Linux process namespace mechanism to map device ownership to the process namespace, the device view and process view within the container are naturally consistent. Combined with the "three-level control" strategy, this solution balances the global visibility of physical devices with the dedicated isolation of container devices, and can be seamlessly integrated into existing cloud platforms without modifying the physical device driver.

[0041] S20: In response to a system directory traversal request, output the matching directory entries based on the matching results of the process namespace of the current process and the home namespace field of the device object.

[0042] In this optional embodiment, by dynamically and transparently filtering out device directory entries that do not belong to the current process's namespace on the critical paths of system directory traversal, devices that do not belong to the container are not visible from the user space perspective. In this embodiment, the system directory refers to the Sysfs directory.

[0043] In an optional embodiment, step S20 above further includes: S21: Get the process namespace of the current process and traverse the directory entries under the system directory.

[0044] When a directory traversal request is initiated from user space, step S21 is executed. For example, a process inside the container (assuming it is the SystemUI process of Android cloud phone instance A) needs to enumerate the currently available camera devices, so it calls the standard library functions opendir and readdir to open and read the / sys / class / video4linux directory.

[0045] In this optional embodiment, when processing a Sysfs directory read request, the context is first obtained so that the kernel can determine which process namespace the process that initiated the request belongs to.

[0046] After obtaining the process namespace of the current process, the kernel begins to traverse all entries in the target directory. The specific traversal process is as follows: Locating the parent directory node: The kernel resolves the target directory's inode (Inode) and corresponding directory entry structure (Dentry) in the kernel based on the file path.

[0047] Accessing child nodes in a linked list: Sysfs' directory structure is typically organized in the kernel using linked lists or tree structures. The kernel uses the parent directory structure to find the head of the linked list containing all its child items.

[0048] Looping Traversal: The kernel initiates a traversal loop, visiting each node in the linked list in turn. Each node represents a directory entry (sysfs_dirent). For example, for the camera directory, the nodes in the linked list might represent video0, video1, etc.

[0049] Cache space preparation: The kernel prepares a buffer to store the returned data, which is used to store directory entry information that will be returned to the user process.

[0050] S22: If the directory entry is a device directory entry, then obtain the device object corresponding to the directory entry.

[0051] During the traversal of the linked list, not all directory entries need to be isolated. Sysfs contains not only device directory entries but also non-device directory entries such as property files and subdirectories. However, the isolation logic only applies to device directory entries. Therefore, logic is added to determine whether the currently traversed directory entry is a device directory entry.

[0052] For each directory entry encountered, the kernel first checks its type flag. By calling a helper function, the kernel determines whether the directory entry represents a device object. If the directory entry is a regular attribute file (such as video0 / name), it is determined to be a non-device directory entry; if the directory entry is a device directory (such as video0), it is determined to be a device directory entry.

[0053] If it is determined to be a device directory entry, the kernel further obtains the device pointer from the s_dev field (device management field) of the directory entry, which directly points to the device object defined in step S10.

[0054] To prevent device objects from being unregistered by other threads during concurrent access, the kernel typically performs a brief read lock on the device object using RCU (Read-Copy-Update) or a spinlock the moment the pointer is acquired, ensuring the validity of the device object during this check.

[0055] This step maps abstract directory entries to device objects with ownership information. This mapping process provides a solid foundation for subsequent device visibility checks, ensuring that only devices visible within a specific process namespace are processed further.

[0056] S23: If the process namespace of the current process matches the namespace field of the device object, output the directory entry.

[0057] For the device directory entry determined in step S22, its owner namespace field is matched with the process namespace of the current process to determine whether to perform output or filtering for that device directory entry. The matching logic is as follows: The kernel calls the function corresponding to the visibility determination logic, passing in two parameters: the target device object and the current process namespace. Internally, this function performs the following checks: (1) Global Visibility Check: Check if the device object's home namespace field is NULL (empty value), and check if the device object's home namespace field points to the initial process namespace. If either of the above conditions is met, it means that the device object is a globally shared device or a host core device. If the matching result is "match", the kernel determines that the current process has permission to view the device directory entry, and then outputs the device directory entry.

[0058] (2) Exclusive Isolation Check: If the device object is not of a globally visible type, the kernel continues to check if the value of the process namespace to which the current process belongs is the same as the value of the namespace field belonging to the device object. If the memory addresses of the two pointers are exactly the same, it means that the device object is exclusive to the container where the current process resides. If the matching result is "match", the kernel determines that the current process has permission to view the device directory entry.

[0059] If the process namespace of the current process matches the namespace field of the device object, the directory entry is output. Specifically, the kernel calls the standard directory entry filling function (similar to the filldir operation in the kernel). This function copies information about the current directory entry (such as the filename "video0", inode number, file type, etc.) to a pre-prepared kernel buffer. Simultaneously, the kernel increments the number of bytes copied to ultimately inform user space how much data was successfully read.

[0060] After processing the directory entry, the kernel continues traversing the linked list to process the next directory entry. Finally, when the system call returns to user space, the user process (such as an Android application) will see the device directory in its list of read files. At this point, the device appears to the user as if it exists normally.

[0061] S24: If the process namespace of the current process does not match the namespace field of the device object, then filter the directory entries.

[0062] If the global visibility check and the dedicated isolation check find that the device object is neither a global device nor belongs to the current namespace (i.e., the matching result is "no match"), the kernel determines that the current process does not have permission to view the device directory entry.

[0063] If the process namespace of the current process does not match the namespace field of the device object, the directory entry is filtered. Specifically, padding is skipped; the kernel does not call the function to fill the buffer but ignores the directory entry and does not write any information about it to the return buffer. In the traversal loop, the kernel directly executes the jump instruction, moves to the next node in the linked list, without producing any side effects or returning any error information to user space. Since no data is written to the buffer, the user process is completely unaware of the existence of this directory entry.

[0064] When the system call returns, the device directory entry is not present in the user process's file list. Regardless of whether the user knows its specific path, the device cannot be discovered using standard directory traversal methods, achieving perfect isolation.

[0065] The precise request interception, context extraction, object mapping, and namespace-based matching filtering achieved through step S2 successfully hide irrelevant devices at the system directory level, providing a clean and independent device view environment for Android cloud phones and building a strong security barrier. This method ensures that each container can only see its own dedicated devices through dynamic filtering, effectively cutting off side-channel attack paths that infer host load, hardware configuration, or the presence of other tenants based on device list enumeration. The filtering process is entirely performed in kernel space, transparent to user-space applications, requiring no modification to any application code or calls to special APIs. Existing Android systems and Linux scripts can directly obtain the filtered results through standard interfaces, achieving seamless operation. Although additional judgments are introduced in the traversal logic, the performance loss is extremely low due to the involvement of only simple pointer reads and comparison operations, fully meeting the real-time requirements of high-concurrency cloud phone scenarios.

[0066] S30: In response to a system file access request, execute the matching access request based on the matching result of the process namespace of the current process and the home namespace field of the device object to which the system file belongs.

[0067] In this optional embodiment, interception is performed at the file access control level to ensure that even if an attacker guesses the path correctly, if the device corresponding to the Sysfs file does not belong to the namespace of the current process, the kernel will completely cut off the path of information leakage at the content level by denying access.

[0068] In an optional embodiment, step S30 above further includes: S31: Obtain the directory entry of the system file and the process namespace of the process that initiated the access request.

[0069] Upon entering the file open or read handler function, the kernel first needs to extract context information to determine the process namespace to which the process initiating the access request belongs. Specifically, the kernel obtains the task structure of the currently running process and further extracts the process namespace to which the process belongs from the namespace proxy field of the task structure.

[0070] At different stages of file operations (including opening and reading files), the kernel uses pre-defined associated pointers in kernel data structures to precisely locate the underlying device management object associated with the file. Specifically, this can be done as follows: For a file open request, the kernel obtains the inode structure passed to the system call and uses the private data pointer stored in the inode to locate the corresponding Sysfs directory entry. For a file read request, the kernel obtains the associated directory entry through the structure of the already opened file, and then uses the associated pointer stored in the directory entry to locate the underlying Sysfs directory entry.

[0071] Through the above process, the kernel obtains the internal representation object of the currently accessed file, namely the Sysfs directory entry, so that the kernel can find the real device object it points to from the Sysfs directory entry.

[0072] S32: If the system file is a device-related file, then obtain the device object corresponding to the system file.

[0073] The sysfs directory contains a large number of property files (such as power and uevent), symbolic links, and ordinary directories. The isolation logic in this embodiment only applies to files related to the device model, namely the "device directory" or "device property files," hereinafter collectively referred to as device-related files. The identification process for device-related files is as follows: Checking device pointers: The kernel checks the Sysfs directory entry obtained in step S31. This directory entry has a field s_dev (device association field) used to reverse link to the core device object in the kernel device model. The value of this field is used to determine whether the system file is a device file.

[0074] If the device association field is empty (NULL), it means that the file is just a regular directory or a non-device-related attribute file. For such files, the kernel skips the subsequent isolation checks and processes them according to the standard Linux file system logic, ensuring the normal operation of basic system functions.

[0075] If the device association field is not empty, it means that the file belongs to a certain device object (which may be the device directory itself or the property file under the device), and is therefore determined to be a device-related file.

[0076] When the file is determined to be a device-related file, the kernel reads the value of the device association field to obtain the corresponding device object and determine the namespace field to which the device object belongs.

[0077] S33: If the process namespace of the current process matches the namespace field of the device object, then execute the access request.

[0078] After obtaining the process namespace of the current process that initiated the access request and the home namespace field of the device object through the above steps S31 and S32, the kernel matches the process namespace of the current process with the home namespace field of the device object to determine the matching result.

[0079] Specifically, the kernel calls the visibility logic judgment function defined in step S10, passing the attribution namespace field and the process namespace as parameters. This function internally performs the following judgment: Global Device Check: Checks if the device object's home namespace field is NULL or points to the initial namespace. If so, the match result is determined as "match" (i.e., access is allowed).

[0080] Dedicated device check: Checks if the namespace field of the device object is equal to the process namespace of the current process. If the match result is "match" (i.e., access is allowed).

[0081] In scenarios where access is permitted, the kernel will execute different operation processes based on the two phases of file opening and file reading.

[0082] (1) File opening stage: When the matching result is "match," it means that the current process has permission to access the relevant files on that device. At this point, the kernel invokes the standard general file open processing logic. The kernel allocates a file descriptor for the process and establishes a connection between the process and the file. The application successfully obtains a file handle and can perform subsequent read and write operations.

[0083] (2) Data reading stage: When the matching result is "match", it means that the current process has the right to read the files related to the device. At this time, the kernel calls the standard file reading processing logic of sysfs to copy the attribute data generated by the kernel device object into the user space buffer, and the application successfully reads the detailed information of the device (such as device vendor ID, hardware version, etc.).

[0084] S34: If the process namespace of the current process does not match the namespace field of the device object, return an error code to the process that initiated the access request and reject the access request.

[0085] If the global visibility check and the dedicated isolation check find that the device object is neither a global device nor belongs to the current namespace (i.e., the matching result is "no match"), the kernel determines that the current process does not have permission to view the files related to that device.

[0086] In scenarios where access is not permitted, it is necessary to ensure that users are unaware of the existence of files related to the device. The kernel will execute different operation processes based on the two stages of file opening and file reading.

[0087] (1) Rejection during the file opening phase: The kernel does not perform the standard open operation, but directly returns a specific error code, such as -ENODEV (Error No Device).

[0088] Technical meaning: In the Linux system specification, -ENODEV is typically used to indicate that the requested device does not exist or the driver is not loaded. For user-space applications, this means that the device does not exist at that path, or that the device is unavailable in the current system.

[0089] Security Analysis: If the kernel returns "Permission Denied" (-EACCES or -EPERM), an attacker can infer that the device exists but is denied access, thus exposing the device's existence. Returning -ENODEV, however, perfectly hides the device's existence, making the attacker believe their assumption is incorrect.

[0090] (2) Rejection during file read phase: Even if a file is accidentally opened under some very special circumstances, the kernel will still check it when reading data. Once a mismatch is found, the read function immediately stops data transmission and returns the -ENODEV error code.

[0091] Through the above step S30, namespace-based verification logic is implanted in the file opening and reading paths and deceptive error codes are returned, successfully achieving device isolation at the file access level and ensuring the absolute security of the Android cloud phone instance. This mechanism can not only defend against brute-force path detection based on hardware fingerprint databases and ensure that opening calls of unrelated devices return "device does not exist", but also perform verification again during reading to block information leakage caused by historical handles. At the same time, by returning the standard -ENODEV error code, it creates the illusion that the device does not exist, effectively increasing the analysis cost for attackers.

[0092] S40: In response to a device event sending request, the device event is sent to the corresponding process namespace based on the device object's home namespace field.

[0093] In a dynamically running Android cloud phone system, the insertion, removal, and attribute changes of a device (such as disconnecting the network interface or hot-plugging a USB device) will trigger the kernel to send a "Uevent" (user space event) message to the user space, hereinafter referred to as a device event.

[0094] In this optional embodiment, strict namespace filtering is implemented at the device event distribution level to ensure that device events, like device files, are only visible within their respective namespaces, thereby achieving full-process isolation of the device lifecycle.

[0095] In an optional embodiment, step S40 above further includes: S41: Get the namespace field of the device object corresponding to the device event.

[0096] When the device state changes, the kernel generates a device event notification. At this time, the kernel's device model core layer calls the modified event sending function of this optional embodiment and enters the distribution logic: first, based on the kernel object that triggered the event, the corresponding hardware device structure is found in reverse.

[0097] Specifically, in the Linux kernel, in order to access the home namespace field defined in step S10, the kernel must perform type casting and pointer acquisition. First, the kernel calculates the starting address containing the device object based on the passed-in changed kernel object; at the same time, to prevent the device object from being concurrently destroyed during event processing, the kernel may increment the reference count of the device object; finally, once the device object is successfully located, the kernel directly reads the home namespace field of the device object that triggered the event.

[0098] S42: If the home namespace field points to a specific process namespace, then device events will only be sent to that specific process namespace.

[0099] After obtaining the attribution namespace field, the kernel enters the distribution object determination logic to determine whether the device event's distribution mode is to be sent to a specific process namespace or broadcast to all process namespaces. The specific determination logic is as follows: The kernel checks the value of the "Original Namespace" field. If the "Original Namespace" field is not empty (NULL) and is not equal to the "Initial Process Namespace" (i.e., it points to a specific process namespace), then the device is a dedicated device belonging to a specific Android cloud phone container (e.g., container A). In this case, device events are only sent to the specific process namespace. Only udevd and the application within the container dedicated to this device can receive event notifications. The system inside this container can detect device insertion / removal or state changes and respond correctly (e.g., loading drivers, mounting directories), while other containers cannot detect this event.

[0100] S43: If the home namespace field is empty or points to the initial process namespace, then broadcast the device event to all process namespaces.

[0101] The kernel checks the value of the `Original Namespace` field. If the `Original Namespace` field is empty (indicating a physical device on the host machine or the default device) or equal to the `Initial Process Namespace` (indicating a device explicitly marked as globally visible), then the device is a globally shared device. In this case, the device event is broadcast to all process namespaces. Any process listening to this multicast group, regardless of its process namespace (host machine, container A, container B, etc.), will receive the message, maintaining the default behavior of the Linux system. For example, if a physical network cable is unplugged, all containers and the host machine should be aware of this and update their network status accordingly.

[0102] Furthermore, since the device's home namespace field is frequently read during event sending, to prevent race conditions (such as the container being suddenly destroyed during event sending, causing the home namespace field to be released), the kernel can use the RCU mechanism when accessing the home namespace field, or increment the device's reference count when obtaining the device pointer, to ensure that the target namespace object remains valid during event sending.

[0103] Through step S40 above, intelligent routing decisions based on the home namespace field are introduced into the device event sending path, successfully achieving namespace isolation of device events. This ensures global device broadcast compatibility while enabling targeted sending to dedicated devices. This mechanism ensures that containers only receive event streams from dedicated devices, effectively preventing anti-fraud systems from leaking dynamic information about the hardware environment by listening to device events. Furthermore, the targeted sending mechanism eliminates cross-container interference at its source, avoiding system errors or deadlocks caused by containers mistakenly mounting devices due to erroneous triggering. In addition, in high-density deployment scenarios, this mechanism avoids physical event broadcasting waking up all container daemons, ensuring that events are only sent to the target container, significantly reducing bus load and improving overall system throughput.

[0104] In one optional embodiment, in response to a container creation request, device resources are allocated to the container, and a device object corresponding to the device resources is constructed; Set the namespace field of the device object to the namespace of the process to which the container belongs; Call the kernel interface to register the constructed device object into the kernel.

[0105] In this optional embodiment, when the cloud phone management platform receives a request to create a new instance, the kernel not only needs to allocate underlying computing resources (such as CPU slices, memory blocks, and physical GPU channels), but also needs to construct the corresponding device object in the kernel and use the home namespace field defined in step S10 to bind these virtual hardware resources to a specific container, thereby activating the isolation mechanism of the above steps.

[0106] First, in response to the container creation request, the system performs resource allocation and object construction. The kernel calls the memory allocation function to request a memory space of the size of a struct device in the kernel heap and initializes it, thereby constructing the corresponding device object. During this process, the system assigns a unique name (such as "gpu0" or "video0") and a device number to the device and establishes a mapping relationship between them and the underlying allocated physical resources. At this point, the device object only exists in memory, has not yet been exposed to the system, and does not have any ownership attributes.

[0107] Next, the system performs the core ownership binding operation. The kernel extracts the pointer to the process namespace belonging to the current container from its task descriptor. The system directly assigns this pointer to the ownership namespace field of the device object, thus logically marking the device as "exclusively for this container." To prevent the namespace structure from being accidentally destroyed due to the premature exit of the container process, which could cause a kernel crash accessing a dangling pointer, the system synchronously calls a reference count increment function to increment the reference count of the target namespace by 1. This operation ensures that the namespace structure remains alive in memory as long as the device object exists.

[0108] Finally, the system calls the kernel device registration interface to formally register the constructed and bound device object into the system's global device model. The registration process automatically triggers the aforementioned isolation logic: when creating a directory in the Sysfs file system, the kernel checks the ownership namespace field according to the logic in step S20, automatically hiding the device's directory entry from other containers; when sending device events, according to the logic in step S40, notifications for that device are only directed to the dedicated container, thus completing the automatic creation of the device node within the container. Through this series of operations, the system successfully transforms a virtual hardware resource into an independent device instance controlled at the kernel level and isolated in user space.

[0109] In one alternative embodiment, in response to a container destruction request, all device objects of the container are traversed; For each device object, call the kernel interface to unregister the device object in the kernel; Release the reference count and memory resources occupied by the namespace field in the device object, and clear the namespace field.

[0110] In this optional embodiment, when the cloud phone instance is stopped or destroyed, all related kernel objects and resources are safely cleaned up to prevent memory leaks and resource exhaustion.

[0111] First, in response to the container destruction request, the system initiates the device traversal process. The kernel locates the device list header maintained in the container management structure. Since the traversal process requires deleting linked list nodes, the system must employ a safe traversal mechanism. This mechanism pre-caches a pointer to the next node while traversing the current node, allowing the current node to be safely removed within the processing loop without causing the linked list to break or the traversal pointer to become invalid.

[0112] For each device object encountered, the system calls the kernel deregistration interface to remove it from the system. This operation triggers a chain reaction of device deregistration: the kernel recursively deletes the directory and attribute files corresponding to the device from the Sysfs file system; sends a device event of type "device removal" (following the logic in step S40), notifying the daemon process in the container to delete the device node under the device directory; and disconnects the device from the underlying driver.

[0113] Finally, the system performs reference count release and memory cleanup. The kernel checks the owner namespace field of the device object; if it is not empty, it calls the reference count decrement function to reduce the reference count of the namespace. If all processes under this namespace have exited and there are no other references, the reference count will reach zero, and the kernel will then release the memory of the namespace structure, marking the complete end of the container's lifecycle.

[0114] For safety, the kernel immediately clears the namespace field (sets it to NULL) after releasing the reference to prevent subsequent code from accidentally accessing the released memory. Finally, the kernel calls the memory release function to return the memory space occupied by the device object, ensuring zero leakage and high stability of the host kernel resources in scenarios where cloud phones are frequently created and destroyed.

[0115] Through the container creation and destruction process described above, the device isolation mechanism is dynamically deployed and securely reclaimed throughout the container lifecycle. During the creation phase, automatic namespace binding and reference counting management ensure real-time isolation of the container's dedicated device and the lifecycle security of namespace objects. During the destruction phase, a rigorous traversal cleanup and resource release mechanism effectively prevents memory leaks and kernel resource exhaustion in high-frequency creation and destruction scenarios, guaranteeing the long-term operational stability of the host machine in high-density cloud phone deployment environments.

[0116] This application establishes a device ownership mechanism at the kernel data structure level and embeds namespace-based verification logic into the three core paths of system directory traversal, file access and opening, and event notification distribution. This implementation constructs a three-dimensional and unbypassable kernel-level isolation barrier. It fundamentally cuts off side-channel information leakage paths based on device enumeration, attribute reading, and event listening, ensuring complete isolation of device fingerprints between containers. Simultaneously, since all filtering logic runs transparently at the kernel level, user-space applications can obtain an independent and pure device view without any modification, maintaining the high-performance characteristics of the native kernel mechanism while achieving strong security isolation.

[0117] This application provides an Android cloud mobile device isolation device based on process namespaces, see reference. Figure 2 , Figure 2 This is a schematic diagram of an embodiment of the Android cloud mobile device isolation device based on process namespaces provided in this application. The Android cloud mobile device isolation device based on process namespaces includes: The field addition module 10 is used to add a home namespace field to device objects in the Linux kernel, and to control the visibility scope of the device object at multiple levels based on the value of the home namespace field; Directory traversal module 20 is used to respond to system directory traversal requests and output matching directory entries based on the matching result of the process namespace of the current process and the home namespace field of the device object; The file access module 30 is used to respond to a system file access request by executing a matching access request based on the matching result between the process namespace of the current process and the home namespace field of the device object to which the system file belongs. The event sending module 40 is used to respond to a device event sending request and send the device event to the corresponding process namespace based on the home namespace field of the device object.

[0118] In an optional embodiment, the field adding module 10 is specifically used for: If the namespace field is empty, the device object belongs to the initial process namespace, and the device object is visible in all process namespaces. If the home namespace field points to the initial process namespace, then the device object is made visible in all process namespaces; If the home namespace field points to a specific process namespace, then the device object is controlled to be visible only in that specific process namespace.

[0119] In an optional embodiment, the directory traversal module 20 is specifically used for: Get the process namespace to which the current process belongs, and traverse the directory entries under the system directory; If the directory entry is a device directory entry, then obtain the device object corresponding to the directory entry; If the process namespace of the current process matches the namespace field of the device object, then the directory entry is output; If the process namespace to which the current process belongs does not match the namespace field of the device object, then the directory entry is filtered.

[0120] In an optional embodiment, the file access module 30 is specifically used for: Obtain the directory entries of the system files and the process namespace to which the process that initiated the access request belongs; If the system file is a device-related file, then obtain the device object corresponding to the system file; If the process namespace of the current process matches the namespace field of the device object, then the access request is executed; If the process namespace to which the current process belongs does not match the namespace field of the device object, an error code is returned to the process that initiated the access request, and the access request is rejected.

[0121] In an optional embodiment, the event sending module 40 is specifically used for: Retrieve the namespace field of the device object corresponding to the device event; If the home namespace field points to the specific process namespace, then the device event will only be sent to the specific process namespace; If the home namespace field is empty or points to the initial process namespace, the device event is broadcast to all process namespaces.

[0122] In an alternative embodiment, it further includes: In response to a container creation request, device resources are allocated to the container, and a device object corresponding to the device resources is constructed. Set the namespace field of the device object to the namespace of the process to which the container belongs; Call the kernel interface to register the constructed device object into the kernel.

[0123] In an alternative embodiment, it further includes: In response to a container destruction request, iterate through all the device objects of the container; For each of the device objects, the kernel interface is invoked to unregister the device object in the kernel; Release the reference count and memory resources occupied by the home namespace field in the device object, and clear the home namespace field.

[0124] See Figure 3 , Figure 3 This is a schematic diagram of the structure of an embodiment of the storage medium provided in this application.

[0125] The storage medium 300 stores program data 310, which, when executed by the processor, implements, as follows: Figure 1 The steps of the Android cloud mobile device isolation method based on process namespaces are described.

[0126] The program data 310 is stored in a storage medium 300 and includes several instructions for causing a network device (which may be a router, personal computer, server, or other network device) or processor to execute all or part of the steps of the methods described in the various embodiments of this application.

[0127] Optionally, the storage medium 300 can be any medium capable of storing program data, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), disk, or optical disc.

[0128] See Figure 4 , Figure 4 This is a schematic diagram of the structure of an embodiment of the computer device provided in this application.

[0129] The device 400 includes a processor 420 and a memory 410 connected to each other. The memory 410 stores a computer program. When the processor 420 executes the computer program, it implements the steps of the Android cloud phone device isolation method based on process namespaces as described above.

[0130] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the storage medium embodiments and computer device embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0131] This application can be used in a wide range of general-purpose or special-purpose computing system environments or configurations. For example: personal computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, network PCs, minicomputers, distributed computing environments including any of the above systems or devices, etc.

[0132] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device embodiments described above are merely illustrative; multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed.

[0133] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0134] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0135] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for isolating Android cloud mobile devices based on process namespaces, characterized in that, include: Add a home namespace field to device objects in the Linux kernel, and control the visibility scope of the device objects at multiple levels based on the value of the home namespace field; In response to a system directory traversal request, the matching directory entries are output based on the matching result between the process namespace of the current process and the home namespace field of the device object; In response to a system file access request, the matching access request is executed based on the matching result between the process namespace of the current process and the home namespace field of the device object to which the system file belongs; In response to a device event sending request, the device event is sent to the corresponding process namespace based on the home namespace field of the device object.

2. The Android cloud mobile device isolation method based on process namespaces according to claim 1, characterized in that, The multi-level control of the visibility scope of the device object based on the value of the attribution namespace field includes: If the namespace field is empty, the device object belongs to the initial process namespace, and the device object is visible in all process namespaces. If the home namespace field points to the initial process namespace, then the device object is made visible in all process namespaces; If the home namespace field points to a specific process namespace, then the device object is controlled to be visible only in that specific process namespace.

3. The Android cloud mobile device isolation method based on process namespaces according to claim 1, characterized in that, The matching result between the process namespace of the current process and the home namespace field of the device object outputs the matched directory entries, including: Get the process namespace to which the current process belongs, and traverse the directory entries under the system directory; If the directory entry is a device directory entry, then obtain the device object corresponding to the directory entry; If the process namespace of the current process matches the namespace field of the device object, then the directory entry is output; If the process namespace to which the current process belongs does not match the namespace field of the device object, then the directory entry is filtered.

4. The Android cloud mobile device isolation method based on process namespaces according to claim 1, characterized in that, Based on the matching result between the process namespace of the current process and the home namespace field of the device object to which the system file belongs, the matching access request is executed, including: Obtain the directory entries of the system files and the process namespace to which the process that initiated the access request belongs; If the system file is a device-related file, then obtain the device object corresponding to the system file; If the process namespace of the current process matches the namespace field of the device object, then the access request is executed; If the process namespace to which the current process belongs does not match the namespace field of the device object, an error code is returned to the process that initiated the access request, and the access request is rejected.

5. The Android cloud mobile device isolation method based on process namespaces according to claim 2, characterized in that, The step of sending the device event to the corresponding process namespace based on the home namespace field of the device object includes: Retrieve the namespace field of the device object corresponding to the device event; If the home namespace field points to the specific process namespace, then the device event will only be sent to the specific process namespace; If the home namespace field is empty or points to the initial process namespace, the device event is broadcast to all process namespaces.

6. The process namespace based Android cloud phone device isolation method of claim 1, wherein, Also includes: In response to a container creation request, device resources are allocated to the container, and a device object corresponding to the device resources is constructed. Set the namespace field of the device object to the namespace of the process to which the container belongs; Call the kernel interface to register the constructed device object into the kernel.

7. The process namespace based Android cloud phone device isolation method according to claim 6, wherein, Also includes: In response to a container destruction request, iterate through all the device objects of the container; For each of the device objects, the kernel interface is invoked to unregister the device object in the kernel; Release the reference count and memory resources occupied by the home namespace field in the device object, and clear the home namespace field.

8. An Android cloud mobile device isolation device based on process namespaces, characterized in that, include: The field addition module is used to add a home namespace field to device objects in the Linux kernel, and to control the visibility scope of the device object at multiple levels based on the value of the home namespace field; The directory traversal module is used to respond to system directory traversal requests and output the matched directory entries based on the matching result of the process namespace of the current process and the home namespace field of the device object. The file access module is used to respond to system file access requests by executing a matching access request based on the matching result between the process namespace of the current process and the home namespace field of the device object to which the system file belongs. The event sending module is used to respond to a device event sending request and send the device event to the corresponding process namespace based on the home namespace field of the device object.

9. A computer device, characterized in that, The computer device includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor invokes the instructions in the memory to cause the computer device to execute the Android cloud phone device isolation method based on process namespaces as described in any one of claims 1-7.

10. A computer-readable storage medium having stored thereon instructions, the instructions comprising, When the instruction is executed by the processor, it implements the Android cloud mobile device isolation method based on process namespace as described in any one of claims 1-7.

Images