Cross-domain communication method and system based on capability token, and readable storage medium

Abstract

The invention discloses a cross-domain communication method and system based on a capability token and a readable storage medium. The method comprises the steps that a capability token of a shared memory area is generated, the capability token is sent to a first process of a security domain, and the shared memory area is an area for data exchange between the security domain and a non-security domain; receiving an access request of a second process in the non-security domain to the shared memory region, wherein a capability token carried by the access request is sent to the second process by the first process; and verifying the access request of the second process according to the capability token, if the verification result is legal, allowing the first process and the second process to perform cross-domain communication based on the shared memory region, and if the verification result is illegal, refusing the second process. In the application, after the first process of the security domain issues the capability token to the second process of the non-security domain, the second process can access the shared memory area, so that the security of cross-domain sharing is ensured.

Description

Technical Field

[0001] This application belongs to the field of information security, and in particular relates to a cross-domain communication method, system and readable storage medium based on capability tokens. Background Technology

[0002] In embedded real-time operating systems, processes or threads frequently need to exchange data, i.e., inter-process communication (IPC). In scenarios with security requirements, systems using ARM TrustZone or memory protection units isolate processes in two different spatial domains (secure domain and non-secure domain). This approach faces the core challenge of balancing high efficiency and high security when implementing cross-domain communication.

[0003] To address this issue, existing technologies primarily involve pre-allocating a shared memory region for two spatial domains to share, and pre-setting a unified, long-term valid permission configuration for each spatial domain. Processes within the domain exchange data by directly reading and writing to this shared region, thereby avoiding multiple copies and ensuring communication efficiency.

[0004] However, permission configuration is applied to the entire domain rather than a single process. Once a single process within a domain is compromised, an attacker can use the domain's preset, persistent global memory access permissions to arbitrarily read and write the entire shared area for an extended period, leading to serious data leaks and unauthorized operations. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a cross-domain communication method, system and readable storage medium based on capability tokens, which can prevent data leakage and unauthorized operation risks caused by attackers accessing the shared memory area when a single process in the non-secure domain is compromised, by setting the shared memory area as a non-secure domain that requires capability tokens to access.

[0006] Firstly, this application provides a cross-domain communication method based on capability tokens, the method comprising: Generate a capability token for the shared memory region and send the capability token to the first process of the security domain. The shared memory region is the area where data is exchanged between the security domain and non-security domain. Receive access requests from a second process within a non-security domain to a shared memory region. The access request carries a capability token sent by the first process to the second process. The access request of the second process is verified based on the capability token. If the verification result is valid, the first process and the second process are allowed to communicate across domains based on the shared memory region. If the verification result is invalid, the second process is rejected.

[0007] In conjunction with the first aspect, in one possible implementation, the method further includes, before generating the capability token for the shared memory region: In response to the shared memory creation request from the first process, a shared memory region is created. The first access permissions for the shared memory region include: allowing non-security domains to access it based on capability tokens.

[0008] In conjunction with the first aspect, in one possible implementation, the capability token includes a lifecycle. After allowing the first and second processes to communicate across domains based on shared memory regions, the method also includes: Receive the cross-domain communication progress of the first and second processes, and destroy the capability token based on the cross-domain communication progress or lifecycle.

[0009] In conjunction with the first aspect, in one possible implementation, after destroying the capability token, the method further includes: Delete the shared memory region.

[0010] In conjunction with the first aspect, in one possible implementation, the capability token also includes second access permissions and address information of the shared memory region. The access request of the second process is verified based on the capability token, specifically as follows: The access request of the second process is verified based on its lifecycle, second access permissions, and the address information of the shared memory region.

[0011] In conjunction with the first aspect, in one possible implementation, the capability token also includes: the domain to which the shared memory region belongs. The access request of the second process is verified based on the capability token, specifically as follows: The access request of the second process is verified based on its lifecycle, second access permissions, address information of the shared memory region, and the domain to which the shared memory region belongs.

[0012] In conjunction with the first aspect, in one possible implementation, the first access permissions to the shared memory region are configured through a memory protection unit or a memory management unit.

