dual-level management

Abstract

Access rights are set for different request circuits on the control bus. Access rights can be set by a level 1 manager and a level 2 manager, allowing two layers of security to be added. The level 1 manager has priority, allowing it to add access rights that cannot be removed by the level 2 manager.

Description

Technical Field

[0001] This disclosure relates to receiving circuitry, and more particularly to receiving circuitry configured to process read or write requests based on stored access permissions. Background Technology

[0002] Processing devices, such as system-on-a-chip (SoCs), comprise multiple different components with different functions. For example, a processing device may include multiple different processing elements configured to execute computer-readable instructions to perform operations on data stored in memory.

[0003] In addition to the processing elements, the processing device may include additional elements that enable the processing device to operate, such as reset registers, switching circuits, etc. Many different elements of the processing device can be accessed by other elements of the processing device via interconnections that exchange control information between the different elements of the processing device.

[0004] When designing a processing device in which components of the processing device can read from or write to storage devices associated with other components of the processing device, it is important to consider security aspects. In particular, some components of the processing device capable of issuing read or write requests to other components of the processing device may execute or respond to instructions from untrusted third-party software or firmware. Therefore, it may be desirable to restrict access to certain components of the processing device. Summary of the Invention

[0005] When a component of a processing system receives an access request from one or more entities, it may be desirable to restrict access to that component for security reasons. This can be done by having a trusted entity define access permissions for the component, specifying whether the component is responsible for serving the incoming read or write requests. However, if access permissions are defined only for a trusted entity, this can reduce the flexibility in controlling access. For example, this could restrict other parties' ability to exercise their own control over access within the device, thereby hindering their security interests. On the other hand, allowing untrusted entities to define access permissions can introduce security risks.

[0006] According to a first aspect, a receiving circuit is provided, the receiving circuit comprising: at least one interface configured to receive a plurality of read or write requests from a plurality of request circuits accessible via at least one control bus, each of the read or write requests being a request for accessing at least one storage device associated with the receiving circuit; at least one register configured to store a plurality of permission settings, wherein each of the plurality of permission settings indicates whether access to the at least one storage device is permitted by one of the plurality of request circuits; and a processing circuit configured to: in response to each of at least one of the plurality of requests for accessing the at least one storage device received at at least one interface, and in response to an indication in the permission settings that access by the request circuit that issued the corresponding request is not permitted; and in response to one or more write requests to the at least one register received from a first management unit, update the permission settings to indicate that access by one or more of the request circuits is not permitted; and subsequently, in response to one or more write requests received from a second management unit for updating the permission settings to allow access by one or more of the request circuits, in response to determining that the first management unit has written the permission settings indicating that access by one or more of the request circuits is not permitted, prevent updates to the permission settings for allowing access by one or more of the request circuits.

[0007] By allowing two entities (i.e., a first management unit and a second management unit) to control access to the storage device associated with the receiving circuitry, these two distinct entities can exercise security benefits within the device. However, this prevents the second management unit (which may not be trusted by the first management unit) from removing certain security layers already imposed by the first management unit. Each security layer can be used to impose access restrictions on different entities. Therefore, the receiving circuitry is both secure and provides the flexibility to allow different entities to add their own security settings.

[0008] In some embodiments, the processing circuitry is configured to: in response to one or more further write requests received from the second management unit for updating permission settings to block access to one or more of the requesting circuitry, allow updating the permission settings to indicate that access is blocked.

[0009] In some embodiments, the permission settings include a plurality of first permission settings and a plurality of second permission settings, wherein each of the plurality of request circuits is associated with one of the first permission settings and one of the second permission settings.

[0010] In some embodiments, the processing circuitry is configured to: in response to determining that a corresponding request has been received from the second management unit, serve the corresponding request regardless of multiple second permission settings, for each of at least one read or write request to at least one storage device received from the second management unit.

[0011] In some embodiments, the processing circuitry is configured to block the corresponding service request in response to an indication in a first permission setting that access is not permitted, for each of at least one read or write request to at least one storage device received from the second management unit.

[0012] In some embodiments, in response to a determination that the request circuit from which the request originates is associated with at least one setting that indicates access is not permitted, a blocking service read or write request is executed.

[0013] In some embodiments, the processing circuitry is configured to: in response to determining that a corresponding request has been received from the first management unit, serve the corresponding request regardless of permission settings, for each of at least one read or write request to at least one storage device received from the first management unit.

[0014] In some embodiments, each of the request circuits is associated with at least one processor configured to execute computer-readable instructions to generate at least one of a plurality of read or write requests.

[0015] In some embodiments, each of the request circuits is associated with a circuit configured to generate at least one of a plurality of read or write requests, wherein the circuit includes at least one of a field-programmable gate array or an application-specific integrated circuit.

[0016] In some embodiments, at least one of the multiple request circuits belongs to a first management unit or a second management unit.

[0017] In some embodiments, the processing circuitry is configured to: receive an identifier of the first management unit from a third management unit before receiving a write request to at least one register from a first management unit and a second management unit; and store the identifier of the first management unit in at least one register, wherein, in response to one or more write requests to at least one register received from the first management unit, one or more permission settings are updated in response to determining that the identifier in the request matches the identifier of the first management unit in at least one register.

[0018] In some embodiments, the third management unit stores the identifier of the first management unit in one or more fuses.

[0019] In some embodiments, the processing circuitry is configured to: receive an identifier of a second management unit from a first management unit; store the identifier of the second management unit in at least one register; and subsequently, in response to one or more further write requests to at least one register received from the second management unit, update one or more permission settings in response to determining that the identifier in the request matches the identifier of the second management unit in at least one register.

[0020] In some embodiments, the processing circuitry is configured to, in response to each of at least one of a request for access to at least one storage device received at at least one interface, perform a read or write operation at at least one address of the at least one storage device indicated in the corresponding request.

[0021] In some embodiments, at least one register includes one or more indications of at least one address to which access permissions are not applicable, wherein the processing circuitry is configured to service the request in response to determining that one of the indications in a received request matches an indication of at least one address to which access permissions are not applicable.

