Secure Serial Peripheral Interface Communication

Abstract

This document discloses aspects of secure serial peripheral interface (SPI) communications. In some aspects, a secure SPI communications module monitors communications sent by a host to a peripheral block coupled to the host via an SPI interconnect. The module compares each command of the communications sent by the host to information indicative of commands that the peripheral block is not authorized to execute. Based on the comparison, the module determines that one of the commands is one of the commands that the peripheral block is not authorized to execute. The module then prevents the peripheral block from receiving at least a portion of each command of the communications. By doing this, the module can prevent the peripheral block from executing unauthorized commands. Execution of unauthorized commands can compromise the security of the peripheral block.

Description

Background Art

[0001] Background As the computerization of society continues to increase and personal computing devices are increasingly relied upon to store sensitive user information and perform a wide variety of operations for users, including driving a vehicle, performing user authentication, and completing digital currency transactions, the world has become increasingly vulnerable to a wide variety of damaging attacks on the sensitive information of computing devices.

[0002] Recent fault-based decryption methods have identified potentially security-threatening methods involving fault injection attacks. Fault injection attacks, in contrast to software injection, involve the attacker physically injecting faults into the computing system, thereby intentionally changing the behavior of electronic components. As a result, fault injection attacks can bypass many low-level system security functions, change the behavior of the computing system, and achieve malicious intentions and / or extract sensitive information. Fault injection attacks can include voltage glitches, clock glitches, laser injection, electromagnetic injection, etc. In some cases, these attacks can introduce fault injection to break or weaken electronic system security in various locations. For this reason, fault injection attacks may change commands or data transferred within the computing system, potentially changing the system's execution flow and causing downstream problems such as key leakage, privilege escalation, or unintended execution of code.

Summary of the Invention

[0003] Summary This document describes apparatuses and techniques for secure Serial Peripheral Interface (SPI) communication. In some aspects, a secure SPI communication module monitors communications sent via an SPI interconnect by a host or other bus controller to a peripheral block coupled to the host. The secure SPI communication module compares each command of the communications sent by the host to information indicating commands that the peripheral block does not have permission to execute. Based on the comparison, the secure SPI communication module determines that one of the respective commands is one of the commands that the peripheral block does not have permission to execute. Next, the secure SPI communication module prevents the peripheral block from receiving at least a portion of each command of the communications. By doing so, the module can prevent the peripheral block from executing unauthorized commands. Execution of unauthorized commands can compromise the security of the peripheral block, such as by changing a status register, disabling a protection scheme, or accessing confidential information.

[0004] The summary of the invention is provided to introduce a simplified concept for implementing secure SPI communication. This is further described in the detailed description below and shown in the drawings. The summary of the invention is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

[0005] Details of one or more aspects of secure SPI communication are described throughout this disclosure with reference to the drawings. Use of the same reference numerals in different examples in the specification and drawings indicates the same or similar elements.

Brief Description of the Drawings

[0006]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

[0007] Detailed Description A computing system includes an integrated circuit having a security circuit section and software to provide means of protection against defects, attacks, and other potentially security-threatening events. In today's computing environment, bad actors can attack computing devices at numerous levels using a multitude of attack vectors. For example, fault injection attacks can reduce the protection provided by many of these security paradigms. Fault injection attacks can bypass system security functions and change the behavior of the system, potentially achieving malicious intent and / or exposing confidential information. Using fault injection attacks, an attacker can indirectly or directly change the programmed operation of an electronic component (e.g., a central processing unit) using glitches (e.g., sudden, temporary injected faults in the system). Such attacks can, in some cases, "brick" the computing device, but in other instances, tightly targeted attacks can pose a threat to security. For example, fault injection attacks can enable an adversary to weaken the control flow of a program. As a result, incorrect functions may be called, such as "return to libc" type attacks. In some cases, these attacks can cause the computing device to expose confidential data or execute unvalidated code. For this reason, fault injection attacks can change commands or data being transferred within the computing system and potentially change the execution flow of the system, causing downstream problems such as key leakage, privilege escalation, or unintended execution of code.

[0008] Conventional techniques were aimed at dealing with such attacks but were generally weak and ineffective in preventing an attacker from modifying commands and compromising system security. For example, in some conventional schemes, the device can attempt to cancel a command and change the last bit in the opcode. However, this type of scheme may be ineffective if the command is still consumed by the peripheral or may not be applicable if two commands are adjacent (e.g., one bit apart). Other previous schemes maintained a command table that mapped multiple commands to a single command opcode. The table agent traversed the command table while receiving each bit of the command and sent a different opcode to the downstream peripheral. Such mapping suffered from problems related to inefficient mapping of certain commands to the table, which could not be removed or included by filtering depending on the system designer's preference. Thus, conventional techniques were vulnerable to various commands that could propagate through the system without constraints or filtering, resulting in system risks related to the execution of unauthorized or unpermitted commands.

[0009] In contrast to conventional security techniques, the present disclosure describes aspects of secure SPI communication. In an aspect, a secure SPI communication module monitors communications transmitted via an SPI interconnect by a host or other bus controller to a peripheral block coupled to the host via the SPI interconnect. The secure SPI communication module compares each command of the communications transmitted by the host with information (e.g., an excluded command list) indicating which commands the peripheral block does not have the right or is not permitted to execute. Based on the comparison, the secure SPI communication module determines that one of each of the commands is one of the commands that the peripheral block does not have the right to execute. In response to the determination, the secure SPI communication module then changes the state of the chip select line and / or the clock line of the SPI interconnect to prevent the peripheral block from receiving at least a portion of each of the commands of the communication. By doing so, the module can prevent the peripheral block from executing unauthorized commands. Executing unauthorized commands can compromise the security of the peripheral block, such as by changing a status register, disabling a protection scheme, accessing confidential information, etc.

[0010] Thus, in contrast to conventional techniques, the secure SPI communication aspects described herein can protect SPI peripheral components by leveraging the native operation, expected behavior, or protection mechanisms of SPI peripheral components such as flash memory devices or chips. Upon examination, flash memory devices can typically protect their status registers through the use of a write protection pin or input (e.g., Write_Protect pin). However, most of these flash memory devices disable this dedicated write protection pin when enabled for quad read commands or when used with quad read commands. Accordingly, the secure SPI communication aspects described herein provide flash memory device protection through replication of write protection by performing selective command filtering and / or selective data filtering.

[0011] Generally, the status register or other peripherals of an SPI flash device include specific protection bits that can be configured to protect or lock various sections of the memory for block protection, sector protection, upper / lower range protection, etc. In other words, setting one or more of these protection bits in the status register can be said to protect or prevent the operation of a predetermined area of the memory according to various protection schemes of the flash memory device. For this reason, the protection scheme or protection definition of the flash memory device can only be changed by using a specific command, and access to the status register is enabled through this command. Instead of filtering all commands by previous techniques, a secure SPI communication mode can protect a selected set of commands useful for accessing the status register and changing the protection state of the flash memory device (e.g., status register writing, etc.). Therefore, if the described mode of secure SPI communication prevents a host or another bus master from issuing these protected commands to change the protection state, the command issuer cannot change the protection state. By doing this, the host or other bus master cannot program or erase the content of the flash memory device. In an aspect, read commands are still transferred as normal, and if desired, a specific area can be segmented to maintain an internal mailbox.

[0012] Regarding status register writes, the secure SPI communication mode can filter the data of the status register write command to the downstream SPI flash device instead of filtering the status register write command to a value without side effects (e.g., read command, etc.). Therefore, the secure SPI communication module can enable all command bytes to pass from the host to the SPI flash device without manipulation. When the secure SPI communication module determines or identifies a command byte as a status register write command (the SPI flash device or vendor can provide a programmable list useful for identifying write status access), the programmed value of the command can be controlled by the secure SPI communication module.

[0013] In some aspects, the SPI device program values can be maintained through a select register and a value register. Generally, the select register controls whether a specific data bit is permitted to pass from the host or is forced from the secure SPI communication module or the SPI device controller. The value register can control what the forced value is assuming what the select bit is set to. For example, assume that the select register and the value register are programmed as a select register set to "0011_0000 (0x30)" and a value register set to "xx01_xxxx". This means that when a status write command is detected, bits 4 and 5 (the 4th and 5th bit positions) are forced to "1" and "0", while the remaining bits of the command are permitted to pass. Since the status write command may vary among chip vendors, what represents the write status can be programmable or configurable, but only 2 to 4 entries may be required.

[0014] In addition to the status write command, secure SPI communication can modify or protect other commands issued by the host or bus master that can affect the state of the protection bits of the peripheral device. This can include a reset command or other vendor-specific commands. To do this, the secure SPI communication mode can perform selective filtering to silence or modify the command before it can be received, captured, or processed by the connected peripherals of the system. As described throughout this disclosure, a secure SPI communication module or SPI command filter can de-assert the chip select line or signal (CSb) of a peripheral device, such as an SPI flash device, before the last bit of the command is fully captured. In an aspect, the secure SPI communication module can detect that a command should be filtered in the eighth clock cycle (e.g., before capture). The secure SPI communication module then de-asserts the chip select line early to ensure that the command bit of the last bit (e.g., the eighth bit) is not captured by the peripheral device. Alternatively or additionally, the secure SPI communication module can gate or hold the SPI clock line to the peripheral after the seventh beat or clock cycle to prevent the peripheral device from capturing the eighth bit of the command being filtered. In some cases, these operations are timing-dependent, and the secure SPI communication module can act to generate control signals (e.g., perform its gating and filtering) within, for example, half of the SPI clock period. For example, using an SPI clock of 25 MHz to 100 MHz, the secure SPI communication module can generate control signals, toggle the chip select line, or gate the SPI clock within 10 to 50 nanoseconds to complete the described command filtering.

[0015] In a secure SPI communication mode, a command filter can be configured or programmed to perform selective command filtering in one or more ways to provide flexibility. In some cases, each command in the command space of 256 possible commands will have a 1-bit enable, for example, through 8 registers for the command space. The secure SPI communication module can use the received command or a portion of the received command to index into a table to determine whether the command is allowed to pass or not (e.g., filtered). For example, the enable bit control indicates or controls whether the command is allowed to pass downstream to the peripheral device or is filtered. In some implementations, a "1" enable bit value indicates that the command is allowed to pass, and a "0" enable bit value indicates that the command is filtered by the secure SPI communication module or the command filter. Before filtering the operation, the host software or firmware can configure or program the filtering table.

[0016] In a secure SPI communication module that performs command filtering, since the secure SPI communication module can simply filter out or block commands that enable operations on the status register of the SPI flash device, status protection of the SPI flash device may not be necessary. For this reason, the advantage of having selective or reduced-complexity command filtering and / or status register command data filtering is that fewer commands or instructions are filtered. In other words, the set of instructions that must be filtered is reduced (e.g., commands related to status register writes), and over the remaining time, the secure SPI communication module enables the host of the system to communicate directly with the SPI flash device. As a result, there is less intervention from the firmware or the secure SPI communication module in that the firmware does not need to capture all command payloads and determine whether these payloads should be passed downstream to the SPI flash device. Alternatively or additionally, the host or system software can configure the secure SPI communication module to perform any combination of the described modes of command or data filtering. For example, the secure SPI communication module can be configured to perform only command filtering, to allow and / or deny command filtering by default, to deny filtering using status protection, to allow filtering using status protection, etc. These and other aspects described herein ensure that after the host or system software sets or configures the secure SPI communication module to perform command filtering and / or A / B split access, the protection settings of the SPI flash device (e.g., SPI flash chip) cannot be arbitrarily changed. Thus, as long as the downstream SPI flash device is operating according to its internal protection mechanism, these aspects enable secure SPI communication to be performed more efficiently with a lower complexity than in the prior art.