[0013] Secondly, this application also provides a cross-domain communication system based on capability tokens, including: a secure domain, a non-secure domain, and a security management device; The security management device is configured to generate capability tokens for shared memory regions of the security domain and non-security domain, send capability tokens to the first process of the security domain, and the shared memory region is the area for data exchange between the security domain and non-security domain; The first process sends a capability token to the second process in a non-security domain; The second process initiates an access request to the shared memory region to the security management device, and the access request carries a capability token. The security management device is also configured to verify the access request of the second process based on the capability token. If the verification result is valid, the first process and the second process are allowed to communicate across domains based on the shared memory region. If the verification result is invalid, the second process is rejected.

[0014] In conjunction with the second aspect, in one possible implementation, the security management device is further configured to create a shared memory region in response to a shared memory creation request from the first process, wherein the first access permissions of the shared memory region include: allowing non-security domains to access it based on capability tokens.

[0015] Thirdly, this application also provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method of any one of the first aspects above.

[0016] Fourthly, this application also provides a computer program product containing instructions that, when executed, perform any of the methods described in the first aspect above.

[0017] Fifthly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method of any one of the first aspects above.

[0018] Compared to existing technologies where the first access permission for shared memory regions is configured to be either entirely open or entirely disabled for non-secure domains, the cross-domain communication method, system, and readable storage medium based on capability tokens provided in this application, in cross-domain communication, sets the first access permission for shared memory regions to allow non-secure domains to access them based on capability tokens, and the capability tokens are issued by processes in the secure domain to processes in the non-secure domain, thereby prohibiting other processes in the non-secure domain that do not carry capability tokens from accessing the shared memory regions, thus ensuring the security of cross-domain sharing. Attached Figure Description

[0019] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A diagram illustrating the cross-domain communication system architecture based on capability tokens provided in this application embodiment; Figure 2 A flowchart of a cross-domain communication method based on capability tokens provided in an embodiment of this application; Figure 3 A schematic diagram of the structure of the capability token provided in this application embodiment; Figure 4 A block diagram of a security management device provided in one embodiment of this application; Figure 5 A block diagram illustrating a security management device provided in another embodiment of this application; Figure 6 A flowchart illustrating a cross-domain communication method based on capability tokens, provided as another embodiment of this application; Figure 7 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0020] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects.

[0022] The following is an explanation of the terms used in this application: Embedded Real-Time Operating System (RTOS): An operating system designed specifically for embedded devices, whose core feature is the ability to process tasks and respond to events within strict time constraints.

[0023] ARM TrustZone: A hardware security technology for embedded operating systems that provides strong system-level isolation by dividing system resources at the hardware level into two independent execution environments—the Secure World and the Normal World.

[0024] Security domain: A trusted and protected execution environment built by hardware and software, in which code and data are considered trustworthy and highly sensitive, and memory access is strictly restricted to prevent unauthorized snooping or tampering.

[0025] Non-secure domain: The normal operating environment in the system that lacks the same level of hardware security protection. In this environment, the operating system and applications are considered potentially untrusted, and their memory access permissions are strictly controlled to prevent them from accessing protected resources without authorization.

[0026] Shared memory region: A specific area in physical memory allocated by the operating system kernel or security hardware. This region is securely configured to allow two or more originally isolated domains to access it simultaneously, thereby providing an efficient data exchange buffer for cross-domain communication. However, its security relies heavily on additional access control mechanisms to prevent unauthorized operations.

[0027] Memory Protection Unit (MPU): A hardware unit used to protect memory. It prevents memory access errors and malicious access by defining different memory regions (such as RAM, peripheral addresses) for different tasks or privilege levels and configuring their access permissions (such as read-only, execute-disable), but it usually does not have virtual address translation capabilities.

[0028] Inter-process communication (IPC) in operating systems refers to the general term for various data exchange and synchronization mechanisms running between different processes (or threads), such as message queues, shared memory, semaphores, and pipes.

[0029] Kernel: The core of the operating system, responsible for managing all critical system resources, including CPU time allocation, memory management, device drivers, and providing basic services such as IPC, providing a secure and abstract hardware environment for application execution.

[0030] Capability Manager: A security subsystem in the operating system responsible for managing and validating capabilities. A capability is an unforgeable token that serves as a permission credential to access objects (such as memory regions or devices) or perform specific operations. The Capability Manager is responsible for creating, distributing, and validating capabilities, ensuring that only entities holding the corresponding valid capabilities can perform operations.

[0031] Global memory access restriction: A coarse-grained memory protection strategy, typically implemented by the MPU or Memory Management Unit (MMU). It refers to uniformly disabling access to a specific memory region, meaning that all tasks attempting to access that region (unless they have higher privileges) will be blocked.

