TWI806736B - Bridge device and method for transferring data between buses - Google Patents

Abstract

A bridging device and a method for transferring data between buses are provided. The bridge device includes a first bus access end, at least one second bus access end, and a processor. The second bus access ends are selectively coupled to at least one terminal belonging to the second protocol, respectively. All or part of the second bus access ends are corresponded to respective security status identifiers. The processor obtains a transaction request from the first bus access end. The processor determines whether a target terminal of the transaction request is one of the terminals. The processor determines whether to transmit the transaction request to the target terminal according to a first secure flag of the transaction request and a secure status identifier corresponding to the second bus access end connected to the target terminal.

Description

Bridge device and method for transferring data between bus bars

The invention relates to a data security technology of an electronic device, and in particular to a bridge device and a method for transferring data between busbars.

According to the complexity of the instruction set, the central processing unit (CPU) can be divided into a complex instruction set computer (CISC) architecture and a reduced instruction set computer (RISC) architecture. CPUs belonging to the RISC architecture are often used in consumer electronic devices such as smartphones and tablet computers. On the other hand, today's life is increasingly dependent on consumer electronic devices, so that the consumer electronic devices will more or less store the user's confidential information, device operation information that cannot be changed, etc., so that the data security more stringent requirements.

There are multiple bus bars in the electronic device to facilitate mutual information transfer between multiple components in the electronic device. However, the protocols implemented by these buses may differ from each other. Compatibility issues may arise when interconnecting buses that implement different protocols. Although some protocols have developed data security technologies (for example, TrustZone technology based on the Advanced Reduced Instruction Set Machine (ARM) architecture of the same family as the RISC architecture) technology), but other protocols (eg, Peripheral Component Interconnect Express (PCI-E)) may not be able to support the aforementioned data security technology accordingly.

The embodiment of the present invention provides a bridge device and a method for transferring data between bus bars, which can enable the terminal of the PCI-E protocol to support the trust zone technology based on the ARM structure through the aforementioned bridge device, and expand the application range of the trust zone technology to achieve Data security.

The bridging device according to the embodiment of the present invention includes a first bus access terminal, at least one second bus access terminal, and a processor. The first bus access terminal is coupled to a first bus of a first protocol. The at least one second bus access port is selectively coupled to at least one terminal of a second protocol respectively. The processor is coupled to the first bus access terminal and the at least one second bus access terminal, wherein all or part of the at least one second bus access terminal corresponds to a respective security state identifier. The processor obtains a first transaction request from the first bus access terminal, wherein the first transaction request includes a first security token. The processor determines whether the first transaction request is based on the first security flag of the first transaction request and the security state identifier corresponding to the at least one second bus access terminal coupled to a target terminal. The second protocol is translated and delivered to the target terminal, wherein the target terminal is one of the at least one terminal.

The method for transferring data between bus bars according to the embodiment of the present invention includes the following steps. obtain a first transaction request from a first bus access port of the bridge device, wherein the first transaction request includes a first security token, the first bus access port coupled to a first protocol The first bus bar, the at least one second bus bar access terminals are respectively selective ground coupled to the at least one terminal of a second protocol, all or part of the at least one second bus access terminal corresponding to a respective security state identifier; and, according to the first transaction request of the first a security flag and the security state identifier corresponding to the at least one second bus access terminal coupled to the target terminal to determine whether to translate and deliver the first transaction request to the target terminal based on the second protocol, Wherein the target terminal is one of the at least one terminal.

Based on the above, the bridging device and the method for performing data security between buses in the embodiments of the present invention enable the terminals belonging to the PCI-E protocol to support the trust zone technology based on the ARM structure through the bridging device. In other words, the bridge device translates and transmits the transaction request through the security status identifier corresponding to the bus access terminal belonging to the PCI-E protocol and the security flag in the transaction request for data access, so that the coupling Terminals connected to the bridge device and belonging to the PCI-E protocol can access data with components under the ARM structure through the trust zone technology, expanding the application range of the trust zone technology to achieve data security.

100, 800: electronic device

102: CPU

105: System memory

107: The first bus bar

110: Bridge device

112: the first bus access terminal

115: switch

116: Processor

118: Bridge terminal

120-1~120-3: terminal

200, 610, 620, 630: table

210: data block

AxPROT, AxPROT[1]: safety mark

M: main access port

S: slave access terminal

RP1~RP3: The second bus access port

310: root port security status table

320:Memory address range table

S410~S448, S440’, S440”, S510~S550, S710~S760, S935, S942~S948: steps

816: Security level confirmer

815-1~815-3: Safety status judge

TYPE: The type of security state lookup table

TYPE1: The first type of security status lookup table

TYPE2: The second type of security status lookup table

RSV: reserved area

Device_ID: device identifier

SIZE_RANGE: Size range

MBR: memory base address

Bit63-24, Bit23-8, Bit7-1, Bit0, Bit63-6, Bit5-1, Bit63-56, Bit55-48, Bit47-40, Bit39-32, Bit31-24, Bit23-16, Bit15-8, Bit7-0: bit

FIG. 1 is a schematic diagram of an electronic device 100 according to an embodiment of the present invention.

FIG. 2 is a schematic diagram of signals of the TrustZone protocol based on the ARM structure.

FIG. 3 is a schematic diagram illustrating how the bridging device performs data access according to the trust zone protocol according to the first embodiment of the present invention.

FIG. 4 is a flowchart of a method for transferring data between buses according to the first embodiment of the present invention.

FIG. 5 is another flowchart of a method for transferring data between buses according to the first to third embodiments of the present invention.

FIG. 6 is a schematic diagram illustrating a security state lookup table and an example thereof for a bridge device recording a terminal as a security state according to a second embodiment of the present invention.