[0017] In various aspects, a secure SPI communication module is coupled to the SPI interconnect of a system that includes a host and an SPI flash device, as well as any number of other system peripheral blocks or components. The secure SPI communication module can implement a command control scheme that includes snooping or monitoring SPI transactions from a host platform to the SPI flash device and intervening when unauthorized traffic is detected. The command control scheme is intended to block any malicious read / write requests or self-contained commands (e.g., chip erase). These self-contained commands may include commands that are not followed by other data such as an address or payload. In an aspect, the scheme can use the SPI command filter and SPI clock controller (e.g., a clock gating cell) described herein. Generally, the command filter can block incoming commands based on a command block list or table, or the filter can allow only authorized commands to pass based on an allowed command list. The command block list or allowed command list can be implemented as software or in a hardware circuit depending on which is used. In an aspect, to block a command, the command filter changes a chip select line or signal line during command propagation, before the eighth SPI clock edge, or at the eighth SPI clock edge.

[0018] At the same time, the command filter can gate or hold the SPI clock line to the SPI flash device until the host system releases the chip select signal. Note that the SPI chip select line and the SPI clock can be toggled simultaneously in a proximate manner (e.g., within the same clock beat or cycle) or in a partially overlapping fashion. In an aspect, the secure SPI communication module includes a clock gating cell for controlling the propagation of the SPI clock. For this reason, the clock gating cell may prevent the SPI clock signal generated at the host from propagating to the SPI flash device, which is effective in preventing glitches in the chip select line or signal. In some cases, when the SPI clock is not gated, the chip select line may require another clock pulse to remove glitches. In other words, without clock signal gating, the command filter may miss the timing to raise the chip select signal to cancel an unauthorized command. For this reason, using SPI clock gating, the secure SPI communication module can de-assert the chip select line or signal before an unauthorized command is fully transmitted to the SPI flash device without glitching, and the SPI device can cancel an incomplete command without executing it.

[0019] These and other aspects of secure SPI communication described herein can ensure that the memory cannot be attacked downstream of the security module or command filter, and that any read or write to the memory is restricted or constrained to specific addresses that cannot be changed by an attacker. The following discussion describes an operating environment, exemplary systems and components, an exemplary implementation of secure SPI communication, an exemplary method, and a system-on-chip (SoC) that can embody the components of the operating environment. In the context of the present disclosure, the operating environment is referenced as an example only.

[0020] Exemplary Environment FIG. 1 shows an exemplary environment 100 that includes an apparatus 102 capable of implementing aspects of secure SPI communication and related communication integrity schemes. The apparatus 102 can be implemented as any suitable device, some of which are shown as smartphone 102-1, tablet computer 102-2, laptop computer 102-3, gaming console 102-4, desktop computer 102-5, server computer 102-6, wearable computing device 102-7 (e.g., smartwatch), and broadband router 102-8 (e.g., mobile hotspot). Although not shown, the apparatus 102 can also be implemented as any of a mobile station (e.g., fixed or mobile STA), mobile communication device, client device, user equipment, mobile phone, entertainment device, mobile gaming console, personal media device, media playback device, health monitoring device, drone, camera, Internet appliance capable of wireless Internet access and browsing, IoT device, and / or any of other types of electronic devices. The apparatus 102 may provide other functions or include components or interfaces, but these are omitted from FIG. 1 for clarity or visual simplicity.

[0021] The apparatus 102 includes an integrated circuit 104 that utilizes one or more processors 106 and a computer-readable medium (CRM 108) that may include a memory medium or a storage medium. The processor 106 can be implemented as a general-purpose processor (e.g., a multi-core central processing unit (CPU) or an application processor (AP)), an application-specific integrated circuit (ASIC), a graphics processing unit (GPU), or a system-on-chip (SoC) in which other components of the apparatus 102 are integrated. In aspects of secure SPI communication, one or more of the processors 106 can also include the integrity functions described throughout this disclosure.

[0022] CRM108 can include any suitable type of memory medium or storage medium, such as read-only memory (ROM), programmable ROM (PROM), random access memory (RAM), dynamic RAM (DRAM), static RAM (SRAM), or flash memory (e.g., SPI flash device or chip). In the context of this discussion, the computer-readable medium 108 of device 102 is implemented as at least one hardware-based or physical storage device that does not include transient signals or carrier waves. The applications, firmware, and / or operating system (not shown) of device 102 can be embodied on the computer-readable medium 108 as processor-executable instructions that can be executed by the processor 106 to provide the various functions described herein. The computer-readable medium 108 can also store device data 110, such as user data or user media, that is accessible through the applications, firmware, or operating system of device 102.

[0023] In this example, integrated circuit 104 includes security circuitry 112. Device 102, integrated circuit 104, or security circuitry 112 can implement a secure cryptographic processor. Security circuitry 112 can be implemented using one or more circuit components 114, such as circuit components 114-1 through 114-n. Circuit components 114 can be programmed to perform any number of operations enabling the functionality of device 102. As described with reference to FIG. 2, examples of circuit components include a processor and multiple functional components, peripherals, and / or IP blocks. Security circuitry 112 can be realized, for example, as a protected enclave, a trusted chip platform, a hardware-based root of trust (RoT) chip (e.g., a silicon RoT), etc. Regardless of how or where security circuitry 112 is incorporated into an electronic device, security circuitry 112 can counter or prevent many different types of attacks, such as attacks or malicious commands issued over the SPI bus or interconnect described for secure SPI communication.

[0024] In an aspect, the security circuit unit 112 includes circuit components 114-1 to 114-n that provide or implement the respective functions of the security circuit unit 112, the RoT circuit unit, the integrated circuit 104, and / or the device 102. To implement an aspect of secure SPI communication, the circuit components 114 can include an SPI command filter 116 and an SPI clock controller 118, which can be implemented as part of a secure SPI communication module. In an aspect, the SPI command filter 116 monitors the communication exchanged between the host of the device 102 and the flash memory module (e.g., CRM108) of the device 102. Typically, the SPI command filter 116 compares each command of the communication transmitted by the host with information indicating which commands the flash memory module does not have the right to execute. Based on the comparison, the SPI command filter 116 determines that one of the respective commands is one of the commands that the flash memory module does not have the right to execute (e.g., a status register write command). In response to the determination, the SPI command filter 116 can deassert the chip select line of the flash memory module or gate or pause the SPI clock line of the flash memory module using the SPI clock controller 118. By doing so, the SPI command filter 116 can prevent the flash memory module from receiving or processing at least a portion of the unauthorized command, thereby preventing the unauthorized command from compromising the security of the flash memory module. Alternatively or additionally, the SPI command filter 116 or the secure SPI communication module can verify the integrity of the binary image stored in the first section of the flash memory module.If the integrity verification fails, the SPI command filter 116 can change the address of the SPI interconnect transaction to cause the host to load a different binary image from the second section of the flash memory module in order to prevent the host from loading an unverified and possibly security - compromised binary image from the first section. These are just some examples of entities useful for enabling secure SPI communication, and their implementation and use vary and are described throughout the present disclosure.

[0025] As shown, the security circuitry 112 is coupled to the interconnect 120, and the interconnect 120 can couple components, peripherals, and / or destinations of the security circuitry to the host or host interface. The interconnect 120 can be implemented, for example, using a bus, switching fabric, link, communication channel, or bus network that enables various circuit components to communicate. In some aspects, the interconnect includes a Serial Peripheral Interface (SPI) interconnect or bus implemented according to the SPI communication standard. In some implementations, the SPI interconnect includes a chip - select line, a clock line, and four I / O lines (e.g., S[3:0] or D[3:0]). Each of the circuit elements can be coupled directly or indirectly to the interconnect 120. The interconnect 120 can communicate with a data port or interface of the device 102 and enable circuit components to communicate with other databases or data networks.

[0026] Device 102 can also include a display 122, a transceiver 124, an input / output port (I / O port 126), and / or a sensor 128. The display 122 can be operatively coupled to one of the processors 106 (e.g., a graphics processing unit (GPU)) and configured to graphically present the respective interfaces of the operating system or applications of the device 102. The transceiver 124 can be configured to enable wired or wireless communication of data (e.g., device data 110) via a wired or wireless network according to any suitable communication protocol. The I / O port 126 of the device 102 can include a universal serial bus (USB) port, a coaxial cable port, and other serial or parallel connectors (including internal connectors) useful for coupling the electronic device to various components, peripherals, or accessories such as a keyboard, microphone, or camera.

[0027] Device 102 also includes a sensor 128 that enables the device 102 to sense various attributes, variations, stimuli, or characteristics of the environment in which the device 102 operates. For example, the sensor 128 can include various motion sensors, ambient light sensors, acoustic sensors, capacitance sensors, infrared sensors, temperature sensors, radar sensors, or magnetic sensors. Alternatively or additionally, the sensor 128 can be configured to interact with or receive input from a user of the device 102 through touch sensing, gesture sensing, or proximity sensing, etc.

[0028] Exemplary circuit components Figure 2 shows an exemplary security circuit section 112 that can be implemented to support secure SPI communication modes at 200, including a processor and a plurality of circuit components. As shown, security circuit section 112 includes a processor 106 coupled to an interconnect 120. Each of processor 106, the plurality of memories, and the plurality of other circuit components 114 can be coupled directly or indirectly to interconnect 120. In an aspect, the components of FIG. 2 can be realized as a secure computing platform or a secure system-on-chip that implements root of trust and / or other secure cryptographic functions. Alternatively or additionally, the components of FIG. 2 can be implemented as one or more ICs, peripheral blocks, or IP blocks of a system coupled by an interconnect 120 that can be implemented as a fabric that operatively couples the components of the system or IP blocks.

[0029] In an aspect, the interconnect 120 can include or couple to an SPI command filter 116 and an SPI clock controller 118, which can be implemented as part of a secure SPI communication module. In an aspect, the SPI command filter 116 monitors communications exchanged between a host of the system and an SPI memory device of the system. Typically, the SPI command filter 116 compares each command of the communications transmitted by the host with information indicating which commands the flash memory module does not have the authority to execute. Based on the comparison, the SPI command filter 116 determines that one of the respective commands is one of the commands that the flash memory module does not have the authority to execute (e.g., a status register write command). In response to the determination, the SPI command filter 116 can deassert the chip select line of the flash memory module or gate or pause the SPI clock line of the flash memory module using the SPI clock controller 118. These are merely some examples of the SPI command filter 116 and the SPI clock controller 118, and their implementation and use vary and are described with reference to FIGS. 3-5 and throughout the present disclosure.

[0030] Processor 106 may be coupled to circuit component 114 through interconnect 120 and / or may be directly coupled to other components or interfaces. As shown in FIG. 2, the system may include a plurality of circuit components 114 coupled to interconnect 120 that enables interaction with processor 106, which can function as the host of the system. In this example, circuit components 114 include register file 202 and various memories 204-210. Circuit components 114 can include one or more memories (e.g., CRM 108) in any suitable configuration and can include ROM 204, SRAM 206, and SPI flash memory 208. In this example, SPI command filter 116 and / or SPI clock controller 118 can be implemented between interconnect 120 and SPI flash memory 208.