[0032] In embedded real-time operating systems (RTOS) with security requirements, such as those supporting ARM TrustZone or MPU technology, tasks are isolated in different security domains. This presents a core challenge for traditional IPC methods in achieving cross-domain communication: balancing high efficiency and high security. To address this challenge, existing technologies offer two solutions: First, message queue-based cross-domain communication, where the kernel acts as a trusted intermediary. Data from the sender is copied from the user space buffer to the kernel space, and then from the kernel to the receiver's user space buffer, with security ensured through kernel isolation. Second, communication based on a fixed shared memory region, where a pre-allocated shared memory region is shared by both domains. Tasks can exchange data by directly reading and writing to this region, avoiding multiple data copies and achieving efficient communication.

[0033] However, message queue solutions introduce additional latency and CPU overhead due to two data copies, and their "time-space" overhead is unacceptable in dynamic scenarios with high real-time requirements. Fixed shared memory solutions, on the other hand, use a system of disabling / allowing memory access to non-secure domains, failing to differentiate between "which task is accessing," "which part of the content is accessing," and "for how long" when faced with concurrent access from different domains. While simple to implement, this approach has several drawbacks: firstly, the granularity of permission management is too coarse—either all tasks can access it, or none can. Secondly, the solution lacks flexibility, unable to assign different permissions to different tasks. Most seriously, the solution is insecure; if a malicious task operates in the shared memory area, it may access data that does not belong to it, leading to data leakage.

[0034] In summary, existing cross-domain IPC methods suffer from difficulties in simultaneously achieving low overhead, real-time performance, and secure isolation control.

[0035] Based on this, this application provides a cross-domain communication method, system, and readable storage medium based on capability tokens to solve the problem that existing technologies cannot simultaneously meet the requirements of efficient communication and secure isolation.

[0036] In one possible implementation, the capability token-based cross-domain communication method provided in this application is applicable to a capability token-based cross-domain communication system. For example, Figure 1 This is an architecture diagram of a cross-domain communication system based on capability tokens provided in an embodiment of this application.

[0037] like Figure 1 As shown, the cross-domain communication system includes a security management device 10, a first process, and a second process. Optionally, the security management device 10 is a capability manager.

[0038] The first process runs in the secure domain, and the second process runs in the non-secure domain. The secure domain includes the first program and the first memory region. The first program runs in the secure domain, and its execution constitutes the first process. The first memory region is a contiguous area of ​​memory used to store the first program and the data generated during its execution. Similarly, the non-secure domain includes the second program and the second memory region. The second program runs in the non-secure domain, and its execution constitutes the second process. The second memory region is a contiguous area of ​​memory that does not overlap with the first memory region and is used to store the second program and the data generated during its execution.

[0039] It should be noted that the system's memory includes a first memory region, a second memory region, and a shared memory region created by the security management device 10. In this application, the security management device 10 generates a capability token and returns it to the security domain or the first process simultaneously with the creation of the shared memory region.

[0040] The shared memory region is a contiguous area of ​​memory that is configured to be accessible by default to the first process and to be accessible by the second process with a capability token. When the second process carries a capability token, both the first and second processes have permission to access the shared memory region. Thus, the first and second processes can read and write data to the shared memory region, and can communicate with each other based on the shared memory region.

[0041] In other embodiments, the shared memory region may also be created in response to a request from the first process. Specifically, it should be understood that when the first process wants to send data to the second process, the first process can determine the size of the shared memory region based on the size of the data to be sent, generate a shared memory creation request, and send a request to the security management device 10 to call ipc_share_create(size, flags). In response to the shared memory creation request from the first process, the security management device 10 creates the shared memory region, generates a capability token for the shared region, and sends the capability token to the first process. The first process sends a capability token to the second process via a system call; The second process initiates an access request to the shared memory region from the security management device 10 by calling ipc_share_map(T), and the access request carries a capability token; The security management device 10 verifies the legality of the capability token. If the verification result is legal, it grants access to the shared memory region to the second process. The first process and the second process communicate across domains and revoke the access rights corresponding to the capability token after the communication is completed. If the verification result is illegal, the second process is rejected.

