Firewall for On-Chip Signaling

Abstract

An on-chip firewall circuit for providing secure on-chip communications is disclosed. The firewall circuit includes a configurable table of port IDs, with configurable settings for each port ID to provide the corresponding port ID with either open or restricted access to components of a secure enclave (SE) module. If access is restricted, commands are rerouted to a portion of secure memory within the SE module, where they can only be read via a secure processing device within the SE module. The secure processing device may require further validation of the port ID before executing commands stored within the secure memory. In this manner, non-secure devices from outside the SE module may be configured to not directly access any of the components within the SE module.

Description

[Background technology]

[0001]

[0001] Semiconductor design applications increasingly use several chips and / or several different hardware modules together, either on the same chip in a system-on-chip (SoC) type environment or across different chips (chipsets). Signals typically pass between components within a given chip with minimal security requirements. However, this opens the possibility that harmful or otherwise unauthorized commands can be issued from within the chip, potentially compromising sensitive data stored on or associated with the chip. Thus, there are many important issues regarding protection of the integrity of the hardware modules and / or data of complex integrated circuit chips.

[0002]

[0002] Features and advantages of embodiments of the claimed subject matter will become apparent upon reading the following detailed description and upon reference to the drawings. [Brief description of the drawings]

[0003] [Figure 1]

[0003] FIG. 1 illustrates a block diagram of an exemplary system-level chip environment including a secure enclave (SE) circuit, according to one embodiment of the present disclosure. [Diagram 2]

[0004] FIG. 1 illustrates a block diagram of an exemplary SE circuit according to an embodiment of the present disclosure. [Diagram 3]

[0005] 3 illustrates a block diagram of an example bridge core including both a firewall circuit and a master control circuit for use within the SE circuit of FIG. 2 in accordance with some embodiments of the present disclosure. [Figure 4]

[0006] 4 highlights various operations performed by the SE circuitry of FIGS. 2 and 3 upon receipt of a restricted command, in accordance with some embodiments of the present disclosure. FIG. [Diagram 5]

[0007] 1 is a flowchart of an exemplary method for providing secure data transfer within an integrated circuit chip or chipset according to some embodiments of the present disclosure. [Figure 6]

[0008] 4 illustrates a block diagram of an example computing platform that may include the SE circuitry of FIG. 2 or FIG. 3 in accordance with an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0004]

[0009] The following detailed description continues with reference to exemplary embodiments, many of which alternatives, modifications and variations will become apparent in light of this disclosure.

[0005]

[0010] An on-chip firewall circuit for providing secure on-chip communication is disclosed. Such a circuit may be used, for example, within a secure enclave (SE) module that includes hardware and memory device(s) that provide a degree of security against malicious activity. A secure memory within the SE module may be used to store sensitive data. According to some embodiments, the firewall circuit includes a configurable table of port IDs, with configurable settings per port ID to provide the corresponding port ID with either open or restricted access to the components of the SE module. If restricted access is provided for a command from a given port ID, the command is rerouted to a portion of the secure memory within the SE module, where it may be read only via a secure processing device within the SE module. The secure processing device may require further validation of the port ID before executing the command stored within the secure memory. In the case of a request for data from the secure memory, the secure processor fetches the requested data and writes the data out to the non-secure memory. In this manner, a non-secure device from outside the SE module may be configured to not directly access any of the components within the SE module. Additionally, the table of port IDs and the classification of each port ID as having either restricted or open access to the SE module can be reconfigured to provide chip-level adaptability and flexibility. Numerous embodiments and variations are contemplated in light of the present disclosure.

[0006] [Brief overview]

[0011] A system-on-chip (SoC) design may use one or more signal buses to route signals between various on-chip modules and circuit blocks within a given chip. Executing such on-chip commands between components of the same system is typically associated with little or no security since such commands are considered secure since they originate from the same system environment. However, this is increasingly not the case since different components within a system-level integrated circuit chip or chipset may be compromised by external malicious actors who seek to access secure information, install viruses, disrupt functionality, and / or harm any of the SoC circuitry. Higher personal computer level systems are protected from such attacks, typically with firewalls to prevent unwanted access to personal computers via the Internet. However, no such firewall protection exists at the chip level to provide protection between circuit blocks of the same SoC or across combined SoCs.

[0007]

[0012] Thus, according to one embodiment of the present disclosure, there is provided herein an on-chip firewall circuit that acts as a gatekeeper to protect the secure components of the SoC from one or more non-secure components of the SoC. In some such embodiments, the firewall circuit includes hardware that is definable using a hardware description language (HDL) such as Very High Speed ​​Integrated Circuit Hardware Description Language (VHDL) or Verilog. The firewall circuit may be included as part of a secure enclave (SE) circuit that includes at least a secure hardware block such as a secure processor and a secure memory. Access to any of the components of the SE circuit from any non-secure device outside the SE circuit is designed to go through the firewall circuit that is configured to determine whether or not a request received from the non-secure device should be allowed. According to some embodiments, the request may be either an access denial, an open access permission, or a limited access permission. When the limited access permission is granted, the non-secure request is instead processed by a secure processor in the SE circuit (assuming further verification is approved), so that the non-secure device is not provided access to other parts of the SE circuit except for the firewall circuit. Numerous embodiments and variations are understood in light of the present disclosure.

[0008]