[0031] In an aspect, SPI flash memory 208 includes a control status register (CSR) and a flash medium configured to store system or host information. The status register of the SPI flash device or other memory peripherals can include specific protection bits that can be configured to protect or lock various sections of the memory for block protection, sector protection, upper / lower range protection, etc. In an aspect, SPI command filter 116 and SPI clock controller 118 can prevent unauthorized commands from being consumed by SPI flash memory 208 and from changing the settings of the CRS of SPI flash memory 208. In some cases, SPI flash memory 208 does not include a write protection input node or the write protection input node of the peripheral block is disabled, for example when quad mode access is enabled. Although not shown, circuit components 114 can include other memories (e.g., one-time programmable or DRAM memories) and / or memories coupled through other components such as additional serial peripheral interface (SPI) or USB-coupled memories.

[0032] As shown in FIG. 2, the circuit component 114 can also include an alert handler 210, an Advanced Encryption Standard (AES) unit (AES unit 212), a Hash-based Message Authentication Code (HMAC) engine (HMAC engine 214), and a Serial Peripheral Interface (SPI) device (SPI device 216). Here, it should be noted that the SPI command filter 116 and / or the SPI clock controller 118 can be implemented between the interconnect 120 and the SPI device 216, whereby the SPI device 216 can be prevented from consuming unauthorized commands as described herein. The circuit component 114 can also include a Universal Asynchronous Receiver / Transmitter (UART) unit (UART unit 218), a General Purpose Input / Output (GPIO) interface (GPIO interface 220), a pin multiplexer (pin mux 222), and a pad controller 224. The plurality of circuit components 114 can further include a random number generator (RNG 226), from which other components can obtain a high entropy value and a timer 228 (e.g., a watchdog timer) for use as an authentication token. Although certain examples of the memory and other components 114 are shown in FIG. 2 or described herein, a given implementation of the security circuit section 112 can include more, fewer, and / or different instances of processors, controllers, memories, modules, or peripheral devices, including duplicates thereof.

[0033] The circuit components shown can operate synchronously based on one or more clock signals. Although not shown in FIG. 2, the security circuit section 112 can include at least one clock generator for generating a clock signal, or can include a reset circuit section for resetting one or more components independently of each other, a plurality of components jointly, or the entire IC chip. Alternatively, the security circuit section 112 may receive at least one clock signal or reset signal from a source external to the security circuit section 112, and this source may or may not be on a separate chip. One or more separate components 114 can operate in their respective individual clock domains. For example, the circuit components can be synchronized to a clock local to each component. Components in different clock domains can operate or communicate asynchronously with each other.

[0034] An exemplary implementation of exemplary components is described below. Processor 106 can be implemented as the "main", "central", or "core" processor of security circuitry 112, through which the functions of a host or bus controller are implemented. Processor 106 can be implemented, by way of example only, using a 32-bit in-order reduced instruction set computing (RISC) core having a multi-stage pipeline. For example, using RISC-V functionality, the processor can implement M (machine) and U (user) modes. By activating a reset pin (not shown) (e.g., through deassertion of an active-low reset pin), processor 106 ends the reset and begins execution of code at the reset vector. The reset vector can begin in ROM 204. ROM 204 validates the code in the embedded flash or any flash memory of the system before jumping there. In other words, the code is expected to be instantiated in the flash before the reset is released. In some cases, the reset across security circuitry 112 as a whole can be made asynchronous active-low with respect to portability specifications to support interoperability between various circuit components. The reset can be generated, as a security measure, by alert handler 210, by a watchdog timer, etc. The reset signal can also be sent to other circuit components such as one of the memories or one of the other components 114.

[0035] The processor 106 has a debug module 230 (DM) and an interrupt controller 232 (ItC) coupled thereto, both of which can be made transplantable. The debug module 230 provides debug access to the processor 106. By interfacing with certain pins of the IC, the logic in the debug module 230 enables the processor 106 to enter the debug mode and provides the function of injecting code (e.g., by emulating instructions) into the device or memory. The interrupt controller 232 can be disposed in proximity to the processor 106. The interrupt controller 232 can receive vectors of interrupt sources from within the security circuitry 112. The interrupt controller 232 can also assign levels and priorities to the interrupts before transferring them to the processor 106 for processing.

[0036] The processor 106 can provide any desired level of performance or include any internal circuit components. For example, the processor 106 can include at least one arithmetic logic unit (ALU) (e.g., including an "additional" ALU for calculating branch targets to remove latency cycles in the obtained conditional branches), a register file, a control unit, and an input / output (I / O) unit, as well as multiple pipeline stages. Using the multiple pipeline stages, the pipeline can perform register writebacks, reduce latency cycles from loads and stores, and prevent pipeline stalls. In this case, the response to a load or store is available in the cycle after the request. The processor 106 can implement a single-cycle multiplier or generate an imprecise exception for an incorrect response to a store, whereby the processor can continue execution beyond the store without waiting for the response. Although not shown, the processor 106 can particularly, or the security circuitry 112 can generally, include an instruction cache for providing a single-cycle access time for instructions.

[0037] The ALU can be configured to perform arithmetic and logical operations on received data. A register file (e.g., register file 202), further described with reference to FIGS. 3A and 3B, can serve as a high-speed semi-temporary memory configured for rapid data access during program or function processing and can be an array of processor registers (e.g., control registers). The register file can be tightly coupled to the ALU of processor 106. To further facilitate access to data, the register file can include multiple read ports or multiple write ports to enable the ALU and / or execution unit to simultaneously retrieve multiple operands in a single cycle. The register file can be formed from flip-flops to accelerate the reading and writing of data bits. The control unit can be configured to control the flow of data throughout the system. The I / O unit can include ports operatively interfaced with other components of device or security circuitry 112. Further aspects of processor 106, circuitry 114, SPI command filter 116, SPI clock controller 118, or secure SPI communication module are described with reference to FIGS. 3-9 and throughout the present disclosure.

[0038] Figure 3 shows an exemplary configuration of system components that implement SPI command filtering, according to one or more aspects, at 300. The exemplary interposer and / or other components of FIG. 3 can be implemented in association with any other components, architectures, entities, or systems described throughout this disclosure. Generally, a secure SPI communication module 302 (e.g., an SPI filter of a RoT circuit) is implemented in an interposer 304 or operatively associated with an SPI-based interconnect between a host system 306 and a downstream peripheral such as an SPI flash device 308. In this example, the secure SPI communication module 302 includes an instance of an SPI command filter 116 (or SPI command detector) and an SPI clock controller 118 that can be implemented or can include a clock gating cell (not shown).

[0039] In an aspect, the SPI interface between the host system 306 and the SPI flash device 308 includes an SPI clock line 310 (SCK310), an SPI chip select line 312 ( / CS312), and a serial data line 314 (S[3:0]314), although other interconnects or fabric configurations may be implemented in connection with secure SPI communication modes. In some cases, the interposer 304 can be implemented as part of a silicon RoT circuit or other security circuitry configured to monitor the commands of the communications exchanged between the host system 306 and the SPI flash device 308. As shown in FIG. 3, the secure SPI communication module 302 or the interposer 304 can include an SPI command filter 116 and an SPI clock controller 118. In an aspect, the SPI command filter has access to the serial data line 314 to traverse the SPI interface to the SPI flash device 308 to monitor commands and opcodes. The SPI command filter 116 can include an output for providing a command-filtered signal 316 (filtered 316) to a logic gate 318 or logic circuitry coupled to the chip select line 312. In some cases, the logic gate 318 includes an exclusive OR gate, an OR gate, an AND gate, a multiplexer, a combination of logic gates, or any other suitable logic. Generally, by changing the state of the command-filtered signal line, the SPI command filter can change (e.g., deassert) the state of the chip select line 312 to prevent the SPI flash device 308 from receiving, consuming, or processing a command or opcode communicated via the data line 312 of the SPI interface. Alternatively or additionally, the SPI command filter 116 can include an output for providing a clock enable signal 320 to the SPI clock controller 118.When an unauthorized command is detected, the SPI command filter 116 can change the state of the clock enable line 320 to gate the SPI clock 310 that propagates to the SPI flash device 308 to the SPI clock controller 118.

[0040] In the context of FIG. 3, the SPI command filter 116 can monitor or snoop on the communications exchanged between the host system 306 and the SPI flash device 308. The SPI command filter 116 can compare each command or opcode of the communications transmitted by the host system with information (e.g., an inclusion table or an exclusion table of commands) indicating whether the SPI flash device has the right or not to execute any command. If there is a right to the command of the communication, the SPI command filter 116 passes the command or opcode downstream to the SPI flash device 306. Alternatively, the SPI command filter 116 may determine that the command or opcode does not have the right to be executed by the SPI flash device 308, for example, in the eighth bit of the opcode or command. In response to the determination, the SPI command filter 116 deasserts the chip select line 312 using the logic gate 318 and gates the SPI clock signal 310 to the SPI flash device using the SPI clock controller 118. Generally, when the chip select line 312 to the downstream SPI flash device is deasserted before the eighth bit or beat of the command or opcode, the SPI flash device 308 discards the command or a part thereof. In some cases, when the SPI command filter 116 only toggles the chip select line 312, the chip select line is prone to glitches due to, for example, combinatorial logic from the eighth bit of the opcode. Generally, when the eighth code has already been received by the SPI flash device 308, it may be too late, so the control of the chip select line 312 should be such that there are no glitches in the registered output. To address this glitch issue, the SPI command filter 116 can gate the SPI clock 310 to control or toggle the chip select line 312 without causing glitches, thereby ensuring that the SPI flash device 308 is prevented from receiving or consuming the eighth bit of the opcode or command.

[0041] Figure 4 shows, at 400, an exemplary system that includes clock gating and command filtering functionality for implementing a secure SPI communication mode. The exemplary root of trust circuit and / or other components of FIG. 3 can be implemented in association with any other components, architectures, entities, or systems described throughout this disclosure. The exemplary system 400 includes a root of trust circuit 402 coupled between or in combination with a host system 306 and an SPI flash device 308. Generally, an SPI command filter 116 and / or a secure SPI communication module 302 can implement aspects of a secure SPI interface as described herein. The SPI command filter 116 can be implemented as a secure serial peripheral interface (SPI) device pass-through module (e.g., a secure SPI communication module 302). By way of example, this secure SPI device pass-through module can include functionality for snooping SPI transactions from a host system to an SPI flash device and intervening in unauthorized traffic. This module can be implemented to block any malicious read / write requests and / or to ensure that a genuine binary image is returned to the host system.

[0042] In this exemplary system, the root of trust circuit 402 is operatively coupled to an SPI bus 404 that includes an SPI clock 310, an SPI chip select line 312, and a serial data line 314, which may be implemented similar to or different from that described with reference to FIG. 3. A clock gate cell 406 (clock gate 406) receives the SPI clock 310 from a system host or a clock circuit and provides the SPI clock 310 to the SPI flash device 308. In an aspect, the SPI command filter 116 monitors the SPI bus 404. The SPI bus 404 includes a chip select bit 408 for the SPI flash device 308. As shown in FIG. 4, the SPI command filter 116 can selectively generate a chip select bit disable signal 410 (CSb_disable 410) to gating logic that gates the application or propagation of the chip select bit 408 to the SPI flash device 308.

[0043] In a secure SPI communication mode, at least some bits (e.g., 7 out of 8 bits) of the SPI command or opcode can be clocked to the SPI flash device 308 based on the SPI clock 310. In some cases, the SPI command filter 116 may not be able to determine whether a command is authorized or unauthorized until it has received all 8 bits of the command. The SPI command filter 116 determines this eighth bit at the initial portion of the SPI clock 310 clock pulse corresponding to the eighth bit of the command, and can then determine whether the command is authorized or unauthorized. For example, the SPI command filter can compare the complete command or opcode to a table of information indicating which commands have authorization for execution by the SPI flash device 308. In response to a determination that the command is unauthorized, the SPI command filter 116 deasserts the clock enable signal of the clock gate 406 to interrupt or delay the SPI clock signal 310 to the SPI flash device 308 in order to prevent the eighth bit of the command from being registered or consumed by the SPI flash device 308. Alternatively or additionally, in response to a determination that the command is unauthorized, the SPI command filter 116 asserts the chip select bit disable signal 410 to the gating logic, thereby causing the gating logic to deassert the SPI chip select signal 312 to the SPI flash device 308 and preventing the device from consuming one or more bits of the unauthorized command. By doing so, the SPI command filter 116 can prevent an unauthorized command from reaching or being registered within the SPI flash device, thereby preventing the execution of unauthorized SPI opcodes.

