Device access method and system for secure container

Abstract

The present disclosure relates to a method and system for device access of a secure container. A first communication module is created in the secure container; a second communication module is created on a server where the secure container is located for communication with the first communication module. A second device node corresponding to the secure container is created on the server, and at least part of hardware resources of a physical device is allocated to the second device node. A first device node corresponding to the at least part of hardware resources is created in the secure container, and access operation information of an application program in the secure container for the first device node is transmitted to the second device node via the first communication module and the second communication module. Thus, the secure container has isolation while being able to invoke hardware resources of the physical device, so as to ensure that hardware access in different secure containers does not affect each other.

Description

Technical Field

[0001] This disclosure relates to the field of container technology, and in particular to a device access method and system for secure containers. Background Technology

[0002] Container technology is a technology that packages software into standardized units for development, delivery, and deployment.

[0003] Container technology ensures the consistency of the application runtime environment, enabling applications to start up faster, and features isolation, scalability, easy migration, and sustainable delivery and deployment.

[0004] Based on these characteristics, container technology is widely used in the cloud service field.

[0005] Containers created based on container technology are mainly divided into two types: ordinary containers and secure containers.

[0006] Ordinary containers primarily achieve resource isolation based on cgroups (control groups) and namespaces. Different ordinary containers share the host machine's operating system kernel, resulting in relatively weak isolation and security.

[0007] Secure containers are implemented based on lightweight virtual machine technology. Each secure container runs in a separate micro virtual machine with its own operating system kernel to avoid sharing the host machine's operating system kernel.

[0008] Safety containers offer greater isolation and security than ordinary containers.

[0009] Due to the isolation between secure containers and the host machine, how to ensure that the hardware resources of the same physical device are shared by multiple secure containers while maintaining isolation, so as to ensure that hardware access in different secure containers does not affect each other, is a technical problem that urgently needs to be solved. Summary of the Invention

[0010] One of the technical problems this disclosure aims to solve is to provide a solution that can ensure the isolation of hardware resources of the same physical device while being shared by multiple secure containers.

[0011] According to a first aspect of this disclosure, a device access method for a secure container is provided, comprising: creating a first communication module within the secure container; creating a second communication module on a server where the secure container resides for communicating with the first communication module; creating a second device node corresponding to the secure container on the server and allocating at least a portion of the hardware resources of the physical device to the second device node; creating a first device node corresponding to the at least a portion of the hardware resources within the secure container; and transmitting access operation information of an application in the secure container to the first device node to the second device node via the first communication module and the second communication module.

[0012] Optionally, the access operation information includes: task instructions that need to invoke hardware resources to execute; and / or data transmission requests that need to be sent to the physical device.

[0013] Optionally, the access operation information is a data transmission request. The method further includes: in response to receiving the data transmission request from the second device node, the device driver requests memory space for storing data and determines the mapping relationship between the host physical address and the passenger virtual address corresponding to the memory space, where the host physical address is the physical address of the memory space on the server and the passenger virtual address is the virtual address of the memory space in the secure container; the device driver sends the passenger virtual address to the application via the second communication module and the first communication module, so that the application can copy the data to the passenger virtual address.

[0014] Optionally, the method further includes: the device driver obtaining data from the host physical address according to the mapping relationship, and sending the data to the physical device.

[0015] Optionally, the step of creating the first device node within the secure container includes: creating a device node simulation module within the secure container, and having the device node simulation module simulate a virtual second device node within the secure container.

[0016] Optionally, the access operation information is a task instruction. The step of transmitting the access operation information of the application in the secure container to the first device node via the first communication module and the second communication module includes: the application in the secure container issuing a task instruction through the first device node; the device node simulation module monitoring the first device node, obtaining the task instruction, and sending the task instruction to the second communication module through the first communication module; and the second communication module transmitting the task instruction to the second device node corresponding to the secure container.

[0017] Optionally, the first device node is located in the kernel space of the secure container, and / or the second device node is located in the kernel space of the server, and / or the first communication module is located in the user space of the secure container, and / or the second communication module is located in the user space of the server.

