Detailed Description
In order that those skilled in the art will better understand the present application, a technical solution in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, shall fall within the scope of the present application.
It should be noted that the terms "first," "second," and the like in the description and the claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments of the application described herein may be implemented in sequences other than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed or inherent to such process, method, article, or apparatus.
First, partial terms or terminology appearing in the course of describing embodiments of the application are applicable to the following explanation:
A software guard extension (Software Guard Extens ion, abbreviated SGX) is intended to protect critical parts of an application from attacks by malware and privileged software. SGX uses a special memory area called the "enclave" (enclave) in which code and data can be encrypted and isolated in the memory of a computer. This ensures that even in the case of an operating system or virtualized environment being attacked, critical parts of the application are protected from attack;
Physical memory protection (Phys ical Memory Protect ion, referred to as PMP for short) refers to a hardware-level protection mechanism for protecting the physical memory of a computer system from unauthorized access and modification. PMP is typically supported by hardware in the processor or system chip to limit access rights to physical memory to enhance system security and stability;
IOPMP is a hardware level protection mechanism for protecting access to physical memory by input/output devices of a computer system from unauthorized access and modification. The technology can limit the access authority of external equipment to the physical memory at the hardware level so as to enhance the safety and stability of the system;
IOMMU is a hardware device for managing access to memory by input/output devices in a computer system. The main function of the method is to provide mapping and access control for the physical memory for the input/output equipment on the hardware level, thereby realizing isolation and protection of memory access. In short, the IOMMU may provide a hardware-level memory virtualization and isolation mechanism to enhance the security and stability of the system;
Remote direct memory access (Remote Direct Memory Access, referred to as RDMA) is a high performance network communication technology that allows one of the computer systems to directly access the memory of the remote computer system without the intervention of a central processing unit (Central Process ing Unit, referred to as CPU). The ability to directly access the remote memory can greatly improve data transmission efficiency and reduce communication delay, and plays an important role in network communication of high-performance computing and large-scale data centers;
A System On Chip (SoC) is an integrated circuit that integrates a plurality of computer System core components, and generally includes a processor core, a memory controller, an input/output interface, a timer, a peripheral controller, and the like. SoC is a highly integrated chip that integrates multiple components in a traditional computer system onto one chip to achieve a more compact, high performance and low power solution;
DMA, a technology used for data transfer in computer systems. DMA allows external devices (e.g., network adapters, hard disk controllers, etc.) to directly access system memory without intervention by a Central Processing Unit (CPU). The direct memory access technology can obviously improve the efficiency of data transmission, lighten the burden of a CPU and is also beneficial to reducing the delay of a system;
content index address (Content Addressable Memory, abbreviated as CAM) is a type of computer memory used for fast searching. Unlike conventional RAM (Random Access Memory) which accesses data from an address, a CAM is a memory that looks up its storage location based on the data itself. In other words, the CAM allows data to be retrieved based on stored content, rather than based on memory addresses. This makes CAM well suited for high speed find and match operations;
A device identifier (Source IDENT IFICAT ion, abbreviated as SID) refers to a device identifier used in IOPMP inspection. In IOPMP, the SID is used to identify the device that originated the memory access request so that the system can identify the source of the request and verify and control its access rights. When a device initiates a memory access request, the system can use the SID to determine the device identity of the access request and verify it to ensure the validity of the request. This helps prevent unauthorized devices from accessing memory and enhances the control and security of memory access by the system to the input/output devices. In summary, SID plays an important role as device identifier in IOPMP for identifying device identity and performing verification and control of memory access rights;
a Device hardware identifier (DEVICE IDENT IFICAT ion, abbreviated as Device ID) refers to a hardware identifier of a Device, which is an identifier used to uniquely identify and identify the Device. Devices are typically assigned a unique Device ID so that the system can identify and manage the different devices;
A Memory Domain (MD) generally refers to a set of Memory address spaces that are grouped together in a manner to facilitate their management, access, and protection. The concept of memory domain is involved in both computer architecture and operating systems.
Example 1
According to an embodiment of the present application, there is provided a method for determining memory access rights of a device, it being noted that the steps shown in the flowchart of the drawings may be performed in a computer system such as a set of computer executable instructions, and that although a logical order is shown in the flowchart, in some cases the steps shown or described may be performed in an order different from that herein.
The method for determining the memory access permission of the device provided by the embodiment of the application can be applied to an application scenario as shown in fig. 1, but is not limited to the application scenario. In the application scenario shown in fig. 1, the server 10 may be a cloud. The server 10 may be connected to one or more client devices 20 via a local area network connection, a wide area network connection, the internet connection, or other type of data network, where the client devices 20 may include, but are not limited to, smart phones, tablets, notebooks, palmtops, personal computers, smart home devices, vehicle devices, etc., which together constitute a client to the server. An operation interface for obtaining a memory access request for accessing data stored in a memory address of a device may be deployed on a graphical user interface on a client device, where the operation interface may be an operation interface for detecting related operations performed by a user to generate the memory access request. The client device 20 may interact with a user through a graphical user interface, so as to implement the method for determining the memory access permission of the device provided by the embodiment of the present application.
In the embodiment of the present application, the system formed by the client device 20 and the server 10 may perform the following steps, if a user needs to access the data stored in the memory address of the system, a corresponding operation may be performed in the operation interface on the client device 20 of the user to upload a memory access request corresponding to the data to be accessed. After receiving the memory access request, the memory access request may be sent to the server 10 through a network. A IOPMP unit may be deployed in the server 10, and the IOPMP unit is used to check the received memory access request to determine whether it has memory access rights. Specifically, the following steps may be performed in the server 10:
Step S102, obtaining a memory access request of the device, and determining at least one IOPMP item matched in IOPMP units by the device, wherein the memory access request is used for enabling the device to request to access data stored in a memory address corresponding to IOPMP units, and the IOPMP item is used for representing a data structure of IOPMP units;
Step S104, verifying the memory access request in at least one IOPMP item to obtain at least one verification result, wherein the verification result is used for indicating whether the equipment has access rights in the corresponding IOPMP item;
Step S106, based on the verification result, generating an access right result corresponding to the memory access request, wherein the access right result is used for indicating whether the device is allowed to access the data stored in the memory address.
In the above process, the memory access request in the server 10 may be verified through the network, and the obtained access right result is sent to the client device 20. The access rights results may be displayed on an operator interface of client device 20 for viewing by a user. And the user can be provided with corresponding authority to view the data required to be viewed in the memory address of the system.
In the embodiment of the application, a pipelined I/O checking module, namely IOPMP units, is arranged to perform pipelined efficient checking on the memory access request, so that the memory access request of the equipment can be checked in multiple stages, namely, the memory access request is checked in multiple IOPMP items, so that the expenditure of authority checking is reduced, and the clock frequency is not influenced. Therefore, the purpose of reducing the cost of safety access to the equipment is achieved, the technical effect of effectively determining the memory access authority of the equipment is achieved, and the technical problem that the memory access authority of the equipment cannot be effectively determined is solved.
The embodiment of the application provides a method for determining the memory access authority of the device shown in fig. 2 under the application scene. Fig. 2 is a flowchart of a method for determining memory access rights of a device according to an embodiment of the present application, as shown in fig. 2, the method may be applied to an input/output physical memory protection IOPMP unit, and may include the following steps:
in step S202, a memory access request of the device is obtained, and at least one IOPMP entry matched by the device in IOPMP units is determined.
In the solution provided in step S202 of the present application, the Device (Device) may be an I/O Device. Memory access may be an access to a Memory (Mem) of a computer system, i.e., to data stored in a Memory address of the system. Computer systems may also be referred to as systems in embodiments of the application. The memory access Request may be used to make the device Request to access the data stored in the memory address corresponding to the IOPMP unit, and may be a Request for the device to access the corresponding data stored in the memory address of the computer system, for example, may be a DMA Request (DMA Request, abbreviated as Req) or may be an I/O Request, where the memory address and the Request data may be included, that is, the memory access Request may be filled with the Request data (data) that needs to be accessed, and the memory address (Addr) where the Request data is located. The request data may be confidential data in a memory address.
Alternatively, the IOPMP most basic structure is an array of entries IOPMP, i.e., IOPMP entries may be used to represent the IOPMP element data structure. The Entry array may contain a large number IOPMP of entries, wherein the Entry array IOPMP may also be referred to as an input/output physical memory protection table (IOPMP Table), or an input/output physical memory protection Entry table (IOPMP Entry TABLE), and the IOPMP entries in the Entry array may be denoted as Entry0, entry x, entry x+1. It should be noted that, the present disclosure is merely illustrative, and the IOPMP entries and the representation method in the entry array are not particularly limited.
In this embodiment, if it is detected that the device has a memory access request to access data stored in a memory address of the computer system, the memory access request may be input into IOPMP units, and IOPMP entries matching the memory access request may be determined.
Optionally, if the user needs to access the data stored in the memory address of the computer system, a corresponding operation may be performed on the client device of the user, for example, the request data to be accessed may be input, the memory address stored in the request data may be input, and a corresponding memory access request may be created through the request data and the memory data required by the user.
Optionally, after the user inputs the corresponding memory access request from the client device, the memory access request may be transmitted to IOPMP units in the server through the network. The memory access request may be obtained by using IOPMP, and IOPMP entries matching with the device that currently issues the memory access request may be screened from the entry array in IOPMP units, where IOPMP units may also be IOPMP checker (IOPMP Checker) that may be used to check whether the memory access request has access rights.
In the related art, the above-mentioned two common hardware I/O isolation mechanisms of IOMMU and TEE have at least the problem that IOMMU may have performance problems under heavy workload because of expensive Input/output translation bypass buffer (Input/Output Trans lat ion Lookas ide Buffer, IOTLB) failure using asynchronous command queues. For the I/O isolation mechanism in a TEE, memory encryption may result in additional memory duplication, thereby degrading I/O performance, and for the IOMMU, it only supports page-level isolation, which may be inadequate for some direct memory access (Direct Memory Access, DMA) scenarios. While for the I/O isolation mechanism in a TEE, some implementations may be limited by the number of security domains, the number of devices, and the risk of communication between security domains, in an IOMMU, complex page tables and I/O virtual address configurations may result in malicious device exploitation vulnerabilities, bypassing the checking of the IOMMU. In TEE, there are attacks that are difficult to prevent, such as replay attacks, security domain switching loopholes, etc., and the setting of IOMMU may result in poor scalability, such as input/output virtual address (I/OVirtual Address, abbreviated as IOVA) allocation and IOTLB becoming a bottleneck in multi-device and tenant scenarios. While for TEE, some implementations may have device count limitations and security domain count limitations, which also affect its extensibility. Therefore, there is still a technical problem that the safety and reliability of the system are low.
However, in the embodiment of the present application, a IOPMP unit is provided, and by using the IOPMP unit, it can be determined whether the data in the memory address of the device access system has access rights, and IOPMP can limit the access of the I/O device to the memory, that is, can limit the specific input/output device to only access the specific memory area, thereby improving the control of the system to external access. IOPMP can perform memory isolation, namely, the access of the device to the memory can be effectively isolated, the irrelevant device is prevented from unauthorized access to the memory, and the security of the system is improved. IOPMP the device can prevent illegal access, i.e., through IOPMP mechanism, the system can effectively prevent unauthorized devices from accessing memory, preventing malware or unauthorized programs from modifying critical system memory areas. IOPMP is commonly used in embedded systems, operating system kernels, virtualized platforms, etc. to enhance the security and stability of the system. Through IOPMP mechanisms, the system can carry out fine-granularity authority control on the access of the input/output equipment to the physical memory, effectively prevent the unauthorized access to the memory, and realize the technical effect of improving the safety and reliability of the system.
Step S204, the memory access request is verified in at least one IOPMP item to obtain at least one verification result.
In the technical solution provided in the above step S204 of the present application, the verification result may be used to indicate whether the device has the access right in the corresponding IOPMP entries, which may also be referred to as the result of the I/O right check (I/O check), the right check result, and the intermediate result. The access rights may be I/O rights.
In this embodiment, after the memory access request of the device is obtained and the IOPMP entry matched in the IOPMP unit by the device is determined, the memory access request may be verified in the IOPMP entry, so as to obtain a corresponding verification result.
Optionally, after determining IOPMP entries matching the device, for the memory access request, a separate verification may be performed for each matched IOPMP entry to verify whether the device has access rights to the corresponding IOPMP entry.
In an embodiment of the present application, IOPMP units may be utilized to pipeline the memory access request. During the checking, at least one IOPMP entry that matches the device that is currently issuing the memory access request may be determined. If the number of the matched IOPMP items is multiple, in the pipeline form checking process, a multi-stage pipeline can be set, and parallel authority checking can be realized in each stage of pipeline, namely, the I/O authorities of memory access requests under the multiple IOPMP items can be determined in parallel. By the method, the purpose of improving the efficiency of determining the memory access permission is achieved by performing tree-shaped parallel permission check on the memory access request, the purpose of improving the performance and the expandability of the computer system is achieved, and the technical effect of effectively determining the memory access permission of the device is achieved.
Optionally, when performing authority checking on the set multi-stage pipeline, a task parallel mode may be adopted for performing authority checking on each stage pipeline, for example, tree parallel in task parallel may be adopted, so that efficiency of authority checking is improved.
It should be noted that, the above parallel manner of performing authority checking on each stage of pipeline is only illustrative, and is not limited herein, and any method and process capable of setting up multiple stages of pipelines and performing authority checking on each stage of pipeline are within the scope of the embodiments of the present application.
Step S206, based on the verification result, generating an access right result corresponding to the memory access request.
In the technical solution provided in the above step S206 of the present application, the access right result may be used to indicate whether the device is allowed to access the data stored in the memory address, which may also be referred to as a final decision, a final access right of the DMA request, or a final I/O access right.
In this embodiment, after the memory access request is verified in IOPMP entries, the access permission result corresponding to the memory access request may be generated based on the verification result after the verification result is obtained.
Optionally, after determining the verification result of the current memory access request under each IOPMP entries, the verification results of the above IOPMP entries may be combined to determine whether the memory access request has permission to access data in a memory address in the system.
Through the steps S202 to S206 of the present application, if the memory in the system needs to be accessed, the memory access permission of the device can be determined first. In the process of determining the memory access authority, a IOPMP unit is set in order to reduce the cost of carrying out secure access on the equipment. If a memory access request is obtained that requires access to the memory of the system, then IOPMP may be utilized to check the memory access request. During the checking, the device may be caused to request access to data stored in the memory address corresponding to IOPMP units using the memory access request. And may determine IOPMP entries that the device matches in IOPMP units. The memory access request may be verified in IOPMP entries to determine whether the device has access rights in the corresponding IOPMP entry, and a corresponding verification result is obtained. And determining whether the current memory access request is allowed to access data in a memory address in the device based on whether the IOPMP entry has access rights. In the embodiment of the application, a pipelined I/O checking module (i.e. IOPMP units) is arranged to perform pipelined efficient checking on the memory access request, so that the memory access request of the device can be checked in multiple stages, namely, in a plurality of IOPMP item checks, to reduce the expenditure of authority checking and not influence the clock frequency. Therefore, the purpose of reducing the cost of safety access to the equipment is achieved, the technical effect of effectively determining the memory access authority of the equipment is achieved, and the technical problem that the memory access authority of the equipment cannot be effectively determined is solved.
The above-described method of this embodiment is further described below.
As an optional implementation manner, step S204, the memory access request is verified in at least one IOPMP item to obtain at least one verification result, including determining the priority order of at least one IOPMP item, and verifying the memory access request in at least one IOPMP item according to the priority order to obtain at least one verification result.
In this embodiment, in the process of verifying the memory access request under IOPMP entries, the priority order of IOPMP entries may be determined, and the memory access request may be verified under IOPMP entries according to the priority order, to obtain a verification result, where the priority order may also be referred to as priority.
Optionally, after determining IOPMP requests that match the device of the current memory access request, a priority order between the matching IOPMP requests may be determined. And uses IOPMP checker to verify memory access requests one by one under IOPMP according to the priority order described above, generating intermediate results.
As an alternative implementation, the memory access request is verified in at least one IOPMP item according to the priority order to obtain at least one verification result, which comprises determining a first IOPMP item in at least one IOPMP item according to the priority order, verifying the memory access request in a first IOPMP item to obtain a first verification result, wherein the verification result comprises the first verification result, and if at least one IOPMP item comprises the next second IOPMP item of the first IOPMP item in the priority order, verifying the first verification result in a second IOPMP item to obtain a second verification result, wherein the verification result comprises the second verification result.
In this embodiment, in validating the memory access request in IOPMP entries in the order of priority, the first IOPMP entry may be determined in the matching IOPMP entry in the order of priority. And verifying the memory access request in the first IOPMP item to obtain a first verification result. If IOPMP entries include the next second IOPMP entry in the priority order of the first IOPMP entry, the first verification result may be verified in the second IOPMP entry, so as to obtain a corresponding second verification result.
Optionally, the first IOPMP entry may be used to represent a IOPMP entry under a first pipeline stage of the plurality of pipeline stages in the IOPMP checker. The second IOPMP entry may be used to represent a IOPMP entry under a first pipeline stage, and a second, following pipeline stage, of the plurality of pipeline stages in the IOPMP checker. The verification result may include a first verification result and a second verification result. The first validation result may be an intermediate result of validating the first IOPMP entries for the first pipeline stage. The second validation result may validate the intermediate result obtained by the second IOPMP entry for a second pipeline Stage, where the first pipeline Stage may be the first Stage (Stage-1), i.e., the first Stage in the pipeline. The second pipeline Stage may be the second Stage (Stage-2). The first IOPMP entries have a higher priority than the second IOPMP entries, i.e., the first IOPMP entries are High priority and the second IOPMP entries are Low priority. The priority order may also be referred to as static priority.
Optionally, the IOPMP checker may include multiple pipeline stages, and the memory access request is validated by respective IOPMP entries under different pipeline stages to obtain corresponding intermediate results.
Alternatively, from the number IOPMP of IOPMP TABLE, a IOPMP entry may be determined that matches the device of the current memory access request. The order of priority in the matching IOPMP entries may be determined. If IOPMP entries in the priority order can be the first IOPMP entry, then the I/O permission check of Stage-1 can be performed and an intermediate result, i.e., the first validation result, can be generated. A second IOPMP entry having a lower priority order than the first IOPMP entry may be determined and an I/O permission check of Stagr-2 may be performed and a corresponding intermediate result, i.e., a second validation result, generated.
Optionally IOPMP is an isolation mechanism for normalizing accesses issued by bus masters and protecting against malicious DMA attacks. It manages the access rights of the device to the physical memory to ensure that the device can only access its authorized memory area. Each master or group of masters having the same bus access rights has a unique identifier called a source ID (i.e., SID). This identifier is used to identify the identity of the device or master to control its access rights to the memory. MD may be used to organize the physical memory that each device may access. A memory domain comprises several consecutive memory regions, each of which may have different access rights. This mechanism allows fine-grained access control to memory. The MD includes three memory areas, a receiving (RECEIVE AREA, abbreviated as RX) area, a transmitting (TRANSMIT AREA, abbreviated as TX) area, and a control register area, the RX area and TX area being used to store input and output data, respectively. By storing data in different regions and assigning different access rights to each region, strict control and protection of the data can be achieved. In general, the standard IOPMP isolation mechanism describes a mechanism for fine-grained management of memory access rights by devices, with fine control of device access being achieved through the SID and memory domain. This mechanism is critical to ensure security and privacy protection of device access.
Optionally IOPMP is a basic structure for managing memory access rights of a device. IOPMP the most basic structure of IOPMP is an array of entries, each indexed from zero, defining a rule when checking transactions. Each IOPMP entry includes a memory region and read/write permissions for that region. This means that each entry describes the access rights to a particular memory region. Each IOPMP entry belongs to only one memory domain, and a memory domain may contain multiple IOPMP entries. Any SID associated with a memory domain is also associated with all IOPMP entries belonging to that memory domain. This association ensures that the access rights to the memory area are effectively managed. IOPMP entries have a static priority, with small numbered entries having a high priority. This means that entries with lower numbers will have higher priority. Upon issuing a transaction IOPMP checks for a match of the transaction with IOPMP entries in order of priority. If the transaction matches the IOPMP entry, IOPMP will check the read/write permissions within that entry. This means that IOPMP is responsible for ensuring that the access rights of the device to the memory meet predefined rules.
In summary, the IOPMP entry array is a basic structure of IOPMP, and is used for managing and controlling access rights of devices to the memory. Each entry describes access rights to a particular memory region while ensuring efficient management of access rights through association with the memory region and SID. The priority and rights checking mechanism ensures security and privacy protection for device access.
Optionally, IOPMP's behavior is controlled by several configuration register tables. Such as a Source identifier to memory domain mapping (Source IDENT IFIER to Memory Domain Mapping, simply SRC2 MD) table that identifies the memory domain associated with a given SID. It consists of multiple sets SRCSMD of registers, each with 64 bit space and two fields, SRC S MD.L and SRC SMD.MD.SRCS MD.L being the lock bit flags of the register, and SRC S MD.MD being a bitmap field for showing whether memory field m is associated with this SID. Memory domain configuration (Memory Domain Configurat ion, abbreviated MDCFG) table defining the relationship between IOPMP entries and memory domains. It has a series of configuration registers, with each register MD m CFG for memory domain m. In the MD m CFG register, MD m cfg.t indicates the last index of the IOPMP entry belonging to memory domain m. Alternatively, if MD m-1CFG.T≤j<MDm CFG.T, then the IOPMP entry with index j belongs to memory domain m, where m >0. Memory field 0 has IOPMP entry with index j < MD 0 cfg.t. The configuration register table is used to define the relationship between the memory domain and the SID, and the relationship between IOPMP entries and the memory domain. Through the configuration register table, the behavior of IOPMP can be accurately controlled, and the access authority of the equipment to the memory is ensured to be effectively managed and controlled. This provides an important guarantee for security and privacy protection of device access.
As an alternative embodiment, the method may include determining the third IOPMP item as the second IOPMP item if the at least one IOPMP item includes the next third IOPMP item of the second IOPMP item in the priority order, determining the second verification result as the first verification result, and returning to performing the steps of verifying the first verification result in the second IOPMP item until the at least one IOPMP item does not include the next third IOPMP item of the second IOPMP item in the priority order.
In this embodiment, if IOPMP entries further include the next third IOPMP entry in the priority order of the second IOPMP entry, then the third IOPMP entry may be determined to be the second IOPMP entry and the second verification result may be determined to be the first verification result. And may return to executing the step of verifying the first verification result in the second IOPMP item until the IOPMP item does not include the next third IOPMP item in the priority order of the second IOPMP item, to obtain a second verification result.
Optionally, if the IOPMP entries matched with the current device include, in addition to the first IOPMP entry and the second IOPMP entry, a third IOPMP entry having a priority lower than that of the first IOPMP entry and the second IOPMP entry, then the third IOPMP entry may be determined to be the second IOPMP entry, and the I/O permission check may be performed on the memory access request under the corresponding pipeline stage, so as to obtain a corresponding intermediate result. Until no other IOPMP entries exist in the matching IOPMP entries.
In an embodiment of the application, a IOPMP pipeline (IOPMP Pipel ine) may be included in IOPMP units, i.e., the IOPMP checker may be a IOPMP checker in pipeline form. IOPMP the pipeline may perform multi-stage checking, i.e., the I/O check may be performed in multiple stages, each stage performing a particular check task, e.g., match checking, permission verification, etc., according to priority. Such a staged arrangement helps to improve the parallelism and throughput of I/O checks. IOPMP pipelines may perform parallel processing, i.e., different stages may process different I/O requests in parallel, thereby speeding up the overall I/O inspection process. This is critical to improving the efficiency and performance of I/O checks. IOPMP the pipeline may perform high bandwidth processing, i.e., in a pipelined fashion that helps to increase the bandwidth processing capacity of the I/O check, enabling the system to more efficiently process large numbers of I/O requests. By means of the IOPMP checker in the pipeline form, the requirement of bandwidth-sensitive I/O access control can be better met, and particularly when a large number of DMA requests are faced, efficient access control and protection can be provided. This arrangement helps to improve the security and reliability of the system for I/O access.
As an optional implementation manner, the first verification result is verified in the second IOPMP item to obtain a second verification result, and the method comprises the steps of determining a sub-check module corresponding to the second IOPMP item in a IOPMP unit, and performing parallel verification on the first verification result and the second IOPMP item by using a first tree arbitration circuit in the sub-check module to obtain the second verification result.
In this embodiment, in the process of verifying the first verification result in the second IOPMP entry to obtain the second verification result, in the IOPMP unit, the sub-inspection module corresponding to the second IOPMP entry may be determined. And in the sub-checking module, the first verification result and the second IOPMP item can be verified in parallel by using a first tree-shaped arbitration circuit to obtain a second verification result, wherein the first tree-shaped arbitration circuit can be a linear arbitration (l inear arbitrat ion) circuit, that is, the IOPMP checker is a IOPMP checker based on tree-shaped arbitration logic. IOPMP the checker may include a plurality of sub-check modules, which are connected by pipeline registers.
Optionally, by combining IOPMP pipelines and IOPMP tree arbitration circuits, the overhead of entitlement checking is further reduced to improve the efficiency of the system to I/O access.
Optionally, the IOPMP checker includes a plurality of sub-check modules that are connected by pipeline registers. This means that multiple sub-inspection modules can perform the authority inspection at the same time without waiting for the completion of the previous authority inspection, i.e., this arrangement can realize parallel processing of multiple sub-inspection modules and connect through pipeline registers, contributing to an increase in the overall inspection processing speed. Each sub-checking module employs tree arbitration circuitry, meaning that they can check the permissions of multiple IOPMP entries in parallel. The tree arbitration circuit can effectively process a plurality of authority check demands, and the overall check efficiency and throughput are improved. The part of the final authority result obtained by the tree arbitration circuit is written into the pipeline register. Thus, the authority check result can be temporarily stored in a register, and the subsequent processing is convenient. And generating the authority in each stage of pipeline inspection according to the pipeline priority to obtain the final I/O access authority as the final access authority of the DMA request. This means that the final access rights are generated by the priority of the pipeline to determine the final access rights of the DMA request.
Optionally, the tree arbitration circuit is configured to coordinate the checking of the permissions of the plurality IOPMP of entries by the plurality of sub-checking modules. The tree arbitration circuit can effectively process a plurality of authority check demands and can process a plurality of check tasks in parallel through pipeline register connection, thereby improving the efficiency and throughput of the whole check. The role of the tree arbitration circuit is to coordinate and manage the permission check requests of the sub-check modules to ensure that multiple permission checks are performed efficiently. The tree arbitration circuit realizes that a plurality of sub-checking modules check the authority of a plurality of IOPMP entries, and the process can be regarded as tree-like parallel task allocation and processing. Different sub-checking modules can perform authority checking on different IOPMP items in parallel through the tree arbitration circuit, so that the efficiency of overall authority checking is improved. Therefore, the tree arbitration circuit is matched with the tree parallel mode utilized by the authority check, so that the parallel processing of a plurality of IOPMP item authorities and the determination of the final access authorities are realized together.
Through the analysis, the tree blanking circuit corresponds to the tree parallel mode, and the parallel authority check is realized together. Because of the tree-like and parallel operation, the corresponding tree-like blanking circuit is also an example. In the embodiment of the application, the tree arbitration circuit and the tree parallelism are not limited, and the tree arbitration circuit and the tree parallelism are all within the protection scope of the embodiment of the application as long as the parallel mode, the corresponding blanking circuit and the specific parallel authority checking process under the corresponding parallel mode and the blanking circuit can be used for parallel authority checking.
In a comprehensive view, the application can process a plurality of authority checking demands in parallel by combining IOPMP pipelines and tree arbitration circuits, and simultaneously save intermediate results through pipeline registers to finally generate the final access authority of the DMA request, thereby reducing the expenditure of authority checking.
As an alternative implementation mode, the method can comprise the step of writing a second verification result output by the first tree-shaped arbitration circuit into a register.
In this embodiment, the second verification result output by the first tree arbitration circuit may be written into a register, where the register may be a pipeline register.
Optionally, there are multiple pipeline stages in IOPMP checker, each IOPMP entry is validated at a different pipeline stage, and the intermediate result is stored in a Register (REG).
Optionally, the IOPMP checker setting in pipeline form is indeed suitable for improving the efficiency of the I/O access control, solving the bandwidth-sensitive application scenario. The IOPMP checker takes as input the memory address, the request data, and IOPMP entry. The data will be used to perform multi-stage I/O access control checks. The masker may be used to filter IOPMP entries, selecting an entry corresponding to the current device ID. This helps to reduce the number of items that need to be inspected, improving inspection efficiency. IOPMP the checker has a plurality of pipeline stages, each stage validating a respective IOPMP entry and storing intermediate results in registers. This staged arrangement improves the parallelism and throughput of the overall I/O check. After passing all I/O permission checks, IOPMP checker generates a final decision to determine if the memory access is authorized. This ensures security verification for each access request.
As an optional implementation manner, the first verification result is verified in the second IOPMP item to obtain a second verification result, which includes determining a time period corresponding to the second IOPMP item, and verifying the first verification result in the second IOPMP item in the time period to obtain the second verification result.
In this embodiment, in the process of verifying the first verification result in the second IOPMP entry to obtain the second verification result, the time period corresponding to the second IOPMP entry may be determined. And verifying the first verification result in the second IOPMP items in a time period to obtain a second verification result, wherein the second Tree arbitration circuit can be a IOPMP Tree arbitration circuit (Tree-based Arbitrat ion).
Optionally, with respect to pipeline setup, there is a real need to address some new issues, especially the state consistency issue between the bus and IOPMP checker. To address this problem, the addition of a Monitor helps to maintain consistency in the blocking state between the bus and IOPMP checker. This arrangement helps ensure the validity of the I/O access control and system performance.
Optionally, IOPMP tree arbitration circuitry employs a tree structure to implement prioritized I/O permission checks, aimed at reducing latency of the checks. This approach can effectively reduce the checking delay to a logarithmic level (log (N)), thereby improving the efficiency and performance of the system for I/O access.
Optionally, at IOPMP the tree arbitration circuit may reduce the inter-seed results to obtain access rights results.
In an optional implementation manner, step S206, generating an access right result corresponding to the memory access request based on the verification result, includes determining a second tree-shaped arbitration circuit in IOPMP units, and performing reduction processing on at least one verification result according to the priority order in the second tree-shaped arbitration circuit to obtain the access right result, wherein the verification result corresponds to a node of the second tree-shaped arbitration circuit.
In this embodiment, in the process of generating the access authority result corresponding to the memory access request based on the verification result, in IOPMP units, the second tree arbitration circuit may be determined. In the second tree-like arbitration circuit, at least one verification result can be reduced according to the priority order to obtain an access right result, wherein the verification result can correspond to a node of the second tree-like arbitration circuit.
Optionally, the IOPMP checker based on tree arbitration logic has the feature that the IOPMP checker compares the authority of each IOPMP entry pair by pair according to priority and generates intermediate results. The intermediate results are processed in a subsequent reduction stage. Tree structure reduction, which reduces intermediate results in tree structure circuits. Unlike other possible optimization checking circuits using back-end EDA tools, tree-based arbitration is implemented at the register transfer level (REGISTER TRANSFER LEVEL, abbreviated as RTL), with more information and human-involved optimizations. The method can adopt different tree structures according to actual requirements to meet different requirements of time sequence (binary tree) and area (N-ary tree) so as to balance different setting targets. And (3) obtaining authority verification results, wherein all the authority verification results reach a final root node according to a priority protocol, and the authority of the root node is the final I/O access authority. Through reduction of the tree structure, combination and final decision of the I/O authority can be efficiently realized.
In summary, the IOPMP checker based on tree arbitration logic utilizes a tree structure to implement reduction and final decision of I/O permissions. The method has high flexibility and optimizability, can perform different levels of optimization according to actual demands, and can efficiently realize effective management of I/O rights.
In the embodiment of the application, a novel scheme for realizing the checking of the I/O authority of the priority is provided, namely a IOPMP tree arbitration circuit based on tree arbitration logic. The scheme reduces latency of the entitlement check to log (N) level through tree arbitration logic. Specifically, the scheme includes the steps of IOPMP the checker comparing the permissions of each IOPMP entry pair-by-pair according to priority and generating an intermediate result. This means that a series of pair-wise comparisons are made in the checker to determine the rights of each IOPMP entry. Next, the intermediate result is reduced using a tree structure circuit. This means that the intermediate results are organized into a tree structure and reduced by logical operations. Unlike using the back-end EDA tool optimization checking circuitry, tree-based arbitration is implemented at the RTL level, meaning that it has more information and human-involved optimization. For example, different tree structures, such as binary and N-ary trees, may be employed depending on the timing and area requirements. And finally, the authority verification result is transmitted to a final root node according to a priority specification, and the authority of the root node is the final I/O access authority. This means that multi-level rights verification is performed by the tree arbitration logic and the result is reduced to the final root node, thereby determining the final I/O access rights. In general, the IOPMP tree arbitration circuit based on the tree arbitration logic realizes efficient priority I/O authority check in a pair-by-pair comparison and tree reduction mode, and optimizes at the RTL level to meet different time sequence and area requirements.
As an optional implementation manner, in the second tree-shaped arbitration circuit, at least one verification result is reduced according to the priority order to obtain an access right result, and the method comprises the steps of determining a root node of the second tree-shaped arbitration circuit, and reducing at least one verification result to the root node according to the priority order to obtain the access right result.
In this embodiment, in the second tree-like arbitration circuit, in the process of performing reduction processing on at least one verification result according to the priority order to obtain the access right result, the root node of the second tree-like arbitration circuit may be determined, and the verification result may be reduced to the root node according to the priority order to obtain the access right result.
Optionally, after determining the root node of the IOPMP tree arbitration circuit, the authority of the root node can be the final I/O access authority according to the priority to the final root node.
Optionally, the final authority verification result is transmitted to the final root node according to the priority specification, and the authority of the root node is the final I/O access authority. This means that multi-level rights verification is performed by the tree arbitration logic and the result is reduced to the final root node, thereby determining the final I/O access rights.
As an optional implementation mode, the method can comprise the steps of generating a missing interrupt signal in the case that source identification information of the device is missing, wherein the missing interrupt signal is used for representing that the source identification information is missing, responding to the missing interrupt signal, interrupting execution of a memory access request and obtaining extension source identification information of the device, and loading the extension source identification information into an extension register table corresponding to a register table of a IOPMP unit, wherein the register table corresponds to an active identification information set and is used for identifying a memory domain associated with the source identification information in the source identification information set, and the extension register table is obtained by extending registers in the register table.
In this embodiment, in the event that the source identification information of the device is missing, a missing interrupt signal may be generated. When the interrupt signal is missing, the execution of the memory access request is interrupted, and the extension source identification information of the equipment is acquired. The extended source identification information may be loaded into an extended register table corresponding to the registers of IOPMP units.
Alternatively, the source identification information may be a device identifier SID. The Extended Source identification information may be an Extended device identifier (Extended Source IDENT IFIER, abbreviated eSID). The register table may be an SRC2MD table, may correspond to a set of source identification information, and is used to identify a memory domain associated with source identification information in the set of source identification information, i.e. to identify a memory domain associated with a given SID. The Extended register table may be an Extended Source identifier to Memory Domain mapping register (Extended Source IDENT IFIER to Memory Domain MAPPING REGISTER, abbreviated eSRCMD), that is, an Extended on-chip SRC2MD register.
Optionally, the mountable segment table in IOPMP is reserved in protected memory. The mountable IOPMP segment table is reserved in protected memory as compared to the entry table in IOPMP or the SRC2MD table. This means that the aforementioned mountable segment table is stored in a protected memory area, e.g. in PMP protected memory in a reduced instruction set computer-V (Reduced Instruct ion Set Computer-V, abbreviated RISC-V). Such a setting may ensure that unauthorized software or devices cannot directly access the segment table, thereby enhancing security. Since the mountable IOPMP segments of the table are retained in protected memory, unauthorized software or devices cannot directly access the table. Such an arrangement provides an effective security mechanism ensuring that access rights to the table are controlled. Based on the above settings, there is no hardware limitation on the size of the mountable IOPMP-segment table, provided that the physical memory is sufficient. This means that the size of the attachable IOPMP-segment table can be extended as needed with sufficient physical memory support without limitation in terms of hardware.
In combination, this arrangement of retaining the mountable IOPMP-segment table in protected memory provides an effective security mechanism that ensures that access rights to the table are controlled and that there are no hardware limitations on the mountable-segment table size with sufficient physical memory support.
Optionally, the specific content of the extension to the existing IOPMP entry table may include an extended SRC2MD register (on-chip), i.e., eSRCMD, which means that the original SRC2MD register is extended to support new functions or attributes. The extended register eSRCMD may be used to store information about more devices or I/O resources to more fully manage access rights to such resources. The extended device identifier, i.e., eSID, which means that the device identifier is extended, possibly to support more kinds or complex device identifications, in order to more finely manage the rights control of the devices. The cold device associated memory domain index, i.e., MD, represents an extension to the cold device associated memory domain index to more flexibly manage the memory access rights associated with the devices. Rights to the cold device extra IOPMP entry (Extend IOPMP Entry), which means that rights extensions are made to the cold device extra IOPMP entry, possibly to support more kinds or complex rights control requirements.
In combination, the above-described extension content extends the functionality and rights-related extensions of existing IOPMP-entry tables to support more kinds or complex device and rights management requirements.
As an optional implementation mode, the method further comprises the steps of matching the extension source identification information with the hardware identification information of the equipment in the memory access request under the condition that the extension source identification information is loaded into the extension register table, and canceling interrupt execution of the memory access request if the extension source identification information is successfully matched with the hardware identification information of the equipment in the memory access request.
In this embodiment, in the case of loading the extension source identification information into the extension register table, the extension source identification information and the hardware identification information of the device in the memory access request may be matched (matched) to determine whether the matching is successful. If the matching between the extended source identification information and the hardware identification information of the device in the memory access request is successful, the interrupt execution of the memory access request can be canceled, wherein the hardware identification information of the device can be a device ID.
In an embodiment of the present application, a procedure called "cold device switch" is provided, which is performed when the device identifier is not in the on-chip SRC2MD table, as follows, IOPMP the checker generates a SID miss interrupt signal. This means that when it is detected that the device identifier is not in the on-chip SRC2MD table, the IOPMP checker will generate an interrupt signal to inform the system that a device identifier miss has occurred. The security monitor (Secure monitor) handles this interrupt by fetching the corresponding IOPMP entry in the mountable IOPMP-segment table and loading eSID, memory fields into the eSRCMD register on-chip and the additional IOPMP entry into the last memory field in the IOPMP-entry table on-chip. This means that the security monitor will handle the interrupt and perform the corresponding operations, including fetching the corresponding IOPMP entry in the mountable IOPMP-segment table, loading eSID and memory fields into the eSRCMD register on-chip, and loading the additional IOPMP entry into the last memory field in the IOPMP-segment table.
In summary, this "cold device switching" procedure is to process the missing device identifier, and by generating an interrupt signal and processing the interrupt signal by the security monitor, it is ensured that the system can correctly process the situation that the device identifier is not in the on-chip SRC2MD table, so as to ensure stable and safe operation of the system, where in the embodiment of the present invention, the last memory domain may be MD62, which is merely illustrative and not limiting.
As an alternative implementation, step S204, determining at least one IOPMP entry that the device matches in IOPMP units includes determining at least one IOPMP entry corresponding to hardware identification information of the device in IOPMP entry set of IOPMP units.
In this embodiment, in determining at least one IOPMP entry that the device matches in IOPMP units, at least one IOPMP entry corresponding to the hardware identification information of the device may be determined in IOPMP entry set of IOPMP units, where IOPMP entry set may be an entry array. The at least one IOPMP entry corresponding to the hardware identification information of the device may be a IOPMP entry associated with the cold device.
Optionally, once the corresponding eSID of the cold device is loaded into the eSRCMD register in the SRC2MD, the Secure Input/output memory management unit page table (Secure Input/Output Memory Management Unit Page Table, sIOPMP for short) may continue to check the DMA request further.
Optionally, further checking of the DMA request by sIOPMP may include the step of comparing eSID in the SRCMD table with the device ID in the DMA packet. This means that eSID in the SRCMD table is compared to the device ID in the DMA request to determine if they match. When eSID matches the device ID in the DMA request successfully, the interrupted DMA request is allowed to continue execution. Once eSID matches the device ID in the DMA request successfully, the system will allow the interrupted DMA request to continue execution. The IOPMP checker selects IOPMP entries associated with the cold appliance. That is, through the above operations, after a successful match, the selection of IOPMP entries associated with the cold device using the IOPMP checker is implemented, where the entries are located in the last memory domain and other memory domains associated with the device.
Optionally, based on the selected IOPMP entries, a staged permission check is performed in a multi-stage tree IOPMP checker to generate final device I/O access permissions. Based on the IOPMP entries selected, the system will enter a multi-stage tree IOPMP checker for staged permission checks to generate the final device I/O access permissions.
Since the cold device switch occurs only in the first DMA request, the subsequent DMA requests will not require additional operations and all the permission check information can be obtained directly from the on-chip hardware, so the cold device switch provides a fast check path for the cold device.
Taken together, the above steps describe that once the corresponding eSID of the cold device is loaded into the eSRCMD register in the SRC2MD, the system performs further checking and processing on the DMA request, ensuring the validity of the fast checking path for the cold device switch.
As an alternative implementation mode, the method can comprise the steps of determining source identification information of the device corresponding to the hardware identification information of the device in a device identification information table if the hardware identification information of the device corresponding to the memory access request is found in the device identification information table, wherein the device identification information table is used for representing a mapping relation between the source identification information of the device and the hardware identification information of the device, indexing a register table based on the source identification information of the device, and determining that the device is in a hot state.
In this embodiment, if the hardware identification information of the device corresponding to the memory access request is found in the device identification information, the source identification information of the device corresponding to the hardware identification information of the device may be determined in the device identification information table. The register Table may be retrieved based on the Source identification information of the device and it may be determined that the device is in a hot state, i.e. the device is a hot device, wherein the device identification information Table may be a device identifier to Source identifier mapping Table (DEVICE IDENT IFIER to Source IDENT IFIER MAPPING Table, abbreviated as DeviceID2 SID). The source identification information may be the retrieved SID. The DeviceID2SID table may also be referred to as a Device2SID table. The device identification information may be used to represent a mapping relationship between source identification information of the device and hardware identification information of the device, that is, a mapping relationship between an actual device ID and a SID used in sIOPMP is recorded in the DeviceID2 SID.
In the embodiment of the application, a deviceID2SID table is introduced and IOPMP remapping mechanisms are added to cope with dynamic I/O tasks. The DeviceID2SID table records the mapping relationship between the actual device IDs and the SIDs used in sIOPMP. If a device changes from a cold state to a hot state, a switch in device state may be achieved by resetting the mapping in the DeviceID2SID table and assigning it a new hot SID. The remapping mechanism and the introduction of the DeviceID2SID table enable the system to dynamically adapt to changes in I/O task load. When the device state changes, the SID can be reassigned by remapping the mapping relationship in the table to effect the switching of the device state. The mechanism can effectively manage dynamic I/O tasks, and ensures that the system can flexibly adapt to the changing task demands.
Optionally, a CAM is utilized to implement a fast and efficient SID lookup process to ensure system critical path performance. CAM is a special memory that can compare input search data with a stored data table and return the address of the matching data. In the DeviceID2SID table, CAM is very suitable for this case, since the number of SIDs of the hot device is limited. Since the number of SIDs for a thermal device is less than 63 in the present embodiment, CAM is very suitable for this case. Since the number of SIDs is fixed, the CAM may treat the SIDs as addresses and the device IDs as content. Such a setup enables the CAM to perform a device ID to SID lookup very efficiently, since the SID is considered an address and its number is limited, in the CAM it is possible to match and return the corresponding SID address very quickly. In general, the present application implements a DeviceID2SID table using CAM, using SID as address, and device ID as content, to implement a fast and efficient SID lookup process. This arrangement is very suitable for cases with a limited number of SIDs, and ensures that the system can quickly find the device ID to SID in the critical path.
As an alternative implementation mode, the method can comprise the steps of determining that the hardware identification information of the device is extension source identification information and determining that the device is in a cold state if the hardware identification information of the device is not found in the device identification information table, matching values in the extension source identification information and the extension register table, determining that the device is in a use state if the values in the extension source identification information and the extension register table are successfully matched, and triggering a missing interrupt signal if the values in the extension source identification information and the extension register table are failed to be matched.
In this embodiment, if the hardware identification information of the device is not found in the device identification information table, it may be determined that the hardware identification information of the device is extension source identification information and that the device is in a cold state. The extension source identification information and the value in the extension register table may be matched. If the matching of the extended source identification information and the values in the extended register table is successful, the device can be determined to be in a use state. If the matching of the extension source identification information and the value in the extension register table fails, a missing interrupt signal can be triggered.
Optionally, after adding the DeviceID2SID table, the I/O check flow is such that the device ID will search in the DeviceID2SID table after receiving the DMA request. This means that the system will first use the device ID to look up in the DeviceID2SID table to determine its corresponding SID. If the match is successful, the retrieved SID will be used to index the subsequent SRC2MD table, which is considered a hot device. If a corresponding SID is successfully matched in the DeviceID2SID table, the system will use the SID to index into the subsequent SRC2MD table to determine that the device is a hot device. Otherwise, this device ID will be considered eSID, i.e. the device is a cold device.
Optionally, eSID are matched to the values in the eSRCMD register, which, if matched, indicates that the cold device is being used, i.e., a cold device switch has occurred. If the matching is unsuccessful, the first time the cold device is used is indicated, a cold device switching interrupt is generated, and the cold device switching interrupt is solved by the related technology in the extensible IOPMP-segment table of the embodiment of the application.
Taken together, this flow describes the I/O check process after the DeviceID2SID table is added. By searching the device ID in the deviceID2SID table, the system can quickly determine the state of the device and further perform corresponding processing so as to ensure that the system can effectively manage hot devices and cold devices and ensure the high efficiency and reliability of the system.
As an alternative embodiment, the method further comprises establishing a mapping relationship between source identification information of the device in the hot state and hardware identification information of the device in the hot state in the device identification information table if the device switches from the cold state to the hot state.
In this embodiment, if the device is switched from the cold state to the hot state, a mapping relationship between source identification information of the device in the hot state and hardware identification information of the device in the hot state is established in the device identification information table, where the device is in the cold state, and it may be described that the device is a cold device.
Optionally, sIOPMP employ different policies for hot and cold device switching, i.e., explicit switching and implicit switching.
Alternatively, in explicit switching, the system can predict which devices are in hot state and which are in cold state. Thus, the system can explicitly set the mapping of device ID to SID. This means that for devices that are in a hot state, the system can directly assign valid SIDs to them so that they can access the physical memory of the system. This explicit switching method enables the system to precisely manage the access rights of the devices, assigning the appropriate rights according to their status.
Optionally, through explicit switching, the system may take different actions in different device states to protect the system from potentially malicious devices. This approach may help the system manage and protect system resources more efficiently, ensuring that only devices in a hot state can access physical memory, while devices in a cold state are restricted or prohibited from accessing. In general, explicit switching is an effective policy for managing access rights of devices according to device states to ensure security of a system and efficient use of resources.
As an alternative implementation mode, the method further comprises the steps of acquiring IOPMP units of hardware identification information of the device, loading the hardware identification information of the device into the frequency of the extended register table by the safety monitor, determining that the device is in a hot state if the frequency is greater than a frequency threshold value, and controlling the safety monitor to replace source device identification information of the device in the hot state with source device identification information of an original device in a cold state in the device identification information table.
In this embodiment, IOPMP units of security monitor may be acquired to load the hardware identification information of the device to the frequency of the extended register table. The frequency may be determined, if the frequency is greater than the frequency threshold, it may be determined that the device is in a hot state, and the security monitor may be controlled to replace source device identification information of the device in the hot state with source device identification information of an original device in a cold state in the device identification information table, where the security monitor may be used to process cold device switching.
Alternatively, the hot and cold state switching of the device is accomplished by implementing a clock algorithm, such as the least recently Used (LEAST RECENT LY Used, abbreviated LRU) approximation algorithm, in the DeviceID2SID table, and additional LRU bits.
Optionally, in implicit switching, the security monitor treats the device as a hot device or a cold device depending on the activity level of the device. When the security monitor frequently loads eSID bits of a device ID into eSRCMD registers, the system will treat this device as a hot device, i.e., the device is active, and needs to be assigned a valid SID so that it can access physical memory. To achieve this, the system tracks the liveness of the device with additional LRU bits using an LRU approximation algorithm in the DeviceID2SID table, then evicts relatively inactive devices from the table according to the LRU bits, and assigns their SIDs to the new device.
Optionally, the method enables the system to adaptively adjust the cold and hot states of the equipment, and dynamically adjusts the access rights of the equipment according to the actual activity level of the equipment. By means of the strategy, the system can effectively manage the access authority of the equipment and dynamically adjust the cold and hot states of the equipment according to the actual workload. In general, through two strategies of explicit switching and implicit switching, the I/O isolation scheme of the embodiment of the application can adapt to dynamic I/O workload, effectively manage the cold and hot states of the equipment, and protect system resources from being accessed by potential malicious equipment.
As an alternative implementation mode, the method further comprises determining IOPMP units of hardware resources, determining initial type operations which are allowed to be executed on the hardware resources, determining target type operations based on the initial type operations, wherein the operation authority range of the target type operations on the hardware resources is smaller than that of the initial type operations on the hardware resources, and/or transferring operation authorities which are allowed to be executed on the hardware resources from an initial operation object to a target operation object.
In this embodiment, the hardware resources of IOPMP units may be determined. An initial type of operation that is allowed to be performed on the hardware resource is determined. The target type operation may be determined based on the initial type operation. The operation authority of the allowed hardware resource to execute the initial type operation can be transferred from the initial operation object to the target operation object, wherein the initial type operation can be I/O access capability or access capability. The operation right may be ownership of the capability. The initial operation object may be an owner of a specific capability. The target operand may be another entity.
Optionally, security management for IOPMP hardware resources employs a "capability-based" abstraction. Each capability controls a particular hardware resource, only the owner having the right to operate the associated hardware. This "capability-based" abstraction includes two basic operations, derivation and migration. The owner may derive a new capability from the existing capability but the rights may be reduced or less extensive. For example, a new I/O access capability may be derived from an existing I/O access capability, but the new capability is narrower in scope or has limited rights. This mechanism allows the system to generate new capabilities as needed to accommodate different rights requirements while ensuring proper degradation or restriction of rights. The transfer, the owner may send ownership or a copy (i.e., with read only rights) to another entity. This means that the owner can transfer the capabilities that he owns to other entities so that the other entities can perform the relevant hardware operations. This mechanism provides a secure way to control the allocation and transfer of ownership and access rights of the capability.
In summary, the "capability" based abstraction provides an efficient way to manage IOPMP hardware resources, by deriving and transferring operations, the system can flexibly control access rights to hardware resources and ensure proper allocation and transfer of rights. Such a safety mechanism helps to protect the safety and stability of the system.
Alternatively, the capability is owned by the security monitor when the system is started. At this stage, the security monitor may optionally transfer ownership of the capability to the initiating system. When the user intends to Create a TEE, ownership of the device and memory is transferred to the TEE using an ownership-based interface, such as create_tee (). The TEE may then call device_map () to map the memory area for a particular Device. By using an ownership-based interface, the security monitor can easily verify the TEE's device mapping operations.
Alternatively, this ownership-based mechanism introduces an effective way of security control for the system. By granting ownership to the security monitor at system start-up and allowing the security monitor to selectively transfer some or all of the resource ownership to the start-up system or TEE, the system can ensure that access to hardware resources is tightly controlled while allowing a particular execution environment to acquire the necessary rights to perform its tasks. This arrangement provides a secure and verifiable way to manage access rights transfer to resources, helping to ensure security and stability of the system.
As an alternative implementation, transferring the operation authority which allows the initial type operation to be performed on the hardware resource from the initial operation object to the target operation object comprises transferring the operation authority which allows the initial type operation to be performed on the hardware resource from the safety monitor of the IOPMP unit to a starting system corresponding to the initial type operation, wherein the initial operation object comprises the safety monitor, and the target operation object comprises the starting system.
In this embodiment, in transferring the operation authority that allows the initial type of operation to be performed on the hardware resource from the initial operation object to the target operation object, the operation authority that allows the initial type of operation to be performed on the hardware resource may be transferred from the security monitor of the IOPMP unit to the start-up system corresponding to the initial type of operation, wherein the initial operation object may include the security monitor. The target operand may include a boot system.
Optionally, to improve the modularity of the security monitor, the functionality is divided into two parts, a hardware controller and a capability layer. The hardware dependent controllers may include interrupt controllers for interrupt isolation, i.e., hardware modules that control and manage system interrupts, ensuring isolation and safe execution of interrupts. IOPMP controller for isolating, managing and controlling IOPMP hardware resource to ensure strict control of access right to device. And the PMP controller is used for memory isolation, management and control of PMP hardware resources and ensures that the access right to the memory area is strictly controlled. The "capability" layer abstracts all hardware resources into "capabilities". Only the owners of a particular capability are granted access to the corresponding hardware resources. The device manager and the memory manager maintain a linked list of ownership transfers for each device and memory region, while the TEE manager maintains a mapping from "capabilities" to hardware, i.e., which hardware resources the TEE can access.
In embodiments of the present application, this modular arrangement provides an efficient way to manage the hardware resources of the system and ensures that access rights to such resources are tightly controlled. By separating the functions into hardware controllers and capability layers, the system can better manage and abstract hardware resources and ensure that only specific "capability" owners can obtain corresponding access rights, thereby improving the security and stability of the system.
In the embodiment of the application, a dynamic extensible I/O isolation mechanism is arranged, so that the overhead caused by I/O isolation inspection under a high-load scene is greatly reduced. The application sets a micro-architecture of IO inspection-a multi-stage tree IOPMP inspector, which allows inspection of more I/O isolation domains (> 1000) without reducing clock frequency. Meanwhile, the method can also support I/O devices with unlimited quantity and provide corresponding block/slow check paths according to the cold and hot states of the devices, so that the conflict between the quantity of the devices and the resource expense is solved. Finally, in order to cope with dynamically changing I/O loads, the embodiment of the application sets an efficient device state switching mechanism, and realizes the cold and hot device conversion close to cold cost. In addition, the SID and device ID in IOPMP are allowed to remap so that the SID and device ID in IOPMP do not need to be hard bound.
Optionally, the method has the characteristic of dynamic scalability, and can greatly reduce the overhead of I/O isolation checking in a high-load scene and support a large number of I/O isolation domains by arranging a multi-stage tree IOPMP checker. The device state management feature can provide a block/slow check path of the cold and hot devices to solve the conflict between the number of devices and the resource cost, and realize the conversion of the cold and hot devices close to the cold cost; the method also has the characteristic of flexibility, can allow SIDs and device IDs in IOPMP to be remapped without hard binding, and therefore the adaptability of the system to dynamically changing I/O loads is improved. In general, the embodiment of the invention provides an efficient, flexible and extensible I/O isolation mechanism, is expected to significantly improve the performance of the system in a high-load scene, and provides a reliable solution for dynamically changing I/O loads.
The embodiment of the application also provides a memory access method of the device from the perspective of accessing the memory of the system by the device, and fig. 3 is a flowchart of a memory access method of the device according to an embodiment of the application, as shown in fig. 3, the method can be applied to an input-output physical memory protection IOPMP unit, and can include the following steps:
In step S302, a memory access request of the device is obtained, and at least one IOPMP entry matched by the device in IOPMP units is determined, where the memory access request is used to make the device request to access data stored in a memory address corresponding to IOPMP units, and the IOPMP entry is used to represent a data structure of IOPMP units.
In the technical solution provided in the above step S302 of the present application, if it is detected that the device has a memory access request for accessing data stored in a memory address of the computer system, the memory access request may be input into the IOPMP unit, and a IOPMP entry matching the memory access request may be determined.
Optionally, if the user needs to access the data stored in the memory address of the computer system, a corresponding operation may be performed on the client device of the user, for example, the request data to be accessed may be input, the memory address stored in the request data may be input, and the corresponding memory access request may be written according to the request data and the memory data required by the user. Optionally, after the user inputs the corresponding memory access request from the client device, the memory access request may be transmitted to IOPMP units in the server through the network. The memory access request may be obtained using IOPMP, and IOPMP entries matching the device currently issuing the memory access request may be screened from the array of entries in IOPMP units.
Step S304, verifying the memory access request in at least one IOPMP item to obtain at least one verification result, wherein the verification result is used for indicating whether the equipment has access rights in the corresponding IOPMP item.
In the technical scheme provided in the above step S304 of the present application, after the memory access request of the device is obtained and the IOPMP entry matched in IOPMP units of the device is determined, the memory access request may be verified in the IOPMP entry, so as to obtain a corresponding verification result.
Optionally, after determining IOPMP entries matching the device, for the memory access request, a separate verification may be performed for each matched IOPMP entry to verify whether the device has access rights to the corresponding IOPMP entry.
Step S306, based on the verification result, generating an access right result corresponding to the memory access request.
In the technical scheme provided in the above step S306 of the present application, after the memory access request is verified in IOPMP entries, the access right result corresponding to the memory access request may be generated based on the verification result after the verification result is obtained.
Optionally, after determining the verification result of the current memory access request under each IOPMP entries, the verification results of the above IOPMP entries may be combined to determine whether the memory access request has permission to access data in a memory address in the system.
In step S308, if the access authority results in allowing the device to access the data in the memory address, the memory access request is transmitted to the memory address to access the data.
In the technical solution provided in the above step S308 of the present application, if it is determined that the access permission result is data in the memory address of the permission device access system, the memory access request may be transmitted to the memory address to access the corresponding data.
In step S310, if the access permission result is that the device is prohibited from accessing the data in the memory address, the transmission of the memory access request to the memory address is prohibited to access the data.
In the technical solution provided in the above step S310 of the present application, if it is determined that the access permission result is that the device is prohibited from accessing the data in the memory address of the system, the transmission of the memory access request to the memory address may be prohibited to access the data.
The method comprises the steps of S302 to S310, obtaining a memory access request of equipment, determining at least one IOPMP item matched with the equipment in IOPMP units, verifying the memory access request in at least one IOPMP item to obtain at least one verification result, generating an access right result corresponding to the memory access request based on the verification result, transmitting the memory access request to access data in a memory address if the access right result is data in the memory address allowing the equipment to access, and prohibiting the memory access request to be transmitted to access data in the memory address if the access right result is data in the memory address prohibiting the equipment from accessing. Therefore, the purpose of reducing the cost of safety access to the equipment is achieved, the technical effect of effectively determining the memory access authority of the equipment is achieved, and the technical problem that the memory access authority of the equipment cannot be effectively determined is solved.
Example 2
According to an embodiment of the present application, an embodiment of a system for determining memory access rights of a device is further provided, and fig. 4 is a schematic diagram of a system for determining memory access rights of a device according to an embodiment of the present application, where, as shown in fig. 4, a system 400 for determining memory access rights of a device may include a IOPMP unit 401 and an output terminal 402.
IOPMP unit 401 for obtaining a memory access request of the device, determining at least one IOPMP item matched in IOPMP unit by the device, wherein the memory access request is used for making the device request to access data stored in a memory address corresponding to IOPMP unit, IOPMP item is used for representing a data structure of IOPMP unit, verifying the memory access request in at least one IOPMP item to obtain at least one verification result, wherein the verification result is used for representing whether the device has access authority in the corresponding IOPMP item, and generating an access authority result corresponding to the memory access request based on the verification result, wherein the access authority result is used for representing whether the device is allowed to access the data stored in the memory address.
In this embodiment, in IOPMP unit 401, a memory access request for a device may be obtained. Then IOPMP may be utilized to check for memory access requests. During the checking, the device may be caused to request access to data stored in the memory address corresponding to IOPMP units using the memory access request. And may determine IOPMP entries that the device matches in IOPMP units. The memory access request may be verified in IOPMP entries to determine whether the device has access rights in the corresponding IOPMP entry, and a corresponding verification result is obtained. And determining whether the current memory access request is allowed to access data in a memory address in the device based on whether the IOPMP entry has access rights.
Optionally, if the user needs to access the data stored in the memory address of the computer system, a corresponding operation may be performed on the client device of the user, for example, the request data to be accessed may be input, the memory address stored in the request data may be input, and the corresponding memory access request may be written according to the request data and the memory data required by the user. The memory access request may be transmitted over a network to IOPMP unit 401 in the server. The memory access request may be obtained using IOPMP, and IOPMP entries matching the device currently issuing the memory access request may be screened from the array of entries in IOPMP units.
Optionally, after determining IOPMP entries matching the device, for the memory access request, a separate verification may be performed for each matched IOPMP entry to verify whether the device has access rights to the corresponding IOPMP entry.
Optionally, after determining the verification result of the current memory access request under each IOPMP entries, the verification results of the above IOPMP entries may be combined to determine whether the memory access request has permission to access data in a memory address in the system.
Optionally, after determining the access rights result, the access rights result may be transmitted to the output 402.
And an output terminal 402, configured to output the access right result.
In this embodiment, after the output 402 receives the access right result transmitted from the IOPMP unit 401, the access right result may be output using the output 402.
Optionally, if it is determined that the access permission result is that the device is allowed to access the data in the memory address of the system, the memory access request may be transmitted to the memory address to access the corresponding data.
Optionally, if it is determined that the access permission result is that the device is prohibited from accessing the data in the memory address of the system, the transmission of the memory access request to the memory address may be prohibited to access the data.
In this embodiment, a system for determining memory access rights of a device is provided. The method comprises the steps of obtaining a memory access request of equipment through an input/output physical memory protection IOPMP unit 401, determining at least one IOPMP item matched with the equipment in the IOPMP unit, verifying the memory access request in at least one IOPMP item to obtain at least one verification result, generating an access right result corresponding to the memory access request based on the verification result, wherein the access right result is used for indicating whether the equipment is allowed to access data stored in a memory address or not, and outputting the access right result through an output end 402.
The above-described system of this embodiment is further described below.
As an alternative embodiment, the system includes a masker for determining at least one IOPMP entry corresponding to the hardware identification information of the device in the IOPMP set of entries of IOPMP units.
In this embodiment, a masker may be included in the system, wherein the masker may be configured to determine at least one IOPMP entry corresponding to the hardware identification information of the device in the IOPMP entry set of IOPMP units.
Optionally, a masker may be used to filter IOPMP the entries, selecting the entry corresponding to the current device ID. This helps to reduce the number of items that need to be inspected, improving inspection efficiency.
As an alternative implementation manner, the IOPMP unit includes a IOPMP checker, configured to verify the memory access request in at least one IOPMP item to obtain at least one verification result, and generate an access right result corresponding to the memory access request based on the verification result.
In this embodiment, the IOPMP unit may include a IOPMP checker, where the IOPMP checker may be configured to verify the memory access request in at least one IOPMP entry to obtain a verification result, and generate an access permission result corresponding to the memory access request based on the verification result.
Optionally, IOPMP checker takes as input the memory address, the request data, and IOPMP entry. The data will be used to perform multi-stage I/O access control checks. IOPMP the checker has a plurality of pipeline stages, each stage validating a respective IOPMP entry and storing intermediate results in registers. This staged arrangement improves the parallelism and throughput of the overall I/O check. After passing the I/O permission check, IOPMP checker generates a final decision to determine whether the memory access is authorized. This ensures security verification for each access request.
As an alternative implementation, the IOPMP checker includes a sub-checking module configured to verify the memory access request in IOPMP entries using a first tree arbitration circuit to obtain a verification result, and a register configured to write the verification result.
In this embodiment, a sub-check module may be included in the IOPMP checker, where the sub-check module may be configured to verify the memory access request in the IOPMP entry using the first tree arbitration circuit to obtain a verification result. The IOPMP checker may also include a register that may be used to write the verification result.
Optionally, the IOPMP checker includes a plurality of sub-checking modules, and the modules are connected through pipeline registers. This arrangement allows parallel processing of a plurality of sub-inspection modules and is connected by pipeline registers, contributing to an increase in the overall inspection processing speed. Each sub-checking module adopts a tree arbitration circuit to check the authority of a plurality of IOPMP entries in parallel. Such parallel processing helps to improve overall inspection efficiency and throughput.
As an alternative embodiment, the system further comprises a safety monitor for maintaining a blocking state between the bus of the IOPMP unit and the IOPMP checker.
In this embodiment, a safety monitor may also be included in the system, wherein the safety monitor may be used to maintain a blocking state between the IOPMP units of bus and the IOPMP checker.
Alternatively, the security monitor may fetch the corresponding IOPMP entry in the mountable IOPMP-segment table and load eSID, memory fields into the eSRCMD register on-chip, and additional IOPMP entries into the last memory field in the IOPMP-entry table on-chip. This means that the security monitor will handle the interrupt and perform the corresponding operations, including fetching the corresponding IOPMP entry in the mountable IOPMP-segment table, loading eSID and memory fields into the eSRCMD register on-chip, and loading the additional IOPMP entry into the last memory field in the IOPMP-segment table.
It should be noted that, the user information (including but not limited to user equipment information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, presented data, etc.) related to the present application, for example, the data to be checked are information and data authorized by the user or sufficiently authorized by each party, and the collection, use and processing of the related data need to comply with the related laws and regulations and standards of the related country and region, and is provided with a corresponding operation entrance for the user to select authorization or rejection.
Example 3
Currently, with rapid development of information technology and increasing complexity of computer systems, data security and privacy protection are common focuses of attention in the industry and academia. The utilization of the confidential data stored in the device attack system becomes an important topic of current system security. In many scenarios such as cloud computing, internet of things, smart phones, etc., careful isolation and protection of device access in the system is required to prevent potential security risks and data leakage.
The hardware I/O isolation mechanism is a device security solution based on a hardware level, and aims to effectively isolate data access among different devices in a system and prevent malicious devices from stealing or tampering confidential data in the system. Among these, IOMMU and TEE are two common hardware I/O isolation mechanisms.
The IOMMU is used to manage the I/O device's access to system memory. Through the IOMMU, a system administrator can allocate an independent memory address space for each device, limiting its direct access to system memory. The isolation can effectively prevent the malicious equipment from reading or falsifying the sensitive data in a DMA mode and the like, and the safety and the reliability of the system are enhanced. The IOMMU plays an important role in the virtualized environment, can help realize isolation between virtual machines, and prevents data sharing and interference between the virtual machines.
Another important I/O isolation mechanism is to utilize the I/O isolation mechanism in TEE. A TEE is a secure execution environment, typically located inside a chip, with a separate secure processing unit, memory space, and isolated I/O address space. The TEE provides a protected execution environment that can perform critical security tasks such as data encryption, authentication, and digital signature. By placing critical applications and data into the TEE for operation, malware and malicious devices can be effectively prevented from reading confidential data in secure memory. For example, ARM Trust Zone (Trust Zone) technology is widely used in mobile devices to protect personal privacy data (e.g., biometric information) from being secured at the mobile end. The TEE mainly adopts two technologies for I/O protection, namely a coarse-granularity segment isolation mechanism, namely a continuous inner coarse area which can be accessed by equipment is limited, and the other technology adopts a memory encryption and integrity protection technology, so that the equipment can only read the data of the ciphertext, and meanwhile, the tampering of the secure memory can be found in time.
The hardware I/O isolation mechanism provides a solid foundation for system security, and also provides important guarantee for data privacy and information security. However, with the increasing capabilities of current devices, the bandwidth of the devices has increased to hundreds of GB per second, and the use of IOMMU for I/O isolation can create a significant performance overhead (greater than 20%). While implementing I/O isolation using TEE technology may limit the number of devices supported, e.g., only <16 security devices can be supported in Trust Zone. However, currently, based on the device virtualization technology, hundreds of virtual devices may exist in a single machine, so the I/O isolation mechanism of the TEE cannot adapt to the current device virtualization scenario.
In the related art, the IOMMU is not set solely for pure security concerns, but it also supports address and interrupt remapping. Therefore, due to its inherent drawbacks, it is not appropriate to include the entire IOMMU in the trusted computing base (Trusted Comput ing Base, abbreviated TCB) of the TEE system. First, the IOMMU presents performance problems under heavy workload because of the expensive IOTLB invalidation using asynchronous command queues. Previous studies have shown that IOTLB flushing may result in an overhead of 20% -30% increase in I/O throughput. Second, the IOMMU only supports page-level isolation, which is insufficient for DMA scenarios, as the memory buffer may be of arbitrary size. In the network stack, there are many sub-page network packets that are difficult to isolate by the IOMMU, requiring additional copy operations. Third, the IOMMU requires complex page tables and I/O virtual address (IOVAs) configurations, which expose vulnerabilities to malicious devices. For example, with vulnerabilities in the shared data structure, checking for IOMMU is bypassed with the descriptor ring. Finally, the poor scalability of IOMMU settings, such as IOVA allocation and IOTLB, can be a bottleneck in multi-device and tenant scenarios. Due to the above limitations, current TEEs do not use (or only partially use) IOMMU as a basic I/O protection mechanism due to performance degradation and the necessity of small TCBs.
In another related art, TEEs tend to use region-based I/O isolation, memory encryption, or a combination of both to defend against DMA attacks. In Trust Zone, all hardware resources are divided into the secure world and the general world, and only components in the secure world can access the secure hardware resources. This may prevent devices in the general world from accessing secure memory through DMA requests. However, this region-based isolation mechanism is limited by the number of memory regions (up to 16 regions) and the number of devices. Other TEE systems, such as SEV, use encrypted memory to prevent malicious DMA accesses. Since the data in secure memory is encrypted, the device cannot decrypt the ciphertext into plaintext without the encryption key. However, using only memory encryption (without an integrity tree) is not resistant to replay attacks, which can roll back old memory regions to the same address. Some TEEs employ both memory encryption and I/O isolation, such as TDX, SGX, SEV-SNP and CCA. SEV-SNPs and CCA propose page-based I/O quarantine mechanisms, RMP and GPC, which are new components within IOMMU or sMMU. However, they still face the same problems as IOMMU, such as asynchronous IOTLB entry flushing, page level isolation, and lack of scalability. In addition, memory encryption also prevents legitimate DMA requests, which requires additional memory copying, which reduces I/O performance.
However, the above method still has a technical problem that the memory access right of the device cannot be effectively determined.
Further, the present application provides a dynamically scalable I/O isolation mechanism, which proposes a series of innovative techniques and methods to address the limitations of conventional I/O isolation techniques. The staged tree IOPMP checker provides a checking mode in a pipeline form, and simultaneously realizes tree parallel authority checking, thereby being capable of efficiently checking DMA requests and improving the performance and expandability of the system. The IOPMP-segment table structure can be mounted, and the IOPMP-segment table structure can be mounted is introduced to support the devices with unlimited quantity. Meanwhile, for the cold equipment, corresponding check metadata can be stored in a safe memory when the cold equipment is not used, and loaded into an on-chip register and a table when the cold equipment is used, so that the efficient management of the cold equipment is realized. IOPMP remapping technology, and utilizing CAM technology to implement high-efficiency switching between cold equipment and hot equipment and raise processing efficiency of system for equipment state conversion.
The IOPMP hardware resource management mechanism based on the 'capability' abstracts the ownership of IOPMP hardware resources into the capability, thereby realizing the transmission and the scaling of the I/O access rights and improving the management flexibility of the system on the hardware resources. The safety monitor is provided with a function of actively switching cold equipment and a function of actively switching the cold equipment by processing the switching of the cold equipment and monitoring the access frequency of different equipment, so that the dynamic management capability of the system on the equipment state is enhanced. In a comprehensive view, the dynamic extensible I/O isolation mechanism introduces a plurality of innovative technologies and methods, so that the flexibility, performance and safety of the system on I/O isolation are improved, and great improvement is expected to be brought to a TEE system. Therefore, the purpose of reducing the cost of safety access to the equipment is achieved, the technical effect of effectively determining the memory access authority of the equipment is achieved, and the technical problem that the memory access authority of the equipment cannot be effectively determined is solved.
The above-described method of this embodiment is further described below.
In embodiments of the present application, an extensible I/O isolation domain mechanism is provided such that the number of isolation domains is not limited. This means that the method can efficiently handle large-scale device isolation requirements, supporting a large number of dynamically changing I/O isolation domains. This scalability is very important for modern large-scale systems and cloud computing environments. A dynamic I/O isolation domain mechanism is provided, and the performance of I/O isolation is ensured. This means that the method can adapt to dynamically changing I/O task loads, ensuring that efficient I/O isolation performance can still be maintained in a constantly changing environment. This is particularly important for I/O task management in dynamic environments such as cloud computing. And an efficient cold and hot equipment switching mechanism is provided, so that the variable I/O task load can be adapted. This means that the method can effectively switch between the cold and hot devices to accommodate the ever changing I/O task load. This efficient switching mechanism helps to maintain system stability and performance.
The above problems are all key challenges in current dynamic, high-load cloud I/O scenarios, and this approach provides innovative solutions to the above challenges. By the method, effective management of large-scale equipment isolation can be realized, and high-efficiency I/O isolation performance is maintained in a dynamic environment, so that requirements of system safety and performance are met.
Optionally, the pipelined I/O check module may ensure efficient multi-cycle checking of memory access requests of the device while not affecting the clock frequency. This is critical to ensure security and privacy protection of device access. The mechanism of the mountable I/O check segment table can realize the on-demand loading of the authority of the cold and hot equipment, and is beneficial to accelerating the authority check process of the hot equipment. Such a mechanism can improve the efficiency of access to devices, particularly for dynamically changing I/O loads. The high-speed switching mechanism of the cold and hot equipment ensures that the dynamic I/O load can be responded in real time, and the switching overhead does not influence the I/O throughput. This is critical to maintaining system stability and performance. The software module configuring the I/O check logic may respond to the I/O interrupt request, handle I/O exceptions, set device cold and hot properties, etc. This helps to achieve overall management and control of device access. The end-to-end I/O protection mechanism can adapt to the current mainstream bus protocol, and realize the I/O security of the SoC level. This is important to ensure the security and reliability of end-to-end I/O access in the system.
By combining the technical points, a comprehensive and efficient I/O isolation mechanism can be constructed, the key problem in the current dynamic and high-load cloud I/O scene is solved, and important guarantee is provided for system safety and performance.
In this embodiment, a standard IOPMP isolation mechanism is provided.
Optionally IOPMP is intended to normalize accesses issued by bus masters and to protect against malicious DMA attacks. In IOPMP settings, each master or group of masters with the same bus access rights has a unique identifier called SID. In particular, if multiple channels with different rights for one device can run in different privilege modes, such as under a processor, each channel or privilege mode should have its own SID. In addition to the SIDs, the IOPMP uses the MD to organize the physical memory that each device can access. A memory domain comprises several consecutive memory regions, each of which may have different access rights. For example, a NIC device may be associated with a memory domain that includes three memory regions, an RX region, a TX region, and a control register region.
Fig. 5 is a schematic diagram of an internal structure of IOPMP, which may include an SRC2MD table, a IOPMP entry table, and a MDCFG table, according to an embodiment of the present application.
Optionally, fig. 5 (a) is a schematic diagram of a mapping table of source identifiers to memory domains, shown in fig. 5 (a), which is a SRC2MD table inside IOPMP, where the SRC2MD table identifies the memory domain associated with a given SID. The table is composed of a plurality of sets of SRC S MD registers, for example, SRC 0MD、SRC1 MD through SRC n MD, each having a 64-bit space and two fields, SRC S MD.L and SRC SMD.MD.SRCS MD.L being the lock bit flags of the register, SRCS MD.MD being a bitmap (bitwise) field showing the memory field m, whether the index m in the figure is associated with the SID.
Optionally, fig. 5 (b) is a schematic diagram of a memory domain configuration table, as shown in fig. 5 (b), which defines a relationship between IOPMP entries and memory domains according to an embodiment of the present application. The table has a series of configuration registers, with register MD m CFG being for memory domain m. In the MD m CFG register, MD m cfg.t indicates the last index of the IOPMP entry belonging to memory domain m. More specifically, if MD m-1CFG.T≤j<MDm CFG.T, then the IOPMP entry with index j belongs to memory domain m, where m >0. Memory field 0 has IOPMP entry with index j < MD 0 cfg.t.
Optionally, fig. 5 (c) is a schematic diagram of an input/output physical memory protection entry table according to an embodiment of the present application, and as shown in fig. 5 (c), the entry array IOPMP is the most basic structure of IOPMP. Each IOPMP entry indexes from zero and defines a rule when checking transactions. The entry includes a memory region and read/write permissions for the region. Each IOPMP entry belongs to only one memory domain, and a memory domain may contain multiple IOPMP entries. Any SID associated with an MD is also associated with all IOPMP entries belonging to the memory domain. IOPMP entries have a static priority, where small numbered entries have a high priority, e.g., entry 0 has a high priority, with Entry x, entry x+1, etc. having a lower priority as the number increases. When a transaction is issued IOPMP checks for a match of the transaction with IOPMP entries in order of priority. If the transaction matches the IOPMP entry, IOPMP checks the read/write permissions within the IOPMP entry. For example, assume memory domain 0, i.e., MD0 has two IOPMP entries, a first entry and a second entry. The first entry has no authority for the memory address and the second entry has read authority. According to the priority, the device associated with memory domain 0 eventually has no access rights to the address.
In this embodiment, a multi-stage tree IOPMP checker is presented.
FIG. 6 (a) is a schematic diagram of I/O check logic in a pipelined fashion, as shown in FIG. 6 (a), wherein the I/O check of the IOPMP pipeline is bandwidth-sensitive rather than delay-sensitive, such as a DMA request of a device, in accordance with an embodiment of the present application. IOPMP may be checked in stages in a pipelined fashion. The IOPMP checker takes as input the memory address, the request data, and the IOPMP entry in the IOPMP entry table. The mask is used to filter IOPMP entries and select entries corresponding to the current device ID, IOPMP checker has multiple pipeline stages, such as a first pipeline stage and a second pipeline stage, to validate respective IOPMP entries at different pipeline stages and store intermediate results in registers, and finally, IOPMP checker generates a final decision after checking all I/O permissions through memory translator checker (Memory Trans lat ion checker, simply MT CHECKER) to determine whether the memory access is authorized.
Alternatively, as shown in FIG. 6 (a), the IOPMP pipeline setup needs to solve some new problems. For example, if it is desired to block a DMA transaction, the blocking state between the bus and IOPMP checker may not be consistent, although DMA tasks may be blocked on the bus, there may still be residual DMA tasks in the IOPMP checker due to the multi-stage pipeline. Thus, a monitor is added to maintain coherency of the blocking state between the bus and IOPMP checker.
Optionally, IOPMP checker takes as input the memory address, the request data, and IOPMP entry. The data will be used to perform multi-stage I/O access control checks. The masker may filter IOPMP the entries, selecting the entry corresponding to the current device ID. This helps to reduce the number of items that need to be inspected, improving inspection efficiency. IOPMP the checker has a plurality of pipeline stages, each stage validating a respective IOPMP entry and storing intermediate results in registers. This staged arrangement improves the parallelism and throughput of the overall I/O check. After passing all I/O permission checks, IOPMP checker generates a final decision to determine if the memory access is authorized. This ensures security verification for each access request. With respect to pipeline setup, there is a real need to address some new issues, especially the problem of state consistency between the bus and IOPMP checker. To address this problem, the addition of monitors helps to maintain consistency in blocking status between the bus and IOPMP checker. This arrangement helps ensure the validity of the I/O access control and system performance.
FIG. 6 (b) is a schematic diagram of a IOPMP tree arbitration circuit according to one embodiment of the present application, as shown in FIG. 6 (b), a IOPMP tree arbitration circuit is provided to implement prioritized I/O permission checking scheme, in which checking delay is reduced to log (N) level based on tree arbitration logic.
Alternatively, as shown in FIG. 6 (b), based on tree arbitration logic IOPMP the checker compares the permissions of each IOPMP entry pair by pair according to priority and generates an intermediate result, which is then reduced in the tree structure circuit. Unlike other possible optimization checking circuits using back-end EDA tools, tree-based arbitration is implemented at the RTL level, with more information and human-involved optimization. For example, the embodiment of the application can adopt different tree structures to meet different requirements of time sequence (binary tree) and area (N-ary tree), and all authority check results reach a final root node according to priority specifications, wherein the authority of the root node is the final I/O access authority.
Optionally, IOPMP tree arbitration circuitry employs a tree structure to implement prioritized I/O permission checks, aimed at reducing latency of the checks. This approach can effectively reduce the checking delay to a logarithmic level (log (N)), thereby improving the efficiency and performance of the system for I/O access.
Alternatively, IOPMP tree arbitration circuitry employs a tree structure, each node representing one IOPMP entry, and leaf nodes representing the final access grant decision. Such a tree structure can effectively enable parallel checking of multiple IOPMP entries. The hierarchical structure of the tree allows the checking of I/O permissions to be broken into multiple phases, each of which processes a portion IOPMP of the entry. Such a hierarchical inspection helps to reduce the delay of the overall inspection. The tree structure allows parallel checking of multiple I/O requests, thereby improving the processing efficiency of the whole system to I/O access. In general, IOPMP tree arbitration circuitry employs an efficient tree structure to enable efficient management of I/O permissions through hierarchical inspection and parallelism. The novel scheme is beneficial to improving the checking efficiency of the system on the I/O access authority, is suitable for bandwidth-sensitive application scenes, and can remarkably reduce the delay of overall checking.
Optionally, the IOPMP checker based on tree arbitration logic has the feature that the IOPMP checker compares the authority of each IOPMP entry pair by pair according to priority and generates intermediate results. The intermediate results are processed in a subsequent reduction stage. Tree structure reduction, which reduces intermediate results in tree structure circuits. Unlike other possible optimization checking circuits using back-end EDA tools, tree-based arbitration is implemented at the RTL level, with more information and human-involved optimization. The method can adopt different tree structures according to actual requirements to meet different requirements of time sequence (binary tree) and area (N-ary tree) so as to balance different setting targets. And (3) obtaining authority verification results, wherein all the authority verification results reach a final root node according to a priority protocol, and the authority of the root node is the final I/O access authority. Through reduction of the tree structure, combination and final decision of the I/O authority can be efficiently realized. In summary, the IOPMP checker based on tree arbitration logic utilizes a tree structure to implement reduction and final decision of I/O permissions. The method has high flexibility and optimizability, can perform different levels of optimization according to actual demands, and can efficiently realize effective management of I/O rights.
Fig. 6 (c) is a schematic diagram of a IOPMP linear arbitration circuit according to an embodiment of the present application, and as shown in fig. 6 (c), a IOPMP linear arbitration circuit is proposed. In the embodiment of the application, the cost of authority checking is further reduced by combining IOPMP pipelines and IOPMP tree-shaped arbitration circuits. The IOPMP checker comprises a plurality of sub-checking modules which are connected through a pipeline register, wherein each sub-checking module adopts a tree arbitration circuit to check the authority of a plurality of IOPMP items in parallel, the part of final authority results obtained by the tree arbitration circuit are written into the pipeline register, and the authority in each stage of pipeline checking is used for generating the final I/O access authority according to the pipeline priority as the final access authority of the DMA request.
Alternatively, the mountable IOPMP segment table is reserved in protected memory as compared to the entry table in IOPMP or the SRC2MD table. This means that the mountable segment table is stored in a protected memory area, e.g. in PMP protected memory in RISC-V. Such a setting may ensure that unauthorized software or devices cannot directly access the segment table, thereby enhancing security. Since the mountable IOPMP segments of the table are retained in protected memory, unauthorized software or devices cannot directly access the table. Such an arrangement provides an effective security mechanism ensuring that access rights to the table are controlled. Based on the above settings, there is no hardware limitation on the size of the mountable IOPMP-segment table, provided that the physical memory is sufficient. This means that the size of the attachable IOPMP-segment table can be extended as needed with sufficient physical memory support without limitation in terms of hardware. In combination, this arrangement of retaining the mountable IOPMP-segment table in protected memory provides an effective security mechanism that ensures that access rights to the table are controlled and that there are no hardware limitations on the mountable-segment table size with sufficient physical memory support.
Optionally, IOPMP pipeline and tree arbitration circuitry are combined to reduce the overhead of entitlement checking. IOPMP the checker includes a plurality of sub-check modules that are connected by pipeline registers. This means that multiple sub-check modules can perform the permission checks simultaneously without waiting for the completion of the previous permission check. Each sub-checking module employs tree arbitration circuitry, meaning that they can check the permissions of multiple IOPMP entries in parallel. The tree arbitration circuit can effectively process a plurality of authority check demands, and efficiency is improved. The part of the final authority result obtained by the tree arbitration circuit is written into the pipeline register. Thus, the authority check result can be temporarily stored in a register, and the subsequent processing is convenient. And generating the authority in each stage of pipeline inspection according to the pipeline priority to obtain the final I/O access authority as the final access authority of the DMA request. This means that the final access rights are generated by the priority of the pipeline to determine the final access rights of the DMA request. In a comprehensive view, a plurality of authority checking demands can be processed in parallel by combining IOPMP pipelines and a tree arbitration circuit, and meanwhile, intermediate results are saved through pipeline registers, and finally, the final access authority of the DMA request is finally generated, so that the expenditure of authority checking is reduced.
In this embodiment, a mountable IOPMP-segment table structure may be provided.
Fig. 7 is a schematic diagram of a mountable IOPMP-segment table structure according to an embodiment of the present application, where, as shown in fig. 7, unlike the entry tag in IOPMP or the SRC2MD table, the mountable IOPMP-segment table is reserved in protected memory, for example, PMP protected memory in RISC-V, and unauthorized software or devices cannot access. Thus, there is no hardware limitation on the size of the mountable IOPMP-segment table, provided that the physical memory is sufficient. The embodiment of the application can expand the results of the existing IOPMP entry table. eSRCMD denotes that the original SRC2MD registers are extended to support new functions or attributes. The extended register eSRCMD may be used to store information about more devices or I/O resources to more fully manage access rights to such resources. eSID, which may be to support more kinds or complex device identification in order to more finely manage the rights control of the device. The cold device associated memory domain index, i.e., MD, represents an extension to the cold device associated memory domain index to more flexibly manage the memory access rights associated with the devices. The rights of the cold device extra IOPMP items, extend IOPMP Entry, represent that the rights extension is performed on the cold device extra IOPMP items, possibly to support more kinds or complex rights control requirements. In combination, the above-described extension content extends the functionality and rights-related extensions of existing IOPMP-entry tables to support more kinds or complex device and rights management requirements.
Alternatively, as shown in fig. 7, when the device identifier SID is not in the on-chip SRC2MD table, an embodiment of the present application sets a procedure called cold device switching. The IOPMP checker generates a SID miss interrupt signal and the security monitor processes the interrupt, obtains the corresponding IOPMP entry in the mountable IOPMP segment table, loads eSID, memory fields into the eSRCMD register on-chip, and loads the additional IOPMP entry into the last memory field in the IOPMP entry table on-chip, with this value being set to MD62 in the embodiment of the application, which is not fixed.
Alternatively, as shown in fig. 7, once the cold device's corresponding eSID is loaded into the eSRCMD register in the SRC2MD, sIOPMP may continue to check for this DMA request further. The method comprises the steps of comparing eSID in a SRCMD table with device IDs in a DMA data packet, allowing interrupted DMA requests to continue to be executed after eSID is successfully matched with the device IDs in the DMA requests, selecting IOPMP entries related to the cold device, namely IOPMP entries in the last memory domain and other memory domains related to the device by a IOPMP checker, and finally entering a multi-stage tree IOPMP checker to conduct staged authority checking based on the selected IOPMP entries to generate final device I/O access authorities, wherein the cold device switching only occurs in the first DMA request. Subsequent DMA requests will not require additional operations and will be able to directly obtain all the permission check information from the on-chip hardware, so the cold device switch provides a fast check path for the cold device.
In this embodiment, IOPMP remapping mechanisms may be provided.
FIG. 8 is a diagram of a IOPMP remapping and device-id information table according to an embodiment of the present application, as shown in FIG. 8, in order to accommodate dynamic I/O tasks, the embodiment of the present application introduces a deviceID2SID table and adds a IOPMP remapping mechanism, since the I/O task load is constantly changing. The DeviceID2SID records the mapping relationship between the actual device ID and the SID used in sIOPMP. If a device changes from a cold state to a hot state, a switch in device state may be achieved by resetting the mapping in the DeviceID2SID table and assigning it a new hot SID. To ensure a fast and efficient SID lookup process, embodiments of the present application utilize the observation that although the range of device IDs may be large, the number of SIDs for a hot device is limited, with an embodiment of the present application set to less than 63. Therefore, the content addressable memory is well suited for use with the DeviceID2SID table. The CAM compares the input search data with the stored data table and returns the address of the matching data. In the DeviceID2SID table, the number of SIDs is fixed. Thus, the SID is considered an address, the device ID is considered content, and may be any value.
Alternatively, as shown in FIG. 8, the flow of I/O check after adding the DeviceID2SID table may include the process that the device ID will search in the device identifier to source identifier mapping table upon receipt of a DMA request. If the match is successful, the retrieved SID will be used to index the subsequent SRC2MD table, which is the hot device. Otherwise, this device ID will be considered eSID, i.e. the device is a cold device. The values in the eSID and eSRCMD registers are matched and if the match is successful, this indicates that the cold device is being used, i.e., a cold device switch has occurred. If the match is unsuccessful, indicating that the cold device is first used, a cold device switch interrupt will be generated, which can be resolved by the related techniques in the scalable IOPMP-segment table described above.
Optionally, sIOPMP also employs different strategies for hot and cold device switching, as shown in fig. 8. In general, there are two main approaches, explicit and implicit. In explicit switching, one predicts which devices are in hot state and which are not. Thus, it can explicitly set the mapping of device ID to SID. In implicit switching, a clock algorithm (LRU approximation algorithm) is implemented in the DeviceID2SID table with additional LRU bits. When the security monitor often loads a device ID into eSID bits in eSRCMD registers, this device should be considered a hot device. The security monitor evicts a relatively inactive device from the DeviceID2SID table based on the LRU bits and assigns its SID to the new device, thereby effecting a switch in the cold and hot states of the device. Using the different strategies described above, the I/O isolation scheme of embodiments of the present application can accommodate dynamic I/O workload and can adaptively adjust the cold and hot states of the device.
In this embodiment IOPMP has software architecture support.
FIG. 9 is a schematic diagram of a IOPMP software architecture according to an embodiment of the application, as shown in FIG. 9, employing a "capability-based" abstraction for securely managing IOPMP hardware resources. Each capability controls a particular hardware resource, only the owner having the right to operate the associated hardware. There are two basic operations of capability, derivation and transfer. Owners may derive a new capability from existing capabilities, but the rights may be reduced or less extensive. For example, one I/O access capability may be derived from an existing I/O access capability, but is narrower in scope or has limited rights. As for the transfer of capability, the owner may send ownership or a copy, i.e. having only read rights, to another entity. At system start-up, all of the capabilities are owned by the security monitor. The security monitor may selectively transfer ownership of the capability to the boot system. When the user intends to Create a TEE, it uses an ownership-based interface, such as create_tee (), to transfer ownership of the device and memory to the TEE. The TEE may then call device_map () to map the memory region for a particular Device. Using the ownership-based interface, the security monitor can easily verify the TEE's device mapping operations.
Alternatively, as shown in FIG. 9, to improve the modularity of the security monitor, the functionality is divided into two parts, a hardware controller and a capability layer. Hardware dependent controllers include interrupt controllers for interrupt isolation, IOPMP controllers for device isolation, and PMP controllers for memory isolation. While the "capability" layer abstracts all hardware resources into "capabilities". Only the owners of a particular capability are granted access to the corresponding hardware resources. The device manager and the memory manager maintain a linked list of ownership transfers (Ownership chain) for each device and memory region, while the TEE manager maintains a mapping from "capabilities" to hardware, i.e., which hardware resources the TEE can access.
In the embodiment of the application, a dynamic extensible IO isolation mechanism is provided and set, so that the cost brought by I/O isolation inspection under a high-load scene is greatly reduced. The application sets a micro-architecture of IO inspection, namely a multi-stage tree IOPMP inspector, which allows inspection of more IO isolation domains (> 1000) without sacrificing clock frequency. Meanwhile, the method can also support I/O devices with unlimited quantity, and provide corresponding block/slow check paths according to the cold and hot states of the I/O devices, so that the conflict between the quantity of the devices and the resource expense is solved. Finally, in order to cope with dynamically changing I/O load, an efficient device state switching mechanism is provided, and cold and hot device conversion close to cold overhead is realized. The SID and device ID in IOPMP are allowed to remap so that IOPMP total SID and device ID do not need to be hard bound.
In the embodiment of the application, if the memory in the system needs to be accessed, the memory access authority of the equipment can be determined first. In the process of determining the memory access authority, a IOPMP unit is set in order to reduce the cost of carrying out secure access on the equipment. If a memory access request is obtained that requires access to the memory of the system, then IOPMP may be utilized to check the memory access request. During the checking, the device may be caused to request access to data stored in the memory address corresponding to IOPMP units using the memory access request. And may determine IOPMP entries that the device matches in IOPMP units. The memory access request may be verified in IOPMP entries to determine whether the device has access rights in the corresponding IOPMP entry, and a corresponding verification result is obtained. And determining whether the current memory access request is allowed to access data in a memory address in the device based on whether the IOPMP entry has access rights. In the embodiment of the application, a pipelined I/O checking module, namely IOPMP units, is arranged to perform pipelined efficient checking on the memory access request, so that the memory access request of the equipment can be checked in multiple stages, namely, the memory access request is checked in multiple IOPMP items, so that the expenditure of authority checking is reduced, and the clock frequency is not influenced. Therefore, the purpose of reducing the cost of safety access to the equipment is achieved, the technical effect of effectively determining the memory access authority of the equipment is achieved, and the technical problem that the memory access authority of the equipment cannot be effectively determined is solved.
Example 4
According to an embodiment of the present application, there is also provided a device for determining a memory access right of an apparatus for implementing the method for determining a memory access right of an apparatus shown in fig. 2.
Fig. 10 is a schematic diagram of a device for determining memory access rights of a device according to an embodiment of the present application, and as shown in fig. 10, a device 1000 for determining memory access rights of a device may include a first obtaining unit 1002, a first verifying unit 1004, and a first generating unit 1006.
The first obtaining unit 1002 is configured to obtain a memory access request of the device, and determine at least one IOPMP entry that the device matches in the IOPMP unit, where the memory access request is used to make the device request to access data stored in a memory address corresponding to the IOPMP unit, and the IOPMP entry is used to represent a data structure of the IOPMP unit.
The first verification unit 1004 is configured to verify the memory access request in at least one IOPMP entry to obtain at least one verification result, where the verification result is used to indicate whether the device has access rights in the corresponding IOPMP entry.
A first generating unit 1006, configured to generate an access right result corresponding to the memory access request based on the verification result, where the access right result is used to indicate whether the device is allowed to access the data stored in the memory address.
Here, the first acquisition unit 1002, the first verification unit 1004, and the first generation unit 1006 described above correspond to step S202 to step S206 in embodiment 1, and the three units are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to those disclosed in embodiment 1 described above. It should be noted that the above-described units may be hardware components or software components stored in a memory (e.g., the memory 1204) and processed by one or more processors (e.g., the processors 1202a,1202 b...the 1202 n), or may be executed as a part of the apparatus in the computer terminal a provided in embodiment 5.
According to an embodiment of the present application, there is also provided a memory access device of an apparatus for implementing the memory access method of the apparatus shown in fig. 3.
Fig. 11 is a schematic diagram of a memory access device of an apparatus according to an embodiment of the present application, and as shown in fig. 11, a memory access device 1100 of the apparatus may include a second obtaining unit 1102, a second verifying unit 1104, a second generating unit 1106, a first transmitting unit 1108, and a second transmitting unit 1110.
A second obtaining unit 1102, configured to obtain a memory access request of the device, and determine at least one IOPMP entry that the device matches in IOPMP units, where the memory access request is used to make the device request to access data stored in a memory address corresponding to IOPMP units, and the IOPMP entry is used to represent a data structure of IOPMP units.
The second verification unit 1104 is configured to verify the memory access request in at least one IOPMP entry to obtain at least one verification result, where the verification result is used to indicate whether the device has access rights in the corresponding IOPMP entry.
The second generating unit 1106 is configured to generate an access right result corresponding to the memory access request based on the verification result.
The first transmitting unit 1108 is configured to transmit a memory access request to the memory address to access the data if the access permission result is that the device is allowed to access the data in the memory address.
The second transmitting unit 1110 is configured to prohibit transmitting the memory access request to the memory address to access the data if the access permission result is that the device is prohibited from accessing the data in the memory address.
Here, it should be noted that the second acquisition unit 1102, the second verification unit 1104, the second generation unit 1106, the first transmission unit 1108, and the second transmission unit 1110 correspond to steps S302 to S310 in embodiment 1, and the five units are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to those disclosed in embodiment 1. It should be noted that the above-described units may be hardware components or software components stored in a memory (e.g., the memory 1204) and processed by one or more processors (e.g., the processors 1202a,1202 b...the 1202 n), or may be executed as a part of the apparatus in the computer terminal a provided in embodiment 5.
In the device for determining the memory access permission of the equipment, if the memory in the system needs to be accessed, the memory access permission of the equipment can be determined first. In the process of determining the memory access authority, a IOPMP unit is set in order to reduce the cost of carrying out secure access on the equipment. If a memory access request is obtained that requires access to the memory of the system, then IOPMP may be utilized to check the memory access request. During the checking, the device may be caused to request access to data stored in the memory address corresponding to IOPMP units using the memory access request. And may determine IOPMP entries that the device matches in IOPMP units. The memory access request may be verified in IOPMP entries to determine whether the device has access rights in the corresponding IOPMP entry, and a corresponding verification result is obtained. And determining whether the current memory access request is allowed to access data in a memory address in the device based on whether the IOPMP entry has access rights. In the embodiment of the application, a pipelined I/O checking module, namely IOPMP units, is arranged to perform pipelined efficient checking on the memory access request, so that the memory access request of the equipment can be checked in multiple stages, namely, the memory access request is checked in multiple IOPMP items, so that the expenditure of authority checking is reduced, and the clock frequency is not influenced. Therefore, the purpose of reducing the cost of safety access to the equipment is achieved, the technical effect of effectively determining the memory access authority of the equipment is achieved, and the technical problem that the memory access authority of the equipment cannot be effectively determined is solved.
Example 5
Embodiments of the present application may provide a computer terminal, which may be any one of a group of computer terminals. Alternatively, in the present embodiment, the above-described computer terminal may be replaced with a terminal device such as a mobile terminal.
Alternatively, in this embodiment, the above-mentioned computer terminal may be located in at least one network device among a plurality of network devices of the computer network.
In this embodiment, the computer terminal may execute program code for acquiring a memory access request of a device and determining at least one IOPMP entry matched in IOPMP units by the device, where the memory access request is used to make the device request to access data stored in a memory address corresponding to IOPMP units, the IOPMP entry is used to represent a data structure of IOPMP units, verifying the memory access request in at least one IOPMP entry to obtain at least one verification result, where the verification result is used to represent whether the device has access rights in the corresponding IOPMP entries, and generating an access right result corresponding to the memory access request based on the verification result, where the access right result is used to represent whether the device is allowed to access the data stored in the memory address.
Alternatively, fig. 12 is a block diagram of a computer terminal according to an embodiment of the present application. As shown in fig. 12, the computer terminal a may include one or more (only one is shown in the figure) processors 1202, a memory 1204, and a transmission means 1206.
The memory may be used to store software programs and modules, such as program instructions/modules corresponding to the method and apparatus for determining memory access rights of devices in the embodiments of the present application, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the method for determining memory access rights of devices described above. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory may further comprise a memory remotely located with respect to the processor, the remote memory being connectable to the computer terminal a through a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.
The processor may call the information and the application program stored in the memory through the transmission device to determine a priority order of at least one IOPMP entry, and perform verification on the memory access request in at least one IOPMP entry according to the priority order to obtain at least one verification result.
Optionally, the processor may further execute program code to determine a first IOPMP entry in the at least one IOPMP entry according to the priority order, authenticate the memory access request in the first IOPMP entry to obtain a first authentication result, wherein the authentication result includes the first authentication result, and authenticate the first authentication result in the second IOPMP entry to obtain a second authentication result if the at least one IOPMP entry includes a next second IOPMP entry in the priority order of the first IOPMP entry, wherein the authentication result includes the second authentication result.
Optionally, the processor may further execute program code to determine a third IOPMP entry as a second IOPMP entry if the at least one IOPMP entry includes a next third IOPMP entry of the second IOPMP entry in the priority order, determine a second verification result as a first verification result, and return to executing the steps until the at least one IOPMP entry does not include a next third IOPMP entry of the second IOPMP entry in the priority order, verify the first verification result in the second IOPMP entry, and obtain the second verification result.
Optionally, the processor may further execute program code for determining, in IOPMP units, a sub-check module corresponding to the second IOPMP entry, and performing parallel verification on the first verification result and the second IOPMP entry by using the first tree arbitration circuit in the sub-check module to obtain a second verification result.
Optionally, the processor may further execute program code for writing the second verification result output by the first tree-like arbitration circuit into the register.
Optionally, the processor may further execute program code for determining a time period corresponding to the second IOPMP entries, and verifying the first verification result in the second IOPMP entries during the time period to obtain a second verification result.
Optionally, the processor may further execute program code for determining a second tree-like arbitration circuit in IOPMP units, and performing reduction processing on at least one verification result in the second tree-like arbitration circuit according to a priority order to obtain an access right result, where the verification result corresponds to a node of the second tree-like arbitration circuit.
Optionally, the processor may further execute program code for determining a root node of the second tree-like arbitration circuit, and reducing at least one verification result to the root node in order of priority to obtain an access right result.
Optionally, the processor may further execute program code for generating a missing interrupt signal in the case that source identification information of the device is missing, where the missing interrupt signal is used to indicate that the source identification information is missing, executing a memory access request in response to the missing interrupt signal, and acquiring extended source identification information of the device, and loading the extended source identification information into an extended register table corresponding to a register table of IOPMP units, where the register table corresponds to an active identification information set and is used to identify a memory domain associated with the source identification information in the source identification information set, and the extended register table is obtained by expanding registers in the register table.
Optionally, the processor may further execute program code for, in the case of loading the extension source identification information into the extension register table, matching the extension source identification information with hardware identification information of the device in the memory access request, and canceling the interrupt to execute the memory access request if the extension source identification information and the hardware identification information of the device in the memory access request are successfully matched.
Optionally, the processor may further execute program code to determine at least one IOPMP entry corresponding to the hardware identification information of the device in the IOPMP entry set of the IOPMP unit.
Optionally, the above processor may further execute program code for determining, if the hardware identification information of the device corresponding to the memory access request is found in the device identification information table, source identification information of the device corresponding to the hardware identification information of the device in the device identification information table, where the device identification information table is used to represent a mapping relationship between the source identification information of the device and the hardware identification information of the device, indexing the register table based on the source identification information of the device, and determining that the device is in a hot state.
Optionally, the processor may further execute program code for determining that the hardware identification information of the device is extension source identification information and determining that the device is in a cold state if the hardware identification information of the device is not found in the device identification information table, matching values in the extension source identification information and the extension register table, determining that the device is in a use state if the extension source identification information and the values in the extension register table are successfully matched, and triggering a miss interrupt signal if the matching of the extension source identification information and the values in the extension register table is failed.
Optionally, the above processor may further execute program code for establishing a mapping relationship between source identification information of the device in the hot state and hardware identification information of the device in the hot state in the device identification information table if the device switches from the cold state to the hot state.
Optionally, the above processor may further execute program code for acquiring IOPMP the frequency at which the security monitor of the unit loads the hardware identification information of the device to the extended register table, determining that the device is in a hot state if the frequency is greater than the frequency threshold, and controlling the security monitor to replace the source device identification information of the device in the hot state with the source device identification information of the original device in the cold state in the device identification information table.
Optionally, the processor may further execute program code to determine IOPMP units of hardware resources, determine an initial type of operation to allow execution of the hardware resources, determine a target type of operation based on the initial type of operation, wherein the range of operation authority of the target type of operation on the hardware resources is smaller than the range of operation authority of the initial type of operation on the hardware resources, and/or transfer operation authority to allow execution of the initial type of operation on the hardware resources from the initial operation object to the target operation object.
Optionally, the processor may further execute program code for transferring the operation authority that allows the initial type operation to be performed on the hardware resource from the security monitor of the IOPMP unit to the start-up system corresponding to the initial type operation, where the initial operation object includes the security monitor and the target operation object includes the start-up system.
Optionally, the processor may call the information and the application program stored in the memory through the transmission device to execute the steps of acquiring a memory access request of the device, determining at least one IOPMP entry matched in the IOPMP unit by the device, wherein the memory access request is used for enabling the device to request to access data stored in a memory address corresponding to the IOPMP unit, IOPMP entries are used for representing a data structure of the IOPMP unit, verifying the memory access request in at least one IOPMP entry to obtain at least one verification result, wherein the verification result is used for representing whether the device has access authority in the corresponding IOPMP entry, generating an access authority result corresponding to the memory access request based on the verification result, transmitting the memory access request to access data in the memory address if the access authority result is data in the memory address allowed to be accessed by the device, and prohibiting the memory access request from being transmitted to the memory address to access data if the access authority result is data in the memory address prohibited to be accessed by the device.
The embodiment of the application provides a method for determining the memory access permission of equipment. In the embodiment of the application, if the memory in the system needs to be accessed, the memory access authority of the device can be determined first. In the process of determining the memory access authority, a IOPMP unit is set in order to reduce the cost of carrying out secure access on the equipment. If a memory access request is obtained that requires access to the memory of the system, then IOPMP may be utilized to check the memory access request. During the checking, the device may be caused to request access to data stored in the memory address corresponding to IOPMP units using the memory access request. And may determine IOPMP entries that the device matches in IOPMP units. The memory access request may be verified in IOPMP entries to determine whether the device has access rights in the corresponding IOPMP entry, and a corresponding verification result is obtained. And determining whether the current memory access request is allowed to access data in a memory address in the device based on whether the IOPMP entry has access rights. In the embodiment of the application, a pipelined I/O checking module, namely IOPMP units, is arranged to perform pipelined efficient checking on the memory access request, so that the memory access request of the equipment can be checked in multiple stages, namely, the memory access request is checked in multiple IOPMP items, so that the expenditure of authority checking is reduced, and the clock frequency is not influenced. Therefore, the purpose of reducing the cost of safety access to the equipment is achieved, the technical effect of effectively determining the memory access authority of the equipment is achieved, and the technical problem that the memory access authority of the equipment cannot be effectively determined is solved.
It will be appreciated by those skilled in the art that the structure shown in fig. 12 is merely illustrative, and the computer terminal a may be a terminal device such as a smart phone (e.g. an Android phone, an iOS phone, etc.), a tablet computer, a palm computer, and a mobile internet device (Mobi LE INTERNET DEVICES, abbreviated as MID), a PAD, etc. Fig. 12 does not limit the structure of the computer terminal a. For example, the computer terminal a may also include more or fewer components (such as a network interface, a display device, etc.) than shown in fig. 12, or have a different configuration than shown in fig. 12.
Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments may be implemented by a program for instructing a terminal device to execute the relevant hardware, and the program may be stored in a computer readable storage medium, where the storage medium may include a flash disk, a Read-only memory (ROM), a random access memory (Random Access Memory, RAM), a magnetic disk, or an optical disk.
Example 6
Embodiments of the present application also provide a computer-readable storage medium. Alternatively, in this embodiment, the computer readable storage medium may be used to store the program code executed by the method for determining the memory access rights of the device provided in the first embodiment.
Alternatively, in this embodiment, the above-mentioned computer-readable storage medium may be located in any one of the computer terminals in the computer terminal group in the computer network, or in any one of the mobile terminals in the mobile terminal group.
Optionally, in this embodiment, the computer readable storage medium is configured to store program code for obtaining a memory access request of the device and determining at least one IOPMP entry matching the device in IOPMP units, wherein the memory access request is for the device to request access to data stored in a memory address corresponding to IOPMP units, the IOPMP entry is for representing a data structure of IOPMP units, validating the memory access request in the at least one IOPMP entry to obtain at least one validation result, wherein the validation result is for representing whether the device has access rights in the corresponding IOPMP entry, and generating an access rights result corresponding to the memory access request based on the validation result, wherein the access rights result is for representing whether the device is allowed to access the data stored in the memory address.
The processor may call the information and the application program stored in the memory through the transmission device to determine a priority order of at least one IOPMP entry, and perform verification on the memory access request in at least one IOPMP entry according to the priority order to obtain at least one verification result.
Optionally, the computer readable storage medium may further execute the program code for determining a first IOPMP entry from at least one IOPMP entry according to a priority order, validating the memory access request in the first IOPMP entry to obtain a first validation result, wherein the validation result includes the first validation result, and validating the first validation result in a second IOPMP entry to obtain a second validation result if at least one IOPMP entry includes a next second IOPMP entry of the first IOPMP entry in the priority order, wherein the validation result includes the second validation result.
Optionally, the computer readable storage medium may further execute the program code for determining the third IOPMP item as the second IOPMP item if the at least one IOPMP item includes a next third IOPMP item of the second IOPMP item in the priority order, determining the second verification result as the first verification result, and returning to execute the steps until the at least one IOPMP item does not include a next third IOPMP item of the second IOPMP item in the priority order, verifying the first verification result in the second IOPMP item, and obtaining the second verification result.
Optionally, the computer readable storage medium may further execute program code for determining, in IOPMP units, a sub-check module corresponding to the second IOPMP entry, and performing parallel verification on the first verification result and the second IOPMP entry by using the first tree arbitration circuit in the sub-check module to obtain a second verification result.
Optionally, the above computer readable storage medium may further execute the program code of writing the second verification result output by the first tree-like arbitration circuit into the register.
Optionally, the computer readable storage medium may further execute program code for determining a time period corresponding to the second IOPMP items, and verifying the first verification result in the second IOPMP items during the time period to obtain a second verification result.
Optionally, the computer readable storage medium may further execute the program code for determining a second tree-like arbitration circuit in IOPMP units, and performing reduction processing on at least one verification result according to the priority order in the second tree-like arbitration circuit to obtain an access right result, wherein the verification result corresponds to a node of the second tree-like arbitration circuit.
Optionally, the computer readable storage medium may further execute program code for determining a root node of the second tree-like arbitration circuit, and reducing at least one verification result to the root node in order of priority to obtain an access right result.
Optionally, the computer readable storage medium may further execute program code for generating a missing interrupt signal in the case that source identification information of the device is missing, wherein the missing interrupt signal is used for indicating that the source identification information is missing, executing a memory access request in response to the missing interrupt signal, and acquiring extended source identification information of the device, and loading the extended source identification information into an extended register table corresponding to a register table of IOPMP units, wherein the register table corresponds to an active identification information set and is used for identifying a memory domain associated with the source identification information in the source identification information set, and the extended register table is obtained by expanding registers in the register table.
Optionally, the above computer readable storage medium may further execute the program code for, in a case where the extension source identification information is loaded into the extension register table, matching the extension source identification information with the hardware identification information of the device in the memory access request, and if the extension source identification information and the hardware identification information of the device in the memory access request are successfully matched, canceling the interrupt of executing the memory access request.
Optionally, the computer readable storage medium may further execute the program code to determine at least one IOPMP item corresponding to the hardware identification information of the device in IOPMP item set of IOPMP units.
Optionally, the above computer readable storage medium may further execute program code for determining, if hardware identification information of a device corresponding to the memory access request is found in the device identification information table, source identification information of the device corresponding to the hardware identification information of the device in the device identification information table, wherein the device identification information table is used to represent a mapping relationship between the source identification information of the device and the hardware identification information of the device, indexing the register table based on the source identification information of the device, and determining that the device is in a hot state.
Optionally, the computer readable storage medium may further execute program code for determining that the hardware identification information of the device is extended source identification information and determining that the device is in a cold state if the hardware identification information of the device is not found in the device identification information table, matching values in the extended source identification information and the extended register table, determining that the device is in a use state if the matching of the extended source identification information and the values in the extended register table is successful, and triggering a miss interrupt signal if the matching of the extended source identification information and the values in the extended register table is failed.
Alternatively, the above-mentioned computer-readable storage medium may further execute the program code of the step of, if the device is switched from the cold state to the hot state, establishing a mapping relationship between source identification information of the device in the hot state and hardware identification information of the device in the hot state in the device identification information table.
Optionally, the above computer readable storage medium may further execute program code for acquiring IOPMP units of the frequency at which the security monitor loads the hardware identification information of the device to the extended register table, determining that the device is in a hot state if the frequency is greater than the frequency threshold, and controlling the security monitor to replace the source device identification information of the device in the hot state with the source device identification information of the original device in the cold state in the device identification information table.
Optionally, the above computer readable storage medium may further execute program code to determine IOPMP units of hardware resources, determine an initial type of operation to allow execution of the hardware resources, determine a target type of operation based on the initial type of operation, wherein the range of operation authority of the target type of operation on the hardware resources is smaller than the range of operation authority of the initial type of operation on the hardware resources, and/or transfer operation authority to allow execution of the initial type of operation on the hardware resources from the initial operation object to the target operation object.
Optionally, the above computer readable storage medium may further execute program code for transferring operation rights allowing an initial type operation to be performed on the hardware resource from the security monitor of the IOPMP unit to a start-up system corresponding to the initial type operation, wherein the initial operation object includes the security monitor and the target operation object includes the start-up system.
Optionally, the computer readable storage medium may further execute program code for obtaining a memory access request of the device, determining at least one IOPMP entry matched in IOPMP units by the device, wherein the memory access request is used for making the device request to access data stored in a memory address corresponding to the IOPMP units, IOPMP entries are used for representing a data structure of the IOPMP units, verifying the memory access request in at least one IOPMP entry to obtain at least one verification result, wherein the verification result is used for representing whether the device has access authority in the corresponding IOPMP entries, generating an access authority result corresponding to the memory access request based on the verification result, transmitting the memory access request to access data in the memory address if the access authority result is data in the allowed memory address, and prohibiting the memory access request from being transmitted to access data in the memory address if the access authority result is data in the prohibited memory address.
Example 7
Embodiments of the application may provide an electronic device that may include a memory and a processor.
Fig. 13 is a block diagram of an electronic device according to a method for determining memory access rights of the device according to an embodiment of the present application. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be exemplary only, and are not meant to limit implementations of the applications described and/or claimed herein.
As shown in fig. 13, the apparatus 1300 includes a computing unit 1301 that can perform various appropriate actions and processes according to a computer program stored in a Read Only Memory (ROM) 1302 or a computer program loaded from a storage unit 1308 into a Random Access Memory (RAM) 1303. In the RAM1303, various programs and data required for the operation of the device 1300 can also be stored. The computing unit 1301, the ROM1302, and the RAM1303 are connected to each other through a bus 1304. An input/output (I/O) interface 1305 is also connected to bus 1304.
Various components in the device 1300 are connected to the I/O interface 1305, including an input unit 1306, such as a keyboard, mouse, etc., an output unit 1304, such as various types of displays, speakers, etc., a storage unit 1308, such as a magnetic disk, optical disk, etc., and a communication unit 1309, such as a network card, modem, wireless communication transceiver, etc. The communication unit 1309 allows the device 1300 to exchange information/data with other devices through a computer network such as the internet and/or various telecommunication networks.
The computing unit 1301 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of computing unit 1301 include, but are not limited to, a Central Processing Unit (CPU), a graphics processing unit (Graphics Process ing Unit, abbreviated as GPU), various specialized artificial intelligence (ART IFICIAL INTEL L IGENCE, abbreviated as AI) computing chips, various computing units running machine learning model algorithms, a digital signal Processor (DIGITAL SIGNAL Processor, abbreviated as DSP), and any suitable Processor, controller, microcontroller, etc. The computing unit 1301 performs the respective methods and processes described above, for example, a method of determining memory access rights of a device. For example, in some embodiments, the method of determining memory access rights of a device may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as storage unit 1308. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device 1300 via the ROM 1302 and/or the communication unit 1309. When the computer program is loaded into the RAM 1303 and executed by the computing unit 1301, one or more steps of the above-described method of determining memory access rights of a device may be performed. Alternatively, in other embodiments, computing unit 1301 may be configured to perform the method of determining the memory access rights of the device in any other suitable way (e.g. by means of firmware).
Example 8
Embodiments of the present application also provide a computer program product. Optionally, in this embodiment, the computer program product may include a computer program, where the computer program when executed by a processor implements the method for determining a memory access permission of a device according to the embodiment of the present application.
According to an embodiment of the present application, there is provided a method for determining memory access rights of a device, it being noted that the steps shown in the flowchart of the drawings may be performed in a computer system such as a set of computer executable instructions, and that although a logical order is shown in the flowchart, in some cases the steps shown or described may be performed in an order different from that herein.
The method embodiment provided in embodiment 8 of the present application may be executed in a mobile terminal, a computer terminal, or a similar computing device. Fig. 14 is a block diagram of a hardware structure of a computer terminal (or mobile device) for implementing a method for determining memory access rights of a device according to an embodiment of the present application, as shown in fig. 14, the computer terminal 140 (or mobile device) may include one or more (shown as 1402a, 1402b in the figure.) processors 1402 (the processor 1402 may include, but is not limited to, a microprocessor (Microcontrol lerUnit, abbreviated as MCU) or a processing device such as a programmable logic device (Field Programmable GATE ARRAY, abbreviated as FPGA)), a memory 1404 for storing data, and a transmission device 1406 for a communication function. Among other things, a display, an input/output interface (I/O interface), a universal serial BUS (Universal Serial Bus, simply USB) port (which may be included as one of the ports of the BUS BUS), a network interface, a power supply, and/or a camera may be included. It will be appreciated by those of ordinary skill in the art that the configuration shown in fig. 14 is merely illustrative and is not intended to limit the configuration of the electronic device described above. For example, the computer terminal 140 may also include more or fewer components than shown in fig. 14, or have a different configuration than shown in fig. 14.
The hardware block diagram shown in fig. 14 may be used not only as an exemplary block diagram of the computer terminal 140 (or mobile device) described above, but also as an exemplary block diagram of the server described above, and in an alternative embodiment, fig. 14 shows, in block diagram form, an embodiment in which the computer terminal 140 (or mobile device) shown in fig. 14 described above is used as a computing node in a computing environment 1501.
Fig. 15 is a block diagram of a computing environment for a method of determining memory access permissions of a device according to an embodiment of the present application, as shown in fig. 15, the computing environment 1501 includes a plurality of (1510-1, 1510-2, shown) computing nodes (e.g., servers) running on a distributed network. The computing nodes each contain local processing and memory resources and end user 1502 may run applications or store data remotely in computing environment 1501. An application may be provided as a plurality of services 1520-1,1520-2,1520-3 and 1520-4 in computing environment 1501, representing services "F", "G", "I", and "H", respectively.
End user 1502 may provide and access services through a web browser or other software application on a client, in some embodiments, provisioning and/or requests of end user 1502 may be provided to portal gateway 1530. The ingress gateway 1530 may include a corresponding agent to handle provisioning and/or requests for services (one or more services provided in the computing environment 1501).
Services are provided or deployed in accordance with various virtualization techniques supported by the computing environment 1501. In some embodiments, services may be provided according to Virtual Machine (VM) based virtualization, container based virtualization, and/or the like. Virtual machine-based virtualization may be the emulation of a real computer by initializing a virtual machine, executing programs and applications without directly touching any real hardware resources. While the virtual machine virtualizes the machine, according to container-based virtualization, a container may be started to virtualize the entire operating system so that multiple workloads may run on a single operating system instance.
In one embodiment based on container virtualization, several containers of a service may be assembled into one Pod (e.g., kubernetes Pod). For example, as shown in fig. 15, service 1520-2 may be equipped with one or more Pod 1540-1, 1540-2. The Pod may include an agent 1545 and one or more containers 1542-1,1542-2, 1542-M (collectively referred to as containers). One or more containers in the Pod handle requests related to one or more corresponding functions of the service, and the agent 1545 typically controls network functions related to the service, such as routing, load balancing, and the like. Other services may also be equipped with Pod similar to Pod.
In operation, executing a user request from an end user 1502 may require invoking one or more services in the computing environment 1501, and executing one or more functions of one service may require invoking one or more functions of another service. As shown in FIG. 15, service "F"1520-1 receives a user request of end user 1502 from ingress gateway 1530, service "F"1520-1 may invoke service "G"120-2, and service "G"1520-2 may request service "I"1520-3 to perform one or more functions.
The computing environment may be a cloud computing environment, and the allocation of resources is managed by a cloud service provider, allowing the development of functions without considering the implementation, adjustment or expansion of the server. The computing environment allows developers to execute code that responds to events without building or maintaining a complex infrastructure. Instead of expanding a single hardware device to handle the potential load, the service may be partitioned to a set of functions that can be automatically scaled independently.
Various implementations of the systems and techniques described here above can be implemented in digital electronic circuitry, integrated circuit System, field Programmable Gate Array (FPGA), application Specific Integrated Circuit (ASIC), application Specific Standard Product (ASSP) SPECIFIC STANDARD PARTS, system-on-a-Chip (SOC), complex programmable logic device (Complex Programmable Logic Device, CPLD), computer hardware, firmware, software, and/or combinations thereof. The various embodiments described above may include being implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be a special or general purpose programmable processor, operable to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
Program code for carrying out methods of the present application may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.
Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuit systems, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), systems On Chip (SOCs), complex Programmable Logic Devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. The various embodiments described above may include being implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be a special or general purpose programmable processor, operable to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
Program code for carrying out methods of the present application may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.
In the context of the present application, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read-Only Memory, simply EPROM or flash Memory), an optical fiber, a portable compact disc read-Only Memory (Compact Disc Read-Only Memory, simply CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a Cathode Ray Tube (CRT) or Liquid CRYSTAL DISPLAY, LCD) monitor for displaying information to the user; other types of devices may also be used to provide interaction with the user, for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user may be received in any form (including acoustic input, speech input, or tactile input).
The systems and techniques described here can be implemented in a computing system that includes a background component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front-end component (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such background, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (Local Area Network, abbreviated LAN), a wide area network (Wide Area Network, abbreviated WAN), and the Internet.
The computer system may include a client and a server. The client and server are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server incorporating a blockchain.
It should be noted that, the foregoing reference numerals of the embodiments of the present application are merely for describing the embodiments, and do not represent the advantages and disadvantages of the embodiments.
In the foregoing embodiments of the present application, the descriptions of the embodiments are emphasized, and for a portion of this disclosure that is not described in detail in this embodiment, reference is made to the related descriptions of other embodiments.
In the several embodiments provided in the present application, it should be understood that the disclosed technology may be implemented in other manners. The above-described embodiments of the apparatus are merely exemplary, and are merely a logical functional division, and there may be other manners of dividing the apparatus in actual implementation, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be through some interfaces, units or modules, or may be in electrical or other forms.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method of the various embodiments of the present application. The storage medium includes various media capable of storing program codes, such as a usb disk, a read-only memory, a random access memory, a removable hard disk, a magnetic disk, or an optical disk.
The foregoing is merely a preferred embodiment of the present application and it should be noted that modifications and adaptations to those skilled in the art may be made without departing from the principles of the present application, which are also intended to be considered as protecting the scope of the present application.