CN115221086A

CN115221086A - Bus control system, method and electronic device

Info

Publication number: CN115221086A
Application number: CN202210810208.4A
Authority: CN
Inventors: 周欣; 马致远; 贾民虎
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2022-07-11
Filing date: 2022-07-11
Publication date: 2022-10-21

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 present disclosure relates to the field of bus control technologies, and in particular, to a bus control system, method and electronic device.

Background

A bus is a set of common information carrying lines that can be time shared by multiple devices/components. The bus can be connected with a plurality of devices, the device capable of initiating information transmission on the bus is called a master device, and the device which cannot actively initiate communication on the bus and can only receive and inquire bus information is called a slave device. In the current access control design of a system on chip (SoC), generally, downstream of a system bus, a slave side access filter (SlvAF) determines access authority of an access request of a slave device to arbitrate whether the request is valid.

In an access control system based on the downstream slave device of the bus, once the upstream master device of the bus is attacked or the master device itself has a security hole, resources in other master devices are illegally invaded or leaked, which causes data invasion and system abnormality.

Disclosure of Invention

The embodiment of the present application provides a bus control system, a bus control method and an electronic device, and various aspects of the embodiments of the present application are described below.

In a first aspect, a bus control system is provided, comprising: the system comprises a first main device and a second main device, wherein the first main device is connected with the second main device through a system bus; and the first access controller is arranged between the first master device and the system bus and used for performing access control on an access request which is sent by the second master device and aims at the first master device.

In a second aspect, a method for bus control is provided, which is applied to a bus control system, and the bus control system includes: the system comprises a first main device and a second main device, wherein the first main device is connected with the second main device through a system bus; the first access controller is arranged between the first master device and the system bus and used for performing access control on an access request which is sent by the second master device and aims at the first master device; the method comprises the following steps: transmitting an access request sent by the second master device for the first master device through the system bus; and performing access control on the access request by utilizing the first access controller.

In a third aspect, an electronic device is provided, comprising the bus control system as described in the first aspect.

According to the embodiment of the application, the access controller is arranged between the main equipment and the system bus to carry out access control on the access request, so that access permission control between the main equipment is realized, illegal access of the main equipment caused by loopholes or attacks is avoided, the access risk is reduced, and the safety and the stability of the system are improved.

Drawings

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

Fig. 2 is a schematic diagram of a bus control system according to an embodiment of the present disclosure.

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

Fig. 4 is a flowchart illustrating a method for controlling a bus according to an embodiment of the present disclosure.

Fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described clearly and completely with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only some embodiments of the present application, and not all embodiments.

A bus is a set of common information carrying lines that can be time shared for multiple devices or components. Buses may be connected on-chip, between chips, on-board, or between computer systems. A plurality of devices can be connected to the bus in an attached mode, the device capable of initiating information transmission on the bus is called a master device, and the device which cannot actively initiate communication on the bus and can only receive and inquire bus information is called a slave device.

With the continuous development of integrated circuits, system-on-chip applications in smart terminals such as mobile phones and electronic products are becoming more and more widespread. The system-on-chip, also called system-on-chip, is a micro system that integrates a microprocessor, an analog IP core, a digital IP core, and a memory (or off-chip memory control interface) on a single chip.

In the current SoC access control design, a slave device is generally judged to have access right based on an initiator identifier, physical address information, security attributes and a read/write request by a slave device side access filter (SlvAF) at the downstream of a system bus, so as to arbitrate whether the request is valid. Slvlaf belongs to a class of hardware Intellectual Property (IP) for implementing access control functions.

Fig. 1 is a schematic diagram of a bus-based downstream slave access control system 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 coupled to the system bus 130 and may initiate access to information. The first master device 110 may be, for example, a processor, a wireless receiving device. The second master device 120 is coupled to the system bus 130 and may initiate access to information. The second master device 120 may be, for example, a signal audio processing apparatus, a wireless receiving apparatus.

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

A first slave device 140 is coupled to the system bus 130 for receiving a query for bus information. The first slave device 140 may be, for example, a printing apparatus, an audio playing apparatus.

The first slave access filter 150 is connected to a port on the system bus 130 at one end and to the first slave device 140 at the other end, and can perform access control or check on the access instruction of the first slave device 140.