[0018] According to a second aspect of this disclosure, a device access system for a secure container is provided, comprising: a client device and a server device, wherein the server device is disposed within a host machine where the secure container is located, including a second device node corresponding to the secure container and a second communication module for communicating with a first communication module, the second device node being allocated at least a portion of the hardware resources of a physical device, the client device being disposed within the secure container, including the first communication module and the first device node corresponding to at least a portion of the hardware resources, the client device transmitting access operation information of an application in the secure container targeting the first device node to the second device node via the first communication module and the second communication module.

[0019] Optionally, the access operation information is a data transmission request. In response to receiving the data transmission request from the second device node, the device driver requests memory space for storing data and determines the mapping relationship between the host physical address and the passenger virtual address corresponding to the memory space. The host physical address is the physical address of the memory space on the host machine, and the passenger virtual address is the virtual address of the memory space in the secure container. The device driver sends the passenger virtual address to the application through the second communication module and the first communication module so that the application can copy the data to the passenger virtual address.

[0020] Optionally, the device driver retrieves data from the host physical address based on the mapping relationship and sends the data to the physical device.

[0021] Optionally, the first device node is located in the kernel space of the secure container, and / or the second device node is located in the kernel space of the host machine, and / or the first communication module is located in the user space of the secure container, and / or the second communication module is located in the user space of the host machine.

[0022] According to a third aspect of this disclosure, a computing device is provided, comprising: a processor; and a memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method described in the first aspect above.

[0023] According to a fourth aspect of this disclosure, a computer program product is provided, including executable code that, when executed by a processor of an electronic device, causes the processor to perform the method described in the first aspect above.

[0024] According to a fifth aspect of this disclosure, a non-transitory machine-readable storage medium is provided, on which executable code is stored, which, when executed by a processor of an electronic device, causes the processor to perform the method described in the first aspect above.

[0025] Therefore, this disclosure creates a first communication module and a first device node within a secure container, and creates a second communication module on the server where the secure container resides for communication with the first communication module, as well as a second device node corresponding to the secure container. Access operation information of the application targeting the first device node is transmitted to the second device node via the first and second communication modules. This allows the second device node to be used by the application within the secure container under the action of the first device node, the first communication module, and the second communication module. Furthermore, the hardware resources corresponding to the second device node are allocated specifically for the secure container, enabling the secure container to access the hardware resources of the physical device while maintaining isolation, ensuring that hardware access within different secure containers does not interfere with each other. Attached Figure Description

[0026] The above and other objects, features and advantages of this disclosure will become more apparent from the more detailed description of exemplary embodiments thereof taken in conjunction with the accompanying drawings, wherein like reference numerals generally denote like parts.

[0027] Figure 1 A schematic diagram of a device access method for a secure container according to an embodiment of the present disclosure is shown.

[0028] Figure 2 A schematic diagram of a device access method for a secure container according to another embodiment of the present disclosure is shown.

[0029] Figure 3 A schematic diagram of the structure of a device access system according to an embodiment of the present disclosure is shown.

[0030] Figure 4 A schematic diagram of a server instance where the device access system of this disclosure is deployed is shown.

[0031] Figure 5 A schematic diagram of the structure of a computing device according to an embodiment of the present disclosure is shown. Detailed Implementation

[0032] Preferred embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0033] The concept of secure containers is primarily compared to regular containers. The main difference is that each secure container (generally a container group (pod)) runs in a separate micro-virtual machine, possessing an independent operating system kernel and secure isolation at the virtualization layer. Because cloud container instances use shared multi-tenant clusters, the security isolation requirements for containers are more stringent than for users having their own private Kubernetes (a container cluster management system, abbreviated as "K8s") clusters. With secure containers, the kernel, computing resources, storage, and network are isolated between containers from different tenants. This protects user resources and data from being preempted and stolen by other users.

[0034] In other words, ordinary containers run directly in the user space of the host machine (such as a server) and can communicate with the kernel space of the host machine. Secure containers, on the other hand, run in a separate micro-virtual machine, have their own independent operating system kernel, and cannot communicate directly with the kernel space of the host machine.

[0035] The aforementioned characteristics of secure containers prevent device nodes created on the host machine from communicating directly with them. Therefore, it's impossible to create device nodes on the host machine that can communicate with secure containers, as is the case with regular containers.

[0036] In view of this, this disclosure proposes a device access scheme (also known as a device virtualization scheme) adapted to secure containers based on the working characteristics of secure containers, so that secure containers can share the hardware resources of physical devices while maintaining isolation, so as to ensure that hardware access in different secure containers will not affect each other.