[0022] In some embodiments, the processing circuitry is configured to: in response to one or more write requests received from at least one of the first management unit and the second management unit, write an indication of one or more addresses to which access rights are not applicable to write to at least one register.

[0023] In some embodiments, in response to each of at least one of the requests for access to at least one storage device received at at least one interface, a packet indicating the failure of the request is sent to the request circuit from which the corresponding request originated, in response to an indication in any of one or more permission settings that indicates access is not permitted.

[0024] In some embodiments, the receiving circuit is adapted to an integrated circuit.

[0025] According to a second aspect, an integrated circuit including the receiving circuitry described in the first aspect is provided, the integrated circuit being configured as an accelerator subsystem of a host system.

[0026] In some embodiments, the second management unit is associated with a management program running on the host system.

[0027] In some embodiments, the integrated circuit includes a plurality of processing units configured to execute computer-readable instructions to perform operations on data, wherein each of the plurality of processing units includes a control register, and wherein at least one storage device includes a control register of a processing unit.

[0028] According to a third aspect, a method implemented in a receiving circuit is provided, the method comprising: storing a plurality of permission settings, wherein each of the plurality of permission settings indicates whether access to at least one storage device associated with the receiving circuit is permitted by one of a plurality of request circuits; updating the permission settings to indicate that access by one or more of the request circuits is not permitted in response to one or more write requests to at least one register received from a first management unit; and subsequently, in response to one or more write requests received from a second management unit for updating the permission settings to allow access by one or more of the request circuits, blocking updates to the permission settings for allowing access by one or more of the request circuits in response to determining that the first management unit has written permission settings indicating that access by one or more of the request circuits is not permitted; receiving a plurality of read or write requests from a plurality of request circuits accessible via at least one control bus, each of the read or write requests being a request for access to at least one storage device associated with the receiving circuit; and blocking the corresponding read or write request from being served in response to at least one of the plurality of requests for access to at least one storage device associated with the receiving circuit, in response to an indication in the permission settings indicating that access by one of the request circuits issuing the corresponding request is not permitted.

[0029] According to a fourth aspect, a computer program is provided that, when executed by a processor of a receiving circuit, causes the method described according to a third aspect to be performed.

[0030] According to a fifth aspect, a non-transitory computer-readable medium is provided for storing a computer program according to a fourth aspect. Attached Figure Description

[0031] To better understand the invention and illustrate how to implement it, reference will now be made to the accompanying drawings by way of example, wherein:

[0032] Figure 1 The control bus used for switching between groups between initiators and targets is shown;

[0033] Figure 2 The fields of the header used for data packets sent over the network are shown;

[0034] Figure 3 An example of a target is shown;

[0035] Figure 4 An example is shown that includes a set of access permissions based on two levels defined by the target-initiator.

[0036] Figure 5 An example of a set of multiple access permissions with a flag indicating whether a Level 1 manager has written access permissions is shown;

[0037] Figure 6 Another example is shown of a set of multiple access permissions with a flag indicating whether the Level 1 manager has written access permissions;

[0038] Figure 7 An example method implemented using a control bus is shown; and

[0039] Figure 8 An example method implemented in the receiving circuit is shown. Detailed Implementation

[0040] The techniques described herein can be implemented in a processing unit. An example processing unit in which this technique can be implemented is the intelligent processing unit (IPU) described in our earlier U.S. Application No. 15 / 885925, the contents of which are incorporated herein by reference. However, the techniques described herein can also be applied to other types of devices.

[0041] The control bus, which carries control functions, is implemented in an integrated circuit (i.e., a chip). (See reference) Figure 1 The diagram illustrates an exemplary control bus 700. The control bus 700 is a data path for carrying single-word control traffic within a ring. The control bus 700 is a pipelined data bus via which data packets move sequentially in a pipeline at a rate determined by clock pulses applied to the control bus 700. The ring includes multiple nodes 710, where traffic is passed from one node 710 to the next node 710 in a flow direction around the ring. The output port 750 of each node is connected to the input port 760 of the next node 710 in the ring.

[0042] Some of the nodes 710 include connections to receiving circuitry 720 (referred to herein as bus target 720) for receiving read or write requests to the storage device associated with bus target 720. Some of the nodes also include connections to requesting circuitry 730 (referred herein as bus initiator 730) that issued the read or write request. In this embodiment, control bus 700 carries traffic between up to 16 bus initiators and 512 bus targets. Therefore, node 710 is a block in control bus 700 that connects bus initiator 730 or bus target 720 to control bus 700.

[0043] Examples of on-chip components / devices that include bus initiator 730 include: an on-chip processor running software or firmware, I / O ports (e.g., PCI express endpoints that receive requests from software running on an external processor connected to the IPU via PCIe), and hardware units that communicate with another hardware unit on the chip using a control bus. Each of these components is capable of issuing read or write requests via its request circuit / bus initiator 730. All bus initiators 730 are on-chip. Each component that includes bus initiator 730 also includes a request block that issues read or write requests via bus initiator 730.

[0044] Examples of on-chip components / devices including bus targets 720 include: a hardware unit with a control register storing parameters controlling the operation of the hardware unit; an on-chip storage device (e.g., SRAM or non-volatile memory); a bridge to an off-chip storage device (such as a DRAM memory controller); and circuitry for converting packets from the described control bus communication protocol to another protocol. Each of these bus targets 720 is associated with a storage device from which it can be read or written. All bus targets 720 are on-chip. Each component including a bus target 720 also includes a receive block containing a storage device that can be written to or read from in response to a request received at the bus target 720.

[0045] Each of the bus initiators 730 is capable of issuing a request to the bus target 720 and receiving a completion from the bus target 720. Each request is either a command to read from a storage device associated with the bus target 720 (e.g., an attached addressable entity or an automatically generated register) or a request to write to such a storage device associated with the bus target 720. In response to receiving such a request, the bus target 720 responds by issuing a completion. The completion provides a status update indicating whether the read or write request was successful.

[0046] Control bus node 710 connects bus initiator 730 and bus target 720 to control bus 700. Control bus node 710 handles control bus 700 transaction routing and manages control bus 700 access protocols. Each control bus node 710 may have either a bus initiator interface or a bus target interface.