The basic idea of an access control system based on a bus downstream slave device is to perform authority check on four elements, namely, checking security identification (SecMI) of a master device, physical address information to be accessed, read/write requests and security attributes of each access request. The master device security identifier is also called a master device security hardware identifier, and is generally a fixed identifier allocated to each master device in an SoC integration stage, and cannot be changed after a chip is taped. The physical address information to be accessed generally refers to the physical starting address and physical ending address to be accessed by the pen request. The read/write request is generally used to indicate whether the request is currently to read data or write data. The security attributes are typically secure (S) or non-secure (NS) request attributes.

Based on the above four elements, an access authority table can be established for each access request, as shown in the table below fig. 1. The access authority table is used for limiting the designated physical address interval, and only specified read or write access can be carried out by specific SecMID carrying specific security attributes. Therefore, when a specific slave device is accessed downstream of the bus, the target slave device can be reached for data access only after the access authority table in the SlvAF is checked. And if the access right table in the SlvAF is rejected, returning data by using a preset value in the virtual slave equipment, so that the back pressure of the bus request cannot be caused, and the request cannot reach the target slave equipment. In some processing modes, the pen access request can also reach the target slave device, but when the data returns to pass through the SlvAF, the data is replaced by a 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 reached for data access only after the check of the access authority table by the first slave access filter 150. If the access permission check of the first slave access filter 150 is not passed and is rejected, the data return is performed by using the preset value in the virtual slave device, which will not cause back pressure on the system bus 130 request and will not allow the access request to reach the first slave device 140. In some processing manners, the access request may also reach the first slave device 140, but when the data returns to pass through the first slave access filter 150, the data will be replaced with a preset value.

The access control system based on the downstream slave device of the bus generally cannot control the authority of the upstream master device of the bus, cannot control the access between the upstream master devices of the bus, and cannot form a perfect access control system. But there are also resource access scenarios between masters upstream of the system bus, such as first master 110 accessing second master 120. Once a host device is broken or abnormal execution occurs, the resources of the host device are illegally invaded and information is leaked. Moreover, at this time, the request sent by the master device is not authentic, which may cause intentional or unintentional reading and writing on resources in other master devices, resulting in data leakage or malicious rewriting of data, thereby causing data infringement and system abnormality.

It should be noted that the above-mentioned problem of data leakage and data violation of access between the masters on the SOC bus is merely an example, and the embodiments of the present application may be applied to any type of scenario where access between masters on the system bus is at risk.

Therefore, how to develop a scheme with small access risk between the main devices on the system bus is a problem to be solved.

Based on this, the present application provides a bus control system, and the following describes the present application in detail.

Fig. 2 is a schematic diagram of a bus control system according to an embodiment of the present disclosure. The bus control system 200 may include a first master 210, a second master 220, a system bus 230, and a first access filter 240.

The first master device 210 is connected to the system bus 230, and may initiate access request information through the system bus 230 or receive access request information through the system bus 230. The first master device 210 may refer to any one of a plurality of 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 may initiate access request information through the system bus 230, or may receive access request information through the system bus 230. The second master device 220 may refer to any one of a plurality of master devices connected to the system bus 230 different from the first master device 210, and may be, for example, a memory, an audio signal processing apparatus, a wireless receiving apparatus.

The system bus 230 is used for transmitting control information such as access requests, and the control information may include control signals and timing signals. The system bus 230 is typically the path for communication 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 configured to check or access control an access request of the first master device 210, for example, the access control may be performed on an access request sent by the second master device 220 for the first master device 210. The first access controller 240 may also be referred to as an Access Filter (AF).

The access request typically includes a rights access table. As shown in table 1, the authority access table may include elements such as security identification of the master device, physical address information to be accessed, read/write request, security attribute, and the like. The first access controller 240 may arbitrate whether an access request sent to the first master device 210 is secure based on the physical address information, initiator identifier, security attributes, read/write requests, and other access rights.

TABLE 1

Address information	Master device security identification	Read/write	Safe/unsafe
				0x0000_0000-0x0000_0FFF	0x1	Read-only	S
0x0000_1000-0x0000_1FFF	0x2	Write-only	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 may be divided into the following steps:

in step one, the second master device 220 issues an access request for the first master device 210 through the system bus 230, where the access request may include an authorization access table, and the authorization access table may include authorization elements such as a master device security identifier and physical address information to be accessed.

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

Step three, the first access controller 240 performs an access right check on the access request. If the access request passes the access permission check, the access request of the second master device 220 can access the resource inside the first master device 210. If the access request does not pass the access permission check, the access request is rejected by the first access controller 240, and the first access controller 240 is triggered to send an exception report, which may return to a preset value, for example, a preset value in the virtual master device is used for data return. In some embodiments, the pen access request may also arrive at the first master device 210, but the data will be replaced with a preset value as the data returns through the first access controller 240. When the second master device 220 causes an illegal access to the first master device 210 due to a bug or an attack, the first access controller 240 may filter out an illegal access request that does not comply with the access right, thereby implementing right control of access between master devices and reducing the access risk.

In some implementations, there may be a scenario where the first master device 210 accesses the second master device 220, and an access controller may be disposed between the second master device 220 and the system bus 230, and the access controller may also be configured as a first access controller 240, configured to perform access control on an access request issued by the first master device 210 for the second master device 220. Therefore, the access authority control between the main devices is realized, and the access risk is reduced.

In some implementations, the bus control system 200 can also include multiple slave devices connected to the system bus 230. The slave device can only receive inquiry information via the system bus 230, and may be, for example, a memory, an audio player. The first slave device is any one of a plurality of slave devices. A slave-side access controller may be provided between the slave device and the system bus 230 for performing access control on an access request transmitted to the slave device. The second access controller may be any one of a plurality of slave-side access controllers. Such as a second access controller, is located between the first slave device and the system bus 230 for access control of access requests sent to the first slave device.

The first access controller 240 may not only perform access control on the access request of the first master device 210, but also receive the access request sent by the first master device 210 and perform access right configuration on 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 issued by the first master device 210 may be for a first slave device. In some embodiments, the first access request issued by the first master device 210 may be for a second master device. The embodiment of the application makes up the defects of SlvAF only by the downstream of the bus in functionality and completeness based on the access control design of the upstream main equipment side of the bus, forms comprehensive bus access control, and reduces system access risks to a greater extent.

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

The second access controller arranged in front of the first slave device performs an access right check on the first access request, and only the first access request passing the check can actually access the resource of the first slave device. Otherwise, the rejection of the second access controller is triggered, and the second access controller reports the exception, or returns a preset value.

In some implementations, a complex SoC design may integrate the master IPs of different vendors, and the architecture design proprietary to the vendors has no unified standard, so that some bus transmissions sent by the master IPs do not support the security attribute. For the master device which does not support the security attribute, an additional mechanism is needed to add the security attribute, otherwise, the downstream authority checking mechanism cannot be met, and the arbitration condition of the downstream access control of the bus cannot be met. Further, the integrity and flexibility of the whole access control system of the chip system are difficult to meet, personal privacy information and data security of the user are threatened, and the security experience and the product trust feeling of the user are influenced finally. The first access controller 240 may add a security attribute to the first access request to help a master device that does not support the security attribute to issue a desired security signal, meeting the permission check requirement of the downstream slave-side access controller. The first access controller 240 may flexibly integrate security schemes of different IP providers, and construct a perfect access control system on the master device side and the slave device side of the SoC system, which is helpful to further increase security and reduce attack surface.

The configuration of the first access controller 240 is typically completed before the corresponding master is initialized, and the slave side access controller also has similar flow constraints.

The authority access table and the security attribute information in the first access controller 240 are generally configured in a Trusted Execution Environment (TEE). The TEE may be, for example, a TEE environment in a power-on start-up stage of the SoC, or may be a TEE environment in runtime. Generally, the configuration of the first access controller 240 should be limited to the TEE environment to be configured and support the function of locking the configuration.

In some implementations, the first access controller 240 may support a lock function for each address region within the permission configuration table of the access request, as shown in table 2. After the authority configuration is locked, the authority configuration table can be edited again only after the whole system is reset. Alternatively, the first access controller 240 may lock the configuration of a certain address region according to the appeal of the physical address change, and may not be changed before the system-wide reset. Optionally, the first access controller 240 may also not lock the configuration of an address region for dynamic change at runtime.

TABLE 2