[0037] Figure 1 A schematic diagram of a device access method for a secure container according to an embodiment of the present disclosure is shown.

[0038] See Figure 1 This disclosure creates a communication module on both the secure container and the server (i.e., the host machine) where the secure container resides. The communication module within the secure container can be referred to as the first communication module, and the communication module on the server can be referred to as the second communication module. The first communication module resides in the user space of the secure container, and the second communication module resides in the user space of the server. The first communication module and the second communication module can communicate with each other. For example, the first communication module and the second communication module can perform network communication, such as Socket communication.

[0039] This disclosure also creates a device node in both the secure container and the server where the secure container resides. The device node inside the secure container can be referred to as the first device node, and the device node on the server can be referred to as the second device node.

[0040] The second device node is created for each secure container. That is, each secure container corresponds to one second device node.

[0041] At least a portion of the hardware resources of a physical device can be allocated to a second device node. Each second device node corresponds one-to-one with a secure container. Allocating at least a portion of the hardware resources of a physical device to a second device node means allocating the hardware resources of the physical device to the secure container. The physical device can be a hardware device within a server, or a hardware device connected to the server but located outside the server.

[0042] Physical devices can refer to physical equipment, such as cloud server hosts. Hardware resources can refer to physical hardware resources, such as CPUs (Central Processing Units), memory, disks, networks, etc. For heterogeneous computing devices, hardware resources can also include GPUs (Graphics Processing Units) and NPUs (Neural Processing Units). As an example, a physical device can be a heterogeneous computing device that includes various types of computing units such as CPUs, GPUs, and NPUs. Heterogeneous computing refers to a computing method that uses computing units with different types of instruction sets and architectures to form a system. Common categories of computing units mainly include CPUs, GPUs, and NPUs.

[0043] Device nodes can serve as an interface between device drivers (kernel mode) and applications (user mode). Applications can communicate with device drivers through device nodes via IOCTL (Input / Output Control), memory mapping, or direct read / write. IOCTL is a system call specifically designed for device input / output operations. This call takes a device-specific request code as input, and its functionality depends entirely on the request code.

[0044] Taking Linux as an example of a server operating system, all devices (device information) are stored as files in the ` / dev` directory and accessed via files. A device node is an abstraction of a device by the Linux kernel; a device node is essentially a file. Applications access device nodes through a set of standardized calls, independent of any specific driver. The driver is responsible for mapping these standard calls to the specific operations of the actual hardware.

[0045] The second device node can be a device node created by the device driver (device driver program).

[0046] The first device node can be a virtual device node obtained through simulation in a secure container.

[0047] The second device node is located in the server's kernel space.

[0048] The first device node resides in the kernel space of the secure container.

[0049] The second device node can be viewed as an interface between the device driver and the application running in the secure container. However, due to the isolation nature of the secure container, the second device node cannot be passed into the secure container for use by the application within it. Therefore, the first device node created within the secure container can act as the second device node for the secure container's use. That is, for the application in the secure container, the first device node is the interface between the application and the device driver, and the application can communicate with the device driver through the first device node.

[0050] In other words, the first device node and the second device node correspond to the same set of hardware resources. The first device node can be used as the entry point for the hardware resources allocated to the second device node within the secure container, and applications within the secure container can access the hardware resources by accessing the first device node.

[0051] Application access operation information for the first device node can be transmitted to the second device node via the first and second communication modules. Thus, through the actions of the first device node, the first communication module, and the second communication module, the second device node can be used by the application within the secure container.

[0052] The second device node can communicate directly with the device driver, and the hardware resources corresponding to the second device node are allocated specifically for the secure container. Therefore, the device driver can map the access operation information of the application in the secure container to the first device node to the actual hardware, so that the secure container can call the hardware resources of the physical device while maintaining isolation, to ensure that hardware access in different secure containers will not affect each other.

[0053] When it is necessary to allocate hardware resources from multiple different physical devices to the same secure container, a second device node corresponding to the secure container can be created for each physical device. Each second device node is allocated at least a portion of the hardware resources of the physical device corresponding to it. Multiple first device nodes can be created within the secure container. The types of access operations that applications within the secure container perform on the first device nodes mainly include two types: task instructions that require access to the hardware resources of the physical device for execution, and data transmission requests that need to be sent to the physical device.