[0044] Generally, the SPI command filter 116 or the secure SPI communication module 302 can block any downstream commands if they are not permitted and / or exchange the address field of read commands to support A / B partitioning or binary image schemes. As described herein, the SPI command filter 116 can be configured to block these commands if the incoming commands are within a block list configured by the system's software or hardware (e.g., for CSR commands). When the SPI command filter 116 blocks a command, the filter can change or toggle the chip select line or chip select bit at the edge of the eighth beat or cycle of the SPI clock 310 and gate or hold the SPI clock 310 low until the host system releases that chip select line (e.g., upstream from the SPI command filter 116). In an aspect, the SPI command filter 116 can use the clock gate cell 406 to prevent the SPI clock 310 from propagating to the attached SPI flash device 308, thereby reducing or preventing glitches on the chip select line and ensuring proper operation of the SPI flash device. When the SPI command filter 116 does not gate the SPI clock line 310, the chip select line 312 may require one or more clock cycles to resolve any glitches. In some cases, this timing delay may cause the SPI command filter 116 to miss the correct timing to assert or change the chip select line to cancel a self - contained command such as a chip erase command. For this reason, the SPI command filter 116 can de - assert the SPI chip select line and gate the SPI clock line to prevent glitches on the SPI chip select line and ensure that the timing of the chip select line toggle is effective in preventing self - contained commands from being consumed by the SPI flash device.Furthermore, in the context of an SPI command filter that controls the chip select line, in order to enable the deassertion of the SPI chip select line to function, several assumptions regarding SPI communication can be made. These assumptions include that the deassertion of the SPI chip select line during the transmission operation does not degrade the quality of the flash device's I / O, and that if the chip select line is deasserted before the eighth SPI clock cycle or beat, the SPI flash device 308 can cancel the command or process without making any assumptions regarding the intended behavior of the command. For example, the SPI flash device 308 may not charge the charge pump in the seventh SPI clock cycle or beat in order to prepare for erasing the SPI flash device chip. Although described in the context of host-to-SPI device access, the aspects described herein can also be applied to SPI device-to-host access to prevent unauthorized payloads or data issued by the SPI flash from reaching the host device.

[0045] The secure SPI communication module 302 can also perform an address operation where software can configure this module to swap SPI data line 0 to the downstream device for the first 32 bits of data following an SPI command. This can support, for example, commands that are read commands, excluding dual IQ and quad IQ commands. Generally, an SPI device can provide two programmable CSRs to support this address operation feature. In an aspect, these registers include a mask register and a data register that holds or stores data to be sent to the downstream device. The mask register can be set by the host or the secure SPI communication module 302 to indicate one or more of the address bits to be swapped. If the mask bit corresponding to the address bit position is 1, the value transferred to the downstream device can be the value from the data register instead of the value from the host system. In an aspect, one or both of the registers are implemented as 32-bit registers. If the 4B address mode of the SPI flash device is not enabled, the lower 24 bits from the register can be used for the address operation. The use of these address operation features can vary. One purpose is to provide host access to an A / B binary image. In an aspect, the system's root of trust circuit 402 or other RoT can verify the binary image stored by the SPI flash device 308. If this binary image has been manipulated by a malicious attack or reliability issue, the logic in the RoT circuitry can set the register to redirect the host system's request to another partition of the SPI flash device (e.g., the other half of the flash or a split partition).

[0046] Figure 5 shows an exemplary timing diagram of SPI communication signaling that can implement a secure SPI communication mode at 500. The timing diagram 500 shows the respective timings and transitions of signals according to one or more modes of secure SPI communication. As described herein, various SPI interconnect signals can be received by the SPI command filter 116 and / or the secure SPI communication module, and then these signals can be passed, gated, or propagated to a downstream SPI peripheral such as an SPI flash device. In this example, the SPI chip select signal (CSb_in502) can proceed on the SPI chip select line from the host system 306 to the secure SPI communication module 302, the SPI clock signal 504 (SCK_in504) can proceed on the SPI clock line from the host system 306, and the SPI I / O line 506 (Io[0]_i506) can proceed on the serial data line of the SPI interconnect from the host system 306 to the secure SPI communication module 302. In an aspect, the filter signal 508 (Filter508) can represent a signal or interrupt indicating when an authorized command is detected or determined by the SPI command filter 116. In response to the detection or determination of an unauthorized command, the SPI command filter 116 can generate, modify, or toggle one or more other signals according to the aspects described herein. In this example, the SPI command filter raises a command-filtered signal 510 (Filtered510), which can propagate to the SPI chip select line logic coupled to the SPI clock and / or the clock gating cell. Here, the SPI clock output signal 512 (SCK_out512) can represent the output of the clock gating cell to the clock input of the SPI flash device, and the chip select output signal 514 (CSb_out514) can represent the output of the chip select line logic to the chip select input of the SPI flash device.

[0047] As an example, when a command is transmitted as the IO[0]_i506 signal from the host system 306 to the SPI device 308, the CSb_in signal 502 is asserted by the SPI interface of the host system 306 and remains asserted for the duration of the transmission. The CSb_in signal 502 is asserted and latched by the filtered signal 510 and passed to the SPI flash device 308. By latching the chip select signals (e.g., the CSb_in signal 502 and the CSb_out signal 514) in this way, clean chip select assertion and subsequent operations without glitches can be guaranteed if necessary. Without this function, if glitches occur on the chip select line, the SPI flash device may exhibit unknown behavior that may include a reset that damages or destroys the contents of the SPI flash device 308. In an aspect, each of the bits of the command or opcode (e.g., 8 bits) is clocked into the SPI device 308 based on the SCK_out512 signal being the SCK_in504 signal. In this example, the command filter 116 may not determine whether the command is authorized or unauthorized until the command filter 116 has received all eight bits of the command. When the command filter 116 determines the eighth bit of the command at 516 in the initial portion of the SCK_in502 clock pulse corresponding to the eighth bit of the command and determines that the command is an unauthorized command (e.g., by comparing the command to a command block list), the command filter 116 performs command filtering. In this example, the SPI command filter 116 asserts the filtered command signal 510 at 518, thereby being able to assert or de-assert (depending on the polarity configuration of the SPI flash pins) the CSb_out514 signal. The SPI command filter 116 also de-asserts the clock enable of the clock gating cell to interrupt or delay the SCK_out512 signal to the SPI flash device.By doing so, the SPI command filter 116 can prevent the eighth bit of the command or opcode from being registered or consumed by the SPI flash device 308. Further, by gating the clock and deasserting the chip select signal, the SPI command filter 116 can avoid glitches on the chip select line, thereby preventing the SPI flash device 308 from receiving or interpreting and executing any inaccurate or unauthorized commands. This example was implemented by an instance where a command was sent from the host system 306 to the SPI device 308, but the same logic can be used to implement the reverse use, that is, when the SPI device 308 sends an unauthorized payload or data to the host system 306, this implementation will prevent the host from consuming unauthorized communication as in this example.

[0048] Exemplary methods Methods 600 - 800 can be performed, but are not necessarily shown as each set of blocks representing actions or operations limited to the order or combination shown for performing the operations by each block. Further, any one or more of the operations can be repeated, combined, rearranged, or linked to provide a wide range of additional and / or alternative methods. The described techniques are not limited to execution by one entity or multiple entities operating on one system or device. In an aspect, the operations or actions of methods 600 - 800 are executed or managed by a processor, security circuit components, memory, secure SPI communication module, SPI command filter, SPI clock control, or other entity configured to perform secure SPI communication. For clarity, the methods are described with reference to the elements of FIG. 1 and / or the entities, components, or configurations described with reference to FIGS. 2 - 5 and FIG. 9.

[0049] Figure 6 shows an exemplary method 600 for secure SPI communication that can be implemented by an SPI command filter 116 or a secure SPI communication module operatively associated with a host or SPI interconnect according to one or more aspects. In various aspects, the SPI command filter 116 or the secure SPI communication module can implement the operations of method 600 to block downstream commands from reaching one or more peripheral blocks (e.g., flash memory devices) if they are not authorized or permitted.

[0050] At 602, the SPI command filter monitors communications exchanged via an SPI interconnect between a host of the system and a peripheral block of the system. For example, the SPI command filter can snoop or monitor the data lines of a serial peripheral interface interconnect or bus to obtain the bits of the command or opcode of the SPI communication being communicated via the SPI interconnect. In some cases, commands are transmitted from the system host to an SPI flash device.

[0051] At 604, the SPI command filter compares each command of the communication with information indicating whether the peripheral block has the authority to execute any of the commands. In some cases, the SPI command filter indexes into a table using the received command or a portion of the received command to determine whether the command is permitted to pass (e.g., filtered). For example, an enable bit control indicates or controls whether a command is permitted to pass downstream to a peripheral device or is filtered. In some implementations, an enable bit value of "1" indicates that the command is permitted to pass, and an enable bit value of "0" indicates that the command is filtered by a secure SPI communication module or command filter.

[0052] At 606, the SPI command filter determines, based on a comparison, that one of each of the commands is one of the commands that the peripheral block does not have the authority to execute. In other words, the SPI command filter detects commands that are not permitted or not authorized to propagate to the peripheral block on the SPI interconnect. The SPI command filter can determine that a command has no authority based on a partial or complete command, such as in the 8th bit of the command or the corresponding opcode.

[0053] At 608, the SPI command filter prevents the peripheral block from receiving at least a portion of each command that the peripheral block does not have the authority to execute. In an aspect, the SPI command filter changes the state of the chip select line or the clock line from the SPI interconnect to the peripheral block. In some cases, the SPI command filter gates the clock to the SPI peripheral and then toggles the chip select line. This can prevent glitches on the chip select line when the SPI command filter is functioning to prevent consumption of unauthorized commands. This can prevent the peripheral block from receiving, consuming, or processing at least a portion of a command that the peripheral block does not have the authority to communicate. From operation 608, method 600 returns to operation 602 and can continue monitoring or snooping the SPI interconnect for unauthorized commands issued across the SPI interconnect to the above or other peripheral blocks of the system.

[0054] FIG. 7 shows an exemplary method 700 for filtering SPI communication commands according to one or more aspects. In various aspects, the SPI command filter 116 or the secure SPI communication module can perform the operations of method 700 to block these downstream commands from reaching one or more peripheral blocks (e.g., flash memory devices) if the downstream commands are unauthorized or not permitted.

[0055] At 702, the SPI command filter monitors each command of the communication exchanged via the SPI interconnect between the host and the peripheral device. For example, the SPI command filter can snoop or monitor the data lines of the serial peripheral interface interconnect or bus to obtain the bits of the command or opcode of the SPI communication being communicated via the SPI interconnect. In some cases, the command is sent from the system host to the SPI flash device.