[0013] In one embodiment, a method of providing secure data transfer within an integrated circuit chip or chipset includes receiving a command issued from a processing device within the integrated circuit chip or chipset, comparing a source ID associated with the processing device to a plurality of stored IDs, and identifying the source ID as having restricted access or open access in response to the source ID being found among the plurality of stored IDs. In response to the source ID having restricted access, the method includes redirecting an address associated with the command to a portion of secure memory, reading the portion of secure memory using the secure processing device, and executing the command in the portion of secure memory using the secure processing device, and in response to the source ID having open access, the method includes executing the command using the processing device that issued the command.

[0009]

[0014] In another embodiment, the firewall circuit includes a stub circuit configured to receive an unsecure on-chip signal from an unsecure source and identify a source ID corresponding to the unsecure on-chip signal. The firewall circuit further includes a memory configured to hold at least one stored ID, and a state machine configured to transmit the secure on-chip signal to the secure source in response to the secure processing device verifying an access right associated with the unsecure on-chip signal. The access right is verified when the source ID corresponds to at least one of the stored IDs.

[0010]

[0015] In another embodiment, a SoC includes a network interface configured to route signals between a plurality of on-chip hardware blocks, a firewall circuit coupled to the network interface and configured to receive a non-secure on-chip signal from a non-secure source and transmit a secure on-chip signal via the network interface to a secure source coupled to the network interface, a secure processing device coupled to the network interface, and a secure memory coupled to the network interface. The firewall circuit includes a stub circuit configured to receive the non-secure on-chip signal from the non-secure source and identify a source ID corresponding to the non-secure on-chip signal. The firewall circuit further includes a memory configured to hold at least one stored ID, and a state machine configured to transmit the secure on-chip signal to the secure source in response to the secure processing device verifying an access right associated with the non-secure on-chip signal. The access right is verified when the source ID corresponds to at least one of the stored IDs.

[0011] [On-chip signaling environment]

[0016] 1 illustrates an exemplary digital signaling environment 100 according to one embodiment. Digital signaling environment 100 may represent various circuit blocks or modules within an SoC and / or multi-chip package. Thus, the various circuit blocks described herein may be implemented using integrated circuits fabricated on a single chip, across multiple chips in the same chip package, or across chips in different chip packages.

[0012]

[0017] The digital signaling environment 100 may include some form of signal bus 102 designed to route signals between various circuit blocks. Various circuit blocks, such as a processor 104, a memory 106, or network I / O circuitry 108, may be coupled to one or more ports of the signal bus 102. Any other circuitry or other signal buses may also be coupled to the signal bus 102 via bus connections 110.

[0013]

[0018] Processor 104 may represent any number of processing devices implemented as any number of processor cores. Processor 104 may be any type of processor, such as, for example, a microprocessor, an embedded processor, a digital signal processor (DSP), a graphics processor (GPU), a network processor, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or other device configured to execute code.

[0014]

[0019] Memory 106 may be implemented using any suitable type of digital storage including, for example, flash memory and / or random access memory (RAM). In some embodiments, memory 106 may include various layers of a standard memory hierarchy and / or a standard memory cache. Memory 106 may be implemented as a volatile memory device, such as, but not limited to, a RAM, a dynamic RAM (DRAM), or a static RAM (SRAM) device.

[0015]

[0020] The network I / O 108 may represent any type of wired and / or wireless network interface designed to send and receive signals over a network. Wired communications may conform to existing (or future developed) standards, such as, for example, Ethernet. Wireless communications may conform to existing (or future developed) standards, such as, for example, LTE (Long Term Evolution), Wireless Fidelity (Wi-Fi), Bluetooth, and / or cellular communications, including Near Field Communications (NFC). Exemplary wireless networks include, but are not limited to, wireless local area networks, wireless personal area networks, wireless metropolitan area networks, cellular networks, and satellite networks.

[0016]

[0021] According to some embodiments, each of the processor 104, memory 106, network I / O 108, and any other devices coupled to the bus 102 via the bus connection 110 may be designated as a non-secure source. A secure enclave (SE) module 112 may also be coupled to the bus 102, where various circuit components within the SE module are designated as secure sources (as represented by the bold lines). A secure source or secure device may be any circuit or device that can be fully trusted, while a non-secure source or device may be any circuit or device whose security may be compromised and therefore cannot be fully trusted. A non-secure source within the signaling environment 100 may wish to access one or more of the components within the SE module 112 (e.g., the secure memory). Typically, rudimentary security may be imposed in such situations to basically ensure that a request is received from the correct port of the bus 102. However, more security may be required to ensure that a compromised non-secure source connected to the bus 102 is identified and denied access to the SE module 112.

[0017]

[0022] 2 illustrates a more detailed block diagram of SE module 112, according to some embodiments. SE module 112 may include various hardware devices or circuits coupled to a network on chip (NOC) 200. For example, SE module 112 may include a firewall circuit 202, a secure processor 204, a secure memory 206, an electronic fuse 208, and a master control circuit 210, each coupled to NOC 200.

[0018]

[0023] According to some embodiments, NOC 200 is a router-based packet-switched network that can span both synchronous and asynchronous clock domains. In other embodiments, NOC 200 uses non-clocked asynchronous logic. In either case, NOC 200 can allow each coupled device to operate in its own clock domain. In some other embodiments, a standard signal bus is used in place of NOC 200.

[0019]

[0024] According to some embodiments, the firewall circuit 202 receives various commands, represented as untrusted master signals (e.g., NTr master signals), from one or more non-secure devices. These non-secure commands may be requests to read data stored in the secure memory 206 or may be requests to modify some functionality within the SE module 112, such as modifying any of the digital fuses within the electronic fuses 208. Thus, the firewall circuit 202 acts as a kind of gatekeeper to ensure that any command received from a non-secure device is first verified before being executed. This verification process may include allowing the non-secure device to have open access to one or more devices within the SE module 112, or allowing limited access for the non-secure device by executing the received command instead using the secure processor 204 of the SE module 112. Further details of the firewall circuit 202 are provided with reference to FIG. 3. Each of the secure processor 204 and the secure memory 206 may have an architecture similar to the processor 104 and the memory 106, respectively.