[0054] If the access operation information is a task instruction, then after the application in the secure container transmits the task instruction for the first device node to the second device node via the first communication module and the second communication module, the device driver can call resources from the hardware resources allocated to the second device node to execute the task instruction according to the task instruction obtained from the second device node. The execution result of the task instruction can be returned to the application via the second communication module and the first communication module, or it can be returned to the application via the second device node, the second communication module, the first communication module, and the first device node.

[0055] If the access operation information is a data transmission request, the application in the secure container, after transmitting the data transmission request to the first device node via the first and second communication modules to the second device node, responds to the data transmission request obtained from the second device node. It can allocate a memory space for storing data, determine the mapping relationship between the Host Physical Address (HPA) and Guest Virtual Address (GVA) corresponding to the memory space, and then send the Guest Virtual Address to the application via the second and first communication modules. Alternatively, the Guest Virtual Address can be sent to the application via the second device node, the second communication module, the first communication module, and the first device node. The application can copy the data it wants to send to the physical device to the Guest Virtual Address. The device driver can retrieve the data from the Host Physical Address based on the mapping relationship between the Guest Virtual Address and the Host Physical Address and send the data to the physical device. Therefore, when the application transmits data to the physical device, it does not need to transmit the data via data transfer; it only needs to copy the data to a specific address range to efficiently complete the data transfer from the secure container to the host machine without going through a data transfer step.

[0056] The host physical address is the physical address of the memory space on the server, while the guest virtual address is the virtual address of the memory space within the secure container. The application sends a data request for the first device node, also known as an address space allocation request. This request is passed through the first and second communication modules to the device driver located on the server. When the device driver requests memory space, it can allocate a segment of memory at the server's kernel layer. The address of the allocated memory is the Host Virtual Address (HVA). Based on the HVA of the allocated memory space, the corresponding host physical address can be determined, i.e., the HVA can be converted to the HPA. In determining the mapping relationship between the HPA and GPA, the device driver can interact with the hypervisor managing the secure container to complete the mapping between the HPA and GPA.

[0057] Figure 2 A schematic diagram of a device access method for a secure container according to another embodiment of the present disclosure is shown.

[0058] In this embodiment, a device node simulation module can be created within the secure container. The device node simulation module serves two purposes: first, to simulate a virtual first device node within the secure container; and second, to monitor, intercept, and forward access operation information (tasks) of applications within the secure container targeting the first device node.

[0059] The device driver may include a task scheduler, a resource allocator, and a data processing module. The task scheduler is used to schedule tasks submitted by multiple secure containers through a first device node and a second device node; the resource allocator is used to allocate and isolate the hardware resources of multiple secure containers; and the data processing module is used for data transfer between secure containers and the server.

[0060] Traditional device drivers are not designed with support for secure containers in mind, resulting in various shortcomings. This solution improves device driver support for secure containers through the following settings.

[0061] 1. Multiple device nodes

[0062] Traditional device drivers typically provide only one device node, serving as the interface between the kernel device driver and user-space programs. Multiple user programs can communicate with the kernel device driver through the device node using methods such as IOCTL, memory mapping, or direct read / write. However, a single device node is not suitable for isolating multiple secure containers.

[0063] Therefore, this disclosure proposes a scheme where a device driver provides multiple device nodes. Based on the characteristics of secure containers, it proposes allocating multiple device nodes to different secure containers via network communication. That is, by using device nodes simulated within the secure containers and communication modules respectively located in the secure containers and on the server, device nodes provided by the device driver are allocated to the secure containers. This achieves the following advantages:

[0064] 1) Task isolation can be easily achieved between multiple device nodes. In the case of a single device node, the device driver cannot be shared by multiple secure containers;

[0065] 2) It's difficult to distinguish which security container a task originates from, making task isolation challenging. However, with multiple device nodes, the device driver can differentiate between them, thus isolating tasks originating from different security containers.

[0066] 3) Different priorities can be implemented among multiple device nodes. Based on task isolation, the device driver can assign different priorities to each device node, thereby achieving task priority among different types of security containers.

[0067] 4) Resource isolation can be achieved between multiple device nodes. Similar to task isolation, in the case of multiple device nodes, the device driver can reserve a certain amount of resources for each node, thereby avoiding the situation in a single device node where one process consumes too many resources, causing other processes to not get enough resources.