Address information	Master device security identification	Read/write	Safe/unsafe	Locking in
					0x0000_0000-0x0000_0FFF	0x1	Read-only	S	Is that
0x0000_1000-0x0000_1FFF	0x2	Write-only	NS	Whether or not
					0x0000_2000-0x0000_2FFF	0x3	Read, write	S	Is that
0x0000_3000-0x0000_3FFF	0x4	Read, write	NS	Whether or not

In some implementations, the first access controller 240 may specify a specific address region for the first access request, corresponding to issuing a security attribute specifying S or NS. I.e. the first access controller 240 may switch the security attributes according to the physical address. Optionally, the first access controller 240 may also pass through the security attributes in the master original request. Transparent transmission (pass-through) means that the communication is only responsible for transmitting the transmitted content from the source address to the destination address without any change to the content of the service data, regardless of the content of the transmitted service.

In some implementations, the first access controller 240 may set which address regions in the accessed master are accessible to external specific masters. Such as a first access request to the first master device 210, the first access controller 240 may set certain address areas in the first master device 210 to be accessible to an external specific master device. Alternatively, the first access controller 240 may not set an external specific master access object to some address areas in the first master 210.

In some implementations, the SoC integration stage does not assign a master security hardware identification to all masters, and in the trusted execution environment, the first access controller 240 may modify the master security hardware identification in the first access request. Optionally, the first access controller 240 may add the master security hardware identification in the first access request. So that the access request sent by the master device without the master device security hardware identification can meet the access check requirement of the downstream slave device access controller.

Optionally, the requirements of the system bus hooked host on the functions are different, the first access controller 240 may support parameterized configuration of the functions when the IP is instantiated, and the first access controller 240 may also support parameterized configuration of the functions when the IP calls the sub-modules. This helps to further reduce the physical area and thus power consumption.

Optionally, the first access controller 240 may be extended to support a plurality of system bus protocols, including but not limited to Advanced Microprocessor Bus Architecture (AMBA), advanced extensible interface protocol (AXI) protocol, and the like.

According to the embodiment of the application, the access controller is arranged between the main equipment and the system bus to perform access control on the access request, so that access permission control between the main equipment is realized. The embodiment of the application is based on the access control design of the upstream master device side of the bus, and is complementary with the access control of the conventional slave device to form a combined control system of the upstream and downstream of the bus, so that the illegal access of the master device caused by bugs or attacks is avoided, the access risk is reduced, the safety and stability of the system are improved, and the user experience and the trust sense are improved.

Fig. 3 is a schematic diagram of one 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 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 may initiate access request information through the system bus 330, or may receive access request information through the system bus 330.

The system bus 330 is used for transmitting 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 for performing access control or checking on an access request sent to the first master device 310, for example, the access control may be performed on an access request sent by the second master device 320 for the first master device 310. The first access controller 340 may also be referred to as an Access Filter (AF). The first access controller 340 may also receive an access request from the first master device 310, and perform permission configuration on the first access request from 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 for performing access control on an access request sent to the second master device 320, for example, the access request sent by the first master device 310 to the second master device 320 may be performed with access control. The third access controller 350 may also receive an access request from the second master device 350, and perform access right configuration on the access request from the second master device 350.

The second access controller 360 is provided between the first master device 370 and the system bus 330, and can perform access check on a visiting instruction to the first slave device 370.

A first slave device 370 is coupled to system bus 130 for receiving queries for bus information. The first slave device 370 may be, for example, an audio playback apparatus.

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

In the first embodiment, the second master device 320 sends an access request to the first master device 310. As shown by the dashed line in fig. 3, the flow of the access request can be divided into the following steps:

in step one, the third access controller 350 receives an access request sent by the second master device 350, and performs access right configuration on the access request sent by the second master device 350. The configured access right may include elements such as a security identifier of the master device, physical address information to be accessed, read/write requests, security attributes, and the like.

In step two, the third access controller 350 issues an access request to the first master device 310 through the system bus 330. The access request may include a rights access table including configured access rights.

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

Step four, the first access controller 340 performs an access right check on the access request. Access permission checks, such as a master security identification, physical address information to be accessed, read/write requests, security attributes, etc., may be included. If the access request passes the access permission check, the access request of the second master device 320 can access the resource inside the first master device 310. If the access request does not pass the access permission check, the first access controller 340 is triggered to reject the access request, and the first access controller 340 sends an exception report, which may return a preset value, for example, a preset value in the virtual master device is used for data return.