FIG. 7 is a flowchart of a method for transferring data between buses according to a second embodiment of the present invention.

FIG. 8 is a schematic diagram of an electronic device according to a third embodiment of the present invention.

FIG. 9 is a flowchart of a method for transferring data between buses according to a third embodiment of the present invention.

In the embodiment of the present invention, the terminal belonging to the PCI-E protocol can support the trust zone technology based on the ARM structure through the bridging device. FIG. 1 is a schematic diagram of an electronic device 100 according to an embodiment of the present invention. The electronic device 100 mainly includes a CPU 102, a system memory 105, a first bus 107, a bridge device 110, a switch 115 belonging to the PCI-E protocol, and terminals 120-1~120-3 belonging to the PCI-E protocol.

The central processing unit 102 in this embodiment is a processor with an Advanced Reduced Instruction Set Machine (ARM) architecture. The CPU 102, the system memory 105, and the first bus 107 belonging to the first protocol are all implemented based on the ARM structure. In other words, the first bus bar 107 belongs to the first protocol, and the first protocol in this embodiment may be based on A bus protocol for the ARM architecture. For example, this first protocol may be an AXI, ACE or ACE-lite protocol.

The bridge device 110 is coupled to the first bus bar 107 , one or more switches 115 belonging to the PCI-E protocol, and one or more terminals 120 - 1 -120 - 3 . The bridge device 110 is used to bridge and convert the data and instructions belonging to the first bus 107 belonging to the first protocol into data and instructions belonging to the second protocol (the PCI-E protocol in this embodiment), so that the central processing unit 102 can pass through the bridge. The device 110, the switch 115 and the terminals 120-1~120-3 access data. Moreover, the bridging device 110 converts the data and commands belonging to the second command into data and commands belonging to the first bus 107 of the first protocol, so that the terminals 120-1~120-3 communicate with the central processing unit 102 through the bridging device 110 Or the system memory 105 accesses data. The bridging device 110 in this embodiment may be a root complex (root complex; RC) conforming to the PCI-E protocol.

The number of switches 115 and terminals 120-1~120-3 and the connection relationship between these components are only examples of this embodiment. Those who apply this embodiment can adjust the number of switches and terminals and the connections of these components according to their needs. Connection relationship, for example, a certain terminal can be connected to the bridge device 110 through multiple switches. On the other hand, the person applying this embodiment can selectively connect the switch 115 or the terminals 120 - 1 - 120 - 3 to the bridge device 110 according to their needs.

In other embodiments consistent with the present invention, in addition to the first bus bar 107 being directly coupled to the bridge device 110, the first bus bar 107 can also be indirectly coupled to the bridge device through a system memory control unit (SMMU) in the ARM architecture. device 110, this embodiment does not limit whether the connection between the first bus bar 107 and the bridging device 110 is through its other components to achieve.

The bridge device 110 includes a first bus access port 112 , at least one second bus access port RP1 - RP3 and a processor 116 . The first bus access port 112 is coupled to the first bus 107 belonging to the first protocol. The first bus access terminal 112 in this embodiment can also be divided into the main access terminal M for providing the information sent by the bridge device 110 to the first bus 107 and the main access terminal M for providing the information provided by the first bus 107. The message is received by the slave access terminal S of the bridge device 110 . Specifically, the bridge device 110 can retrieve the information (such as incoming memory transaction data) provided by the first bus 107 according to the memory location in the aforementioned message, by retrieving the information corresponding to each terminal in the bridge device 110 Register setting of the memory location range (for example, the memory location range set by the memory base and the memory limit), so as to find the terminal corresponding to the message and Carry out the location reference of the primary interface (for example, the first bus protocol based on the ARM structure) and the secondary interface (for example, the PCI-E protocol), so that the aforementioned information (memory transaction data) Provided in the corresponding busbar or corresponding terminal belonging to the second protocol. In other words, when the bridge device 110 uses the message (memory transaction data) to find the target terminal belonging to the second protocol, it does not need to convert the memory location, and the bridge device 110 can transfer the corresponding terminal belonging to the second protocol to If the memory location range corresponding to the first protocol is set, there is no need to perform memory address conversion.

The second bus access ports RP1 - RP3 are respectively selectively coupled to at least one terminal 120 - 1 - 120 - 3 belonging to the second protocol (PCI-E protocol). For example, the second bus access port RP1 can be coupled to the terminal 120-1 through the switch 115, the second bus access The terminals RP2-RP3 are directly coupled to the terminals 120-2-120-3. The second bus access ports RP1 - RP3 in this embodiment may be referred to as root ports. Those who apply this embodiment adjust the number of access ports RP1 - RP3 of the second bus according to their needs. The switch 115 and the terminals 120-1-120-3 are devices belonging to the second protocol (PCI-E protocol). The processor 116 is coupled to the first bus access port 112 and the second bus access ports PR1 - PR3 , and implements the method and corresponding technology for transferring data between the bus bars through the aforementioned components.

The bridge device 110 also includes a bridge terminal 118 . The bridge terminal 118 in this embodiment may be a root-complex (Root-Complex) integrated terminal (integrated end-point).

The trust zone technology based on the ARM structure is described here. FIG. 2 is a schematic diagram of signals of the trust zone protocol based on the ARM structure. The trust zone protocol is defined by the architecture of the ARM system for the purpose of extending security. The trust zone agreement mainly defines the respective security status identifiers of these components for each component, and sets them in the transaction request for data access to present its security level (that is, the transaction request is divided into "secure access" and the security flag "unsecure access"). The security state identifier will distinguish the corresponding component into "safe state" and "non-safe state". The security flag in the transaction request will distinguish the transaction request into "secure access" and "non-secure access". The transaction request in this embodiment is a related instruction for data access.

