CN115221086A - Bus control system, method and electronic device - Google Patents

Abstract

A bus control system, method and electronic device are provided. The bus control system includes: the first master device is connected with the second master device through a system bus; and the first access controller is arranged between the first master device and the system bus and is used for performing access control on an access request which is sent by the second master device and aims at the first master device. According to the embodiment of the application, the access controller is arranged between the main device and the system bus to carry out access control on the access request, so that access permission control between the main devices is realized, the access risk is reduced, and the safety and the stability of the system are improved.

Description

Bus control system, method and electronic device

technical field

The embodiments of the present application relate to the technical field of bus control, and more particularly, to a bus control system, method, and electronic device.

Background technique

A bus is a set of common information transmission lines that can be shared by multiple devices/components in time. Multiple devices can be attached to the bus. The device that can initiate information transmission on the bus is called the master device, and the device that cannot actively initiate communication on the bus and can only receive and query the bus information is called the slave device. At present, in the access control design of the system on chip (SoC), the access request of the slave device is generally judged by the slave side access filter (SlvAF) downstream of the system bus to arbitrate the access request. Whether the pen request is valid.

There are also resource access scenarios between master devices upstream of the system bus. In an access control system based on slave devices downstream of the bus, once the master device upstream of the bus is attacked or the master device itself has a security vulnerability, resources in other master devices will be created. It is illegally invaded or leaked, causing data violation and system abnormality.

SUMMARY OF THE INVENTION

Embodiments of the present application provide a bus control system, method, and electronic device, and various aspects of the embodiments of the present application are introduced below.

In a first aspect, a bus control system is provided, comprising: a first master device and a second master device, the first master device and the second master device are connected through a system bus; a first access controller, arranged in a between the first master device and the system bus, for performing access control on the access request sent by the second master device to the first master device.

In a second aspect, a method for bus control is provided, which is applied to a bus control system, where the bus control system includes: a first master device and a second master device, the first master device and the second master device pass through the system The buses are connected to each other; the first access controller is arranged between the first master device and the system bus, and is used to perform access control on the access request sent by the second master device for the first master device; The method includes: transmitting, through the system bus, an access request sent by the second master device to the first master device; and using the first access controller to perform access control on the access request.

In a third aspect, an electronic device is provided, including the bus control system according to the first aspect.

In the embodiment of the present application, an access controller is set between the master device and the system bus to control the access request, which realizes the access control between the master devices and helps to avoid illegal access of the master device due to loopholes or attacks. , reducing the access risk and improving the security and stability of the system.

Description of drawings

FIG. 1 is a schematic diagram of an access control system based on a downstream slave device of a bus.

FIG. 2 is a schematic diagram of a bus control system provided by an embodiment of the present application.

FIG. 3 is a schematic diagram of one possible implementation of the system of FIG. 2 .

FIG. 4 is a schematic flowchart of a method for bus control provided by an embodiment of the present application.

FIG. 5 is a schematic structural diagram of an electronic device provided by an embodiment of the present application.

Detailed ways

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all of the embodiments.

A bus is a set of common information transmission lines that can be shared by multiple devices or components in time-sharing. A bus can connect within a chip, between chips, between boards, or between computer systems. Multiple devices can be attached to the bus. The device that can initiate information transmission on the bus is called the master device, and the device that cannot actively initiate communication on the bus and can only receive and query the bus information is called the slave device.

With the continuous development of integrated circuits, the application of SoCs in smart terminals such as mobile phones and electronic products has become more and more extensive. A system-on-chip, also known as a system-on-chip, is a tiny system that integrates a microprocessor, analog IP core, digital IP core, and memory (or off-chip memory control interface) on a single chip.

In the current SoC access control design, the slave device is generally accessed based on the initiator identification, physical address information, security attributes, and read/write requests through the slave side access filter (SlvAF) downstream of the system bus. Judgment of authority to arbitrate whether the request is valid. SlvAF belongs to a class of hardware intellectual property (Intellectual Property, IP), and is used to implement the function of access control.

FIG. 1 is a schematic diagram of an access control system based on a downstream slave device in a SoC. As shown in FIG. 1 , the bus access control system includes: a first master device 110 , a second master device 120 , a system bus 130 , a first slave device 140 , a first slave access filter, and the like.