[0068] 5) Different resource sizes can be allocated among multiple device nodes. With resource isolation, the resource size of each device node can be statically or dynamically allocated to different sizes, thus different containers can obtain different resource sizes.

[0069] 6) The number of multiple device nodes does not need to be fixed and can be dynamically allocated, which can support a flexible number of containers.

[0070] 2. Task Scheduler

[0071] Traditional task managers typically do not have a task scheduler, or the implementation of the task scheduler is very simple.

[0072] In this disclosure, the task scheduler can schedule tasks submitted from different device nodes based on time slices, physical execution units, or other methods (such as priority) to ensure that: tasks on device nodes with the same priority occupy the same time slice or physical execution unit; and tasks on higher-priority device nodes occupy more time slices or physical execution units than tasks on lower-priority device nodes.

[0073] 3. File Explorer

[0074] To prevent a single secure container from consuming excessive resources, a resource manager can be used to isolate resources, ensuring that: a secure container cannot access resources within other secure containers; and each secure container cannot use resources beyond its limits. Similarly, like a task scheduler, a resource manager can set different resource limits for different containers, achieving better hardware resource utilization through different resource allocation strategies.

[0075] 4. Data Processing Module

[0076] Responsible for establishing a data transmission channel between the secure container and the host device.

[0077] 5. The device nodes of secure containers are implemented based on the kernel (the kernel of an operating system, often specifically referring to the kernel of the Linux operating system). Application software is unaware of this and requires no modifications.

[0078] 6. It can operate within a standard safety container.

[0079] Applications within secure containers (such as TensorFlow) utilize devices (e.g., GPUs and NPUs). When submitting tasks to these devices, there are two main interaction paths: control flow and data flow. Control flow refers to the task instructions sent to the physical device, while data flow is the data submitted to the physical device.

[0080] This disclosure can achieve device virtualization isolation from both control flow and data flow perspectives.

[0081] 1. Control Flow

[0082] Applications within the secure container can issue task commands through a first device node. Upon detecting a task command, the device node simulation module can intercept it and forward it to a second communication module via a first communication module. The second communication module can then transmit the task command to the second device node corresponding to the secure container. After receiving the task command from the second device node, the device driver can, under the guidance of the task scheduler, invoke the hardware resources allocated for the secure container to execute the task command.

[0083] For example, within the secure container, the main function is to forward IOCTL calls from the user layer to the kernel layer. The application makes an IOCTL call to the device node simulation module through the first device node. After the device node simulation module intercepts this operation, it transmits it to the corresponding second device node on the host machine through the first communication module and the second communication module.

[0084] 2. Data Flow

[0085] When an application (such as TensorFlow) within a secure container transmits data to a device, it typically does so by having the device driver request memory space for the data via a method called memory mapping, and then copying the data into the corresponding address space.

[0086] In this disclosure, an application can request an address space through a device node emulation module. The device node emulation module within the secure container can then pass this task to the data processing module on the host machine. The data processing module first requests a memory segment (HVA) at the host machine's kernel layer and then translates it into the host machine's physical address (HPA). The data processing module can interact with the hypervisor managing the secure container to map the host machine's physical address (HPA) to the container's guest virtual address (GVA), thus obtaining the mapping relationship between the two. The GVA is returned to the data processing module, which can then use a second communication module and a first communication module to return the GVA to the application layer of the secure container. This allows the application to copy data to this address range, and the data processing module can find the corresponding HVA to retrieve the data. This efficiently completes the transfer of data from the secure container to the host machine without requiring data transfer.

[0087] Compared with existing solutions, this disclosure has at least the following advantages:

[0088] 1) The technical solution disclosed herein is mainly in the kernel driver and does not involve the user-space API interface. When the user API interface is modified, this disclosure does not need to be modified, thus ensuring that the user is unaware of the changes and avoiding the risks and losses that may arise during upgrades and maintenance.

[0089] 2) This disclosure achieves resource isolation and sharing of devices by forwarding the node IOCTL class call, realizes a virtualization scheme for shared devices of secure containers, and completes the address mapping between the secure container GVA and the host HVA by managing the secure container hypervisor. Data performance can be improved by avoiding data copying and moving.

[0090] 3) In this disclosure, since the physical addresses of the resources of each device node are in the same physical address range, no additional address translation or additional page table structure is required, and therefore there will be no performance loss.