According to the signal schematic diagram shown in FIG. 2 , and in conjunction with the corresponding description in Section A4.7 of the AXI and ACE protocol specifications in the Advanced Microcontroller Bus Architecture (AMBA), FIG. 2 shows the data block of the table 200 A security token AxPROT[1] is presented in 210, which is used to represent the current transaction (transaction) security level. When the value of AxPROT[1] is "0", it means that the transaction is "secure access"; when the value of AxPROT[1] is "1", it means that the transaction is "non-secure access". That is to say, the transaction request corresponding to the value of AxPROT[1] being "0" can perform data access to components whose security status identifiers are "secure status" and "non-secure status". However, the transaction request corresponding to the value of AxPROT[1] is "1" can only perform data access to the component whose security state identifier is "non-secure state", but the transaction corresponding to the value of AxPROT[1] is "1" The request cannot perform data access to a component whose security status identifier is "secure status". Therefore, many embodiments of the present invention will record in the bridge device 110 all or part of the second bus access ports RP1-RP3 corresponding to their respective security status identifiers, so as to determine the connection with these second bus bars according to these security status identifiers. The terminals 120-1-120-3 connected to the access terminals RP1-RP3 are in a "secure state" or a "non-secure state".

In this way, if a transaction request is transmitted from the first bus 107 to the bridge device 110, the bridge device 110 can detect the security flag in the transaction request according to the security status identifiers corresponding to the access ports RP1-RP3 of the second bus. Decide whether to pass the transaction request to the corresponding target terminal, so as to perform data access in compliance with the trust zone protocol. Conversely, if a transaction request is transmitted from one of the terminals 120-1 to 120-3 to the bridge device 110, the bridge device 110 may also be connected to the second bus access port corresponding to the terminal that sends the transaction request. The security status identifier is used to adjust the security flag in the transaction request, and then the adjusted transaction request can be transmitted to the first bus 107, so as to perform data access in compliance with the trust zone protocol.

Fig. 3 illustrates how the bridging device 110 proceeds according to the first embodiment of the present invention Schematic diagram of performing data access in compliance with the trusted zone protocol. In addition to the multiple components described in FIG. 1 , FIG. 3 also shows data required for data access in the trusted zone protocol, such as the root port security state table 310 and the memory address range table 320 .

The root port security state table 310 is used to record the respective security state identifiers corresponding to each of the bridge terminal 118 and the second bus access ports RP1 - RP3 . The port numbers described in the root port security state table 310 are the corresponding numbers of the bridge terminal 118 and the second bus access ports RP1 - RP3 . The root port security state table 310 shown in FIG. 3 indicates that the value of the security state identifier corresponding to the bridge terminal 118 and the second bus access port RP3 is "0", so the bridge terminal 118 and the second bus are connected to each other. The terminal 120-3 connected to the terminal RP3 is a "safe state" component; the value of the security state identifier corresponding to the second bus access terminals RP1 and RP2 is "1", so it is the same as the second bus access terminal. The terminals 120-1 and 120-2 connected to RP1 and RP2 are components of "non-secure state".

In the first embodiment, the memory address range table 320 is used to record the bridge terminal 118 and the memory address range corresponding to each of the second bus access ports RP1 - RP3 . In other words, each of the bridge terminal 118 and the second bus access ports RP1 - RP3 is assigned a respective memory address region and recorded in the memory address region table 320 . For example, the memory address range corresponding to the bridge terminal 118 is "0xA000_0000~0xAFFF_FFFF", the memory address range corresponding to the terminal 120-1 connected to the second bus access port RP1 is "0xB000_0000~0xBFFF_FFFF", and according to And so on.

FIG. 4 is a flowchart of a method for transferring data between buses according to the first embodiment of the present invention. The method in FIG. 4 is mainly applicable to the bridging device 110 in FIG. 3 , and according to FIG. 3 The components and corresponding information shown in the document are described. On the other hand, the method in FIG. 4 is mainly that the bridge device 110 in FIG. 3 obtains a transaction request for data access from the first bus 107, and hopes to communicate with the terminals 120-1~120-3 or bridges belonging to the second agreement. The processing flow of data access by the terminal 118 . Please refer to FIG. 3 and FIG. 4 at the same time. In step S410 , the bridge device 110 obtains the first transaction request of the first bus 107 from the first bus access terminal 112 . In the description of this embodiment, the transaction request obtained from the first bus 107 from the first bus access terminal 112 is referred to as the first transaction request. In other words, the first transaction request is a transaction that is expected to be transmitted from the first bus 107 through the bridge device 110 to a terminal belonging to the second protocol or a bridge terminal for data access.

In step S420, when the aforementioned first transaction request is obtained, the processor 116 of the bridge device 110 determines whether the target terminal corresponding to the first transaction request is one of the terminals 120-1~120-3 connected to the bridge device 110 one.

The bridging device 110 of this embodiment searches the memory address range table 320 according to the target address in the first transaction request, so as to determine whether the aforementioned target address falls into the bridge terminal 118 or the second bus access port RP1-RP3 The memory location interval, so as to determine whether the target terminal corresponding to the first transaction request is the bridge terminal 118 or one of the terminals 120-1120-3.

For example, when the target address in the first transaction request is "0xF000_0011", it means that the target address of the first transaction request does not fall into any memory location interval in the memory address interval table 320, so from the step S420 proceeds to step S430 (ie, step S420 is NO), the bridge device 110 responds to the first bus 107 with an error message through the first bus access terminal 112 . At this time, the first transaction request is a failure.