[0020]

[0025] According to some embodiments, the electronic fuse 208 represents a digitally configurable circuit that may be used to set a secret key code. Thus, in some embodiments, the state of the electronic fuse 208 may be used to set authentication parameters of a particular non-secure device. Other uses of the electronic fuse 208 will be appreciated.

[0021]

[0026] The master control circuit 210 represents the coordination and transmission of on-chip master signals sent by the SE module 112 to non-secure slave devices, according to some embodiments. Such signals are represented in FIG. 2 as untrusted slave signals (e.g., NTr slave signals). For example, the secure processor 204 may be instructed to retrieve data from the secure memory 206 and write the data to a non-secure device (such as memory 106). A write command may be sent from the SE module 112 via the master control circuit 210. In some embodiments, the master control circuit 210 is part of the firewall circuit 202. The master control circuit 210 and the firewall circuit 202 may collectively be referred to as a bridge core.

[0022]

[0027] 3 illustrates a block diagram of an exemplary bridge core 300 including both a firewall circuit 202 and a master control circuit 210, according to one embodiment. Various signals entering and leaving bridge core 300 are designated as either secure signals (within the secure domain of SE module 112) or non-secure signals (in the non-secure domain outside of SE module 112). According to some embodiments, firewall circuit 202 acts as an untrusted bridge circuit and master control circuit 210 acts as a trusted bridge circuit.

[0023]

[0028] According to some embodiments, a command is received from one or more of the non-secure devices (e.g., an NTr master signal) at a first stub circuit 302 in the firewall circuit 202. As used herein, a stub circuit is used to perform signal conditioning of signals passing between the non-secure domain and the secure domain. In some examples, the first stub circuit 302 is configured for asynchronous clocking. According to one embodiment, the first stub circuit 302 is configured to determine an ID associated with the received command. The ID may be related to the port on which the command is received on a system bus, such as the bus 102. In one example, the first stub circuit 302 strips the ID bits from the received command and passes the ID to be compared to a stored ID in a look-up table (LUT) 304. The comparison may be performed using the secure processor 204. Other logical structures used to store IDs may be used in place of the LUT 304. According to some embodiments, the first stub circuit 302 may be implemented as a combination of various logic gates and incorporated into its own application specific integrated circuit (ASIC).

[0024]

[0029] According to some embodiments, the LUT 304 stores a given number of local device IDs that may correspond to one or more known ports of the bus 102. The access rights for each of the stored IDs may be reconfigured using the secure processor 204. These access rights may include "open" access or "restricted" access. If the received ID is not found in the list of stored IDs, the received command may be blocked from accessing any part of the SE module 112 and a response may be provided to indicate that the access has been blocked. As mentioned above, open access may be given to an ID that is secure, and thus the received command is given access to one or more devices in the SE module 112. For example, a read command provided by a processor external to the SE module 112 may be given the ability to directly access the secure memory 206 if it is given open access. Restricted access may be given to an ID that represents a device or port that may be compromised and therefore not fully trusted. As a result, such a command is not given the ability to directly access any of the devices in the SE module 112. Instead, restricted commands are intercepted and written to a portion of secure memory 206 where such commands may then be accessed and executed by secure processor 204. Before executing the redirected command, secure processor 204 may perform any further authentication procedures, such as public / private keying, on the received command. For example, a restricted read command (e.g., requesting data stored in secure memory 206) provided by a processor external to SE module 112 will not be allowed to access secure memory 206, but will instead be redirected to be written to a dedicated portion of secure memory 206. The read command is then accessed and executed by secure processor 204 to read the data from secure memory 206. The data is sent out (via master control circuit 210) to be written to a non-secure memory location.In this manner, the non-secure processor can access requested data via the non-secure memory without ever being allowed direct access to the data in the SE module 112 .

[0025]

[0030] According to some embodiments, the designation of open vs. restricted access for a given ID is provided as a bit or set of bits that can be used to indicate that access is restricted, i.e., according to one example, if a given bit or set of bits is set, access is restricted, otherwise access is open.

[0026]

[0031] According to some embodiments, a state machine 306 receives the requested command from the first stub circuit 302 along with the access rights and LUT entry number associated with the command. Depending on whether the access rights are open or restricted, the state machine 306 directs the command to the appropriate location in the SE module 112 as a trusted slave signal. For example, a command classified as open may be routed directly to the requested device in the SE module 112. However, a command classified as restricted is routed to an address in the secure memory 206. The rerouted address may be formed according to some embodiments by a concatenation of bits from a restricted base address (RBA) register, an ID associated with the command, and a lower address from a non-secure device. According to some embodiments, one of the bits of the rerouted address may be used to provide a doorbell request represented by the doorbell 308. According to some embodiments, the doorbell request serves as an interrupt signal to the secure processor 204, alerting the secure processor 204 that a command with restricted access has been written to the secure memory 206, along with the location of the command within the secure memory 206. In this way, the secure processor 204 can be instructed to execute the command promptly.

[0027]

[0032] According to some embodiments, bridge core 300 includes one or more registers 310 designed to be reconfigurable and accessible by secure processor 204 via one or more config signals. Secure processor 204 may reconfigure and access various operations of bridge core 300 via any of registers 310. In one example, a restricted base address (RBA) register may be used to specify both the high and low order bits in a redirected address, as shown in the example table below.