[0091] 4) This disclosure has high maintainability, high performance and high flexibility. Compared with other different solutions, it is more suitable for heterogeneous computing applications in containers in the future and should occupy a place in future heterogeneous computing cloud services.

[0092] This disclosure modifies the device driver to create a device node for a secure container, and simulates the device node within the secure container. Based on the simulated device node, communication between the device node created by the device driver and the application within the secure container is achieved through network communication, thereby achieving resource isolation and making it suitable for secure containers.

[0093] Unlike existing device virtualization schemes in secure containers, this disclosure proposes a lightweight device virtualization scheme that directly implements multiple device nodes in the kernel device driver and links them to device nodes inside the secure container via a network. This achieves the goal of allowing a single physical device to be shared by multiple secure container instances while ensuring resource and task isolation between secure containers.

[0094] Figure 3 A schematic diagram of the structure of a device access system according to an embodiment of the present disclosure is shown.

[0095] like Figure 3 As shown, the device access system includes client devices and server devices. The client devices are located within a secure container. The server devices are located on the host machine (such as a server) where the secure container resides.

[0096] The server-side device includes a second device node corresponding to the secure container and a second communication module for communicating with the first communication module. The second device node is allocated at least a portion of the hardware resources of the physical device.

[0097] The client device includes a first communication module and a first device node corresponding to at least a portion of the hardware resources.

[0098] The client device can transmit access operation information of the application in the secure container to the second device node via the first communication module and the second communication module.

[0099] The client device may also include a device node simulation module. The server device may also include a data processing module, a task scheduler, a resource allocator, etc. For details regarding the device node simulation module, data processing module, task scheduler, and resource allocator, please refer to the relevant descriptions above; they will not be repeated here.

[0100] Figure 4 A schematic diagram of a server instance where the device access system of this disclosure is deployed is shown.

[0101] like Figure 4As shown, multiple secure containers can be created within a server (such as a cloud server). Each secure container can run AI (Artificial Intelligence) applications, such as TensorFlow. Client devices are deployed within the secure containers, and server devices are deployed on the host machine where the secure containers reside. The client and server devices can communicate using the TCP / IP protocol and also support RDMA (Remote Direct Memory Access). Through the roles of the client and server, local or remote GPUs can be shared by multiple secure container instances while ensuring resource and task isolation between the secure containers.

[0102] Figure 5 A schematic diagram of a computing device is shown, which can be used to implement the above-described device access method for a secure container according to an embodiment of the present invention.

[0103] See Figure 5 The computing device 500 includes a memory 510 and a processor 520.

[0104] Processor 520 may be a multi-core processor or may contain multiple processors. In some embodiments, processor 520 may include a general-purpose main processor and one or more special-purpose coprocessors, such as a graphics processing unit (GPU), a digital signal processor (DSP), etc. In some embodiments, processor 520 may be implemented using custom circuitry, such as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA).

[0105] Memory 510 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by the processor 520 or other modules of the computer. Permanent storage devices may be read-write storage devices. Permanent storage devices may be non-volatile storage devices that retain stored instructions and data even when the computer is powered off. In some embodiments, permanent storage devices use mass storage devices (e.g., magnetic or optical disks, flash memory) as permanent storage devices. In other embodiments, permanent storage devices may be removable storage devices (e.g., floppy disks, optical drives). System memory may be a read-write storage device or a volatile read-write storage device, such as dynamic random access memory. System memory may store some or all of the instructions and data required by the processor during operation. Furthermore, memory 510 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and disks and / or optical disks may also be used. In some embodiments, memory 510 may include a removable storage device that is readable and / or writable, such as a laser disc (CD), a read-only digital multifunction optical disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-high-density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not contain carrier waves or transient electronic signals transmitted wirelessly or via wired connections.

[0106] The memory 510 stores executable code, which, when processed by the processor 520, enables the processor 520 to execute the device access method described above.

[0107] The method, system, and computing device for accessing a secure container according to the present invention have been described in detail above with reference to the accompanying drawings.

[0108] Furthermore, the method according to the invention can also be implemented as a computer program or computer program product, which includes computer program code instructions for performing the steps defined in the above-described method of the invention.