In contrast, when the target address in the first transaction request falls into the memory location range corresponding to the specific terminal in the memory address range table 320, it means that the target terminal of the first transaction request is the specific terminal, so it will From step S420 to step S440 (that is, step S420 is yes), the processor 116 of the bridge device 110 is based on the first security token of the first transaction request and the corresponding second bus access terminal coupled to the target terminal. The security status identifier is used to determine whether to translate and deliver the first transaction request to the target terminal based on the second agreement. In this way, the target terminal will obtain the translated first transaction request from the bridging device 110 , so as to perform data access according to the first transaction request.

Because step S440 may have different operations in multiple embodiments of the present invention, the details of steps S442, S444, S446 and S448 in step S440 in FIG.

Please refer to FIG. 3 and FIG. 4 at the same time. In step S442, the processor 116 determines whether the first security token of the first transaction request is a first value (the first value in this embodiment is set to "0"). When the first security flag is the first value ("0"), it means that the first transaction request is "secure access", and the first transaction request can perform data access regardless of the security status of the target terminal. Therefore, from the step S442 proceeds to step S448, where the processor 116 translates the first transaction request based on the second protocol (PCI-E protocol) and transmits it to the target terminal known in step S420. Relatively, when the first security flag is not the first value ("0"), for example, the value of the first security flag is "1", indicating that the first transaction request is "non-secure access", so enter from step S442 In step S444, the processor 116 continues to judge whether the security state identifier corresponding to the second bus access terminal of the target terminal is the first value ("0"), thereby judging whether the target terminal belongs to "secure state" or "non-secure state". shape state".

In step S444, when the security state identifier corresponding to the target terminal is the first value ("0"), it means that the target terminal is in a "safe state". Since the first transaction request is "non-secure access" and cannot perform data access to the target terminal in the "secure state", it will enter step S446 from step S444, and the processor 116 returns an error message to inform that the first transaction is issued Data access failed for the requested component. In contrast, in step S444, when the security state identifier corresponding to the target terminal is not the first value ("0"), for example, the value of the security state identifier corresponding to the target terminal is "1", indicating that the target terminal It is "unsafe state". Since the first transaction request is "non-secure access" and data access can be performed on the target terminal in "non-secure state", it will enter step S448 from step S444, and the processor 116 bases the first transaction request on the second agreement (PCI-E protocol) translated and delivered to the target terminal.

For example, if the central processing unit 102 in FIG. 1 makes a first transaction request to the terminal 120-1 through the first bus 107, the processor 116 in FIG. 3 will use the first transaction request after obtaining the first transaction request (step S410). The target address of a transaction request queries the memory location interval table 320 to determine whether the target address is located in the memory location interval corresponding to the terminals 120-1~120-3 connected to the bridge device 110 or the bridge terminal 118, thereby It is judged whether the target terminal corresponding to the first transaction request is known by the bridge device 110 (step S420). Here, the target terminal is the terminal 120-1, so the target address falls within the memory address range "0xB000_0000~0xBFFF_FFFF" corresponding to the second bus access port RP1.

After learning that the target terminal is the terminal 120-1, the processor 116 in FIG. The security flag in the first transaction request is already known as "secure access" or "non-secure access", and cooperates with the security status identifier corresponding to the second bus access terminal RP1 connected to the terminal 120-1 (Numerical value "1") presents it as "non-secure state", so it is judged whether to translate and transmit the first transaction request to the terminal 120-1 (step S440). In detail, if the first transaction request is "secure access", then the bridge device 110 transmits the first transaction request to the terminal 120-1 based on the trust zone protocol (go to step S448 after step S442); if the first transaction The request is "non-secure access", since the security state identifier corresponding to the terminal 120-1 indicates that the terminal 120-1 is in the "non-secure state", the bridging device 110 transmits the first transaction request to the terminal based on the trust zone protocol 120-1 (go to step S448 via steps S442 and S444).

Here is another example based on FIG. 4. If the central processing unit 102 in FIG. 1 makes the first transaction request to the terminal 120-3 through the first bus 107, since the terminal 120-3 is in a "safe state", if the first transaction request If it is "non-secure access", then the bridge device 110 returns an error message to the CPU 102 in FIG. 1 based on the trust zone protocol (go to step S446 after steps S442 and S444).

FIG. 5 is another flow chart of the method for transferring data between buses according to the first embodiment of the present invention. The method in FIG. 5 is mainly that the bridge device 110 in FIG. 3 obtains a transaction request for data access from the terminals 120-1~120-3 or the bridge terminal 118, and hopes to perform data access with the components on the first bus 107. processing flow. Please refer to FIG. 3 and FIG. 5 at the same time. In step S510, the processor 116 obtains a second transaction request from one of the second bus access ports RP1-RP3. The second transaction request is coupled to the second Provided by the main terminals of the bus access ports RP1~RP3. The main terminal is the terminal belonging to the second agreement One of the terminals 120-1~120-3 or the bridge terminal 118. In the description of this embodiment, the transaction request obtained from the terminals 120-1-120-3 connected to one of the second bus access terminals RP1-RP3 is referred to as the second transaction request. In other words, the second transaction request is a transaction that is expected to be transmitted from the terminal or bridge terminal belonging to the second protocol to the corresponding component of the first bus 107 through the bridge device 110 for data access.

In steps S520 to S550, when the aforementioned second transaction request is obtained, the processor 116 of the bridge device 110 adjusts the security status identifier corresponding to one of the second bus access ports RP1-RP3 coupled to the main terminal. The second security token in the second transaction request, and based on the first agreement, the adjusted second transaction request is translated and delivered to the first bus access terminal 112, so that the second transaction request can be delivered to the The first bus bar 107 .