[0042] It should be noted that in this application, the shared memory region is created by the security management device 10, and the access permissions of the shared memory region are bound to the capability token. The capability token and its corresponding permissions can be dynamically generated or revoked, which allows this application to configure temporarily valid access credentials, thereby reducing the exposure time window and attack surface of the shared memory region and solving the security risks faced by the fixed shared memory region due to static permissions.

[0043] On the other hand, such as Figure 2 As shown, this application also provides a cross-domain communication method based on capability tokens, which can be applied to... Figure 1 Taking a cross-domain communication system as an example, the following steps are included: Step 101: Generate a capability token for the shared memory region and send the capability token to the first process of the security domain. The shared memory region is the area where data is exchanged between the security domain and the non-security domain. Specifically, the capability token of this application includes a second access permission, which can be any one of read-only, write-only, or read-write. One possible implementation is, such as Figure 3 As shown, the capability token may also include at least one of the following: token ID, lifecycle / validity period, domain, shared memory address, size of shared memory, and verification information; One possible implementation includes, before generating the capability token for the shared memory region: In response to the shared memory creation request from the first process, a shared memory region is created. Specifically, the first process requests the security management device 10 to create shared memory within the security domain by calling ipc_share_create(size, flags); After receiving a shared memory creation request, the security management device 10 allocates physical memory for the shared memory region to be created and configures access permissions for the shared memory region through the MPU / MMU. The first access permissions for the shared memory region include: allowing non-security domains to access it based on capability tokens.

[0044] Furthermore, security domains can access shared memory regions by default.

[0045] Compared to existing cross-domain communication methods based on fixed shared memory, this application generates capability tokens for shared memory regions, binds the capability tokens to the shared memory regions, and sets access permissions based on the capability tokens for non-secure domains. This allows the kernel to verify the capability token every time it receives an access request, prohibiting unauthorized processes from non-secure domains from accessing shared memory. This achieves fine-grained access permission and timeliness management for shared memory regions, thereby improving the security of cross-domain communication.

[0046] Step 102: Receive the access request from the second process in the non-security domain to the shared memory region. The capability token carried in the access request is sent by the first process to the second process. Optionally, the first process passes the capability token to the second process via a system call.

[0047] Step 103: Verify the access request of the second process based on the capability token. If the verification result is valid, allow the first process and the second process to communicate across domains based on the shared memory region. If the verification result is invalid, reject the second process.

[0048] Optionally, the second process initiates an access request to the shared memory region to the security management device 10 by calling the ipc_share_map(T) interface, where T is the capability token; In one possible implementation, the security management device 10 sequentially verifies the access request of the second process by checking the lifecycle, second access permission, address information of the shared memory region, and the domain to which the shared memory region belongs in the capability token.

[0049] For example, the verification process is as follows: the security management device 10 obtains the capability token ID and queries the database to determine whether the capability token was generated by the security management device 10; next, it queries the database to obtain the generation timestamp of the capability token and obtains the current timestamp; when the time difference between the capability token generation timestamp and the current timestamp is less than or equal to the validity period, it continues to check the shared memory address, domain, second access permissions, and other information. If they all match the information of the capability token stored in the database, the verification is successful.

[0050] For example, if the second access permission is read and write, then after verification, the second process can directly read and write to the shared memory. At the same time, the first process also reads and writes in the shared memory area, and the two processes achieve zero-copy cross-domain communication.

[0051] This application combines hardware isolation mechanisms such as MPU / TrustZone with capability token mechanisms to achieve cross-domain process communication that balances security and efficiency.

[0052] In one possible implementation, after allowing the first and second processes to communicate across domains based on shared memory regions, the method further includes: Step 104: Receive the cross-domain communication progress of the first process and the second process, and destroy the capability token according to the cross-domain communication progress or lifecycle.

[0053] It is worth mentioning that when cross-domain communication is completed, the first process or the second process will send a communication completion signal to the security management device 10.

[0054] In one possible implementation, the security management device 10 also creates a token table and stores the capability token in the token table after generating it, while also sending the capability token to the first task. In the subsequent verification stage, the capability token carried by the second process can be directly compared with the capability token in the token table to approve or deny the access request.

[0055] The security management device 10 is configured to maintain the token table. When either cross-domain communication is completed or the lifecycle is exhausted, the security management device 10 will destroy the capability token and delete the relevant information of the capability token from the token table.