[0047] Bus initiator 730 sends a request to control bus 710 and receives a completion response. Once bus initiator 730 is granted bus access by its connected node 710, bus initiator 730 can send its request transaction to control bus 700 via its node 710. Bus initiator 730 also receives completion from bus target 720 in response to its previously issued read or write requests.

[0048] Request and completion tokens are also issued in the ring. These are packets that circulate around the ring and allow the bus initiator 730 and bus target 720 to arbitrate access to the control bus 700. The number of tokens circulating around the ring at any given time is controlled by the regulator 740. The regulator 740 initially issues tokens, and as will be understood, tokens are added and removed by the bus initiator 730 and bus target 720 as they send and receive requests and completions. Tokens are used to grant access to the control bus 700 to the bus initiator 730 and bus target 720. The control bus regulator 740 is responsible for controlling access to the control bus 710 by issuing request and completion tokens to the bus 710. The request and completion tokens circulating on the control bus 700 (set by the regulator 740) determine how many incomplete transactions the control bus 700 supports.

[0049] The tokens take the form of request tokens and completion tokens. A request token grants bus initiator 730 access to control bus 700. A completion token grants bus target 720 access to control bus 700. Request tokens circulate along control bus 700 until bus initiator 730 with pending requests receives the token and removes it from control bus 700. Each request token includes an identifier (referred to as initid). The identifier initid identifies either regulator 740 or bus initiator 730 in the ring. When a request token arrives at node 710, the bus initiator 730 of that node 710 will remove the request token from the ring in response to determining that either the identifier in the request token matches the identifier of that bus initiator 730 or matches the identifier of that regulator 740. Therefore, when a request token arrives at node 710 (which contains an interface to bus initiator 730, which has pending requests to be issued) and thus contains a matching identifier, or if the request token contains an identifier of regulator 740, when the request token arrives at node 710 (which contains an interface to any bus initiator 730, which has pending requests to be issued), the request token circulates on the control bus 700 and is removed.

[0050] When the bus initiator 730 removes the request token from the control bus 700, the bus initiator 730 issues a request to the control bus 700. This request can be a write request or a read request. A write request is a request to write to the storage device associated with the bus target 720. A read request is a request to read from the storage device associated with the bus target 720.

[0051] A write request includes a header and a payload. These are sent seamlessly to the control bus 700. The payload contains data to be written to the associated storage device of the bus target / multiple bus targets 720. Write requests can be unicast or broadcast. A unicast write request is issued to a single identified bus target 720 on the control bus 700. A broadcast write request is issued to all bus targets 720 on the control bus 700.

[0052] When bus target 720 receives a unicast write request, it issues a write completion notification in response to the receipt of the write request. The write completion is returned to the bus initiator 730 that issued the write request. The write completion packet includes an indication of whether the write request was successful. For broadcast write requests, bus target 720 does not return a write completion notification.

[0053] Each read request includes a header without a payload. Read requests are unicast. The bus target 720 receiving the read request responds by issuing a read complete message. The read complete message includes a header and a payload, where the payload contains the data read from the address indicated in the read request. The read complete message also includes an indication of whether the read was successful. This indication is included in the header of the read complete packet. If the read complete message includes an indication that the read request was unsuccessful, the bus initiator 730 receiving the read complete message will ignore the data included in the payload.

[0054] refer to Figure 2 The diagram illustrates an example of the header 800 of one of the packets sent to the control bus 700. Header 800 can be a header for a read request, write request, read complete, write complete, request token, or completion token. Certain fields can be omitted for some of these packet types. For example, the address field 840 can be omitted from request and completion tokens.

[0055] Some of the packets circulating on bus 700 also include payloads (e.g., write requests or read completions), but these are not included in... Figure 2 The following is shown. The bits along the header number indicate the bits of header 800. This example header 800 includes 32 bits, where bits 0:3 indicate the transaction type 810, bits 4:7 indicate the bus initiator 730 or regulator 740 identifier 820, bits 8:16 indicate the bus destination identifier 830, and bits 17:31 indicate the address offset 840. These numbers are only examples, and the number of bits in header 800 and the bit allocation of different fields may differ in other examples.

[0056] The header 800 includes an indication 810 for the transaction type. This indication 810 identifies whether the group is a read request, write request, read complete, write complete, request token, or completion token.

[0057] The header 800 includes an identifier 820 for either the bus initiator 730 or the regulator 740. This is the initid field discussed above. In a request packet, identifier 820 indicates which of the bus initiators 730 will provide the request packet to the control bus 700. In a completion packet, identifier 820 indicates the destination bus initiator 730 for completion. For a request token packet, identifier 820 is an identifier for either the regulator 740 or the bus initiator 730. If identifier 820 identifies the regulator 740, the request token can be removed / consumed by any bus initiator 730. If identifier 820 identifies one of the bus initiators 730, the request token can be removed / consumed only by the bus initiator 730 identified by identifier 820. On the other hand, a completion token can be removed / consumed by any bus destination 720. In some embodiments, identifier 820 may not be present in the completion token packet. In other embodiments, identifier 820 in the completion token packet may identify the regulator 740.

[0058] The header 800 includes a bus destination identifier field 830, which identifies one of the bus destinations 720. For a unicast request packet, the identified bus destination 720 is the destination of the request. The identified bus destination 720 will respond to the request. In the case of a broadcast request packet, field 830 includes an indication that the packet is a broadcast packet.

[0059] In some cases, bus target 720 is associated with multiple bus target identifiers, where different bus target identifiers are associated with different storage devices associated with the bus target. For example, a first bus target identifier may be associated with the management register of bus target 720, while a second bus target identifier may be associated with another storage device associated with the same bus target 720. In this case, field 830 can identify one of the storage devices associated with a particular bus target 720.

[0060] For completion groups, field 830 identifies the bus target 720 from which the completion group originates. This information can be used for debugging purposes. When multiple bus targets 720 aggregate their status into a single completion group (executed when a completion response broadcast request is issued), field 830 does not identify the bus target 720. In this case, field 830 is undefined.