Specifically, in step S520, the processor 116 of the bridge device 110 determines whether the security state identifier corresponding to one of the second bus access ports RP1-RP3 coupled to the main terminal is the first value (" 0"). If the security status identifier corresponding to the main terminal in step S520 is the first value ("0") (that is, step S520 is yes), it means that the main terminal is "safe status", and the information sent by the main terminal The transaction request is also "secure access", therefore, when the security status identifier corresponding to the main terminal in step S520 is the first value ("0"), then step S520 enters step S540, and the processor 116 sets the second The second security flag in the transaction request is set to the first value ("0"). In contrast, if the security state identifier corresponding to the primary terminal in step S520 is not the first value ("0") (No in step S520), that is, the security state identifier is the second value ("1"), indicating This primary endpoint is "unsecured" and thus the primary The transaction request sent by the terminal is "non-secure access". Therefore, when the security status identifier corresponding to the main terminal in step S520 is not the first value ("0"), then step S520 enters step S530, and the processor 116 sets the second security flag in the second transaction request is the second value ("1").

After completing step S530 or step S540, in step S550, the processor 116 translates and transmits the adjusted second transaction request to the first bus access terminal 112, so that the second transaction request can pass through the bridge device 110 to the first bus bar 107. Therefore, the method in FIG. 5 is an execution step for the bridge device 110 to obtain a transaction request from the terminals 120 - 1 - 120 - 3 or the bridge terminal 118 .

In the first embodiment of the present invention, the memory location interval table 320 in FIG. 3 mainly records the corresponding memory address intervals of the bridge terminal 118 and the second bus access terminals RP1~RP3, and the bridge device 110 can be based on The target address in the transaction request queries the memory location interval table 320 to know the target terminal corresponding to the transaction request. If multiple terminals are connected to a single second bus access port (e.g., second bus access port RP1), the respective security state identifiers corresponding to these terminals are connected to the same second bus access port. End but the same.

In other embodiments consistent with the present invention, the bridge device 110 may also record other information corresponding to the bridge terminal 118 and the terminals 120-1-120-3 connected to the second bus access ports RP1-RP3 (for example, , the device identifier of each terminal) to know the target terminal corresponding to the transaction request. Moreover, in other embodiments consistent with the present invention, the bridge device 110 may also only record the bridge terminal 118 and the terminals 120-1-120-3 connected to the second bus access terminals RP1-RP3 as "safety status 』related Information to determine the target terminal corresponding to the transaction request, without recording the corresponding terminal as "non-secure state". The second embodiment will be described below.

FIG. 6 is a schematic diagram illustrating a security state lookup table and an example thereof for a bridge device recording a terminal as a security state according to a second embodiment of the present invention. Here, the corresponding information for recording the "security status" terminal is called a security status lookup table. The security state lookup table of this embodiment can have two types, the first type can be shown in the table 610 of Figure 6, and the table 610 is used to record the device identifier of the terminal in the "safe state"; the second type can be as follows As shown in the table 620 in FIG. 6 , the table 620 is used to record the memory address area allocated by the terminal in the "safe state". In detail, the table 610 is represented by 64 bits, and the 0th bit to the 63rd bit are described here. The 0th bit is used to indicate the type TYPE of this security status lookup table, for example, when the 0th bit is "0", it is expressed as the first type TYPE1, which is the type of the device identifier of the recording terminal; the 1st to 7th bits The bit Bit7-1 and the 24th to 63rd bits Bit63-24 belong to the reserved area RSV; the 8th to 23rd bits Bit23-8 store the device identifier Device_ID conforming to the second protocol (PCI-E protocol). The device identifier Device_ID conforming to the PCI-E protocol in this embodiment is an example of a 16-bit bus/device/function (Bus/Device/Function; BDF). The table 620 is also represented by 64 bits, and the 0th bit to the 63rd bit are used for illustration here. The 0th bit Bit0 is used to represent the type TYPE of this security status lookup table, for example, when the 0th bit is "1", it represents the second type, which is the type of the memory address interval of the recording terminal; bits 1 to 5 Bit Bit5-1 is used to indicate the size range SIZE_RANGE of the memory address interval, the size range of this embodiment can be between 4KB to 4GB; the 6th to 63rd bit Bit63-6 is to store the corresponding terminal memory base Address (Memory Base Address) MBR.

The table 630 is an example of the aforementioned table 610 and table 620 . The first column (row) of the table 630 is related information corresponding to the second bus access port RP1 belonging to the second protocol (PCI-E protocol), indicating that the second bus access port RP1 is in a "safe state" ( Because the table 630 does not record the "non-safe state" components), and the 0th bit of the first column is "0", it is the aforementioned first type. The third column of the table 630 is related information corresponding to a terminal (for example, a card reader) belonging to the second protocol (PCI-E protocol), indicating that the card reader is in a "secure state". On the other hand, although the bridge device 110 is connected to a terminal (for example, a PCI-E sound card), this terminal (sound card) is not recorded in the table 630 because it is in a "non-secure state".

FIG. 7 is a flowchart of a method for transferring data between buses according to a second embodiment of the present invention. The method in FIG. 7 is mainly applicable to the bridge device 110 in FIG. 1 , and will be described according to the corresponding information shown in FIG. 6 . The method in FIG. 7 described in the second embodiment is that the bridging device 110 in FIG. 1 obtains a transaction request for data access from the first bus 107, and hopes to connect with the terminals 120-1~120-3 or bridges belonging to the second agreement. The processing flow of data access by the terminal 118.

In step S410 of FIG. 7 , the bridge device 110 obtains the first transaction request of the first bus 107 from the first bus access terminal 112 . In particular, the difference between the multiple steps in Figure 7 of the second embodiment and Figure 4 of the first embodiment is that step S420 and step S430 in Figure 4 of the first embodiment will determine whether the target terminal of the first transaction request is the terminal connected to the bridge device 110, but the second embodiment in FIG. 7 is to integrate the corresponding technical content of step S420 and step S430 in FIG. Step S440' in Fig. 7 will be described in detail below.