[0028] [Table 1]

[0029] [Table 2]

[0030]

[0033] In the above example registers, the width of the restricted address is 64 bits wide. The first RBA register uses the lowest two bits to determine the restricted address window size, with bits 14-31 forming part of the address. The second RBA register uses each of its 32 bits to form the high order 32 bits of the address. Other bit arrangements are possible, this is just one example of using two registers to set the redirected address for a restricted command.

[0031]

[0034] In some embodiments, registers 310 include LUT registers for providing ID entries and their associated access rights. An example of such a LUT register is provided below.

[0032] [Table 3]

[0033]

[0035] In this example, the least significant bit indicates whether the entry in the LUT is valid, and the next bit indicates whether the ID entry has restricted access (set as 1) or open access (set as 0). The various stored ID matches are provided in the remaining bits in the register.

[0034]

[0036] Various other registers may also be used to configure other aspects of bridge core 300, such as the total number of address bits passing across trusted bridges, the total number of address bits passing across untrusted bridges, the width of the data bus associated with received on-chip command signals, the width of the ID field used within SE module 112 across NOC 200, and the width of the ID field used across bus 102 external to SE module 112, to name a few. It should be understood that register 310 may be included within firewall 202 or may be considered a separate module from bridge core 300.

[0035]

[0037] According to some embodiments, trusted master signals received from within the SE module 112 (such as a request to write data to an unsecure memory device external to the SE module 112) pass through a second stub circuit 312 before being sent as an on-chip untrusted slave signal to one or more unsecure devices. The second stub circuit 312 may operate in a similar asynchronous manner as the first stub circuit 302. According to some embodiments, the second stub circuit 312 may be implemented as a combination of various logic gates and incorporated into its own application specific integrated circuit (ASIC).

[0036]

[0038] 4 illustrates a block diagram highlighting some of the operations that occur in the SE module 112 during receipt of a restricted command, according to one embodiment. An untrusted master signal is received at a slave controller 402, which may be similar to the untrusted bridge or first stub circuit 302 described above. The slave controller 402 is designated as a "slave" because it represents a device that receives a command issued by another device. In one example, the untrusted master signal represents a read request issued by a non-secure processor for data stored in the secure memory 206 of the SE module 112.

[0037]

[0039] The slave controller 402 passes the received command to a decoder block 404, which is designed to strip the ID bits from the command and use those bits as part of a redirected address for storage as a message 406 in memory. According to some embodiments, the message is stored in the secure memory 206 of the SE module 112. Note that according to some embodiments, redirecting the command to be written to a dedicated portion of the secure memory occurs in response to the ID associated with the command being flagged as restricted.

[0038]

[0040] According to some embodiments, writing the message 406 in memory provides a doorbell interrupt signal to the secure CPU 408. In response, the secure CPU 408 reads the message left for it in memory and executes the command (assuming any further authentication procedures have passed). In the illustrated example, the command left in memory is a command to read data held in the secure memory 206. The secure CPU 408 therefore retrieves the requested data and transmits it to the slave unsecured memory device as an untrusted slave signal via the master controller 410. The master controller 410 is designated as a "master" because it represents a device that issues commands to another device. According to some embodiments, the master controller 410 is similar to the trusted bridge or second stub circuit 312 described above.

[0039] [method]

[0041] FIG. 5 illustrates an example flow diagram of a method 500 of using a firewall to provide secure on-chip communication between devices, according to one embodiment. The method 500 may be performed in whole or in part by, for example, the SE module 112 and / or the firewall circuit 202. The operations, functions, or actions described in each block of the example method 500 may be stored as computer-executable instructions in a non-transitory computer-readable medium, such as a memory and / or data storage of a computing system. In some embodiments, a circuit and / or circuit module configured to perform the operations, functions, or actions described in each block of the example method 500 may be implemented using a hardware programming language, such as VHDL or Verilog. As will be further appreciated in light of the present disclosure, for this and other processes and methods disclosed herein, the functions performed in the method 500 may be performed in a different order. Additionally or alternatively, two or more operations may be performed simultaneously or otherwise overlappingly. It should be noted that all operations of method 500 can be performed on-chip or in the same SoC package using all on-chip signals such as AXI signals or Wishbone signals, to name a few. AXI refers to the Advanced eXtensible Interface and is part of a standard microcontroller bus architecture that defines a parallel high-performance, synchronous, high-frequency, multi-master, multi-slave communication interface designed for on-chip communication. Similarly, Wishbone refers to an open-source hardware computer bus for on-chip communication.

[0040]

[0042] Method 500 begins at block 502, where a command is received from a non-secure source. According to some embodiments, the command is received at a firewall circuit within the SE module. The command may be an on-chip signal, such as an AXI signal. In some examples, the received command is a request for data from a secure memory within the SE module. In some other examples, the received command is a request to change the state of one or more registers, fuses, and / or memory blocks within the SE module. In either case, the command is received from a device external to the SE module and is therefore designated as having been received from a non-secure source, according to some embodiments.

[0041]

[0043] According to one embodiment, the source ID associated with the received command is compared to a list of stored IDs in block 504. The source ID may be any number of bits long and may relate to the port of the system or chip bus from which the command was issued. In some embodiments, the source ID is represented by four bits allowing for 16 different source ID combinations.

[0042]