The first master device 110 is connected to the system bus 130 and can initiate access to information. The first master device 110 may be, for example, a processor or a wireless receiving apparatus. The second master device 120 is connected to the system bus 130 and can initiate access to information. The second master device 120 may be, for example, a signal audio processing apparatus or a wireless receiving apparatus.

The system bus 130 is used to transmit control information, which may include control signals and timing signals. The system bus 130 is generally the communication path between the CPU and interfaces such as memory and input/output devices.

The first slave device 140 is connected to the system bus 130 for receiving and querying bus information. The first slave device 140 may be, for example, a printing device or an audio playing device.

One end of the first slave access filter 150 is connected to the port on the system bus 130 , and the other end is connected to the first slave device 140 , and can perform access control or inspection on the visiting instruction of the first slave device 140 .

The basic idea of the access control system based on the downstream slave device of the bus is to check the four elements of the master device's secure master identification (SecMID), the physical address information to be accessed, the read/write request, and the security attribute for each access request. Do a permission check. The master device security identifier is also called the master device security hardware identifier, which is generally a fixed identifier assigned to each master device during the SoC integration stage, and cannot be changed after the chip is taped out. The physical address information to be accessed generally refers to the physical start address and physical end address to be accessed by the request. The read/write request is generally used to indicate whether the current request is to read data or write data. The security attributes are generally secure (secure, S) or non-secure (non-secure, NS) request attributes.

Based on the above four elements, an access permission table can be established for each access request, as shown in the table below Figure 1. The access permission table is used to limit the specified physical address range, which can only be accessed by a specific SecMID carrying a specific security attribute for a specified read or write access. In this way, when accessing a specific slave device downstream of the bus, the target slave device can be accessed for data access only after checking the access permission table in the SlvAF. If the access permission table check in SlvAF is rejected, data is returned with the preset value in the virtual slave device, which will not cause back pressure on the bus request, nor will the request reach the target slave device. In some processing methods, the access request can also reach the target slave device, but when the data is returned through SlvAF, the data will be replaced with the preset value.

For example, when the first master device 110 accesses the first slave device 140 through the system bus 130, the first slave device 140 can be accessed for data access only after the first slave access filter 150 checks the access permission table. If the access authority check of the first slave access filter 150 fails and is rejected, the data is returned with the preset value in the virtual slave device, which will not cause the back pressure requested by the system bus 130 and will not allow the access The request arrives at the first slave device 140 . In some processing manners, the access request can also reach the first slave device 140, but when the data is returned through the first slave access filter 150, the data will be replaced with a preset value.

The access control system based on the slave device downstream of the bus generally does not control the authority of the master device upstream of the bus, cannot manage and control the access between the master devices upstream of the bus, and cannot form a complete access control system. However, there are also resource access scenarios between master devices upstream of the system bus, for example, the first master device 110 accesses the second master device 120 . Once the master device is breached or executed abnormally, the resources of the master device will be illegally invaded and information will be leaked. Moreover, at this time, the request sent by the master device is untrustworthy, which will cause intentional or unintentional reading and writing of resources in other master devices, resulting in data leakage or malicious rewriting of data, resulting in data violation and system abnormality.

It should be noted that the problem of data leakage and data violation in the access between master devices on the SOC bus mentioned above is only an example, and the embodiments of the present application can be applied to any risk of access between master devices on the system bus. type of scene.

Therefore, how to develop a solution with low access risk between master devices on the system bus is a problem that needs to be solved.

Based on this, an embodiment of the present application proposes a bus control system, and the embodiment of the present application is described in detail below.

FIG. 2 is a schematic diagram of a bus control system provided by an embodiment of the present application. The bus control system 200 may include a first master device 210 , a second master device 220 , a system bus 230 and a first access filter 240 .

The first master device 210 is connected to the system bus 230 , and can initiate access request information through the system bus 230 , and can also receive access request information through the system bus 230 . The first master device 210 may refer to any one master device among multiple master devices connected to the system bus 230 , and may be, for example, a processor, a memory, or a wireless receiving apparatus.

The second master device 220 is connected to the system bus 230 , and can initiate access request information through the system bus 230 , and can also receive access request information through the system bus 230 . The second master device 220 may refer to any one of the multiple master devices connected to the system bus 230 that is different from the first master device 210, and may be, for example, a memory, an audio signal processing device, or a wireless receiving device.