In step S440' in FIG. 7, the processor 116 of the bridge device 110 determines whether to send The first transaction request is translated and delivered to the target terminal of the first transaction request based on the second agreement. In detail, in step S710 of FIG. 7 , the processor 116 determines whether the first security token of the first transaction request is a first value (“0”). When the first security flag is the first value ("0"), it means that the first transaction request is "secure access", and the first transaction request can perform data access regardless of the security status of the target terminal. Therefore, from the step Step S710 proceeds to step S720, where the processor 116 translates the first transaction request based on the second protocol (PCI-E protocol) and transmits it to the target terminal of the first transaction request. Relatively, when the first security flag is not the first value ("0"), for example, the value of the first security flag is "1", indicating that the first transaction request is "non-secure access", so enter from step S710 In step S730, the processor 116 determines whether the type of the first transaction request is a Peripheral Component Interconnect (PCI) memory transaction type (ie, the second type described in FIG. 6 ).

If the category of the first transaction request is Peripheral Component Interconnect (PCI) memory transaction category (that is, step S730 is yes), then enter step S740 from step S730, and the processor 116 retrieves according to the target address of the first transaction request The security status lookup table (here, table 630 in FIG. 6 is taken as an example) is used to judge whether corresponding information is found from the security status lookup table. If the processor 116 does not find the corresponding information from the security state lookup table according to the target address, it means that the target terminal of the first transaction request is in "non-secure state" and the first transaction request is "non-secure access". Enter step S720 from step S740, processor 116 Translate and deliver the first transaction request to the target terminal based on the second protocol. Relatively, the processor 116 finds corresponding information from the security state lookup table according to the target address, indicating that the target terminal of the first transaction request is in a "secure state" and the first transaction request is "non-secure access". From step S740 to step S760, the processor 116 returns an error message, and at this time the first transaction request has not been delivered to the target terminal.

Relatively, if the category of the first transaction request is not a Peripheral Component Interconnect (PCI) memory transaction category (that is, step S730 is No), then from step S730, enter step S750, and the processor 116 is based on the target device of the first transaction request The identifier is used to retrieve the security state lookup table in FIG. 6 (here, table 630 is taken as an example). If the processor 116 does not find the corresponding information from the security state lookup table according to the target address, it means that the target terminal of the first transaction request is in "non-secure state" and the first transaction request is "non-secure access". From step S750 to step S720, the processor 116 translates the first transaction request based on the second agreement and transmits it to the target terminal. Relatively, the processor 116 finds corresponding information from the security state lookup table according to the target address, indicating that the target terminal of the first transaction request is in a "secure state" and the first transaction request is "non-secure access". From step S750 to step S760, the processor 116 returns an error message, and at this time the first transaction request has not been delivered to the target terminal.

In addition, in the second embodiment, the transaction request for data access is obtained from the terminals 120-1~120-3 or the bridge terminal 118, and the processing flow of wishing to perform data access with the components on the first bus 107 The method is the same as that described in FIG. 5 in the first embodiment.

In the first embodiment, in Fig. 3 and Fig. 4 and the corresponding explanations, it is possible to record the security state identifiers corresponding to the second bus access terminals RP1~RP3, but it is not possible to record each The endpoint's security state identifier. On the other hand, the security status lookup table in FIG. 6 of the second embodiment can selectively record the corresponding information with the target address of the transaction request or the target device identifier, so the second embodiment can record the security status identification of each terminal symbol. Moreover, the security state lookup table in FIG. 6 of the second embodiment only records the corresponding data of the terminal or bridge terminal in the "safe state", but does not record the corresponding data of the terminal or bridge terminal in the "non-secure state". Those who apply this embodiment can also make the security state lookup table in Figure 6 of the second embodiment only record the corresponding data of terminals or bridge terminals in the "non-secure state", but not record the terminals or bridges in the "safe state" Corresponding information of the terminal, so as to achieve the aforementioned effects.

FIG. 8 is a schematic diagram of an electronic device 800 according to a third embodiment of the present invention. The main difference from FIG. 3 is that the third embodiment splits the functions of the processor 116 in FIG. 3 in the first embodiment into the security level confirmer 816 in FIG. The safety state determiners 815-1~815-3 in RP3. The memory location interval table 320 in FIG. 3 of the first embodiment is recorded in the corresponding memory or storage element accessible by the security level validator 816 in FIG. 8 of the third embodiment, but the bridge terminal 118 in the root port security state table 310 And the respective security state identifiers corresponding to each of the second bus access terminals RP1 - RP3 are respectively recorded by the corresponding security state determiners 815 - 1 - 815 - 3 . For example, in FIG. 8 described in the third embodiment, the security state determiner 815-1 records the security state identifier corresponding to the second bus access port RP1; the security state determiner 815-2 records the second bus access port The security state identifier corresponding to RP2; the security state determiner 815-3 records the security state identifier corresponding to the second bus access port RP3.

Fig. 9 is a method for transferring data between bus bars according to a third embodiment of the present invention law flowchart. The method in FIG. 9 is mainly applicable to the bridge device 110 in FIG. 1 , and will be described according to the corresponding information shown in FIG. 6 . The method in FIG. 7 described in the second embodiment is that the bridging device 110 in FIG. 1 obtains a transaction request for data access from the first bus 107, and hopes to connect with the terminals 120-1~120-3 or bridges belonging to the second agreement. The processing flow of data access by the terminal 118. Step S410 , step S420 and step S430 in FIG. 9 are the same as the corresponding steps in FIG. 4 , the only difference is that step S410 , step S420 and step S430 in FIG. 9 are implemented by the security level validator 816 in FIG. 8 . When step S420 is yes (the target terminal corresponding to the first transaction request is one of the terminals connected to the electronic device 800 in FIG. To the target security state determiner (assumed to be a safe state) in the second bus access terminal (assumed to be the second bus access terminal RP1 in FIG. 8 ) coupled to the target terminal (assumed to be the terminal 120-1 in FIG. 8 ) Determiner 815-1).