[0044] The various stored IDs may be arranged in a look-up table (LUT) or other type of logical configuration that also includes an indication of whether each of the stored IDs has restricted or open access to the SE module 112. In some embodiments, one or more bits are assigned to each ID entry to indicate whether the associated ID has restricted or open access to the SE module. In some embodiments, one or more bits may also be used to indicate that the listed ID has blocked access (e.g., denied entry to the SE module). The source ID may be compared to the stored IDs, for example, using a secure processor in the SE module.

[0043]

[0045] According to one embodiment, at block 506, a determination is made as to whether the source ID is found among the stored IDs. If the source ID is not found among the stored IDs, then at block 508, the command associated with the source ID is rejected. According to some embodiments, a message is sent back to the source that issued the command to indicate that access to the SE module has been blocked. The message can be as simple as a few bits coded to indicate the blocked request.

[0044]

[0046] If the source ID is found among the stored IDs, then at block 510 a determination is made as to whether the matching stored ID is flagged as restricted. As discussed above, one or more bits may be assigned to designate whether the stored ID is restricted. In one example, if the one or more bits are not set to indicate restricted access, then access is open and the method proceeds to block 512. The command is executed via the non-secure device that issued the command to either read data from secure memory in the SE module or reconfigure some aspect of the SE module.

[0045]

[0047] If the matching stored ID is flagged as restricted, then the command is redirected to a portion of secure memory at block 514. The memory address used for the redirected command may be, according to some embodiments, a concatenation of bits from a restricted base address (RBA) register, the source ID associated with the command, and the low order address bits from the non-secure device that issued the command. According to some embodiments, a secure processor in the SE module may be alerted that a command has been written to secure memory using an interrupt signal (e.g., a doorbell). The secure processor may also be provided with the address in secure memory where the command was stored.

[0046]

[0048] In block 516, the secure processor accesses the command stored in the secure memory. As part of this operation, or immediately prior to this operation, the secure processor may perform any number of other authentication techniques to verify the authenticity of the source that issued the command. These authentication techniques may include public / private keying, message formats, or any type of password, to name a few.

[0047]

[0049] At block 518, the secure processor executes the command originally issued by a non-secure source external to the SE module. In this manner, a non-secure source with limited access is blocked from directly accessing any portion of the SE module, and instead, the command is executed using the secure processor within the SE module. In some examples, the command is a request for data, in which case the secure processor reads the requested data and writes the data to a non-secure memory device to be accessed by the non-secure source external to the SE module. In some other examples, the command is a request to reconfigure a portion of the SE module (e.g., reconfigure one or more electronic fuses or other gate logic), in which case the reconfiguration is performed using the secure processor within the SE module.

[0048] [Exemplary Computing Platform]

[0050] FIG. 6 illustrates an exemplary computing platform 600 that may include the SE module 112, according to certain embodiments of the present disclosure. In some embodiments, the computing platform 600 may host or otherwise be incorporated into a personal computer, a workstation, a server system, a laptop computer, an ultra laptop computer, a tablet, a touchpad, a portable computer, a handheld computer, a palmtop computer, a personal digital assistant (PDA), a mobile phone, a combination mobile phone and PDA, a smart device (e.g., a smartphone or a smart tablet), a mobile internet device (MID), a messaging device, a data communication device, an imaging device, a wearable device, an embedded system, and the like. In certain embodiments, any combination of different devices may be used. As mentioned above, the SE module 112 may include an on-chip firewall circuit configured to control access rights to the SE module for any other components outside the SE module.

[0049]

[0051] In some embodiments, the computing platform 600 may comprise any combination of a processor 602, a memory 604, an SE module 112, a network interface 606, an input / output (I / O) system 608, a user interface 610, and a storage system 612. In some embodiments, the SE module 112 includes at least its own secure processor and secure memory. As will be further appreciated, buses and / or interconnects are also provided to enable communication between the various components listed above and / or other components not shown. The computing platform 600 may be coupled to a network 616 via the network interface 606 to enable communication with other computing devices, platforms, or resources. Other components and functions not reflected in the block diagram of FIG. 6 will become apparent in light of this disclosure, and it will be understood that other embodiments are not limited to any particular hardware configuration.

[0050]

[0052] The processor 602 may be any suitable processor and may include one or more co-processors or controllers to assist in controlling and processing operations associated with the computing platform 600. In some embodiments, the processor 602 may be implemented as any number of processor cores. The processor (or processor core) may be any type of processor, such as, for example, a microprocessor, an embedded processor, a digital signal processor (DSP), a graphics processor (GPU), a network processor, a field programmable gate array, or other device configured to execute code. The processor may be a multi-threaded core in that it may include two or more hardware thread contexts (or "logical processors") per core.

[0051]

[0053] The memory 604 may be implemented using any suitable type of digital storage including, for example, flash memory and / or random access memory (RAM). In some embodiments, the memory 604 may include various standard tiers of memory hierarchy and / or standard memory caches. The memory 604 may be implemented as a volatile memory device, such as, but not limited to, a RAM, a dynamic RAM (DRAM), or a static RAM (SRAM) device. The storage system 612 may be implemented as a non-volatile storage device, such as, but not limited to, one or more of a hard disk drive (HDD), a solid state drive (SSD), a universal serial bus (USB) drive, an optical disk drive, a tape drive, an internal storage device, an external storage device, a flash memory, a battery-backed synchronous DRAM (SDRAM), and / or a network-accessible storage device. In some embodiments, the storage system 612 may comprise techniques for increasing storage performance protection enhancements for valuable digital media when multiple hard drives are included.

[0052]