[0056] In one possible implementation, after the access request of the second process is verified, the security management device 10 updates the first access permission to allow the second process to access the shared memory region. Then, after the capability token is destroyed, this application reconfigures the first access permission to restore it to its initial state, allowing non-security domains to access it based on the capability token. At this point, the second process cannot access the shared memory region, thus ensuring the security of cross-domain sharing.

[0057] Compared to existing cross-domain communication methods based on message queues, this application improves communication efficiency by dynamically configuring capability tokens for shared memory regions, thus avoiding multiple data copies. Furthermore, compared to the existing shared memory access permission management method based on overall disabling, this application revokes the capability token after cross-domain communication is completed, updates the MPU permissions immediately after the capability token is revoked, and regenerates the capability token during the next cross-domain communication between processes. This introduces a dynamic generation and destruction of capability tokens, enabling controlled access to the shared memory region, thereby improving the efficiency and flexibility of cross-domain communication while ensuring security.

[0058] In one possible implementation, after destroying the capability token, the method further includes: Delete the shared memory region.

[0059] Specifically, when cross-domain communication is required between processes again, the security management device 10 will recreate the shared memory region and delete the shared memory region after the cross-domain communication ends. By dynamically creating the shared memory region, this application avoids the shared memory region from being continuously attacked due to its long-term existence, thus significantly improving the security of the system.

[0060] In one possible implementation, this application can also authorize the second process to communicate with the first process based on an encrypted handshake using a temporary key. Specifically, when the first process needs to communicate with the second process, it sends a request to the security management device 10. The security management device 10 generates a temporary key for this communication and distributes it to both the first and second processes through a secure channel. Afterward, the first and second processes can use the temporary key to establish an encrypted communication link, thereby achieving secure cross-domain communication under the authorization of the security management device 10.

[0061] For example, Figure 6 This is another flowchart illustrating the cross-domain communication method based on capability tokens provided in this application embodiment, as shown below. Figure 6 As shown, the method includes the following steps: Step S201: The first process requests the creation of a security domain and a non-security domain; Step S202: Create a shared memory region, generate a capability token for the shared memory region, and send the capability token to the first process of the security domain. The first access permissions for the shared memory region include: allowing non-security domains to access the region based on the capability token. Step S203: The first process sends a capability token to the second process in the non-security domain; Step S204: The second process sends an access request to the shared memory region, and the access request carries a capability token. Step S205: Verify the access request of the second process based on the capability token; For example, if it is valid, then steps S2051 to S2053 are executed sequentially; if it is invalid, then steps S2054 to S2055 are executed.

[0062] Step S2051: Update the first access permission to allow the second process to access; Step S2052: The first process and the second process perform cross-domain communication based on a shared memory region; Step S2053: Receive communication progress information and determine whether the communication or capability token lifecycle is complete; For example, if so, then execute steps S20531 to S20532; otherwise, execute step S20533.

[0063] Step S20531: Destroy the ability token; Step S20532: Restore the first access permission to its initial state; Step S20533: Maintain the validity of the capability token; Step S2054: Reject the second process and return an error; Step S2055, terminate.

[0064] It should be noted that although the operations of the method of the present invention are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart may be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0065] In another aspect, this application also provides a cross-domain communication system based on capability tokens, including: a secure domain, a non-secure domain, and a security management device 10; Security management device 10 is configured to generate capability tokens for shared memory regions of security and non-security domains, send capability tokens to the first process of the security domain, and the shared memory region is the area where data is exchanged between the security domain and the non-security domain; The first process sends a capability token to the second process in a non-security domain; The second process initiates an access request to the shared memory region to the security management device 10, and the access request carries a capability token. The security management device 10 is also configured to verify the access request of the second process based on the capability token. If the verification result is valid, the first process and the second process are allowed to communicate across domains based on the shared memory region. If the verification result is invalid, the second process is rejected.

[0066] For example, Figure 4 This is a block diagram of the security management device 10 provided in the embodiments of this application, such as... Figure 4 As shown, the security management device 10 includes a memory generation module 11, an access receiving module 12, and a security verification module 13, for deployment in a computer system to achieve cross-domain communication. The memory generation module 11 generates capability tokens for a shared memory region and sends these tokens to a first process in the secure domain. The access receiving module 12 receives access requests from a second process outside the secure domain to the shared memory region, the access request carrying a capability token sent from the first process to the second process. The security verification module 13 verifies the access request from the second process based on the capability token, and allows or denies cross-domain communication between the first and second processes based on the verification result.