[0061] The header 800 includes an address field 840 that indicates an address in the associated storage device of the bus target. This address may be an address in an automatically generated register associated with the bus target 720. The address may also be an address within an address window associated with the bus target 720. In a request packet, this address indicates the address against which a read or write operation will be performed. In a completion packet, the address field 840 contains the same address as the address present in the address field 840 of the corresponding request packet, in response to which the completion packet is issued.

[0062] As described above, access to the control bus 700 by the bus target 720 and bus initiator 730 is controlled by a token system. The bus initiator 730 may issue a request to the control bus only when it has consumed a request token for a node 710 to which it is connected. The bus target 720 may issue a completion token to the control bus 700 only when it has consumed a completion token for a node 710 to which it is connected. The regulator 740 is responsible for issuing tokens and thus controls the extent to which multiple transactions can cycle simultaneously on the control bus.

[0063] The lifecycle of a Control Bus 700 transaction is divided into two main phases: the request phase and the completion phase.

[0064] During the request phase, when the bus initiator 730 has a pending request, it waits for a request token to arrive at its connected node 710. When a request token is received at the connected node 710, if the request identifier 820 identifies either the bus initiator 730 itself or the regulator 740, in response to such a determination, the bus initiator 730 consumes the request token and replaces it with a pending request. Some of the nodes 710 controlling the bus 700 include interfaces to the attached bus initiator 730. Each interface at each of these nodes 710 checks the initiator identifier 820 in the request token and, when it determines that an appropriate identifier exists, provides the request token to the bus initiator 730. The interface making the determination can be part of the processing logic of the bus initiator 730 itself, or it can be a separate circuit of the node 710.

[0065] Some of the nodes 710 in the control bus 700 include interfaces to the attached bus target 720. Each interface in such a node 710 checks the target identifier 820 in a request packet and provides the request packet to the bus target 720, the request packet containing an identifier that matches the identifier of the attached bus target 720. The interface used to make the determination can be part of the processing logic of the bus target 720 itself, or it can be a separate circuit of the node 740.

[0066] Each bus target 720 includes a buffer where read or write requests are received from bus initiators 730 on control bus 700. The buffers in each bus target 720 are large enough to store requests from each bus initiator 730 on control bus 700. For example, if control bus 700 supports 16 initiators, the buffers in each bus target 720 can store at least 16 requests. The processing logic of the bus target 720 processes the requests stored in the buffers sequentially and issues the corresponding completion notification to control bus 700. By providing buffer space for requests from all bus initiators 720 on control bus 700, each request is removed once it arrives at its corresponding bus target 720.

[0067] Some of the bus targets 720 are configured as slow bus targets. When a request is received directed to a slow bus target, the slow bus target consumes the request, operates on it, and replaces the request with a request token on the control bus 700.

[0068] Some of the bus targets 720 are configured as fast bus targets. A fast bus target 720 is a bus target 720 that operates on a request upon receiving it (i.e., by reading or writing to the memory address it identifies), but causes the request to circulate on the control bus. In other words, the bus target 720 that processes the request does not consume the request. Instead, the request is consumed by the bus initiator 730 that issued it. The bus initiator 730 replaces the request with a request token that subsequently circulates on the control bus 700. Configuring the bus targets 720 as fast bus targets has at least two advantages. First, this mode of operation is efficient for broadcast requests because a request that will be processed by multiple bus targets 720 will not subsequently be consumed by the first of these bus targets 720. Instead, the request will propagate to all of the multiple bus targets 720 without being consumed by the first bus target 720 it encounters. Second, the regeneration of the request token by the bus initiator 730 means that the next bus initiator 730 along the ring 700 has the highest priority access to the control bus 700, resulting in a fairer bus access scheme.

[0069] Following the request phase, a completion phase is executed. During the completion phase, after receiving and processing the request, bus target 720 sends a completion packet to control bus 700, which is consumed by the bus initiator 730 from which the corresponding request originated. If a completion token arrives at its connected node 710, bus target 720 with pending completion will issue its completion.

[0070] When bus target 720 receives a read or write request from control bus 700, whether the read or write request is serviced depends on whether the stored access permissions indicate that the bus initiator 730 from which the request originated has access to the bus target. In other words, access permissions are defined on a bus initiator-bus target basis. These access permissions are part of the management state stored in the management register of bus target 720.

[0071] Each of the bus target 720 and the bus initiator 730 includes processing logic and a storage device for performing the described operations. The processing logic may include processing logic configured to execute computer-readable instructions stored in the memory of the target 720 or the initiator 730 to perform the operations. The processing logic may alternatively or additionally include a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).

[0072] refer to Figure 3 The diagram illustrates an example bus target 720. Bus target 720 includes a bus target management register 910, which can be written to in response to a write request received from the control bus 700. Such a request to write to the management register 910 of the bus target can be referred to as a management request. The bus target management register 910 stores the access permissions for each bus initiator 730. These access permissions can be written to the management register 910 by selected units referred to as first and second management units (also referred to as level 1 managers and level 2 managers), which will be discussed in more detail later. Each management unit includes a bus initiator 730 for issuing write requests to the target management state to define access permissions.

[0073] Additionally, each bus target 720 includes at least one node management register 940. The node management register 940 can be written via a dedicated node management broadcast write request, which writes a common state set to all node management registers 940 in the bus target 720. This broadcast write is performed by another management unit (referred to herein as the Level 0 Manager), which will be discussed in more detail later.

[0074] In addition to at least one bus target management register 910, bus target 720 is associated with an additional storage device 920, which is part of a receive block 950 to which bus target 720 belongs. The additional storage device 920 may include storage devices with automatically generated registers and / or other features. The additional storage device 920 may include control registers on a small chip 4 of chip 2 that is addressable via another bus. The additional storage device 920 may allow access to off-chip storage devices, such as host storage devices accessible via a PCI link. In this case, the additional storage device 920 is the host scheduler's memory, which provides data written to the host memory.