Alternatively, the third access controller 240 may support the lock function for each address region within the authority configuration table of the access request. After the authority configuration is locked, the authority configuration table can be edited again only after the whole system of the SoC is reset. Optionally, the first access controller 240 may lock the configuration of a certain address region according to the appeal of the physical address change, and the SoC may not be changed before the system-wide reset. Alternatively, the first access controller 240 may not lock the configuration of an address region for dynamic change at runtime. As shown in the access right table at the upper right position of fig. 3, a right configuration lock function is added. As shown in the access right table at the lower right position in fig. 3, the right configuration lock function is not added.

In the second embodiment, the first master device 310 sends an access request to the second master device 320. As shown in fig. 3, the flow of the access request can be divided into the following steps:

first, the first access controller 340 receives an access request sent by the first master device 310, and performs access right configuration on the access request sent by the first master device 310. The configured access right may include elements such as a security identifier of the master device, physical address information to be accessed, read/write requests, security attributes, and the like.

Alternatively, if the security attribute is not supported in the bus transmission issued by the first master device 310. The first access controller 340 may 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 out a desired security signal, so as to meet the requirement of the permission check of the third access controller 350 on the destination master device side.

In step two, the first access controller 340 issues an access request for the second master 320 through the system bus 330. The access request may include a rights access table including configured access rights.

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

Step four, the third access controller 350 performs an access right check on the access request. Access permission checks, such as a master security identification, physical address information to be accessed, read/write requests, security attributes, etc., may be included. If the access request passes the access permission check, the access request of the first master device 310 can access the resource inside the second master device 320. If the access request does not pass the access permission check, the rejection of the third access controller 350 is triggered, and the third access controller 350 sends an exception report, which may return a preset value, for example, a preset value in the virtual master device is used for data return.

Embodiment three, the first master device 310 sends a first access request to the first slave device 370. As shown in fig. 3, the flow of the access request can be divided into the following steps:

first, the first access controller 340 receives a first access request sent by the first master device 310, and performs access right configuration on the first access request. The configured access right may include elements such as a security identifier of the master device, physical address information to be accessed, read/write requests, security attributes, and the like.

Alternatively, if the first master device 310 does not support the security attributes in the bus transfer. The first access controller 340 may 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 out a desired security signal, so as to meet the requirement of the permission check of the second access controller 360 on the destination slave device side.

In step two, the first access controller 340 issues a first access request to the first slave device 370 through the system bus 330. The first access request may include a rights access table including configured access rights.

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

Step four, the second access controller 360 performs an access right check on the first access request. Access permission checks, such as a master security identification, physical address information to be accessed, read/write requests, security attributes, etc., may be included. If the first access request passes the access permission check, the first master device 310 may access the resource within the first slave device 360. If the first access request does not pass the access permission check, the rejection of the second access controller 360 is triggered, and the second access controller 360 sends an exception report, which may return a preset value, for example, a preset value in the virtual slave device is used for data return.

The access control method and the access control device of the bus have the advantages that based on the access control design of the upstream master device side of the bus, access permission control between the master devices is achieved, the access control is complementary with the access control of conventional slave devices, a combined control system of the upstream and downstream of the bus is formed, illegal access of the master devices due to bugs or attacks is avoided, and access risks are reduced. The embodiment of the application also solves the problem that the main equipment does not support the security attribute, can flexibly integrate security schemes of different IP suppliers, constructs a perfect access control system of the main equipment side and the slave equipment side of the SoC system, and is favorable for further increasing the security and reducing attack surfaces.

System embodiments of the present application are described in detail above in conjunction with fig. 1-3, and method embodiments of the present application are described in detail below in conjunction with fig. 4. It is to be understood that the description of the method embodiments corresponds to the description of the system embodiments, and therefore reference may be made to the previous system embodiments for portions that are not described in detail.

Fig. 4 is a flowchart illustrating a method for controlling a bus according to an embodiment of the present disclosure. The method of fig. 4 may be applied to the bus control system described in any of the previous embodiments. The bus control system can comprise a first master device and a second master device, wherein the first master device and the second master device are connected 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. The method of fig. 4 includes steps S410 to S420, which are described in detail below.

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