[0109] Alternatively, the present invention can also be implemented as a non-transitory machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) storing executable code (or computer program, or computer instruction code) thereon, which, when executed by a processor of an electronic device (or computing device, server, etc.), causes the processor to perform the various steps of the method described above according to the present invention.

[0110] Those skilled in the art will also understand that the various exemplary logic blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein can be implemented as electronic hardware, computer software, or a combination of both.

[0111] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems and methods according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0112] The various embodiments of the present invention have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for accessing a device in a secure container, comprising: Create the first communication module within the secure container; Create a second communication module on the server where the secure container is located to communicate with the first communication module; Create a second device node on the server corresponding to the security container, and allocate at least a portion of the hardware resources of the physical device to the second device node; A virtual first device node corresponding to at least a portion of the hardware resources is created within the secure container; as well as The access operation information of the application in the secure container to the first device node is transmitted to the second device node via the first communication module and the second communication module.

2. The method of claim 1, wherein, The access operation information includes: task instructions that need to call hardware resources to execute; and / or data transmission requests that need to be sent to the physical device.

3. The method of claim 2, wherein, The access operation information is the data sending request, and the method further includes: In response to receiving the data transmission request from the second device node, the device driver requests memory space for storing data and determines the mapping relationship between the host physical address and the passenger virtual address corresponding to the memory space. The host physical address is the physical address of the memory space on the server, and the passenger virtual address is the virtual address of the memory space within the secure container. The device driver sends the aircraft virtual address to the application via the second communication module and the first communication module, so that the application can copy data to the aircraft virtual address.

4. The method according to claim 3, further comprising: The device driver obtains the data from the host physical address according to the mapping relationship and sends the data to the physical device.

5. The method of claim 1, wherein the step of creating a virtual first device node within the secure container comprises: A device node simulation module is created within the secure container, and a virtual first device node is simulated within the secure container by the device node simulation module.

6. The method according to claim 5, wherein, The access operation information is a task instruction. The step of transmitting the access operation information of the application in the secure container to the second device node via the first communication module and the second communication module includes: The application in the secure container issues task commands through the first device node; The device node simulation module monitors the first device node, acquires the task instruction, and sends the task instruction to the second communication module through the first communication module; and The second communication module transmits the task instructions to the second device node corresponding to the secure container.

7. The method according to any one of claims 1 to 6, wherein, The first device node is located in the kernel space of the secure container, and / or The second device node is located in the kernel space of the server, and / or The first communication module is located in the user space of the secure container, and / or The second communication module is located in the user space of the server.

8. A device access system for a secure container, comprising: Client device and server device The server-side device is located within the host machine of the secure container, and includes a second device node corresponding to the secure container and a second communication module for communicating with the first communication module. The second device node is allocated at least a portion of the hardware resources of the physical device. The client device is located within the secure container and includes a first communication module and a virtual first device node corresponding to at least a portion of the hardware resources. The client device transmits access operation information of the application in the secure container to the first device node via the first communication module and the second communication module to the second device node.

9. The system according to claim 8, wherein, The access operation information is a data transmission request. In response, the device driver obtains the data transmission request from the second device node, requests memory space for storing data, and determines the mapping relationship between the host physical address and the passenger virtual address corresponding to the memory space. The host physical address is the physical address of the memory space on the host machine, and the passenger virtual address is the virtual address of the memory space in the secure container. The device driver sends the aircraft virtual address to the application via the second communication module and the first communication module, so that the application can copy data to the aircraft virtual address.

10. The system according to claim 9, wherein, The device driver obtains the data from the host physical address according to the mapping relationship and sends the data to the physical device.

11. The system according to any one of claims 8 to 10, wherein, The first device node is located in the kernel space of the secure container, and / or The second device node is located in the kernel space of the host machine, and / or The first communication module is located in the user space of the secure container, and / or The second communication module is located in the user space of the host machine.

12. A computing device, comprising: processor; as well as A memory having executable code stored thereon, which, when executed by the processor, causes the processor to perform the method as described in any one of claims 1 to 7.

13. A computer program product comprising executable code that, when executed by a processor of an electronic device, causes the processor to perform the method as claimed in any one of claims 1 to 7.

14. A non-transitory machine-readable storage medium having executable code stored thereon, which, when executed by a processor of an electronic device, causes the processor to perform the method as described in any one of claims 1 to 7.

Images