[0054] The processor 602 may be configured to execute an operating system (OS) 614, which may comprise any suitable operating system, such as Google Android (Google Inc., Mountain View, Calif.), Microsoft Windows (Microsoft Corp., Redmond, Wash.), Apple OS X (Apple Inc., Cupertino, Calif.), Linux, or a real-time operating system (RTOS). As will be understood in light of this disclosure, the techniques provided herein may be implemented without regard to the particular operating system provided with computing platform 600, and thus may be implemented using any suitable existing or later developed platform.

[0053]

[0055] The network interface 606 may be any suitable network chip or chipset that enables wired and / or wireless connections between the computing platform 600 and / or other components of the network 616, thereby enabling the computing platform 600 to communicate with other local and / or remote computing systems, servers, cloud-based servers, and / or other resources. The wired communications may conform to existing (or future developed) standards, such as, for example, Ethernet. The wireless communications may conform to existing (or future developed) standards, such as, for example, cellular communications, including LTE (Long Term Evolution), Wireless Fidelity (Wi-Fi), Bluetooth, and / or Near Field Communications (NFC). Exemplary wireless networks include, but are not limited to, wireless local area networks, wireless personal area networks, wireless metropolitan area networks, cellular networks, and satellite networks.

[0054]

[0056] The I / O system 608 may be configured to interface various I / O devices with other components of the computing platform 600. The I / O devices may include, but are not limited to, a user interface 610. The user interface 610 may include devices (not shown), such as, for example, a display element, a touchpad, a keyboard, a mouse, and speakers. The I / O system 608 may include a graphics subsystem configured to process images for rendering on a display element. The graphics subsystem may be, for example, a graphics processing unit or a visual processing unit (VPU). An analog or digital interface may be used to communicatively couple the graphics subsystem with the display element. For example, the interface may be any of High Definition Multimedia Interface (HDMI), DisplayPort, Wireless HDMI, and / or any other suitable interface using wireless high definition compliant techniques. In some embodiments, the graphics subsystem may be integrated into the processor 602 or any chipset of the computing platform 600.

[0055]

[0057] It will be appreciated that in some embodiments, the various components of computing platform 600 may be combined or integrated into a system-on-chip (SoC) architecture. In some embodiments, the components may be hardware components, firmware components, software components, or any suitable combination of hardware, firmware, or software.

[0056]

[0058] In various embodiments, computing platform 600 may be implemented as a wireless system, a wired system, or a combination of both. When implemented as a wireless system, computing platform 600 may include components and interfaces suitable for communicating over a wireless shared medium, such as, for example, one or more antennas, transmitters, receivers, transceivers, amplifiers, filters, control logic, etc. Examples of wireless shared media may include portions of a wireless spectrum, such as the radio frequency spectrum. When implemented as a wired system, computing platform 600 may include components and interfaces suitable for communicating over a wired communication medium, such as, for example, input / output adapters, physical connectors for connecting the input / output adapters with corresponding wired communication media, network interface cards (NICs), disk controllers, video controllers, audio controllers, etc. Examples of wired communication media may include wires, cable metal leads, printed circuit boards (PCBs), backplanes, switch fabrics, semiconductor materials, twisted pair wires, coaxial cables, optical fibers, etc.

[0057]

[0059] Some of the embodiments described herein may be implemented using, for example, a machine-readable medium or article that may store instructions or sets of instructions that, when executed by a machine, may cause the machine to perform methods and / or operations according to the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, process, or the like, and may be implemented using any suitable combination of hardware and / or software. A machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium, and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disk read only memory (CD-ROM), recordable compact disk (CD-R) memory, rewritable compact disk (CD-RW) memory, optical disk, magnetic medium, magneto-optical medium, removable memory cards or disks, various types of digital versatile disks (DVDs), tapes, cassettes, or the like. Instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, and the like, implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

[0058]

[0060] Unless otherwise specified, terms such as "processing," "computing," "calculating," "determining," or the like may be understood to refer to actions and / or processes of a computer or computing system, or similar electronic computing device, that manipulates and / or transforms data represented as physical quantities (e.g., electrons) in registers and / or memory units of the computer system into other data that is similarly represented as physical quantities in registers, memory units, or other such information storage, transmission, or display of the computer system. Embodiments are not limited in this context.

[0059]

[0061] The term "circuit" or "circuitry", as used in any embodiment herein, is a functional device and may comprise, for example, alone or in any combination, hardwired circuitry, programmable circuitry such as one or more computer processors with one or more individual instruction processing cores, state machine circuitry, and / or firmware that stores instructions executed by the programmable circuitry. The circuitry may include a processor and / or controller configured to execute one or more instructions to perform one or more operations described herein. The instructions may be embodied, for example, as an application, software, firmware, etc. configured to cause the circuitry to perform any of the aforementioned operations. The software may be embodied as a software package, code, instructions, instruction sets, and / or data recorded in a computer readable storage device. The software may be embodied or implemented to include any number of processes, which in turn may be embodied or implemented to include any number of threads, etc. hierarchically. The firmware may be embodied as hard-coded (e.g., non-volatile) code, instructions or instruction sets, and / or data in a memory device. The circuitry may be embodied as circuitry that collectively or individually forms part of a larger system, such as an integrated circuit chip or chipset, an application specific integrated circuit (ASIC), a system on a chip (SoC), a desktop computer, a laptop computer, a tablet computer, a server, a smartphone, etc. Other embodiments may be implemented as software that may be stored on a machine-readable medium and executed by a programmable control device. As described herein, various embodiments may be implemented using hardware elements, software elements, or any combination thereof.Examples of hardware elements may include processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Thus, a circuit or circuitry is a functional physical apparatus that may be either integrated circuitry, printed circuit board circuitry, gate level logic, analog and / or digital circuitry, one or more programmed processors or processing entities (e.g., a combination of instructions and one or more processors configured to execute those instructions).