[0075] Bus target 720 is connected to control bus 710 via an interface including a request port and a completion port. The request port receives read and write requests from control bus 700, which are buffered in request buffer 960 and then passed to processing logic 930. The completion port sends completion information from completion buffer 970 to control bus 700. Processing logic 930 can perform functions implemented in hardware or software. Processing logic 930 may include one or more of an ASIC, FPGA, or at least one processor configured to execute computer-readable instructions stored in at least one memory of bus target 720.

[0076] Processing logic 930 determines whether to service the request by examining the bus initiator identifier present in the read / write request received at bus target 720 and by looking up the stored access permissions associated with the bus initiator 730 identified in the read / write request in register 910. If the access permissions indicate that the bus initiator 730 identified in the read / write request has access to the storage device 920 associated with bus target 720 according to the stored access permissions, bus target 720 will determine to service the request by allowing the read / write operation. After this, processing logic 930 will cause a completion packet to be sent to control bus 700. If the access permissions indicate that the bus initiator 730 identified in the read / write request does not have access to the storage device 920 associated with bus target 720, bus target 720 will not service the request. In this case, bus target 720 will return a completion packet indicating to the bus initiator 730 that the request was not successfully executed. This completion packet is sent via the completion port by processing logic 930. The completion packet is buffered in completion buffer 970 before being sent through the completion port.

[0077] Bus target management register 910 stores management status information. All bus targets 720 contain such register 910 residing in the management space. The types of information contained in the bus target management status are the same in each of the bus targets 720. However, the bus target management status can be programmed with different settings on a per-bus-target basis. The bus target management status includes access permissions defined for each bus initiator 730 in each bus target 720. The bus target management status may include indications of certain addresses of whitelisted storage devices accessible via the bus target 720; that is, access permissions do not apply to these addresses and they can be read and written by any of the bus initiators 730.

[0078] Further management states (referred to as node management states) are stored in register 940 of bus target 720. The node management states are programmed with the same settings for all bus targets 720. This can be achieved by one or more bus initiators 730 issuing one or more broadcast write requests to bus target 720. The node management states include the identifier of a level 1 manager. The node management states include the identifier of a level 2 manager. The node management states include fuse state settings distributed from the system fuse box, including the identifier of a level 1 manager.

[0079] Each bus initiator 730 has a unique initiator ID assigned in non-programmable hardware. The node management register 940 in each bus target 720 defines the initiator ID of the bus initiator 730 for the Level 2 manager. This can be set programmably, but only via a write request issued by the Level 1 manager. Because the ID of the bus initiator 730 for the Level 2 manager must be identical in every register 940 of each target 720, the Level 1 manager uses a broadcast write to write this ID to all bus targets 720 on the bus 700.

[0080] Each bus target 720 is also associated with a storage device 920. Unlike the bus target management register 910, the associated storage device 920 can take different forms and vary depending on the bus target 720. Therefore, unlike the bus target management register 910 (which is the same for each bus target (even though the state stored in register 910 differs between bus targets 720)), the associated storage device 920 component is different for each bus target 720.

[0081] When bus target 720 receives a read / write request, it distinguishes between read / write requests pointing to register 910 and read / write requests pointing to storage device 920 based on the bus target identifier 830 contained in the request. Each bus target 720 is associated with two different identifiers. The first of these identifiers is associated with register 910, and the second of these identifiers is associated with the associated storage device 920. Processing logic 930 checks the bus target identifier 830 and selects one of register 910 and storage device 920, wherein the read / write request for storage device 920 is processed according to the bus target identifier 830.

[0082] Processing logic 930 uses access permissions stored in register 910 to determine how to process received read or write requests to / from storage device 920. Processing logic 930 receives a read or write request and checks the bus initiator identifier contained in the request. Processing logic 930 uses the bus initiator identifier to look up the access permissions of the bus initiator 730 in the bus target management register 910. If processing logic 930 determines, based on its associated permission settings, that the bus initiator 730 has access to the associated storage device 920, then processing logic 930 allows the request to be fulfilled. In this case, a read / write operation is performed on storage device 920. On the other hand, if processing logic 930 determines, based on its associated permission settings, that the bus initiator 730 does not have access to the associated storage device 920, then processing logic 930 prevents the write or read request from being served.

[0083] In this embodiment, the set of access permission settings stored in register 910 includes two subsets of access permissions. Between them, the subset of access permissions is defined by a first component (hereinafter referred to as the Level 1 management unit) and a second component (hereinafter referred to as the Level 2 management unit). Either the Level 1 management unit or the Level 2 management unit can write to either subset of access permissions. However, the Level 2 management unit cannot update access permission settings that have been set by the Level 1 manager to block access.

[0084] Each subset of access permission settings includes settings associated with each bus initiator 730. For a given bus initiator 730, if any of the access permission settings for that bus initiator 730 includes an indication that access is not permitted, then read or write requests received from the bus initiator 730 are not serviced (this rule applies to exceptions for Level 1 and Level 2 management units). However, read or write requests from a Level 1 management unit to the storage device 920 are always serviced. Unless a Level 1 access permission setting indicates that Level 2 managers are not permitted to access, read or write requests from a Level 2 management unit to the storage device 920 are serviced. Therefore, Level 1 settings take precedence over Level 2 settings because they also prevent Level 2 managers from accessing the storage device.

[0085] refer to Figure 4 This illustrates the different possibilities for setting access permissions. As shown in Table 1100, each bus initiator 730 is associated with two different settings, one for each level of access permission. For bus initiator 1, both level 1 and level 2 access permissions indicate (via 0b) that a specific bus target 720 is allowed to access the storage setting 1100. Therefore, a request issued by bus initiator 1 and received at bus target 720 will be served by bus target 720, i.e., a read or write operation will be performed.

[0086] For bus initiator 2, the Level 1 access permission setting indication (via 0b) allows access to a specific bus target 720 of storage setting 1100. However, the Level 2 access permission setting indication (via 1b) disallows access to a specific bus target 720. Therefore, requests initiated by bus initiator 2 (assuming bus initiator 2 is not a Level 1 manager or a Level 2 manager) and received at bus target 720 will not be served by bus target 720; that is, no read or write operations will be performed.