Step S440" of Fig. 9 is similar to step S440 of Fig. 4, the two mainly lie in that step S440" of Fig. 9 is realized by the target security state determiner (assumed to be the security state determiner 815-1), and the target security The state determiner records the corresponding security state identifier of the access terminal of the second bus. The details of step S440" will be described below using the security state determiner 815-1 as an example.

In step S942, the security state determiner 815-1 determines whether the first security token of the first transaction request is a first value (“0”). When the first security flag is the first value ("0"), it means that the first transaction request is "secure access", and the first transaction request can perform data access regardless of the security status of the target terminal. Therefore, from the step S942 enters step S948, and the security state determiner 815-1 bases the first transaction request on the second agreement (PCI-E protocol) is translated and delivered to the terminal 120-1. Relatively, when the first security flag is not the first value ("0"), for example, the value of the first security flag is "1", indicating that the first transaction request is "non-secure access", so enter from step S942 In step S944, the security status determiner 815-1 continues to determine whether the security status identifier corresponding to the second bus access terminal RP1 is the first value ("0"), thereby determining whether the target terminal belongs to "safe status" or " unsafe state".

In step S944, when the security status identifier RP1 is the first value ("0"), it means that the terminal 120-1 is in the "safe status". Since the first transaction request is "non-secure access" and cannot perform data access to the target terminal in the "secure state", it will enter step S946 from step S944, and the security state determiner 815-1 returns an error message to inform The component that issued the first transaction request failed to access its data. In contrast, in step S944, when the security state identifier corresponding to the terminal 120-1 is not the first value ("0"), for example, the value of the security state identifier corresponding to the terminal 120-1 is "1". , indicating that the terminal 120-1 is in a "non-secure state". Since the first transaction request is "non-secure access" and data access can be performed on the terminal 120-1 of "non-secure state", it will enter step S948 from step S944, and the security state determiner 815-1 will first The transaction request is translated and delivered to the terminal 120-1 based on the second protocol (PCI-E protocol).

In addition, in the third embodiment, the transaction request for data access is obtained from the terminals 120-1~120-3 or the bridge terminal 118, and the processing flow of wishing to perform data access with the components on the first bus 107 The method is the same as that described in FIG. 5 in the first embodiment. The method described in FIG. 5 in the third embodiment may be implemented by the security level confirmer 816 in FIG. 8 or the security state determiners 815-1~815-3 in FIG. 8 .

To sum up, the bridging device and the method for data security between buses described in the embodiments of the present invention enable the terminals belonging to the PCI-E protocol to support the trust zone technology based on the ARM structure through the bridging device. In other words, the bridge device translates and transmits the transaction request through the security status identifier corresponding to the bus access terminal belonging to the PCI-E protocol and the security flag in the transaction request for data access, so that the coupling Terminals connected to the bridge device and belonging to the PCI-E protocol can access data with components under the ARM structure through the trust zone technology, expanding the application range of the trust zone technology to achieve data security.

S410~S448: steps

Claims (18)