The system bus 230 is used to transmit control information such as access requests, and the control information may include control signals and timing signals. The system bus 230 is generally the communication path between the CPU and interfaces such as memory and input/output devices.

The first access controller 240 is disposed between the first master device 210 and the system bus 230, and is used to check or access the access request of the first master device 210. For example, the second master device 220 can control the access request of the first master device The access request sent by 210 performs access control. The first access controller 240 may also be referred to as an access filter (AF).

An access request usually includes a permission access table. As shown in Table 1, the permission access table may include such elements as master device security identification, physical address information to be accessed, read/write requests, security attributes, and the like. The first access controller 240 may judge whether the access request sent to the first master device 210 is safe based on the physical address information, initiator identification, security attributes, read/write request and other access rights.

Table 1

Address information Main Equipment Safety Identification read/write safe/unsafe 0x0000_0000-0x0000_0FFF 0x1 read only S 0x0000_1000-0x0000_1FFF 0x2 just write NS 0x0000_2000-0x0000_2FFF 0x3 read, write S 0x0000_3000-0x0000_3FFF 0x4 read, write NS

As shown by the dotted line in FIG. 2 , the flow of the access request sent by the second master device 220 to the first master device 210 can be divided into the following steps:

Step 1, the second master device 220 issues an access request for the first master device 210 through the system bus 230, this access request may include a permission access table, and the permission access table may include the master device security identification, the physical address information to be accessed, etc. Permission element.

In step 2, the system bus 230 transmits the access request to the first access controller 240 .

Step 3, the first access controller 240 checks the access authority for the access request. If the access request passes the access permission check, the access request of the second master device 220 can access resources inside the first master device 210 . If the access request does not pass the access authority check, it will be rejected by the first access controller 240, which will trigger the first access controller 240 to issue an exception report, which can return to a preset value, such as the preset value in the virtual master device. value for data return. In some embodiments, the access request can also reach the first host device 210, but when the data is returned through the first access controller 240, the data will be replaced with a preset value. When the second master device 220 illegally accesses the first master device 210 due to a loophole or an attack, the first access controller 240 can filter out illegal access requests that do not meet the access rights, so as to achieve access rights between master devices Control and reduce access risk.

In some implementations, there may also be a scenario in which the first master device 210 accesses the second master device 220. An access controller may be set between the second master device 220 and the system bus 230, and the access controller may also be configured as the first master device 220. An access controller 240 configured to perform access control on the access request sent by the first master device 210 to the second master device 220 . Thereby, the access authority control between the master devices is realized, and the access risk is reduced.

In some implementations, the bus control system 200 may also include multiple slave devices connected to the system bus 230 . The slave device can only receive the query information through the system bus 230, which can be, for example, a memory or an audio playback device. The first slave device is any one of the multiple slave devices. An access controller on the slave device side may be set between the slave device and the system bus 230 to perform access control on the access request sent to the slave device. The second access controller may be any one of multiple slave device side access controllers. For example, the second access controller is located between the first slave device and the system bus 230, and is used to perform access control on the access request sent to the first slave device.

The first access controller 240 can not only perform access control on the access request from the first master device 210 , but also receive the access request sent by the first master device 210 and configure the access rights for the access request sent by the first master device 210 . The access request sent by the first master device 210 is also referred to as a first access request. In some embodiments, the first access request sent by the first master device 210 may be directed to the first slave device. In some embodiments, the first access request sent by the first master device 210 may be directed to the second master device. Based on the access control design on the bus upstream master side, the embodiments of the present application make up for the insufficiency of the SlvAF downstream of the bus in functionality and completeness, form comprehensive bus access control, and greatly reduce system access risks.

The first access controller 240 generally performs access control according to the configuration information of the access authority. After the first access request sent by the first master device 210 passes through the first access controller 240, it should have access rights items that need to be checked by the second access controller on the slave side, such as SecMID information, destination physical address information, read/write There are four elements of information and security attribute information.

The second access controller arranged in front of the first slave device performs an access authority check on the first access request, and only the first access request that passes the check can actually access the resources of the first slave device. Otherwise, the rejection of the second access controller will be triggered, and the second access controller will report the abnormality, and may also return to the default value.