[0067] In some embodiments, such as Figure 5 As shown, the security management device 10 also includes a destruction module 14 and a deletion module 15; the destruction module 14 is used to receive the cross-domain communication progress of the first process and the second process, and destroy the capability token according to the cross-domain communication progress or life cycle; the deletion module 15 is used to delete the shared memory region after destroying the capability token.

[0068] The following is for reference. Figure 7 , Figure 7 A schematic diagram of the structure of a computer system suitable for implementing the embodiments of this application is shown. like Figure 7 As shown, the computer system includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 702 or programs loaded from storage section 708 into random access memory (RAM) 703. RAM 703 also stores various programs and data required for the system's operating instructions. CPU 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0069] The following components are connected to I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 710 as needed so that computer programs read from it can be installed into storage section 708 as needed.

[0070] Specifically, according to embodiments of this application, the flowchart above refers to... Figure 2 The described process can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program contains program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit (CPU) 701, it performs the functions defined in the system of this application.

[0071] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0072] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. 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 indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or 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 functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0073] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be housed in a processor; for example, a processor can be described as including a receiving module, a determining module, and a storage module. The names of these units or modules do not necessarily limit the specific unit or module itself; for example, a receiving module can also be described as "receiving message data sent by a sub-site."

[0074] In another aspect, this application also provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method of any of the first aspects described above.

[0075] In another aspect, this application also provides a computer program product containing instructions that, when executed, perform the method of any of the first aspects described above.

[0076] In another aspect, this application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method of any of the first aspects described above.

[0077] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A cross-domain communication method based on capability tokens, characterized in that, The method includes: Generate a capability token for a shared memory region and send the capability token to the first process of the security domain. The shared memory region is a region where data is exchanged between the security domain and the non-security domain. Receive an access request from a second process within a non-security domain to the shared memory region, wherein the access request carries a capability token sent by the first process to the second process; The access request of the second process is verified based on the capability token. If the verification result is valid, the first process and the second process are allowed to communicate across domains based on the shared memory region. If the verification result is invalid, the second process is rejected.

2. The method according to claim 1, characterized in that, Before generating capability tokens for shared memory regions, the method further includes: In response to the shared memory creation request of the first process, the shared memory region is created, and the first access permissions of the shared memory region include: allowing the non-security domain to access it based on a capability token.

3. The method according to claim 2, characterized in that, The capability token includes a lifecycle. After allowing the first process and the second process to perform cross-domain communication based on the shared memory region, the method further includes: Receive the cross-domain communication progress of the first process and the second process, and destroy the capability token according to the cross-domain communication progress or the lifecycle.

4. The method according to claim 3, characterized in that, After destroying the capability token, the method further includes: Delete the shared memory region.

5. The method according to claim 3 or 4, characterized in that, The capability token also includes second access permissions and address information for the shared memory region. The access request to the second process is verified based on the capability token, specifically as follows: The access request of the second process is verified based on the lifecycle, the second access permission, and the address information of the shared memory region.

6. The method according to claim 5, characterized in that, The capability token also includes: the domain to which the shared memory region belongs. The access request to the second process is verified based on the capability token, specifically as follows: The access request of the second process is verified based on the lifecycle, the second access permission, the address information of the shared memory region, and the domain to which the shared memory region belongs.

7. The method according to claim 2, characterized in that, The first access permission to the shared memory region is configured through a memory protection unit or a memory management unit.

8. A cross-domain communication system based on capability tokens, characterized in that, include: Security domains, non-security domains, and security management devices; The security management device is configured to generate a capability token for a shared memory region and send the capability token to a first process of the security domain, wherein the shared memory region is a region where data is exchanged between the security domain and non-security domains. The first process sends a capability token to the second process in the non-security domain; The second process initiates an access request to the shared memory region to the security management device, the access request carrying the capability token; The security management device is further configured to verify the access request of the second process based on the capability token. If the verification result is valid, the first process and the second process are allowed to conduct cross-domain communication based on the shared memory region. If the verification result is invalid, the second process is rejected.

9. The system according to claim 8, characterized in that, The security management device is further configured to create the shared memory region in response to a shared memory creation request from the first process, wherein the first access permissions for the shared memory region include allowing the non-security domain to access it based on a capability token.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the cross-domain communication method based on capability tokens as described in any one of claims 1-7.

Images