[0087] Similarly, for bus initiator 3, the Level 2 access permission setting indication (via 0b) allows access to a specific bus target 720 of storage setting 1100. However, the Level 1 access permission setting indication (via 1b) disallows access to a specific bus target 720. Therefore, a request issued by bus initiator 3 (assuming bus initiator 3 is not part of the Level 1 manager) and received at bus target 720 will not be served by bus target 720; that is, no read or write operation will be performed.

[0088] For bus initiator 4, since access is not permitted under the Level 1 and Level 2 access permission settings, requests from bus initiator 4 (assuming bus initiator 4 is not a Level 1 manager) will not be served by bus target 720; that is, no reads or writes will be performed.

[0089] Therefore, two layers of security are supported, which allows the Level 2 management unit to add its own security requirements on top of the Level 1 security requirements applicable to the Level 2 management unit itself. This means that any request made by the bus initiator 730 (other than requests from the Level 1 and Level 2 managers) can be blocked by settings distributed from either of the management units.

[0090] This section describes how to configure permission settings for Level 1 and Level 2 snap-ins. (Refer to [link / reference] again) Figure 1 and Figure 3 As noted, the bus target management register 910 stores the management status of the associated bus target 720, including access permission settings. This management status can be written to by a management unit issuing a write request to the control bus 700, the write request having a bus target identifier associated with the bus target management register 910 of the associated bus target 720. Other bus initiators 730, besides the management unit's bus initiator 730, cannot write to the management status.

[0091] One of the bus initiators 730 belongs to the third management unit (referred to as the Level 0 Manager). The Level 0 Manager contains a state that is set during manufacturing and cannot be changed. The Level 0 Manager is the system fuse box. The Level 0 Manager is configured to issue write requests to the control bus 700 to assign its state to the nodes 710 and bus targets 720 in the system. The write request includes the identifier of the Level 0 Manager as the bus initiator identifier 820. Each bus target 720 updates its state in the node management register 940 in response to determining that the bus initiator identifier 820 in the received write request to its bus target management register 910 matches the identifier of the Level 0 Manager.

[0092] The state distributed by the Level 0 manager includes the identifier of the Level 1 manager, which is stored in the bus target management register 910 of each bus target 720. The Level 1 manager can then issue a write request to update a state in the bus target management register 910 as it will be identified as a Level 1 manager by the bus target 720. The Level 1 manager can issue (via its request circuitry) a write request to write the identifier of the Level 2 manager to the bus target management register 910 of each of the targets 720. The write of the Level 2 manager's identifier to the target 720 is performed before further bus activity is permitted. Once the Level 2 manager's identifier is distributed to the target 720, the Level 2 manager can then issue (via its request circuitry) a write request to update a state in the bus target management register 910 as it will be identified as a Level 2 manager by the bus target 720.

[0093] The Level 1 manager can update the Level 1 or Level 2 permission settings stored in the Bus Target Management Register 910. The Level 2 manager can also update the Level 1 or Level 2 permission settings stored in the Bus Target Management Register 910. When an incoming write request for updating the Level 1 or Level 2 permission settings stored in register 910 is received at bus target 720, processing logic 930 identifies the bus initiator identifier 820 contained in the write request. If the bus initiator identifier 820 matches the identifier of the Level 1 manager stored in register 910, processing logic 930 updates the Level 1 or Level 2 permission settings in register 910 according to the write request.

[0094] Assuming these permission settings have not yet been written by the Level 1 manager to block access, the Level 2 manager can also update the Level 1 and Level 2 permission settings stored in register 910. In other words, the Level 2 manager can add security layers, but cannot remove security layers added by the Level 1 manager.

[0095] If a Level 1 manager has removed access permissions (i.e., changed the permission settings to indicate that a given bus initiator 730 is not allowed to access), a Level 2 manager may subsequently not re-enable that access. In other words, a Level 2 manager cannot change an access permission setting already set by a Level 1 manager to indicate that access is not allowed. This can be achieved by the following: when an incoming write request for updating the Level 1 or Level 2 permission settings stored in register 910 is received at bus target 720, the processing logic 930 identifies the bus initiator 730 that sent the request from the identifier 820 contained in the write request and checks the indication stored in register 910 to determine whether a Level 1 manager has written target access permission settings to block access. If the bus initiator identifier 820 matches the identifier of the Level 2 manager's bus initiator 730 stored in register 910, and the Level 1 manager has not set permission settings to block access, the processing logic 930 updates the permission settings in register 910 according to the write request. If the bus initiator identifier 820 does not match the identifier of either the Level 2 manager or the Level 1 manager stored in register 910, then processing logic 930 will not update the permission settings upon request and will return completion to bus initiator 730, which will send a request indicating that the request failed. If the bus initiator identifier 820 matches the identifier of the Level 2 manager stored in register 910, but the stored indication indicates that the Level 1 manager has already set permission settings to prevent access, then processing logic 930 will not update the permission settings upon request and will return completion to bus initiator 730, which will send a request indicating that the request failed.

[0096] When the system starts, the Level 1 manager first writes to the target management register 910 to define the Level 1 access permission settings. Subsequently, the Level 2 manager writes to the target management register 910 to define the Level 2 access permissions. Therefore, the Level 1 manager first defines the access permissions for the first layer. The Level 2 manager then adds its own access permission layer. If any layer of access permissions prevents the bus initiator 730 from accessing the device, the processing logic 930 prevents the bus initiator 730 from reading or writing to the storage device 920.

[0097] Access permission settings are useful for preventing certain software entities of system 1000 from having read or write access to the storage device 920 associated with the bus target of chip 2. This software could be untrusted third-party software, and restricting access to such third-party software is useful.

[0098] A sample application of the two-level management system will now be provided.