[0060] Further Exemplary Embodiments

[0062] The following examples relate to further embodiments, from which numerous permutations and configurations are apparent.

[0061]

[0063] Example 1 is a firewall circuit including a stub circuit configured to receive an unsecure on-chip signal from an unsecure source and identify a source ID corresponding to the unsecure on-chip signal. The firewall circuit further includes a memory configured to hold at least one stored ID, and a state machine configured to transmit a secure on-chip signal to a secure source in response to the secure processing device verifying an access right associated with the unsecure on-chip signal. The access right is verified when the source ID corresponds to at least one of the stored IDs.

[0062]

[0064] Example 2 includes the subject matter of Example 1, and the non-secure on-chip signal and the secure on-chip signal are AXI (Advanced eXtensible Interface) signals or Wishbone signals.

[0063]

[0065] Example 3 includes the subject matter of example 1 or 2, wherein the non-secure on-chip signal comprises an instruction to read one or more addresses of the secure memory.

[0064]

[0066] Example 4 includes the subject matter of any one of Examples 1 to 3, and the state machine is configured to send a secure on-chip signal to a portion of the secure memory in response to the access right being a restricted access right.

[0065]

[0067] Example 5 includes the subject matter of example 4, further comprising a doorbell register coupled to the state machine and configured to send an interrupt signal to the secure processing device to instruct the secure processing device to read a portion of the secure memory.

[0066]

[0068] Example 6 includes the subject matter of any one of examples 1-5, wherein the at least one stored ID is arranged in a look-up table (LUT).

[0067]

[0069] Example 7 includes the subject matter of example 6, in which the LUT includes access rights associated with each of the at least one stored ID.

[0068]

[0070] Example 8 is a system on chip (SoC) including a network interface configured to route signals between a plurality of on-chip hardware blocks, a firewall circuit coupled to the network interface and configured to receive a non-secure on-chip signal from a non-secure source and transmit a secure on-chip signal via the network interface to a secure source coupled to the network interface, a secure processing device coupled to the network interface, and a secure memory coupled to the network interface. The firewall circuit includes a stub circuit configured to receive the non-secure on-chip signal from the non-secure source and identify a source ID corresponding to the non-secure on-chip signal. The firewall circuit further includes a memory configured to hold at least one stored ID, and a state machine configured to transmit the secure on-chip signal to the secure source in response to the secure processing device verifying an access right associated with the non-secure on-chip signal. The access right is verified when the source ID corresponds to at least one of the stored IDs.

[0069]

[0071] Example 9 includes the subject matter of example 8, wherein the secure enclave (SE) module comprises a network interface, a firewall circuit, a secure processing device, and a secure memory.

[0070]

[0072] Example 10 includes the subject matter of Example 9 and includes a signal bus having a plurality of ports, the SE module being coupled to one of the plurality of ports, and one or more non-secure sources being coupled to a corresponding one or more other of the plurality of ports.

[0071]

[0073] An eleventh embodiment includes the subject matter of any one of the eighth to tenth embodiments, in which the non-secure on-chip signal and the secure on-chip signal are AXI signals or Wishbone signals.

[0072]

[0074] Example 12 includes the subject matter of any one of examples 8-11, wherein the non-secure on-chip signal comprises an instruction to read one or more addresses of the secure memory.

[0073]

[0075] Example 13 includes the subject matter of any one of Examples 8 to 12, and wherein the state machine is configured to send a secure on-chip signal to a portion of the secure memory in response to the access right being a restricted access right.

[0074]

[0076] Example 14 includes the subject matter of example 13, wherein the firewall circuitry comprises a doorbell register coupled to the state machine and configured to send an interrupt signal to the secure processing device to instruct the secure processing device to read a portion of the secure memory.

[0075]

[0077] Example 15 includes the subject matter of any one of examples 8-14, wherein the at least one stored ID is arranged in a look-up table (LUT).

[0076]

[0078] Example 16 includes the subject matter of example 15, in which the LUT includes an access right associated with each of the at least one stored ID.

[0077]

[0079] Example 17 includes the subject matter of any one of examples 8-16, wherein the secure processing device is configured to access the at least one stored ID and reconstruct the at least one stored ID.

[0078]

[0080] Example 18 is a method of providing secure data transfer within an integrated circuit chip or chipset. The method includes receiving a command issued from a processing device within the integrated circuit chip or chipset, comparing a source ID associated with the processing device to a plurality of stored IDs, and identifying the source ID as having restricted access or open access in response to the source ID being found among the plurality of stored IDs. In response to the source ID having restricted access, the method includes redirecting an address associated with the command to a portion of secure memory, reading the portion of secure memory using the secure processing device, and executing the command in the portion of secure memory using the secure processing device. In response to the source ID having open access, the method includes executing the command using the processing device that issued the command.

[0079]

[0081] Example 19 includes the subject matter of example 18, wherein the command is an AXI signal or a Wishbone signal.

[0080]

[0082] Example 20 includes the subject matter of example 18 or 19, wherein the command comprises an instruction to read or write one or more addresses in the secure memory.

[0081]

[0083] Example 21 includes the subject matter of any one of Examples 18-20, wherein the command comprises an instruction to read one or more addresses of the secure memory, and executing the command in the portion of the secure memory comprises reading data in the one or more addresses of the secure memory using the secure processing device, and writing the data to the non-secure memory using the secure processing device.

[0082]

[0084] Example 22 includes the subject matter of any one of examples 18-21, wherein the plurality of stored IDs are arranged in a look-up table (LUT).