In step S420, access control is performed on an access instruction to the first master device using the first access filter.

If the access command passes the access right check, the second main device can access the resource in the first main device. If the access instruction does not pass the access permission check, the first access controller is triggered to reject the access instruction, and the first access controller sends an exception report and can also return a preset value.

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

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

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

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

Optionally, the first access controller may support parameterized configuration of functions when IP instantiations.

Alternatively, the first access controller may be extended to support multiple system bus protocols.

The access controller provided by the embodiment of the application is realized through a hardware IP in a chip, is difficult to embody in physical appearance, and can deduce the access control logic of a system bus through means of codes, processes and debugging, thereby distinguishing the bus control method based on the slave equipment from the bus control method based on the slave equipment.

Fig. 5 is a schematic structural diagram of an electronic device provided in 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 previous paragraphs.

It should be noted that the electronic device mentioned in the embodiments of the present application is an electrical device composed of microelectronic devices, and refers to a device that can be composed of electronic components such as integrated circuits, transistors, and electronic tubes, and functions by applying electronic technology (including software). 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 mobile terminal, a touch screen, or the like. For example, the electronic device may be a smart phone, a portable phone, a game machine, 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 (PMP), a Personal Digital Assistant (PDA), a robot controlled by an electronic computer, a numerical control or program control system, or the like. The electronic device may also be a portable communication terminal having a wireless communication function and a pocket size. Further, the electronic device may be a flexible device or a flexible display device.

It should be understood that, in the various embodiments of the present application, "first", "second", and the like are used for distinguishing different objects, and are not used for describing a specific order, the order of execution of the above-mentioned processes is not meant to imply any order of execution, and the order of execution of the processes should be determined by their functions and inherent logic, and should not be construed as limiting the implementation processes of the embodiments of the present application.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one type of logical functional division, and other divisions may be realized in practice, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

In the several embodiments provided in this application, it should be understood that when a portion is referred to as being "connected" or "coupled" to another portion, it is intended that the portion can be not only "directly connected," but also "electrically connected," with another element interposed therebetween. In addition, the term "connected" also means that the parts are "physically connected" as well as "wirelessly connected". In addition, when a portion is referred to as "comprising" an element, it means that the portion may include another element without excluding the other element unless otherwise stated.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

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

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A bus control system, comprising:

the system comprises a first main device and a second main device, wherein the first main device is connected with the second main device through a system bus;

and the first access controller is arranged between the first master device and the system bus and used for performing access control on an access request which is sent by the second master device and aims at the first master device.

2. The bus control system according to claim 1, further comprising:

the first slave device is connected with the system bus;

and the second access controller is arranged between the first slave equipment and the system bus and used for performing access control on the access request sent to the first slave equipment.

3. The bus control system of claim 2, wherein the first access controller is further configured to:

receiving a first access request sent by the first master device, wherein the first access request is used for accessing the first slave device;

adding a security attribute in the first access request.

4. The bus control system of claim 2, wherein the first access controller is further configured to:

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 of claim 2, wherein the first access controller is further configured to:

modifying, in the trusted execution environment, the primary device secure hardware identification in the first access request, and/or,

and adding the safety hardware identifier of the main equipment.

6. A method for bus control is applied to a bus control system, and the bus control system comprises the following steps:

the first access controller is arranged between the first master device and the system bus and used for performing access control on an access request which is sent by the second master device and aims at the first master device;

the method comprises the following steps:

transmitting an access request sent by the second master device to the first master device through the system bus;

and performing access control on the access request by utilizing the first access controller.

7. The method of claim 6, wherein the bus control system further comprises:

the first slave device is connected with the system bus;

a second access controller provided between the first slave device and the system bus;

the method further comprises the following steps:

and performing access control on the access request sent to the first slave device by utilizing the second access controller.

8. The method of claim 7, further comprising:

adding a security attribute in the first access request.

9. The method of claim 7, further comprising:

10. The method of claim 7, further comprising:

modifying, in the trusted execution environment, the master secure hardware identification in the first access request, and/or,

and adding the safety hardware identifier of the main equipment.

11. An electronic device, characterized in that it comprises a bus control system according to any one of claims 1-5.