[0099] In the example, the on-chip processor is a Level 1 manager, and the hypervisor running on host 93 is a Level 2 manager. The trusted system hypervisor is provided with access to the storage device 920 associated with each bus target 720 and the bus target management register 910 of each bus target 720. In other words, Level 1 access permissions are not set to block access to the Level 2 manager. However, as a Level 2 manager, the hypervisor is free to add Level 2 access permissions to restrict access by user virtual machines running on the host. This prevents fraudulent or malicious user processes from compromising system availability for other users and from leaking data belonging to other users. The on-chip processor remains free to set Level 1 access permissions as needed, such as operator policies. For example, an operator may decide to exclude the on-chip processor from access by certain bus initiators 730 (e.g., those outside of system services).

[0100] A two-tiered control system, executed by a first management unit and a second management unit, has been described using two sets of access permissions. However, the embodiments are not limited to using two sets of access permissions; a single set of access permissions may also be used. (See reference...) Figure 5 This illustrates a set of access permission settings 1300 with this situation. A flag is stored as part of the access permission settings to indicate whether access has been blocked through the first management unit.

[0101] exist Figure 5 In the diagram, both the first access permission setting (for initiator 1) and the third access permission setting (for initiator 3) show the case where the first management unit has not modified the access permission settings. Since the first management unit has not modified the relevant access permission settings to indicate that access is not allowed, the flag indicates that the access permission can be modified by the second management unit. In this case, the settings can be modified by the second management unit. The second access permission setting (for initiator 2) shows the case where the first management unit has modified the access permission settings to indicate that access is allowed. Since the first management unit has not modified the relevant access permission settings to indicate that access is not allowed, the flag indicates that the access permission can be modified by the second management unit. In this case, the second management unit can modify the access permission settings. The fourth access permission setting (for initiator 4) shows the case where the first management unit has modified the access permission settings to indicate that access is not allowed. Since the first management unit has modified the relevant access permission settings to indicate that access is not allowed, the flag indicates that the access permission cannot be modified by the second management unit. In this case, the second management unit cannot modify the access permission settings.

[0102] exist Figure 5 In the table shown, the fifth column indicates whether access is allowed to the corresponding initiator 730 (the settings applied to that initiator 730).

[0103] refer to Figure 6 This illustrates another example of a set of permission settings 1200 that can be stored in bus target 720. The set of permission settings 1200 includes level 1 permission settings and level 2 permission settings for each of the set of bus initiators 730, and a flag associated with each setting indicating whether the setting has been set by the first management unit.

[0104] exist Figure 6 Regarding the Level 1 access permission settings associated with Initiators 1 and 3, the Level 1 management unit has not yet written these settings to prevent access. Regarding the Level 1 access permission settings associated with Initiator 4, the first management unit has already written this setting to prevent access. Therefore, the second management unit cannot change this setting. Regarding the Level 2 access permission settings associated with Initiators 1, 3, and 4, the first management unit has not yet written these settings to prevent access. Therefore, the second management unit can change any of these settings. Regarding the Level 2 access permission settings associated with Initiator 2, the first management unit has already written this setting to prevent access. Therefore, the second management unit cannot change this setting.

[0105] As described above, certain whitelisted addresses can be defined in the target management register 910. The setting of whitelisted addresses is subject to rules similar to those discussed above regarding access permission settings. Both the first and second management units can define a set of whitelisted addresses. However, the second management unit may not whitelist addresses in the storage device where the first management unit has already blocked access to that storage device. In response to determining that access to the storage device 920 containing that address has been blocked by the first management unit, processing logic 930 blocks write requests for writing to whitelisted addresses.

[0106] refer to Figure 7 The diagram illustrates a method 700 according to an embodiment of this application. It should be understood that although the steps of method 700 are shown sequentially, the time periods for performing the steps may overlap.

[0107] In S710, each of the multiple request circuits dispatches at least one of the read or write requests to the control bus for transmission to at least one of the multiple receiving circuits.

[0108] In the S720, the control bus propagates each of at least some of the requests, at least until those requests have been served by at least one of the receiving circuits.

[0109] In S730, each of the multiple receiving circuits receives one or more read or write requests dispatched by the requesting circuit.

[0110] In S740, each of the receiving circuits serves one or more of the corresponding requests by providing at least one read or write access to the storage device associated with the corresponding receiving circuit.

[0111] refer to Figure 8 This illustrates a method 800 according to an embodiment of this application. It should be understood that, according to the embodiment, the order of these steps can be determined based on… Figure 8 The order shown has changed.

[0112] In S810, multiple permission settings are stored in at least one register of the receiving circuit.

[0113] In S820, the interface of the receiving circuit receives one or more write requests from the first management unit, and in response to these one or more write requests, updates the permission settings to indicate that one or more of the requesting circuits are not allowed to access.

[0114] In S830, the interface of the receiving circuit receives one or more write requests from the second management unit, which are requests to allow one or more of the requesting circuits to access. In response to determining that the first management unit has written permission settings indicating that one or more of the requesting circuits are not allowed to access (as performed in S820), the update of the permission settings used to allow one or more of the requesting circuits to access is blocked.

[0115] In S840, the interface of the receiving circuit receives multiple read or write requests from multiple request circuits accessible via at least one control bus. Each of the read or write requests is a request to access at least one storage device associated with the receiving circuit.

[0116] In S850, in response to an instruction in the permission field that does not allow access to at least one of the request circuits that made the corresponding request, a service read or write request is blocked.

[0117] It should be understood that the above embodiments are described by way of example only.

Claims

1. A receiving circuit, the receiving circuit comprising: at least one interface configured to receive a plurality of read or write requests from a plurality of requesting circuits accessible over at least one control bus, each of the read or write requests being a request to access at least one storage device associated with the receiving circuit; at least one register configured to store a plurality of permission settings, wherein each of the plurality of permission settings indicates whether access to the at least one storage device by one of the plurality of requesting circuits is permitted; and processing circuitry configured to: in response to each of at least one of a plurality of requests received at the at least one interface to access the at least one storage device, prevent a respective read or write request from being serviced in response to an indication in the permission settings that access by one of the requesting circuits that issued the respective request is not permitted; and in response to a write request to the at least one register received from a first management unit, update a first permission setting of the permission settings to indicate that access by a first one of the requesting circuits is not permitted; subsequently, in response to a write request received from a second management unit to update the first permission setting of the permission settings to permit access by the first one of the requesting circuits, prevent the update to the first permission setting of the permission settings to permit access by the first one of the requesting circuits in response to determining that the first management unit has written the first permission setting of the permission settings to indicate that access by the first one of the requesting circuits is not permitted; and in response to a further write request received from the second management unit to update a second permission setting of the permission settings for a second one of the requesting circuits, if the first management unit has not modified the second permission setting of the permission settings to indicate that access by the second one of the requesting circuits is not permitted, permit the update to the second permission setting of the permission settings.