[0056] At 704, the SPI command filter compares each command to a table of commands that the peripheral device is not authorized to execute or receive. In some cases, the SPI command filter indexes the table using the received command or a portion of the received command to determine whether the command is permitted to pass (e.g., filtered) or not. For example, an enable bit indicates or controls whether the command is permitted to pass downstream to the peripheral device or is filtered. In some implementations, an enable bit value of "1" indicates that the command is permitted to pass, and an enable bit value of "0" indicates that the command is filtered by the secure SPI communication module or the command filter.

[0057] In 706, the SPI command filter determines for each command whether the peripheral device has the right to execute it. In response to confirming from 706 that each command has the right to execute, the method proceeds to 708, where the SPI command filter passes the communication containing each command to the peripheral device via the SPI interconnect.

[0058] Alternatively, in response to determining that each command does not have the right to execute, the method proceeds to 710, where the SPI command filter can perform a countermeasure operation to prevent the peripheral device from receiving or processing at least a portion of the command for which it has no authority. To do this, the SPI command filter gates the SPI clock line to the peripheral device at 710. This can prevent the propagation of clock beats, transitions, or signals to the peripheral chip, thereby preventing the peripheral device from consuming or processing at least a portion of the command. In some cases, the SPI command filter gates the SPI clock line on or near the eighth beat or clock cycle, such that the eighth bit command is communicated to the peripheral device, thereby causing the peripheral device to discard the unauthorized command.

[0059] At 712, the SPI command filter de-asserts the SPI chip select line to the peripheral device. In some cases, the SPI command filter de-asserts the SPI chip select line on or near the 8th beat or clock cycle, such that the 8th bit command is communicated to the peripheral device. In an aspect, by de-asserting (or asserting depending on the logic polarity) the SPI chip select line while the SPI clock is gated or interrupted, the SPI command filter can toggle the SPI chip select line without causing glitches on the SPI chip select line or the SPI peripheral. By doing so, the SPI command filter can prevent the peripheral device from consuming or processing the 8th bit of the command, thereby causing or forcing the peripheral device to discard or otherwise reject an unauthorized command or a received portion thereof. In some implementations, the SPI command filter can de-assert the chip select line and gate the clock signal either simultaneously or within a short time frame, e.g., less than half of the SCK period (e.g., 10 - 50 nanoseconds at 25 MHz - 100 MHz). This can be effective in preventing the de-assertion of the chip select line from causing glitches in the peripheral device. At 714, the SPI command filter can resume the SPI clock line when the host releases the upstream chip select line, thereby enabling continuous operation of the SPI interconnect.

[0060] FIG. 8 shows an exemplary method 800 for manipulating command addresses to enable alternating binary image access according to one or more aspects. In various aspects, the SPI command filter 116 or the secure SPI communication module can implement the operations of method 800 and enable A / B mode binary images or split access of the flash memory device.

[0061] At 802, a secure SPI communication module or a RoT device of the system accesses an SPI flash memory device via an SPI interconnect that couples the host of the system to the flash memory device. The flash memory device can include multiple partitions in which different binary images or other information of the host system are stored. At 804, the secure SPI communication module or the RoT device verifies a binary image stored in a first partition of the SPI flash memory device.

[0062] Optionally, at 806, in response to verifying that the binary image is authentic, the secure SPI communication module or the RoT device enables the host of the system to load the binary image from the SPI flash memory device. Optionally, at 808, the secure SPI communication module traverses an SPI interconnect for accessing a second partition of the SPI flash memory device and manipulates one or more address bits of a command. At 810, the secure SPI communication module enables the host of the system to load another binary image from the second partition of the SPI flash memory device.

[0063] Exemplary system-on-chip FIG. 9 shows various components of an exemplary system on chip 900 (SoC900) that can perform secure SPI communication according to one or more aspects. The SoC900 can be implemented as a single or multiple fixed, mobile, stand-alone, or embedded device in any form of consumer, computer, portable, user, server, communication, telephone, navigation, gaming, audio, camera, messaging, media playback, and / or other types of SoC-compatible devices such as device 102 shown in or described with reference to FIG. 1. One or more of the components shown can be implemented as separate components, modules, IP blocks, or as integrated components in at least one integrated circuit of the SoC900. Generally, the various components of the SoC900 are coupled via an interconnect 120 and / or one or more fabrics that support communication between components according to one or more aspects of secure SPI communication.

[0064] The SoC900 can include one or more communication transceivers 124 that enable wired and / or wireless communication of device data 110, such as received data, transmitted data, or other information identified above. Examples of communication transceivers 124 include near field communication (NFC) transceivers, wireless personal area network (WPAN) wirelesses compliant with various IEEE802.15 (Bluetooth™) standards, wireless local area network (WLAN) wirelesses compliant with any of various IEEE802.11 (WiFi™) standards, wireless wide area network (WAN) (WWAN) wirelesses for cellular connectivity (e.g., compliant with the 3rd Generation Partnership Project (3GPP®)), wireless metropolitan area network (MAN) (WMAN) wirelesses compliant with various IEEE802.16 (WiMAX™) standards, infrared (IR) transceivers compliant with the Infrared Data Association (IrDA) protocol, and wired local area network LAN Ethernet transceivers.

[0065] The SoC900 can also include one or more data input / output ports 126 (I / O ports 126) through which any type of data, media content, and / or other inputs, such as user-selectable inputs, messages, applications, music, TV content, recorded video content, and any other type of audio, video, and / or image data received from any content and / or data source, including sensors such as microphones or cameras, can be communicated. The data I / O ports 126 can include USB ports for fiber optic interconnects or cables, coaxial cable ports, fiber optic ports, and other serial or parallel connectors (including internal connectors) for operatively coupling flash memories, optical media writers / readers (e.g., DVDs, CDs), etc. These data I / O ports 126 can be used to couple the SoC to components, peripherals, or accessories such as keyboards, microphones, cameras, or other sensors.

[0066] The SoC900 of this example can include at least one processor 106 (e.g., any one or more of an application processor, a microprocessor, a digital signal processor (DSP), a controller, etc.), which processes (e.g., executes) computer-executable instructions to control the operation of the device, and a combined processor and memory system (e.g., implemented as part of the SoC). In an aspect, the processor 106 can execute computer-readable instructions (e.g., an operating system or firmware) to implement the host function of the SoC900 that interacts with other components and / or peripheral blocks of the SoC. The processor 106 can be implemented as an application processor, an embedded controller, a microcontroller, a security processor, an artificial intelligence (AI) accelerator, etc. Generally, a processor or processing system can be implemented at least partially in hardware, which can include an integrated circuit or on-chip system, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), and other implementation components in silicon and / or other materials.

[0067] Alternatively or additionally, the SoC900 can be implemented using any one or a combination of electronic circuit portions that can include software, hardware, firmware, or fixed logic circuitry implemented in connection with the processing and control circuitry shown generically at 902 (as electronic circuit portion 902). This electronic circuit portion 902 can implement executable or hardware-based modules (not shown in FIG. 9) through processing / computer-executable instructions stored on a computer-readable medium, through logic circuitry and / or hardware (such as an FPGA), etc.

[0068] In one aspect, SoC900 includes an interconnect 120, which can include any one or more of a system bus, link, channel, interconnect, crossbar, data transfer system, or other switch fabric that couples various components within the device to enable various aspects of secure PSI signaling and / or communication. The system bus or internet can include any one or more of different bus structures such as a memory bus or memory controller, SPI bus, SPI interconnect, peripheral bus, parity block, CRC block, ECC block, TU-LU fabric, universal serial bus, and / or a processor or local bus that utilizes any of a wide variety of bus architectures, or combinations thereof.

[0069] SoC900 also includes one or more memory devices 904 that enable data storage. Examples include random access memory (RAM), non-volatile memory (e.g., read-only memory (ROM), flash memory, erasable programmable read-only memory (EPROM), and electrically erasable programmable read-only memory (EEPROM)), and disk storage devices. One or more of the memory devices 904 can communicate via an SPI interconnect coupled to an SPI command filter 116 and / or an SPI clock controller 118 that implement the aspects of secure SPI communication described herein. The memory devices 904 can be distributed across different logical memory levels of the system and different physical components. The memory devices 904 provide a data storage mechanism for storing device data 110, other types of code and / or data, and various device applications 906 (e.g., software applications or programs). For example, an operating system 908 can be maintained as software instructions executed by a processor 106 within the memory device 904.

[0070] In some implementations, the SoC 900 also includes an audio and / or video processing system 910 that processes audio data and / or passes audio and video data to the audio system 912 and / or the display system 914 (e.g., a video buffer or the screen of a smartphone or camera). The audio system 912 and / or the display system 914 can include any device that processes, displays, and / or otherwise renders audio, video, display, and / or image data. The display data and the audio signal can communicate with the audio components and / or the display components via other similar communication links such as an RF (radio frequency) link, an S-video link, an HDMI (High-Definition Multimedia Interface), a composite video link, a component video link, a DVI (Digital Video Interface), an analog audio connection, a video bus, or a media data port 916. In some implementations, the audio system 912 and / or the display system 914 are external or separate components of the SoC 900. Alternatively, the display system 914 can be an integrated component of the SoC 900, such as part of an integrated touch interface, for example.

[0071] The SoC 900 of FIG. 9 can be an exemplary implementation of the device 102 of FIG. 1, or an exemplary implementation of a device or system that can execute the secure SPI communication aspects described with reference to FIGS. 1-8. For this reason, the SoC 900 can include a security circuitry 112 (e.g., a RoT device), an SPI command filter 116, and / or an SPI clock controller 118. These can be separate circuitry or IP blocks, or can be included as part of another IC chip or device such as the processor 106, the electronic circuitry 902, or the memory device 904. Thus, one or more of the components shown can be integrated on the same semiconductor substrate, semiconductor package, IC chip, SoC, or single printed circuit board (PCB).

[0072] As shown, the security circuit section 112 of the SoC900 is implemented using instances of an SPI command filter 116 and an SPI clock controller 118, which can be configured (e.g., as a secure SPI communication module) or can include components as described in FIGS. 1-5. Thus, the security circuit section 112, the SPI command filter 116, and the SPI clock controller 118 can enable the SoC900 to implement the secure SPI communication modes described herein. For example, the SPI command filter 116 can monitor the communications exchanged between the host of the SoC102 and the flash memory module of the SoC102 (e.g., the memory device 904). In an aspect, the SPI command filter 116 compares each command of the communications transmitted by the host with information indicating which commands the flash memory module does not have the right to execute. Based on the comparison, the SPI command filter 116 determines that one of the respective commands is one of the commands that the flash memory module does not have the right to execute (e.g., a status register write command). In response to the determination, the SPI command filter 116 can de-assert the chip select line of the flash memory module or can gate or pause the SPI clock line of the flash memory module using the SPI clock controller 118. By doing so, the SPI command filter 116 can prevent the flash memory module from receiving or processing at least a portion of the unauthorized commands, thereby preventing the unauthorized commands from compromising the security of the flash memory module. Alternatively or additionally, the SPI command filter 116 or the secure SPI communication module can verify the integrity of the binary image stored in the first section of the flash memory module.If the integrity verification fails, the SPI command filter 116 can change the address of the SPI interconnect transaction to cause the host to load a different binary image from the second partition of the flash memory module to prevent the host from loading an unverified and possibly security-compromised binary image from the first partition. Thus, the concept of secure SPI communication described herein can be implemented by or in conjunction with the SoC 900 of FIG. 9.