In some implementations, complex SoC designs integrate master device IPs from different vendors, and there is no unified standard for vendor-private architecture designs, so some master device IPs do not support security attributes in bus transmissions. For a master device that does not support security attributes, additional mechanisms are required to add security attributes, otherwise, the downstream permission checking mechanism cannot be satisfied, and the arbitration conditions of the access control downstream of the bus cannot be satisfied. In turn, the overall access control system of the chip system will be difficult to meet the completeness and flexibility, posing a threat to the user's personal privacy information and data security, and ultimately affecting the user's security experience and product trust. The first access controller 240 can add a security attribute to the first access request, so as to help the master device that does not support the security attribute to send out the desired security signal, and satisfy the permission checking requirements of the downstream slave device side access controller. The first access controller 240 can flexibly integrate the security solutions of different IP providers, and build a complete access control system on the master side and the slave side of the SoC system, which helps to further increase security and reduce the attack surface.

The configuration of the first access controller 240 is usually completed before the initialization of the corresponding master device, and the slave device side access controller also has similar process constraints.

The permission access table and security attribute information in the first access controller 240 are usually configured in a trusted execution environment (TEE). For example, the TEE may be the TEE environment in the power-on and start-up phase of the SoC, or may be the TEE environment at runtime. Generally, the configuration of the first access controller 240 should be limited to the TEE environment, and supports the function of locking the configuration.

In some implementations, the first access controller 240 may support a locking function for each address region in the permission configuration table of the access request, as shown in Table 2. After the permission configuration is locked, the permission configuration table can be edited again only after the whole system is reset. Optionally, the first access controller 240 may lock the configuration of a certain address area according to the request of physical address change, which cannot be changed until the whole system is reset. Optionally, the first access controller 240 may also not lock the configuration of a certain address area for dynamic change at runtime.

Table 2

Address information Main Equipment Safety Identification read/write safe/unsafe locking 0x0000_0000-0x0000_0FFF 0x1 read only S Yes 0x0000_1000-0x0000_1FFF 0x2 just write NS no 0x0000_2000-0x0000_2FFF 0x3 read, write S Yes 0x0000_3000-0x0000_3FFF 0x4 read, write NS no

In some implementation manners, the first access controller 240 may specify a specific address area for the first access request, corresponding to sending out a security attribute specifying S or NS. That is, the first access controller 240 can switch the security attribute according to the physical address. Optionally, the first access controller 240 may also transparently transmit the security attribute in the original request of the master device. Transparent transmission means pass-through, which means that in communication, regardless of the content of the transmitted service, it is only responsible for transmitting the content of transmission from the source address to the destination address, without making any changes to the content of the service data.

In some implementations, the first access controller 240 can set which address regions in the accessed master device can be accessed by an external specific master device. As a first access request sent to the first host device 210, the first access controller 240 may set certain address areas in the first host device 210 to be accessible by a specific external host device. Optionally, the first access controller 240 may also not set an external specific host device access object for some address areas in the first host device 210 .

In some implementations, the master device security hardware identifier is not allocated to all master devices in the SoC integration stage, and in a trusted execution environment, the first access controller 240 may modify the master device security hardware identifier in the first access request. Optionally, the first access controller 240 may add the master device security hardware identifier in the first access request. In order to make the access request issued by the master device without the master device security hardware identification assigned, the access check requirements of the access controller of the downstream slave device can be satisfied.

Optionally, the master devices attached to the system bus have different requirements for functions, the first access controller 240 may support parameterized configuration of functions during IP instantiation, and the first access controller 240 may also call sub-modules in the IP. Parameterized configuration of functions is supported. This helps to further reduce the physical area, thereby reducing power consumption.

Optionally, the first access controller 240 can be extended to support multiple system bus protocols, including but not limited to advanced microcontroller bus architecture (AMBA), advanced extension interface (AXI) agreement, etc.

In the embodiment of the present application, an access controller is set between the master device and the system bus to control the access request, so as to realize the access authority control between the master devices. The embodiment of the present application is based on the access control design on the upstream master side of the bus, which complements the access control of the conventional slave device, forms a combined control system on the upstream and downstream of the bus, and avoids the illegal access of the master device due to loopholes or attacks. Helps reduce access risks, improve system security and stability, and enhance user experience and trust.