[0083]

[0085] Example 23 includes the subject matter of example 22, wherein the LUT includes an indication for each of the plurality of stored IDs of whether a given stored ID is restricted or not.

[0084]

[0086] Example 24 includes the subject matter of any one of Examples 18 to 23, and in response to the source ID having restricted access, the method includes issuing an interrupt to the secure processing device to instruct the secure processing device to read a portion of the secure memory.

[0085]

[0087] Example 25 includes the subject matter of any one of examples 18-24, comprising reconstructing one or more of the plurality of stored IDs using the secure processing device.

[0086]

[0088] Numerous specific details are described herein to provide a thorough understanding of the embodiments. However, it will be understood by those skilled in the art that the embodiments may be practiced without these specific details. In other instances, well-known operations, components, and circuits have not been described in detail so as not to obscure the embodiments. It can be understood that specific structural and functional details disclosed herein may be representative and do not necessarily limit the scope of the embodiments. Moreover, although the subject matter has been described in language specific to structural features and / or method operations, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or operations described herein. Rather, the specific features and operations described herein are disclosed as example forms of implementing the claims.

Claims

1. 1. A firewall circuit, comprising: a stub circuit configured to receive an unsecured on-chip signal from an unsecured source and identify a source ID corresponding to the unsecured on-chip signal; a memory configured to hold at least one stored ID; a state machine configured to transmit a secure on-chip signal to a secure source in response to the secure processing device verifying access rights associated with the non-secure on-chip signal; wherein the access right is verified when the source ID corresponds to at least one of the stored IDs.

2. The firewall circuit of claim 1 , wherein the non-secure on-chip signals and the secure on-chip signals are Advanced eXtensible Interface (AXI) signals or Wishbone signals.

3. The firewall circuit of claim 1 , wherein the non-secure on-chip signal comprises an instruction to read one or more addresses of a secure memory.

4. 2. The firewall circuit of claim 1, wherein the state machine is configured to transmit the secure on-chip signal to a portion of a secure memory in response to the access right being a restricted access right.

5. 5. The firewall circuit of claim 4, further comprising: a doorbell register coupled to the state machine and configured to send an interrupt signal to the secure processing device to instruct the secure processing device to read the portion of the secure memory.

6. 2. The firewall circuit of claim 1, wherein the at least one stored ID is arranged in a look-up table (LUT).

7. The firewall circuit of claim 6 , wherein the LUT includes access rights associated with each of the at least one stored ID.

8. A system on chip (SoC), comprising: a network interface configured to route signals between a plurality of on-chip hardware blocks; a firewall circuit coupled to the network interface and configured to receive unsecured on-chip signals from an unsecured source and to transmit secure on-chip signals via the network interface to a secure source coupled to the network interface; a secure processing device coupled to the network interface; a secure memory coupled to the network interface; Equipped with The firewall circuit includes: a stub circuit configured to receive the unsecured on-chip signal and identify a source ID corresponding to the unsecured on-chip signal; a memory configured to hold at least one stored ID; a state machine configured to transmit the secure on-chip signal to the secure source in response to the secure processing device verifying access rights associated with the non-secure on-chip signal; and wherein the access right is verified when the source ID corresponds to at least one of the stored IDs.

9. The SoC of claim 8 , wherein a secure enclave (SE) module comprises the network interface, the firewall circuitry, the secure processing device, and the secure memory.

10. 10. The SoC of claim 9, comprising a signal bus having a plurality of ports, the SE module being coupled to one of the plurality of ports and one or more non-secure sources being coupled to a corresponding one or more other of the plurality of ports.

11. The SoC of claim 8 , wherein the non-secure on-chip signals and the secure on-chip signals are AXI signals or Wishbone signals.

12. The SoC of claim 8 , wherein the non-secure on-chip signal comprises an instruction to read one or more addresses of the secure memory.

13. 9. The SoC of claim 8, wherein the state machine is configured to send the secure on-chip signal to a portion of the secure memory in response to the access right being a restricted access right.

14. 14. The SoC of claim 13, wherein the firewall circuitry comprises a doorbell register coupled to the state machine and configured to send an interrupt signal to the secure processing device to instruct the secure processing device to read the portion of the secure memory.

15. The SoC of claim 8 , wherein the at least one stored ID is arranged in a look-up table (LUT).

16. The SoC of claim 15 , wherein the LUT includes an access right associated with each of the at least one stored ID.

17. The SoC of claim 8 , wherein the secure processing device is configured to access the at least one stored identity and reconstruct the at least one stored identity.

18. 1. A method for providing secure data transfer within an integrated circuit chip or chipset, comprising: receiving a command issued from a processing device within the integrated circuit chip or chipset; comparing a source ID associated with the processing device to a plurality of stored IDs; in response to the source ID being found among the plurality of stored IDs, identifying the source ID as having restricted access or open access; in response to the source ID having the restricted access, redirecting an address associated with the command to a portion of a secure memory; reading the portion of the secure memory using a secure processing device; executing the command in the portion of the secure memory using the secure processing device; In response to the source ID having the open access, executing the command using the processing device that issued the command; A method comprising:

19. 20. The method of claim 18, wherein the command comprises an instruction to read one or more addresses of the secure memory, and executing the command in the portion of the secure memory comprises reading data in the one or more addresses of the secure memory using the secure processing device, and writing the data to a non-secure memory using the secure processing device.

20. 20. The method of claim 18, wherein in response to the source ID having restricted access, the method comprises issuing an interrupt to the secure processing device to instruct the secure processing device to read the portion of the secure memory.

Images