[0073] Unless the context clearly requires otherwise, the use of the term "or" in this specification may be considered to permit the inclusion or application of one or more of the items connected by the term "inclusive disjunction" or "or" (e.g., the phrase "A or B" may be interpreted as permitting only "A", only "B", or both "A" and "B"). Also, as used herein, the phrase referring to "at least one of" a list of items refers to any combination of those items, including a single member. For example, "at least one of a, b, or c" includes a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiple of the same elements (e.g., a-a, a-a-a, a-a-b, a-a-c, a-b-b, a-c-c, b-b, b-b-b, b-b-c, c-c, and c-c-c, or any other order of a, b, and c). Further, the items represented in the accompanying figures and the terms discussed in this specification may indicate one or more items or terms, and thus, the single or plural forms of the items and terms in this written description may be referred to interchangeably. The aspects of secure SPI communication are described in language specific to certain features / methods, but the subject matter of the appended claims is not necessarily limited to the specific features or methods described. Rather, the specific features and methods are disclosed as exemplary implementations of secure SPI communication.

[0074] In the following example, an exemplary implementation of a secure SPI pass-through module is defined and described. modulespi_passthrough importspi_device_pkg::*; ( inputclk_i, / / SPI receives clk inputrst_ni, / / SPI is reset inputclk_out_i, / / SPI outputs clk The configuration command filter information can be provided as a 256-bit register. If the command congif is stored in the DPSRAM, this will be subject to change. If this is supported, the command config is valid in the sixth command cycle and only 8 bits are provided. input[255:0]cfg_cmd_filter_i, / / Address operation input[31:0]cfg_addr_mask_i, input[31:0]cfg_addr_value_i, Address mode: input cfg_addr_4b_en_i, input spi_mode_espi_mode_i, For SPI in, the pass-through module can reuse the existing spi_s2p and cmdparse. However, the pass-through supports the A / B binary scheme using its own s2p and cmdparse. input host_sck_i, input host_csb_i, input [3:0]host_s_i, output logic[3:0]host_s_o, / / clk_out_i domain ouyput logic[3:0]host_s_en_o, / / clk_out_i domain In some implementations, it outputs passthrough_req_t passthrough_o from SPI to SPI_HOST and downstream devices from the terminal, and inputs passthrough_rsp_t passthrough_i.

[0075] In the case of the mailbox indicator, when the read command is within the mailbox address and the mailbox function is enabled, the "read command" process module sends the signal through the pass-through and takes control of the SPI line. If this signal is asserted during the address phase, the pass-through drops CSb to the SPI flash device and waits for the host's CSb de-assertion. input mailbox_hit_i, / / Event / / "cmd_filtered": Indicator of the incoming command filter that has been filtered out output event_cmd_filtered_o ); In connection with the secure SPI pass-through, several definitions are defined as follows. State typedef enum logic[2:0]{ In the idle state, the incoming SPI is transferred to SPI_HOST and finally to the SPI flash device. StIdle, When the beat reaches the 8th beat (strictly speaking, 7 and a half), the state machine can check the incoming data and determine whether to block the command or continue to proceed to the downstream device based on the given config and cmd_filter. StFilter, When the command is filtered, the IP from this SCK to SPI_HOST can be turned off, and CSb can be de-asserted at StWait. SCK will be turned off at StFilter. In this waiting state, the state machine waits for the CSb de-assertion from the host system. StWait, Output command handling - This is mostly replicated code from the SPI flash mode, but exists here to control the output enable. In the pass-through mode, when the command is permitted, data originates from the downstream device, but no hint of the output state (high-Z or driving) is given. Therefore, the pass-through module controls the "oe" of the upstream pads according to the SPI protocol. This follows the same protocol as described in the read command module, status module, and SFDP / JEDEC module. When St from StIdle or StAddress moves to StHighZ, a waiting timer is set thereby. When the waiting timer expires and StHighZ moves to StDriving, this does not progress until CSb is asserted. StDriving, StHighZ, In an aspect, the address operation can be implemented as described below. For example, one special feature of the SPI pass-through is the A / B binary image support. The logic can exchange certain bits of the data with pre-configured values. In this state, the logic examines the addr_mask and the data and exchanges the lines if necessary. After this, ST moves to StDriving or StHighZ. If the address hits the Mailbox area and SW enables the mailbox, ST cancels the current transaction and moves to the StWait state. StAddress }passthrough_st_e; passthrough_st_est, st_d; Exemplary command types and various commands The pass-through module may loosely track the command phase instead of strictly following all bits on the SPI line. Commands in the SPI flash can be classified as follows. / / -{Address,PayloadOut}: An example is ReadData. / / -{Address,Dummy,PayloadOut}: FastRead / Dual / Quad commands have a dummy. / / -{Dummy,PayloadOut}: Releases power-down / Manufacturer ID. / / -{PayloadOut}: The device sends data to the host immediately after the opcode. / / -{Address,PayloadIn}: The host sends back the address and payload. / / -{PayloadIn}: The host sends the payload without an address hint. / / -None: The command completes without an address payload (in / out). When the received command has more than one state, the counter value is set to assist the state machine to move to the next state at precise timing. The "cmd_type_t" structure has information for the command. The actual value of the command is a compile-time parameter. The logic latches the parameters into this structure when receiving an 8-bit opcode and references this throughout the transaction.

[0076] Exemplary address etc. driven by the host after the opcode counter localparam int unsigned MaxAddrBit = 32; localparam int unsigned AddrCntW = $clog2(MaxAddrBit); Exemplary dummy localparam int unsigned MaxDummyBit = 8; localparam int unsigned DummyCntW = $clog2(MaxDummyBit); typedef enum logic { PayloadIn = 1’b0, PayloadOut = 1’b1 } payload_dir_e; typedef struct packed { There is an address logic addr_en; When swap_en is 1, the logic replaces incomindaddr with a pre - configured value for certain bits. logic addr_swap_en; When it is 1, addr_size is affected by the "cfg_addr_4b_en_i" logic addr_4b_affected.

[0077] Example where there is a dummy logic dummy_en; Payload direction: When payload_en is set, the command has payloads in both directions. "payload_dir" determines input (0) or output (1). logic[3:0] payload_en; payload_dir_e payload_dir; In the aspect, addr_size is determined based on "addr_4b_affected". If it is 1 and "cfg_addr_4b_en_i" is 1, "addr_size" is 31. Otherwise, it is set to 23. logic[AddrCntW - 1:0] addr_size; logic[DummyCntW - 1:0] dummy_size; } cmd_type_t; localparam cmd_type_t CmdInfoNone = '{ addr_en: 1’b0, addr_swap_en: 1’b0, addr_4b_affected: 1’b0, dummy_en: 1’b0, payload_en: 4’h 0, payload_dir: PayloadIn, addr_size: ’0, dummy_size: ’0 }; localparam cmd_type_t CmdInfoPayloadIn=’{ addr_en: 1’b0, addr_swap_en: 1’b0, addr_4b_affected: 1’b0, dummy_en: 1’b0, payload_en: 4’h 1, payload_dir: PayloadIn, addr_size: ’0, dummy_size: ’0 }; localparam cmd_type_t CmdInfoPayloadOut=’{ addr_en: 1’b0, addr_swap_en: 1’b0, addr_4b_affected: 1’b0, dummy_en: 1’b0, payload_en: 4’h 2, / / S[1] payload_dir: PayloadOut, addr_size: ’0, dummy_size: ’0 }; localparam cmd_type_t CmdInfoAddrPayloadIn=’{ addr_en: 1’b1, addr_swap_en: 1’b0, addr_4b_affected: 1’b1, dummy_en: 1’b0, payload_en: 4’h1, / / Only S[0] payload_dir: PayloadIn, / / The host sends data addr_size: ’0, / / Determined by logic dummy_size: ’0 }; localparam cmd_type_t CmdInfoAddrPayloadInQuad = ’{ addr_en: 1’b1, addr_swap_en: 1’b0, addr_4b_affected: 1’b1, dummy_en: 1’b0, payload_en: 4’hF, / / S[3:0] payload_dir: PayloadIn, / / The host sends data addr_size: ‘0, / / Determined by logic dummy_size: ’0 }; localparam cmd_type_t CmdInfoAddrPayloadOut = ’{ addr_en: 1’b1, addr_swap_en: 1’b1, addr_4b_affected: 1’b1, dummy_en: 1’b0, payload_en: 4’h2, / / Only S[1] payload_dir: PayloadOut, / / The flash device sends data addr_size: ‘0, / / Determined by logic dummy_size: ’0 }; / / The payload excluding address + dummy + address is always 3B localparam cmd_type_t CmdInfoAddr3BDummyPayloadOut='{ addr_en: 1'b1, addr_swap_en: 1'b0, addr_4b_affected: 1'b0, dummy_en: 1'b1, payload_en: 4'h 2, / / Only S[1] payload_dir: PayloadOut, / / The flash device sends data addr_size: '0, / / Logic determines dummy_size: 'h 7 }; localparam cmd_type_t CmdInfoAddrDummyPayloadOut='{ addr_en: 1'b1, addr_swap_en: 1'b1, addr_4b_affected: 1'b1, dummy_en: 1'b1, payload_en: 4'h 2, / / Only S[1] payload_dir: PayloadOut, / / The flash device sends data addr_size: '0, / / Logic determines dummy_size: 'h 7 }; localparam cmd_type_t CmdInfoAddrDummyPayloadOutDual='{ addr_en: 1'b1, addr_swap_en: 1'b1, addr_4b_affected: 1'b1, dummy_en: 1'b1, payload_en: 4'h 3, / / Only S[1:0] payload_dir: PayloadOut, / / The flash device transmits data addr_size: ‘0, / / Determined by logic dummy_size: ’h 7 }; localparam cmd_type_t CmdInfoAddrDummyPayloadOutQuad=’{ addr_en: 1’b1, addr_swap_en: 1’b1, addr_4b_affected: 1’b1, dummy_en: 1’b1, payload_en: 4’hF, / / S[3:0] payload_dir: PayloadOut, / / The flash device transmits data addr_size: ‘0, / / Determined by logic dummy_size: ’h 7 }; localparam cmd_type_t CmdInfoAddr=’{ addr_en: 1’b1, addr_swap_en: 1’b0, addr_4b_affected: 1’b0, / / TODO:?? dummy_en: 1’b0, payload_en: 4’h 0, payload_dir: PayloadOut, / / The flash device transmits data addr_size: ‘0, / / Determined by logic dummy_size: ’h 0 }; localparam cmd_type_t PassThroughCmdInfo

[0256] =’{ CmdInfoNone, / / 8’h 00 CmdInfoPayloadIn, / / 8’h 01 Status 1 write CmdInfoAddrPayloadIn, / / 8’h02 Page Program CmdInfoAddrPayloadOut, / / 8’h03 Data Read CmdInfoNone, / / 8’h04 Write Disable CmdInfoPayloadOut, / / 8’h05 Status 1 Read CmdInfoNone, / / 8’h06 Write Enable CmdInfoNone, / / 8’h07 CmdInfoNone, / / 8’h08 CmdInfoNone, / / 8’h09 CmdInfoNone, / / 8’h0A CmdInfoAddrDummyPayloadOut, / / 8’h0B Fast Read CmdInfoNone, / / 8’h0C CmdInfoNone, / / 8’h0D CmdInfoNone, / / 8’h0E CmdInfoNone, / / 8’h0F CmdInfoNone, / / 8’h10 CmdInfoPayloadIn, / / 8’h11 Status 3 Write CmdInfoNone, / / 8’h12 CmdInfoNone, / / 8’h13 CmdInfoNone, / / 8’h14 CmdInfoPayloadOut, / / 8’h15 Status 3 Read CmdInfoNone, / / 8’h16 ... CmdInfoNone, / / 8’h1F CmdInfoAddr, / / 8’h20 Sector Erase (4kB) CmdInfoNone, / / 8’h21 ... CmdInfoNone, / / 8’h30 CmdInfoPayloadIn, / / 8’h 31 Status 2 Write CmdInfoAddrPayloadInQuad, / / 8’h 32 Quad Input Page Program CmdInfoNone, / / 8’h 33 CmdInfoNone, / / 8’h 34 CmdInfoPayloadOut, / / 8’h 35 Status 2 Read CmdInfoAddr, / / 8’h 36 Individual Block Lock CmdInfoNone, / / 8’h 37 CmdInfoNone, / / 8’h 38 QPI (Filtered) Input CmdInfoAddr, / / 8’h 39 Individual Block Unlock CmdInfoNone, / / 8’h 3A CmdInfoAddrDummyPayloadOutDual, / / 8’h 3B Fast Read Dual Out CmdInfoNone, / / 8’h 3C CmdInfoAddrPayloadOut, / / 8’h 3D Read Block Lock CmdInfoNone, / / 8’h 3E CmdInfoNone, / / 8’h 3F CmdInfoNone, / / 8’h 40 CmdInfoNone, / / 8’h 41 CmdInfoNone, / / 8’h 42 TODO CmdInfoNone, / / 8’h 43 CmdInfoNone, / / 8’h 44 TODO CmdInfoNone, / / 8’h 45 CmdInfoNone, / / 8’h 46 CmdInfoNone, / / 8’h 47 CmdInfoNone, / / 8’h 48 TODO CmdInfoNone, / / 8’h 49 CmdInfoNone, / / 8’h 4A CmdInfoNone, / / 8’h 4B Read unique ID (TODO) CmdInfoNone, / / 8’h 4C CmdInfoNone, / / 8’h 4D CmdInfoNone, / / 8’h 4E CmdInfoNone, / / 8’h 4F CmdInfoNone, / / 8’h 50 CmdInfoNone, / / 8’h 51 CmdInfoAddr, / / 8’h 52 Block erase (32kB) CmdInfoNone, / / 8’h 53 CmdInfoNone, / / 8’h 54 CmdInfoNone, / / 8’h 55 CmdInfoNone, / / 8’h 56 CmdInfoNone, / / 8’h 57 CmdInfoNone, / / 8’h 58 CmdInfoNone, / / 8’h 59 CmdInfoAddr3BDummyPayloadOut, / / 8’h 5A SFDP read CmdInfoNone, / / 8’h 5B ... CmdInfoNone, / / 8’h 6A CmdInfoAddrDummyPayloadOutQuad, / / 8’h 6B Fast read quad out CmdInfoNone, / / 8’h 6C ... CmdInfoNone, / / 8’h9E CmdInfoPayloadOut, / / 8’h9F JEDEC ID CmdInfoNone, / / 8’hA0 ... CmdInfoNone, / / 8’hD7 CmdInfoAddr, / / 8’hD8 Block erase (64kB) CmdInfoNone, / / 8’hD9 ... CmdInfoNone / / 8’hFF }; Examples that cannot be synthesized in the DC localparam cmd_type_tPassThroughCmdInfoOld

[256] = '{ / / 8’h 00 ’h 00: CmdInfoNone, / / 8’h 01 Write status 1 ’h 01: CmdInfoPayloadIn, / / 8’h 15 Write status 2 ’h 31: CmdInfoPayloadIn, / / 8’h 11 Write status 3 ’h 11: CmdInfoPayloadIn, / / 8’h 02 Page program ’h 02: CmdInfoAddrPayloadIn, / / 8’h 32 Quad input page program: Filtering is expected ’h 32: CmdInfoAddrPayloadInQuad, / / 8’h 03 Data read ’h 03: CmdInfoAddrPayloadOut, / / 8’h 04 Write disable ’h 04: CmdInfoNone, / / 8’h 05 Read status 1 ’h 05: CmdInfoPayloadOut, / / 8’h 35 Read status 2 ’h 35: CmdInfoPayloadOut, / / 8’h 15 Read status 3 ’h 15: CmdInfoPayloadOut, / / 8’h 06 Write enable ’h 06: CmdInfoNone, / / 8’h 0B Fast Read ’h 0B: CmdInfoAddrDummyPayloadOut, / / 8’h 3B Fast Read Dual Output ’h 3B: CmdInfoAddrDummyPayloadOutDual, / / 8’h 6B Fast Read Quad Output ’h 6B: CmdInfoAddrDummyPayloadOutQuad, / / 8’h 20 Sector Erase (4kB) ’h 20: CmdInfoAddr, / / 8’h 52 Block Erase (32kB) ’h 52: CmdInfoAddr, / / 8’hD8 Block Erase (64kB) ’hD8: CmdInfoAddr, / / 8’h 36 Individual Block Lock ’h 36: CmdInfoAddr, / / 8’h 39 Individual Block Unlock ’h 39: CmdInfoAddr, / / 8’h 3D Read Block Lock ’h 3D: CmdInfoAddrPayloadOut, / / 8’h 38 Enter QPI: Filtering Is Expected ’h 38: CmdInfoNone, / / 8’h 42 Program Security Register / / 8’h 44 Erase Security Register / / 8’h 48 Read Security Register / / 8’h 4B Read Unique ID / / 8’h 5A Read SFDP ’h 5A: CmdInfoAddr3BDummyPayloadOut, / / 8’h 90 Manufacturing / Device ID / / 8’h 9F JEDEC ID ’h 9F: CmdInfoPayloadOut, Default: CmdInfoNone }; * / Exemplary signals Internal clock logic[3:0]host_s_en_inclk; logic[3:0]device_s_en_inclk; Indicates whether the pass - through mode is enabled logicis_active; assignis_active=(spi_mode_i==PassThrough); logic[7:0]opcode,opcode_d; When the filter becomes 1 in the 8th beat, lower the SCK enable signal to the CG cell, and at the 8th posedge of SCK, csb_deassert becomes 1. logicfilter; When it is 1, SCK propagates to the downstream SPI flash device.

[0078] logicsck_gate_en; When the control from CSb to the downstream device is 1, CSb is de - asserted. This signal is glitch - sensitive. This value is changed at the SCK posedge. It does not directly drive the CSb output. The downstream CSb is logically OR - ed with this and the CSb from the host system. logiccsb_deassert; bitcn for counting up the counter to start - dummy localparam int unsigned MaxBeat=8+32+8; / / Cmd+Addr+Dummy localparam int unsigned BitCntW=$clog2(MaxBeat); logic[BitCntW-1:0]bitcnt; Address, etc. driven by the host after the opcode counter logic[AddrCntW-1:0] addrcnt, addrcnt_outclk; Dummy counter logic[DummyCntW-1:0] dummycnt, dummycnt_d; END: Counter Exemplary events assign event_cmd_filtered_o = filter; Exemplary mailbox hits. logic mailbox_hit; always_ff@(posedge clk_i or negedge rst_ni) begin if (!rst_ni) mailbox_hit <= 1'b0; / / Reset by CSb else if (mailbox_hit_i) mailbox_hit <= 1'b1; / / Set by event end Exemplary data path Opcode Latch assign opcode_d = {opcode[6:0], host_s_i[0]}; always_ff@(posedge clk_i or negedge rst_ni) begin if (!rst_ni) begin opcode <= 8'h00; end else if (bitcnt < BitCntW'(8)) begin opcode <= opcode_d; end end Command filter: CSb control always_ff@(posedge clk_i or negedge rst_ni) begin if (!rst_ni) csb_deassert <= 1'b0; else if (filter) csb_deassert <= 1'b1; end Looking at the above waveform, examine why sck_gate_en is the inverse of filter OR csb_deassert. assign sck_gate_en = ~(filter | csb_deassert); Exemplary Bitcnt counter, Bitcnt increases until it reaches the maximum value and then waits for reset. always_ff @(posedge clk_i or negedge rst_ni) begin if (!rst_ni) begin bitcnt <= '0; end else if (bitcnt != '1) begin bitcnt <= bitcnt + BitCntW'(1); end end Exemplary Latch, only 2 bits in the 7th cmb opcode logic cmd_7th; / / 7th beat of the transaction logic cmd_8th; / / 8th beat of the transaction logic [1:0] cmd_filter; assign cmd_7th = (bitcnt == BitCntW'(6)); assign cmd_8th = (bitcnt == BitCntW'(7)); always_ff @(posedge clk_i or negedge rst_ni) begin if (!rst_ni) begin cmd_filter <= 2'b00; end else if (cmd_7th) begin In this example, the 7th beat cmd_filter latches 2 bits from cfg_cmd_filter_i.

[0079] This reduces the last filter data path from multiplexing 256 to simply mux2.

[0080] If the following syntax does not function, it can be replaced for(int unsigned i=0;i<128;i++)begin if(i==opcode[6:0])cmd_filter<=cfg_cmd_filter_i[2*i+:2]; end cmd_filter<=cfg_cmd_filter_i[{opcode_d[6:0],1’b0}+:2]; end end Example of command InfoLatch cmd_type_t cmd_info,cmd_info_d; cmd_type_t[1:0]cmd_info_7th; logic cmd_info_latch; always_ff@(posedge clk_i or negedge rst_ni)begin if(!rst_ni)begin cmd_info_7th<=’0; end else if(cmd_7th)begin cmd_info_7th<={PassThroughCmdInfo[{opcode_d[6:0],1’b1}], PassThroughCmdInfo[{opcode_d[6:0],1’b0}]}; end end always_ff@(posedge clk_i or negedge rst_ni)begin if(!rst_ni)begin cmd_info<=’0; end else if(cmd_info_latch)begin Example of latch: Only two cmd_info when the 7th bit arrives. Next, select between the two at the 8th beat for cmd_info_d to reduce timing.

[0081] cmd_info <= cmd_info_d; end end always_comb begin cmd_info_d = ’0; if (cmd_8th) begin Example of latch: Only two cmd_info when the 7th bit arrives. Next, select between the two at the 8th beat for cmd_info_d to reduce timing.

[0082] cmd_info_d = cmd_info_7th[host_s_i[0]]; Example of TODO: Addr size if (cmd_info_7th[host_s_i[0]].addr_4b_affected) begin cmd_info_d.addr_size = (cfg_addr_4b_en_i) ? AddrCntW’(31) : AddrCntW’(23); end Example when dummy_size is set within the state machine end end Exemplary address exchange logic addr_set; logic addr_phase, addr_phase_outclk; assign addr_phase = (st == StAddress); always_ff @(posedge clk_i or negedge rst_ni) begin if (!rst_ni) begin addrcnt <= ’0; end else if (addr_set) begin / / When addr_set is 1, cmd_info has not been latched yet.

[0083] addrcnt <= cmd_info_d.addr_size; end else if (addrcnt!= ’0) begin addrcnt <= addrcnt - AddrCntW’(1); end end always_ff @(posedge clk_out_i or negedge rst_ni) begin if (!rst_ni) addrcnt_outclk <= ’0; else addrcnt_outclk <= addrcnt; end Based on AddrCnt, the logic is swapped.

[0084] TODO: Handle cases of DualIO and QuadIO logic addr_swap; assign addr_swap = cfg_addr_mask_i[addrcnt_outclk] ? cfg_addr_value_i[addrcnt_outclk] : host_s_i[0]; In the aspect, address swapping occurs in the outclk domain. The state machine operates in the inclk domain. The state generates a mux selection signal. The signal latched in the outclk domain activates the mux. always_ff @(posedge clk_out_i or negedge rst_ni) begin if (!rst_ni) addr_phase_outclk <= 1’b0; else addr_phase_outclk <= addr_phase; end Exemplary dummy counter logic dummy_set; always_ff@(posedge clk_i or negedge rst_ni)begin if(!rst_ni)dummycnt<='0; else if(dummy_set)begin dummycnt<=dummycnt_d; end end For the example of the pass-through MUX, since addr_phase_outclk is in the outclk domain, addr_swap can be directly used. The addr_swap value is also determined by addrcnt_outclk. assign passthrough_o.s=(addr_phase_outclk) ?{host_s_i[3:1],addr_swap}: host_s_i; logic[3:0]passthrough_s_en; always_ff@(posedge clk_out_i or negedge rst_ni)begin if(!rst_ni)passthrough_s_en<=4'h1; / / S[0] is active by default else passthrough_s_en<=device_s_en_inclk; end assign passthrough_o.s_en=passthrough_s_en; assign host_s_o=passthrough_i.s; always_ff@(posedge clk_out_i or negedge rst_ni)begin if(!rst_ni)host_s_en_o<='0; / / Input mode else host_s_en_o<=host_s_en_inclk; end assign passthrough_o.sck_gate_en = sck_gate_en; assign passthrough_o.sck = host_sck_i; assign passthrough_o.sck_en = 1’b1; Example of CSb propagation: The csb_deassert signal should be the output of an FF or latch to glitch-free CSb. assign passthrough_o.csb_en = 1’b1; assign passthrough_o.csb = host_csb_i | csb_deassert; passthrough_en assign passthrough_o.passthrough_en = is_active; END: Passthrough Mux Exemplary state machine always_ff @(posedge clk_i or negedge rst_ni) begin if (!rst_ni) begin st <= StIdle; end else begin st <= st_d; end end always_comb begin st_d = st; Exemplary filter filter = 1’b0; Exemplary command Cfg latch cmd_info_latch = 1’b0; Exemplary addr_set addr_set = 1’b0; Exemplary dummy dummy_set = 1’b0; dummycnt_d = ’0; Exemplary output enable host_s_en_inclk = 4’h0; device_s_en_inclk = 4’h1; / / S[0]MOSI is active unique case (st) StIdle: begin if (!is_active) begin st_d = StIdle; end else if (cmd_8th && cmd_filter[host_s_i[0]]) begin st_d = StFilter; filter = 1’b1; Exemplary transmission notification event to SW end else if (cmd_8th) begin cmd_info_latch = 1’b1; Example of bypassing multiple states. The following states are mainly for controlling the output enable signal. However, the StAddress state controls the SPI lines for address exchange in the case of a read command.

[0085] / / Order: addr_en, dummy_en, |payload_en if (cmd_info_d.addr_en) begin st_d = StAddress; addr_set = 1’b1; end else if (cmd_info_d.dummy_en) begin st_d = StHighZ; dummy_set = 1’b1; dummycnt_d = cmd_info_d.dummy_size; end else if (cmd_info_d.payload_en!= 0) begin Example of any input / output payload if (cmd_info_d.payload_dir == PayloadOut) begin st_d = StWait; end else begin st_d = StDriving; end end end end StFilter: begin The command is filtered. Wait until reset(CSb) arrives.

[0086] st_d = StFilter; host_s_en_inclk = 4’h0; / / explicit device_s_en_inclk = 4’h0; end StWait: begin The device returns data to the host. st_d = StWait; Output enable for the host host_s_en_inclk = cmd_info.payload_en; device_s_en_inclk = 4’h0; end StDriving: begin The host sends data to the device st_d = StDriving; Output enable for the device host_s_en_inclk = 4’h0; / / explicit device_s_en_inclk = cmd_info.payload_en; end StHighZ: begin host_s_en_inclk = 4’h0; / / explicit device_s_en_inclk = 4’h0; / / floating if (dummycnt == ’0) begin / / Assume payload_en is not 0 st_d = (cmd_info.payload_dir == PayloadOut)? StWait : StDriving; end end StAddress: begin / / Based on the state, addr_phase is set. Only check whether the counter reaches 0 if (addrcnt == '0) begin if (mailbox_hit_i) begin / / In the address phase, hit the mailbox area. Next, the pass-through filters the command and delegates control to the ReadCmd sub-module.

[0087] st_d = StFilter; filter = 1'b1; end else if (cmd_info.dummy_en) begin st_d = StHighZ; dummy_set = 1'b1; dummycnt_d = cmd_info.dummy_size; end else if (cmd_info.payload_en!= 0) begin st_d = (cmd_info.payload_dir == PayloadOut)? StWait : StDriving; end else begin / / Addr completes the command. Proceed to the waiting state st_d = StWait; end end end default: begin st_d = StIdle; end endcase end Examples of assertions such as when the mailbox hit occurs in the middle rather than at the end of the address phase. ’ASSERT(MailboxHitConflictAddrCnt_A, mailbox_hit_i |-> (addrcnt!= 0)) endmodule: spi_passthrough Additional Example An example of secure SPI communication is provided below.

[0088] Example 1: A method implemented by a security circuit associated with a host of a system for secure serial peripheral interface communication, the method comprising: monitoring, by the host, communications transmitted to a peripheral block of the system coupled to the host via a serial peripheral interface (SPI) interconnect; comparing, by the host, each command of the communications transmitted by the host with information indicating which commands the peripheral block has no authority to execute; determining, based on the comparison, that one of each command is a command that the peripheral block has no authority to execute; and preventing the peripheral block from receiving at least a portion of each command that the peripheral block has no authority to execute.

[0089] Example 2.1: The preventing includes changing a state of a chip select line or a clock line of the SPI interconnect to prevent the peripheral block from receiving at least a portion of each command of the communications transmitted by the host, according to any of the examples.

[0090] Example 2.2: The preventing includes changing a state of a chip select line or a clock line of the SPI interconnect to prevent the peripheral block from receiving at least a portion of each command of the communications transmitted by the host, according to any of the examples.

[0091] Example 3: Each command of the communication includes 8 bits, and changing it includes, in order to prevent at least the 8th bit of each command from being processed by the peripheral block, that the 8th bit of each command is communicated via the SPI interconnect before the 8th clock cycle in which it is communicated, or deasserting the chip select line in this 8th clock cycle, the method according to any of the examples.

[0092] Example 4: Each command of the communication includes 8 bits, and changing it includes, in order to prevent at least the 8th bit of each command from being processed by the peripheral block, that the 8th bit of each command is communicated via the SPI interconnect before the 8th clock cycle in which it is communicated, or gating the clock line in this cycle, the method according to any of the examples.

[0093] Example 5: The peripheral block of the system either does not include a write protection input node, or the write protection input node of the peripheral block is disabled, the method according to any of the examples.

[0094] Example 6: Each command is the first command of the first communication, and the method further includes determining that the second command of the second communication transmitted by the host to the peripheral block includes a status register write command, and changing the status register write command in order to prevent the second communication from changing the status register of the peripheral block, the method according to any of the examples.

[0095] Example 7: Changing the status register write command includes setting the bit positions of the status register write command to predetermined bit values to provide a changed status register write command, and passing the changed status register write command including the predetermined bit values and other bits of the status register write command to the peripheral block, the method according to any of the examples.

[0096] Example 8: Information indicating a command that the peripheral block does not have permission to execute includes a table of commands that the peripheral block does not have permission to execute and commands that the peripheral block has permission to execute, the method according to any of the examples.

[0097] Example 9: The method according to any of the examples, further comprising constructing a table of commands that the peripheral block does not have permission to execute and commands that the peripheral block has permission to execute before monitoring the communication.

[0098] Example 10: Comparing each command of the communication transmitted by the host with the table information includes indexing into the table based on each command and determining whether each command has permission to be executed by the peripheral block, the method according to any of the examples.

[0099] Example 11: The peripheral block of the system includes a memory module coupled to the host via an SPI interconnect, and the memory module includes one of a non-volatile memory or a flash memory, the method according to any of the examples.

[0100] Example 12: The method according to any of the examples, further comprising verifying the binary image stored in the memory module of the system before attempting to load the binary image from the memory module to the host via the SPI interconnect.

[0101] Example 13: Permitting a memory module to transmit a binary image to a host via an SPI interface in response to successful verification of the binary image, or preventing the memory module from transmitting the binary image to the host via the SPI interface in response to unsuccessful verification of the binary image, the method according to any of the examples.

[0102] Example 14: The binary image is a first binary image stored in a first section of the memory module, and the method further includes manipulating an address of a read command for the first binary image to cause the memory module to transmit a second binary image from a second section of the memory module to the host, the method according to any of the examples.

[0103] Example 15: An integrated circuit including circuitry for secure serial peripheral interface communication, the circuitry including a host having a functional core, at least one peripheral block, a serial peripheral interface (SPI) interconnect coupling the host and the at least one peripheral block, and a secure SPI communication module operatively coupled to the SPI interconnect and configured to perform any one of the operations of the above examples.

[0104] Conclusion Although aspects of the described systems and methods for performing secure SPI communication are described in language specific to the features / methods, the subject matter of the appended claims is not necessarily limited to the specific features or methods described as in any of the above examples. Rather, the specific features and methods are disclosed as exemplary implementations of secure SPI communication, and other equivalent features and methods are intended to be included within the scope of the appended claims. Further, it should be understood that various aspects of secure SPI communication are described, and each described aspect can be implemented independently or in relation to one or more other described aspects.

Claims

1. A method implemented by a security circuit associated with a host of a system for secure serial peripheral interface communication, the method comprising: monitoring, by the host, communications transmitted to a peripheral block of the system coupled to the host via a serial peripheral interface (SPI) interconnect; comparing each command of the communications transmitted by the host with information indicating which commands the peripheral block does not have permission to execute; based on the comparison, determining that one of the respective commands includes a status register write command that the peripheral block does not have permission to execute; modifying the status register write command to prevent the status register write command from changing the status register of the peripheral block.

2. Modifying the status register write command comprises: setting bit positions of the status register write command to predetermined bit values to provide a modified status register write command; passing the modified status register write command, including the predetermined bit values and other bits of the status register write command, to the peripheral block. The method according to claim 1.

3. The information indicating commands that the peripheral block does not have permission to execute comprises: a table of commands that the peripheral block does not have permission to execute, and commands that the peripheral block has permission to execute. The method according to claim 1 or 2.

4. The method according to claim 3, further comprising constructing the table of commands that the peripheral block does not have permission to execute and commands that the peripheral block has permission to execute prior to the monitoring of the communications.

5. Comparing each command of the communications transmitted by the host with the information in the table comprises: The method according to claim 3, including indexing into the table based on each of the commands and determining whether each of the commands has the authority to be executed by the peripheral block.

6. The method according to claim 1 or 2, wherein the peripheral block of the system comprises a memory module coupled to the host via the SPI interconnect, and the memory module includes one of a non-volatile memory or a flash memory.

7. The method according to claim 6, further including verifying the integrity of a binary image stored in the memory module of the system before attempting to load the binary image from the memory module to the host via the SPI interconnect.

8. In response to a successful verification of the integrity of the binary image, permitting the memory module to transmit the binary image to the host via the SPI interface, or In response to an unsuccessful verification of the integrity of the binary image, preventing the memory module from transmitting the binary image to the host via the SPI interface, the method according to claim 7 further including this.

9. The binary image is a first binary image stored in a first section of the memory module, and the method includes operating an address of a read command for the first binary image to cause the memory module to transmit a second binary image from a second section of the memory module to the host, the method according to claim 8 further including this.

10. An integrated circuit including a circuit for secure serial peripheral interface communication, the circuit including a host having a functional core, at least one peripheral block, a serial peripheral interface (SPI) interconnect coupling the host and the at least one peripheral block, a secure SPI communication module operatively coupled to the SPI interconnect and configured to perform the operations according to claim 1 or 2, the integrated circuit comprising this.

Images