FIG. 3 is a schematic diagram of a possible implementation of the bus control system of FIG. 2 . As shown in FIG. 3, the bus control system may include a first master device 310, a second master device 320, a system bus 330, a first access filter 340, a third access filter 350, a second access filter 360, and a first access filter 340. A slave device 370.

The first master device 310 is connected to the system bus 330 , and can initiate access request information through the system bus 330 , and can also receive access request information through the system bus 330 .

The second master device 320 is connected to the system bus 330 , and can initiate access request information through the system bus 330 , and can also receive access request information through the system bus 330 .

The system bus 330 is used to transmit control information such as access requests, and the control information may include control signals and timing signals.

The first access controller 340 is disposed between the first master device 310 and the system bus 330, and is used to perform access control or inspection on the access request sent to the first master device 310. The access request sent by the master device 310 performs access control. The first access controller 340 may also be referred to as an access filter (AF). The first access controller 340 may also receive the access request sent by the first master device 310 , and configure permissions for the first access request sent by the first master device 310 .

The third access controller 350 is disposed between the second master device 320 and the system bus 330, and is used to perform access control on the access request sent to the second master device 320. For example, the first master device 310 can control the access to the second master device The access request sent by 320 performs access control. The third access controller 350 may also receive the access request sent by the second master device 350 , and configure the access rights for the access request sent by the second master device 350 .

The second access controller 360 is disposed between the first master device 370 and the system bus 330 , and can perform access check on the access command sent to the first slave device 370 .

The first slave device 370 is connected to the system bus 130 for receiving and querying bus information. The first slave device 370 may be, for example, an audio playback device.

The following describes the access between the master devices and the access process between the master and slave devices in detail.

Embodiment 1: an access request sent by the second master device 320 to the first master device 310 . As shown by the dotted line in Figure 3, the flow of the access request can be divided into the following steps:

Step 1, the third access controller 350 receives the access request sent by the second master device 350, and configures the access rights for the access request sent by the second master device 350. The configured access authority may include the main device security identification, physical address information to be accessed, read/write requests, security attributes, and other elements.

Step 2, the third access controller 350 sends an access request to the first master device 310 through the system bus 330 . This access request can include a permission access table that includes the configured access rights.

Step 3, the system bus 330 transmits the access request to the first access controller 340 .

Step 4: The first access controller 340 checks the access authority for the access request. It can include access permission checks such as master device security identification, physical address information to be accessed, read/write requests, and security attributes. If the access request passes the access permission check, the access request of the second host device 320 can access resources inside the first host device 310 . If the access request does not pass the access permission check, the first access controller 340 will be rejected, and the first access controller 340 will issue an exception report, which can return the default value, such as using the default value in the virtual master device. data is returned.

Optionally, the third access controller 240 may support a locking function for each address area in the permission configuration table of the access request. After the privilege configuration is locked, the privilege configuration table can be edited again only after a system-wide reset of the SoC. Optionally, the first access controller 240 may lock the configuration of a certain address area according to the request of physical address change, which cannot be changed until the SoC is reset. Optionally, the first access controller 240 may also not lock the configuration of a certain address area for dynamic change at runtime. As shown in the access permission table at the upper right of Figure 3, the permission configuration locking function is added. As shown in the access permission table in the lower right position of Figure 3, there is no permission configuration lock function added.

The second embodiment is an access request sent by the first master device 310 to the second master device 320 . As shown in Figure 3, the flow of the access request can be divided into the following steps:

Step 1, the first access controller 340 receives the access request sent by the first master device 310, and configures the access rights for the access request sent by the first master device 310. The configured access authority may include the main device security identification, physical address information to be accessed, read/write requests, security attributes, and other elements.

Optionally, if the security attribute is not supported in the bus transmission sent by the first master device 310 . The first access controller 340 can add a security attribute to the first access request to help the first master device 310 that does not support the security attribute send a desired security signal and satisfy the permission check requirement of the third access controller 350 on the destination master device side.

Step 2, the first access controller 340 sends an access request to the second master device 320 through the system bus 330 . This access request can include a permission access table that includes the configured access rights.

Step 3, the system bus 330 transmits the access request to the third access controller 350 .