2. The receiving circuit of claim 1, wherein, the permission settings comprise a plurality of first level permission settings and a plurality of second level permission settings, wherein each of the plurality of requesting circuits is associated with one of the first level permission settings and one of the second level permission settings.

3. The receiving circuit of claim 2, wherein, the processing circuitry is configured to, for each of at least one of the read or write requests to the at least one storage device received from the second management unit, service the respective request in response to determining that the respective request was received from the second management unit regardless of the plurality of second level permission settings.

4. The receiving circuit of claim 2, wherein, the processing circuitry is configured to, for each of at least one of the read or write requests to the at least one storage device received from the second management unit, prevent servicing of the respective request in response to an indication in the first level permission settings that access is not permitted.

5. The receiving circuit of claim 2, wherein, in response to a determination that the request circuit from which the request originated is associated with at least one setting in either or both of the first or second hierarchical permission settings indicating that access is not permitted, servicing the respective read or write request is prevented.

6. The receiving circuit of claim 1, wherein, the processing circuit is configured to, for each of at least one of the read or write requests to the at least one storage device received from the first management unit, in response to a determination that the respective request is received from the first management unit, service the respective request regardless of the permission settings.

7. The receiving circuit of claim 1, wherein, each of the request circuits is associated with at least one processor configured to execute computer-readable instructions to generate the at least one of the plurality of read or write requests.

8. The receiving circuit of claim 1, wherein, each of the request circuits is associated with circuitry configured to generate the at least one of the plurality of read or write requests, wherein the circuitry comprises at least one of a field programmable gate array or an application integrated circuit.

9. The receiving circuit of claim 1, wherein, at least one of the plurality of request circuits is associated with the first management unit or the second management unit.

10. The receiving circuit of claim 1, wherein, the processing circuit is configured to: prior to receiving the write requests to the at least one register from the first and second management units, receive an identifier of the first management unit from a third management unit; and store the identifier of the first management unit in the at least one register, wherein, in response to the write request to the at least one register received from the first management unit, an update to one or more permission settings is performed in response to a determination that an identifier in the request matches the identifier of the first management unit in the at least one register.

11. The receiving circuit of claim 10, wherein, the third management unit stores the identifier of the first management unit in one or more fuses.

12. The receiving circuit of claim 10, wherein, the processing circuit is configured to: receive an identifier of the second management unit from the first management unit; store the identifier of the second management unit in the at least one register; and subsequently, in response to one or more further write requests to the at least one register received from the second management unit, update the one or more permission settings in response to a determination that an identifier in the request matches the identifier of the second management unit in the at least one register.

13. The receiving circuit of claim 1, wherein, the processing circuit is configured to, in response to each of at least one of the requests received at the at least one interface for access to the at least one storage device, cause a read or write to be performed at at least one address in the at least one storage device indicated in the respective request.

14. The receiving circuit of claim 1, wherein, the at least one register comprises an indication of at least one address to which one or more access permissions do not apply, wherein the processing circuit is configured to, in response to a determination that one of the received requests indicates an address that matches the indication of at least one address to which the access permissions do not apply, service the request.

15. The receiving circuit of claim 14, wherein, The processing circuit is configured to write the indication of at least one address for which the one or more access permissions do not apply into the at least one register in response to one or more write requests received from at least one of the first and second management units.

16. The receiving circuit of claim 1, wherein, In response to each of at least one of the requests received at the at least one interface for accessing the at least one storage device, an indication that access is not allowed in response to an indication in one or more permission settings to send a packet indicating a failure of the request to a request circuit from which the respective request originated.

17. The receiving circuit of any one of claims 1 to 16, wherein, The receiving circuit is adapted for integration into an integrated circuit.

18. An integrated circuit comprising the receiving circuit of claim 17, the integrated circuit being configured to function as an accelerator subsystem of a host system.

19. The integrated circuit of claim 18, wherein, The second management unit is associated with a hypervisor running on the host system.

20. The integrated circuit of claim 18 or claim 19, comprising a plurality of processing units configured to execute computer readable instructions to perform operations on data, wherein, Each of the plurality of processing units comprises a control register, wherein the at least one storage device comprises the control registers of the processing units.

21. A method implemented in a receiving circuit, the method comprising: storing a plurality of permission settings, wherein each of the plurality of permission settings indicates whether access to at least one storage device associated with the receiving circuit is allowed for one of a plurality of request circuits; in response to a write request to the at least one register received from a first management unit, updating a first one of the permission settings to indicate that access is not allowed for a first one of the request circuits; subsequently, in response to a write request received from a second management unit to update the first one of the permission settings to allow access for the first one of the request circuits, preventing the update to the first one of the permission settings to allow access for the first one of the request circuits in response to determining that the first management unit has written the first one of the permission settings to indicate that access is not allowed for the first one of the request circuits; and receiving a plurality of read or write requests from a plurality of request circuits accessible over at least one control bus, each of the read or write requests being a request for accessing the at least one storage device associated with the receiving circuit; in response to each of at least one of a plurality of requests for accessing the at least one storage device associated with the receiving circuit, preventing a respective read or write request from being serviced in response to an indication in the permission settings that access is not allowed for one of the request circuits that issued the respective request; and in response to a further write request received from the second management unit to update a second one of the permission settings for a second one of the request circuits, allowing the update to the second one of the permission settings in case the first management unit has not modified the second one of the permission settings to indicate that access is not allowed for the second one of the request circuits.

22. A computer program product comprising computer readable instructions which, when executed by a processor of a receiving circuit, cause the processor to perform the method of claim 21.

Images