A bridging device comprising: a first bus access terminal coupled to a first bus of a first protocol; at least one second bus access terminal selectively coupled to a second protocol respectively at least one terminal; and a processor coupled to the first bus access port and the at least one second bus access port, wherein all or part of the at least one second bus access port corresponds to each A security state identifier of a security state identifier, wherein the processor obtains a first transaction request from the first bus access terminal, wherein the first transaction request includes a first security token, and the processor obtains a first transaction request according to the The first security token and the security state identifier corresponding to the at least one second bus access terminal coupled to a target terminal are used to determine whether to translate and deliver the first transaction request based on the second protocol to the target terminal. The target terminal of the first transaction request, wherein the target terminal is one of the at least one terminal. The bridging device according to claim 1, wherein the processor obtains a second transaction request from the at least one second bus access port, wherein the second transaction request is coupled to the at least one second bus access port provided by a main terminal of the access terminal, the processor adjusts a second security flag in the second transaction request according to the security state identifier corresponding to the at least one second bus access terminal coupled to the main terminal, and translating and delivering the adjusted second transaction request to the first bus access terminal based on the first protocol. The bridging device as described in claim 1, further comprising: A bridge terminal, wherein the bridge terminal and each of the at least one second bus access end correspond to the respective security state identifiers. The bridging device as claimed in claim 3, wherein each of the bridge terminal and the at least one second bus access terminal is assigned a respective memory address area and recorded in a memory address range table, the The processor searches the memory address range table according to a target address of the first transaction request to determine whether the target terminal corresponding to the first transaction request is one of the at least one terminal. The bridge device as described in claim 1, wherein the processor judges whether the first security token of the first transaction request is a first value, and when the first security token is not the first value, the processor judges Whether the security state identifier corresponding to the at least one second bus access terminal of the target terminal is the first value, when the first security flag is the first value, or when the first security flag is not the first value and the security state identifier is not the first value, the processor translates the first transaction request based on the second protocol and transmits it to the target terminal, when the first security token is not the first value and the security state identifier is the first value, the processor returns an error message to the first bus access port. The bridging device as described in claim 1, further comprising: a security state lookup table, wherein the security state lookup table is used to record a device identifier of the at least one terminal in a security state or the terminal in the security state a memory address area allocated by at least one terminal, Wherein the processor selectively searches according to a target device identifier or a target address of the first transaction request according to whether the category of the first transaction request is a peripheral component interconnect (PCI) memory transaction category The security state looks up a table to determine whether to translate and transmit the first transaction request to the target terminal based on the second protocol. The bridging device as claimed in claim 6, wherein the security state lookup table does not record the at least one terminal in a non-secure state and its corresponding information. The bridging device as claimed in claim 1, wherein the processor includes: a security level confirmer; and at least one security state determiner, wherein the at least one security state determiner is respectively arranged on the at least one second bus bank The terminal, wherein the security level confirmer is used to determine whether the target terminal corresponding to the first transaction request is one of the at least one terminal, and when the target terminal is one of the at least one terminal, the security level The validator provides the first transaction request to a target security state determiner in the at least one second bus access terminal coupled to the target terminal, and the target security state determiner is based on the first transaction request The first security token and the security status identifier corresponding to the at least one second bus access terminal coupled to the target terminal determine whether to translate and deliver the first transaction request to the target based on the second protocol. terminal. The bridging device as claimed in claim 1, wherein the first protocol is a bus protocol based on an Advanced Reduced Instruction Set Machine (ARM) architecture, wherein the second protocol is a peripheral component interconnect fast protocol, The first security flag in the first transaction request is a security level information conforming to a trust zone protocol of the Advanced RISC Architecture, wherein the first transaction request is a data access request. A method for transferring data between buses, suitable for a bridge device, the bridge device includes a first bus access terminal and at least one second bus access terminal, the method includes: from the first The bus access terminal obtains a first transaction request, wherein the first transaction request includes a first security token, the first bus access terminal is coupled to a first bus of a first protocol, and the at least one Second bus access ports are respectively selectively coupled to the at least one terminal of a second protocol, all or part of the at least one second bus access port corresponding to a respective security state identifier; and according to The first security token of the first transaction request and the security state identifier corresponding to the at least one second bus access terminal coupled to a target terminal determine whether the first transaction request is based on the second The protocol is translated and delivered to the target terminal of the first transaction request, wherein the target terminal is one of the at least one terminal. The method as recited in claim 10, further comprising: obtaining a second transaction request from the at least one second bus access port of the bridge device, wherein the second transaction request is coupled to the at least one second bus provided by a main terminal of the bus access; and adjusting a second security flag in the second transaction request according to the security state identifier corresponding to the at least one second bus access coupled to the main terminal, and translating and passing the adjusted second transaction request to the first bus depot based on the first protocol Take the end. The method of claim 10, wherein the bridging device further comprises a bridge terminal, wherein the bridge terminal and each of the at least one second bus access end correspond to the respective security state identifiers. The method according to claim 12, wherein each of the bridge terminal and the at least one second bus access terminal is assigned a respective memory address region and recorded in a memory address region table, and, The method further includes: retrieving the memory address range table according to a target address of the first transaction request to determine whether the target terminal corresponding to the first transaction request is one of the at least one terminal. The method according to claim 10, wherein the determination is based on the first security flag of the first transaction request and the security state identifier corresponding to the at least one second bus access terminal coupled to the target terminal The step of translating and delivering the first transaction request to the target terminal based on the second agreement includes: judging whether the first security token of the first transaction request is a first value; when the first security token is not the When the first value is the first value, judging whether the security state identifier corresponding to the at least one second bus access terminal of the target terminal is the first value; when the first security mark is the first value, or when the first security flag is not the first value and the security status identifier is not the first value, translating and delivering the first transaction request to the target terminal based on the second protocol; and When the first security flag is not the first value and the security status identifier is the first value, return an error message to the first bus access terminal. The method according to claim 10, wherein the bridging device further includes a security state lookup table, wherein the security state lookup table is used to record a device identifier of the at least one terminal in a security state or in the security state A memory address area allocated by the at least one terminal, wherein the first security token corresponding to the first transaction request and the security token corresponding to the at least one second bus access terminal coupled to the target terminal The step of determining whether the first transaction request is translated based on the second protocol and delivered to the target terminal by the state identifier includes: whether the type of the first transaction request is a Peripheral Component Interconnect (PCI) memory transaction type and selectively searching the security state lookup table according to a target device identifier or a target address of the first transaction request to determine whether to translate and deliver the first transaction request to the target based on the second protocol terminal. The method as claimed in claim 15, wherein the security state lookup table does not record the at least one terminal in a non-secure state and its corresponding information. The method as described in claim 10, wherein a processor of the bridging device includes: a security level confirmer; and at least one security state determiner, wherein the at least one security state determiner is respectively set at the at least one second A bus access terminal, wherein in the method, it is judged whether the target terminal corresponding to the first transaction request is one of the at least one terminal connected to the bridging device is executed by the security level validator according to the first security token of the first transaction request and the at least one second bus coupled to the target terminal The step of taking the security status identifier corresponding to the terminal to determine whether to translate the first transaction request based on the second agreement and transmit it to the target terminal includes: when the target terminal is one of the at least one terminal, via The security level confirmer provides the first transaction request to a target security state determiner in the at least one second bus access terminal coupled to the target terminal; via the target security state determiner according to the target security state determiner The first security token of the first transaction request and the security status identifier corresponding to the at least one second bus access terminal coupled to the target terminal are used to determine whether the first transaction request is based on the second protocol. translated and delivered to the target terminal. The method as recited in claim 10, wherein the first protocol is a bus protocol based on an Advanced Reduced Instruction Set Machine Architecture, the second protocol is a peripheral component interconnect fast protocol, and the first transaction request includes The first security token is a security level information conforming to a trust zone protocol of the RISC machine architecture, and the first transaction request is a data access request.

Images