Step 4, the third access controller 350 checks the access authority for the access request. It can include access permission checks such as master device security identification, physical address information to be accessed, read/write requests, and security attributes. If the access request passes the access permission check, the access request of the first host device 310 can access resources inside the second host device 320 . If the access request does not pass the access authority check, the third access controller 350 will be rejected, and the third access controller 350 will send an exception report, which can return the default value, such as using the default value in the virtual master device. data is returned.

Embodiment 3: The first access request sent by the first master device 310 to the first slave device 370 . As shown in Figure 3, the flow of the access request can be divided into the following steps:

Step 1, the first access controller 340 receives the first access request sent by the first master device 310, and configures the access rights for the first access request. The configured access authority may include the main device security identification, physical address information to be accessed, read/write requests, security attributes, and other elements.

Optionally, if the first master device 310 does not support security attributes in the bus transmission. The first access controller 340 can add a security attribute to the first access request to help the first master device 310 that does not support the security attribute to send a desired security signal and satisfy the permission check requirement of the second access controller 360 on the destination slave device side.

Step 2, the first access controller 340 sends a first access request to the first slave device 370 through the system bus 330 . The first access request may include a permission access table, where the permission access table includes configured access permissions.

Step 3, the system bus 330 transmits the first access request to the second access controller 360 .

Step 4, the second access controller 360 checks the access authority of the first access request. It can include access permission checks such as master device security identification, physical address information to be accessed, read/write requests, and security attributes. If the first access request passes the access permission check, the access request of the first master device 310 can access resources inside the first slave device 360 . If the first access request fails the access permission check, the second access controller 360 will be rejected, and the second access controller 360 will issue an exception report, which can return the default value, such as using the default value in the virtual slave device. data is returned.

Based on the access control design on the upstream master side of the bus, the embodiment of the present application realizes access control between master devices, complements the access control of conventional slave devices, forms a combined control system on the upstream and downstream of the bus, and avoids the need for master devices. Illegal access caused by loopholes or attacks reduces access risks. The embodiment of the present application also solves the problem that the master device does not support security attributes, can flexibly integrate the security solutions of different IP providers, and build a complete access control system on the master device side and the slave device side of the SoC system, which helps to further increase security , reduce the attack surface.

The system embodiments of the present application are described in detail above with reference to FIG. 1 to FIG. 3 , and the method embodiments of the present application are described in detail below with reference to FIG. 4 . It should be understood that the descriptions of the method embodiments correspond to the descriptions of the system embodiments, and therefore, for the parts not described in detail, reference may be made to the foregoing system embodiments.

FIG. 4 is a schematic flowchart of a method for bus control provided by an embodiment of the present application. The method of FIG. 4 can be applied to the bus control system described in any of the foregoing embodiments. The bus control system may include a first master device and a second master device, and the first master device and the second master device are connected through a system bus; the first access controller is arranged between the first master device and the system bus, and is used for connecting the first master device and the system bus. The access request sent by the second master device to the first master device performs access control. The method of FIG. 4 includes steps S410 to S420, which will be described in detail below.

In step S410, the access instruction of the second master device to the first master device is transmitted through the bus.

In step S420, use the first access filter to perform access control on the access instruction sent to the first master device.

If the access instruction passes the access permission check, the second master device can access the resources inside the first master device. If the access command fails the access authority check, the first access controller will be rejected, and the first access controller will issue an exception report, and may also return to a preset value.

Optionally, the bus control system may further include a first slave device and a second access controller. The first slave device is connected to the system bus, and the second access controller is arranged between the first slave device and the system bus, and is used for performing access control on the access request sent to the first slave device. In some embodiments, the first master device sends a first access request to the first slave device, and the second access controller is used to perform access control on the first access request sent to the first slave device.

Optionally, receive a first access request sent by the first master device, where the first access request is used to access the first slave device. If the first host device 310 does not support the security attribute, the security attribute may be added in the first access request.

Optionally, the permission configuration of the first access request may be locked, so that the permission configuration is performed in a trusted execution environment.

Optionally, in a trusted execution environment, the first access controller may modify the master device security hardware identifier in the first access request, and/or add the master device security hardware identifier.

Optionally, the first access controller may support parameterized configuration of functions at IP instantiation.

Optionally, the first access controller can be extended to support multiple system bus protocols.

The access controller proposed in the embodiment of the present application is implemented by the hardware IP inside the chip, which is difficult to reflect in physical appearance. The access control logic of the system bus can be inferred by means of code, process and debugging, so as to distinguish it from the slave device based access control logic. the bus control method.

FIG. 5 is a schematic structural diagram of an electronic device provided by an embodiment of the present application. As shown in FIG. 5, the electronic device may include a bus control system 510 as described in any of the foregoing.

It should be noted that the electronic equipment mentioned in the embodiments of the present application is an electrical equipment composed of microelectronic devices, which refers to a device that can be composed of electronic components such as integrated circuits, transistors, and electronic tubes, and that uses electronic technology (including software) to play a role. . The electronic device may be a random device, and the electronic device may be referred to as a terminal, a portable terminal, a mobile terminal, a communication terminal, a portable communication terminal, a portable mobile terminal, a touch screen, or the like. For example, the electronic device may be a smart phone, a portable phone, a game console, a television, a display unit, a head-up display unit for a vehicle, a notebook computer, a laptop computer, a personal computer (PC), a personal media player ( personal media player, PMP), personal digital assistant (personal digital assistant, PDA), robot controlled by electronic computer, numerical control or program control system, etc. The electronic device may also be a portable communication terminal having a wireless communication function and a pocket size. Also, the electronic device may be a flexible device or a flexible display device.

It should be understood that, in various embodiments of the present application, "first", "second", etc. are used to distinguish different objects, rather than to describe a specific order, and the size of the sequence numbers of the above processes does not mean that The sequence of execution, the execution sequence of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

In the several embodiments provided in this application, it should be understood that the disclosed system, apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or Can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, indirect coupling or communication connection of devices or units, and may be in electrical, mechanical or other forms.

In the several embodiments provided in this application, it should be understood that when a part is said to be "connected" or "connected" with another part, it means that the part can not only be "directly connected", but also "electrically connected" ”, while another element intervenes. In addition, the term "connected" also means that the part is "physically connected" as well as "wirelessly connected". Additionally, when a section is referred to as "comprising" an element, unless stated otherwise, it means that the section can include the other element, rather than excluding the other element.

The units described as separate components may or may not be physically separated, and components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution in this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit.

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited to this. should be covered within the scope of protection of this application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims (11)

1. a bus control system, is characterized in that, comprises: a first master device and a second master device, the first master device and the second master device are connected through a system bus; A first access controller, disposed between the first master device and the system bus, is configured to perform access control on an access request sent by the second master device to the first master device. 2. bus control system according to claim 1, is characterized in that, also comprises: a first slave device, connected to the system bus; A second access controller is disposed between the first slave device and the system bus, and is used for performing access control on an access request sent to the first slave device. 3. The bus control system according to claim 2, wherein the first access controller is further configured to perform the following operations: receiving a first access request sent by the first master device, where the first access request is used to access the first slave device; A security attribute is added to the first access request. 4. The bus control system according to claim 2, wherein the first access controller is further configured to perform the following operations: Locking the permission configuration of the first access request, so that the permission configuration is performed in a trusted execution environment. 5. The bus control system according to claim 2, wherein the first access controller is further configured to perform the following operations: In the trusted execution environment, modify the master device security hardware identifier in the first access request, and/or, Add the master device security hardware identification. 6. A method for bus control, characterized in that it is applied to a bus control system, the bus control system comprising: a first master device and a second master device, the first master device and the second master device are connected through a system bus; a first access controller, arranged between the first master device and the system bus, and configured to perform access control on an access request sent by the second master device for the first master device; The method includes: transmit the access request sent by the second master device to the first master device through the system bus; Use the first access controller to perform access control on the access request. 7. The method according to claim 6, wherein the bus control system further comprises: a first slave device, connected to the system bus; a second access controller, arranged between the first slave device and the system bus; The method also includes: The access request sent to the first slave device is accessed by the second access controller. 8. The method according to claim 7, wherein the method further comprises: receiving a first access request sent by the first master device, where the first access request is used to access the first slave device; A security attribute is added to the first access request. 9. The method according to claim 7, wherein the method further comprises: Locking the permission configuration of the first access request, so that the permission configuration is performed in a trusted execution environment. 10. The method according to claim 7, wherein the method further comprises: In the trusted execution environment, modify the master device security hardware identifier in the first access request, and/or, Add the master device security hardware identification. 11. An electronic device, characterized in that it comprises the bus control system according to any one of claims 1-5.

Images