Security subsystem for remote authentication

Abstract

Techniques for providing remote authentication at an integrated circuit device are described. The integrated circuit device may include a memory. The integrated circuit device may also include a write bitmap including a bitmap that tracks write addresses of a detected memory write operation to the memory. The integrated circuit device may further include a security subsystem configured to send one or more address ranges of interest to the write bitmap and obtain a bitmap state from the write bitmap, the bitmap status indicates that a write address within the one or more address ranges of interest is detected.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of priority to U.S. patent application Ser. No. 17 / 852,083, filed on June 28, 2022, and entitled “SECURITY SUBSYSTEM FOR REMOTE ATTESTATION,” and U.S. patent application Ser. No. 17 / 852,073, filed on June 28, 2022, and entitled “SECURITY SUBSYSTEM FOR EXECUTION VERIFICATION,” the entire contents of which are incorporated herein by reference for all purposes. Background Art

[0003] An integrated circuit device may include various processing elements and memory elements, such as a central processing unit (CPU), a specific domain accelerator (e.g., a neural network accelerator, a digital signal processor, etc.), volatile and non-volatile semiconductor memory, etc. Such elements may allow the integrated circuit device to perform various computing tasks, such as processing and storing data. An example of an integrated circuit device is a system on a chip (SoC), which typically integrates multiple computer components onto a single integrated circuit.

[0004] In some cases, an integrated circuit device such as a SoC may include a security module to protect the device from security threats. The security module may be incorporated into the CPU of the SoC, or may be an independently running module. In some cases, the security module may implement a hardware root of trust, which is typically characterized as an area in the hardware of the device that provides a trusted execution environment (TEE) in which only certain software can run, and further provides certain cryptographic functions, such as the management of encryption keys. It is advantageous to implement a root of trust in hardware because malware cannot tamper with the functions provided by the root of trust. Despite progress in SoC hardware security, certain device vulnerabilities still pose challenges to hardware and software designers. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0006] Figure 1 Demonstrated examples of system-on-chip (SoC) incorporating security subsystems;

[0007] Figure 2 Demonstrated examples of security subsystems;

[0008] Figure 3 Demonstrates an example of executing the validation module;

[0009] Figure 4 Shows an example of the inspector block;

[0010] Figure 5 A method for performing execution verification using a secure subsystem of an integrated circuit device is presented;

[0011] Figure 6 Demonstrates an example of remote authentication module;

[0012] Figure 7 Shows an example of writing bitmap;

[0013] Figure 8 Shows example components of an SoC that may be involved during remote attestation;

[0014] Fig. 9 Various example steps of a method for remote authentication using a security subsystem of an integrated circuit device are presented;

[0015] Fig.10 A method for remote authentication using a security subsystem of an integrated circuit device is presented;

[0016] Fig.11 An example of a network device is shown; and

[0017] Fig.12 Example architectures of one or more service provider computers and / or user devices connected via one or more networks are shown. DETAILED DESCRIPTION

[0018] Integrated circuit devices such as system-on-chip (SoC) may have various software or hardware vulnerabilities that put the user of the device at risk. In some cases, one of several types of attacks may compromise the functionality of the device. Such attacks may include software attacks in a trusted execution environment (TEE), fault injection attacks, side channel attacks through hardware root of trust, etc. In many cases, a single vulnerability may result in the execution of unauthorized code on the device, which may allow an attacker to have unrestricted access to data stored on the device and the full functionality of the device.

[0019] In some cases, an attacker can use a fault injection attack or software bug to subvert secure boot at the boot ROM level and compromise the chain of trust before even a portion of external code is executed. The attacker can then interfere with the code starting from the first image loaded by the boot ROM. The attacker can modify the data before it is loaded and disable any checks to be performed. Therefore, there may not be any code on the device that can be trusted to perform any detection. In the presence of cloud-based authentication, the attacker can simply modify the code to correctly provide answers to queries and pass the check, but then run unauthenticated code that compromises the security of the platform.

[0020] Embodiments of the present disclosure address these and other problems by providing a hardware-level security subsystem that can be integrated into a new or existing architecture of an integrated circuit device (such as a SoC). The security subsystem can be suitable for an integrated circuit device having any of a variety of hardware, firmware, or software components. In some cases, embodiments can be integrated into the SoC to detect and prevent different types of attacks. Embodiments can include a security subsystem that provides a hardened hardware root of trust (RoT), an isolated execution environment, an execution verification engine, and / or a remote authentication engine that allows the device to perform two main security sequences: remote memory authentication (or simply "remote authentication") and execution verification.

[0021] Remote authentication is a security mechanism that allows a trusted entity, called a verifier, to measure one or more properties of an untrusted remote device, called a prover. The properties measured by the authentication scheme depend on the conclusions to be drawn from it. For example, an authentication scheme designed to verify the authenticity of a device may only verify that the prover possesses a private key. Remote authentication is a building block for several security mechanisms, such as execution proof, update proof, and control flow integrity verification. One goal of the authentication scheme described herein is to determine whether a device is running unauthorized critical software. In order to achieve this goal, the ability to authenticate code present in different memory areas of the device is important. This provides the ability to query the device remotely from an authentication server and detect any changes in the code running on the device, whether the changes are caused by vulnerability exploits or fault injection attacks. Authentication can be used to ensure that the device is healthy before performing sensitive operations such as digital rights management (DRM) license acquisition or key provisioning.

[0022] In some cases, having the ability to detect if a device has been compromised can allow a remote server to deny service to the device and revoke its credentials in order to contain damage that the device may have caused. Execution Verification analyzes instructions executed by the device's central processing unit (CPU) core to detect and respond to various software exploit techniques, reduce the software attack surface, and verify the integrity of code execution to determine that the code is executing as expected. Execution Verification can be implemented in any SoC based on any instruction set architecture, including ARM, x86, etc., without modifying the CPU core.

[0023] In the following description, various embodiments will be described. For the purpose of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to those skilled in the art that the embodiments may be practiced without the specific details. In addition, well-known features may be omitted or simplified to avoid confusion with the embodiments being described.

[0024] The figures herein follow a numbering convention in which the first digit or digits correspond to the figure number and the remaining digits identify an element or component in the figure. Similar elements or components between different figures may be identified by using similar numerals. For example, 102 may refer to Figure 1 Component "02" in , and similar components in Figure 2 202. As will be appreciated, the elements shown in the various embodiments herein may be added, exchanged, and eliminated to provide a plurality of additional embodiments of the present disclosure. In addition, the proportions and relative scales of the elements provided in the accompanying drawings are intended to illustrate certain embodiments of the present disclosure and should not be considered in a limiting sense.

[0025] Figure 1 An example of a SoC 100 incorporating a security subsystem 102 according to some embodiments of the present disclosure is shown. SoC 100 may be referred to herein (e.g., in the specification or in the claims) alternatively as an “integrated circuit device,” “integrated circuit,” “electronic circuit,” “circuit,” “computer system,” “electronic system,” “system,” “microarchitecture,” etc. Although security subsystem 102 is Figure 1 100, but in some cases, the security subsystem 102 may be considered to include other hardware elements within the SoC 100 that facilitate and / or are used to implement the functionality of the security subsystem 102, but outside the physical boundaries of the security subsystem 102, such as the write bitmap 122 and the trace bus 124.

[0026] SoC 100 may include a CPU subsystem 104, a domain-specific accelerator 110, a memory subsystem 108, a non-volatile memory 112, and a system interconnect 106. In various instances, the system interconnect 106 may include one or more communication channels to allow communication between components of the SoC 100 (such as one or more buses, grids, matrices, structures, or a combination of these communication channels). For example, the system interconnect 106 may include a network-on-chip (NoC) subsystem that allows components of the SoC 100 to communicate by routing data using addressed packets. In some instances, the components of the SoC 100 may communicate via the system interconnect 106 using an Advanced eXtensible Interface (AXI) bus protocol.

[0027] The CPU subsystem 104 may include a set of processors, processor cores, or CPU cores (where such terms are used interchangeably) that are capable of executing instructions. For example, each core may read and execute program instructions simultaneously with the other cores, thereby increasing the speed of multi-threaded programs. The instructions executed by the processor cores may be stored, for example, in the form of a computer program on a computer-readable storage medium. Examples of processor cores that may be included in the CPU subsystem 104 may include processors that support different ISAs (e.g., ARM, x86 or MIP) processor core developed by others.

[0028] In some instances, the memory subsystem 108 may contain volatile memory. For example, the memory subsystem 108 may include various types of random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), etc. In some instances, the non-volatile memory 112 may include a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), NOR / NAND flash memory, and / or some other suitable storage medium. In some instances, the memory subsystem 108 may include some non-volatile memory. In some cases, some or all of the memory subsystem 108 and / or non-volatile memory 112 may be inside the SoC 100, while in other cases, some or all of the memory subsystem 108 and / or non-volatile memory 112 may be outside the SoC 100.

[0029] The domain-specific accelerator 110 may include one or more processors, each of which is optimized to calculate a dedicated algorithm in a specific domain. The domain-specific accelerator 110 may include a neural network accelerator or processor, a digital signal processor, a graphics processing unit (GPU), a network module (e.g., a WiFi module), etc. The domain-specific accelerator 110 may include a memory element for storing data and instructions used by the domain-specific accelerator 110. For example, a neural network processor may include a first memory buffer for storing input data of an inference operation, a second memory buffer for storing weights associated with the inference operation, and a third memory buffer for storing output data of the inference operation. These memory elements may be any suitable type of memory, such as SRAM.

[0030] The security subsystem 102 may include an execution verification module 140 and a remote authentication module 130, or a plurality of each similar module. Using the execution verification module 140, the security subsystem 102 may continuously perform an execution verification sequence (or simply referred to as "execution verification") at runtime or in response to an external or internal event or request. During execution verification, the execution trace in the CPU core in the CPU subsystem 104 is accessed through the accelerator consistency port (ACP) at runtime, or is captured and sent to the execution verification module 140 (or to multiple execution verification modules) across the trace bus 124, and analyzed to detect any deviations from the expected execution flow. In some instances, each CPU core may include a trace block 182 that captures a trace of executed instructions, converts the execution trace into a compressed format, and sends the execution trace to the execution verification module 140 via one of the trace buses 124 in the set of trace buses. In some instances, each of the trace blocks 182 may include an embedded trace macrocell (ETM) or another suitable component for extracting the executed instructions of the corresponding CPU core. In some examples, each of trace buses 124 can utilize an advanced trace bus (ATB) architecture.

[0031] The execution verification module 140 can decode the execution trace to extract the context ID, execution privilege level, and address of all control transfer instructions. In some instances, the execution verification module 140 can extract the virtual destination address of all branch instructions. In some cases, in order to better perform expected checks on execution verification, a branch broadcast feature can be enabled in the CPU core. In some instances, the execution verification module 140 can extract the return address associated with all function calls.

[0032] One of the checks performed by the execution verification module 140 may be a control flow analyzer check, which checks whether the branch destination address falls within the approved address range. Other checks performed by the execution verification module 140 may include function pointer integrity checks, function call return address checks, control flow integrity checks, and execution signature checks. In the function pointer integrity check, the address is checked for a set of valid predetermined addresses or the valid return address of the function call in the simplified version. In the function call return address check, the return address of the function call is stored in the shadow stack. When the function call returns, the return address will be checked for the return address in the shadow stack. In the control flow integrity check, the signatures of the instructions in the critical loops are calculated and saved. The signatures of these loops are calculated during runtime and compared with the stored signatures. In some embodiments, the loop count is also counted to ensure code integrity. In the execution signature check, the signatures of the instructions and the source, destination, and iteration counts are calculated in the critical code segment and compared with the pre-calculated signatures.

[0033] Remote authentication can be initiated by the security subsystem 102 or by a remote server that sends a challenge to a remote authentication agent running, for example, in a host access port. The remote authentication agent forwards the encrypted challenge to the RoT in the security subsystem 102. The RoT authenticates the challenge and, if successful, forwards it to the remote authentication module 130 to process the authentication request. The remote authentication module 130 can process the request and provide a return code with the last challenge based on the contents of the last modified challenge table (LMCT) and the write bitmap 122. The remote authentication response can include a signature of the contents of the challenged address range, as well as the timestamp of the previous request and any memory writes since the last timestamp.

[0034] The RoT can calculate an authenticated completion code (AIC), and the remote authentication agent can return the AIC to the remote server. The remote authentication response will allow the server to detect any content changes within the challenged address range, as well as any unexpected writes that an attacker may make to replace the memory with the original content, thereby passing the signature verification. If an unauthorized memory write or invalid signature is detected at one of the memories in the SoC, the remote authentication server can take action to limit the availability of this device. For example, the remote server can stop delivering any secure content to this device.

[0035] Figure 2An example of a security subsystem 202 according to some embodiments of the present disclosure is shown. The security subsystem 202 may include a RoT 216, a remote authentication module 230, an execution verification module 240, a security control unit 250, and a subsystem interconnect 214. The subsystem interconnect 214 may include one or more communication channels to allow communication between components (e.g., a bus, grid, matrix, structure, etc.) of the security subsystem 202, and further allow communication with the system interconnect 206. As described above, the execution verification module 240 and the remote authentication module 230 may facilitate a remote authentication sequence and an execution verification sequence, respectively.

[0036] As described above, execution verification can consist of checking the instructions executed by the processor core in order to implement policies on the control flow, detect attacks, and authenticate the executed instructions and / or control flow transformations. Since most attacks will ultimately result in an unexpected change of the control flow or tampering with the execution of instructions, the purpose of execution verification is to detect attacks by verifying control flow transformations and / or executed instructions. Execution verification can detect a wide range of attacks, including code reuse attacks, fault injection, and time of use (TOCTOU). Advantageously, in many instances, execution verification does not require any modifications to the CPU core.

[0037] In some instances, the execution verification module 240 obtains execution traces from the CPU core. In some instances, the trace block (e.g., including the ETM) of each core generates the execution trace from this core. The trace is compressed, multiplexed with other trace sources, and routed through funnels and replicators based on the configuration of the component to end in a trace sink (e.g., a buffer or port). In some instances, the compressed trace may only contain information about the execution of branch instructions that may affect the control flow. It can be assumed that any instructions between the two branches are executed. The execution verification module 240 can retrieve the execution trace through the trace bus 224, the subsystem interconnect 214, and / or the system interconnect 206.

[0038] In some instances, instruction traces may be analyzed to detect fault attacks, TOCTOUs, and authenticate the execution of instructions. It should be noted that an attacker who can overwrite or replace code may create a malicious payload that has the same control flow as the original code and passes all control flow verifications. Since the execution trace contains the addresses of some instructions (including trace sources and branch targets), the execution verification module 240 can use these addresses to retrieve the executed instructions from the memory. In order to be closer to what the CPU core has already obtained and executed, the execution verification module 240 can retrieve the memory content from the L2 cache (and can retrieve the content from the RAM in the case of a cache miss). Since the L2 cache may include instructions related to the L1 cache, the instruction read from the L2 cache indicates what the CPU core has read from the main memory.

[0039] Remote attestation is a security mechanism that can determine if the SoC is running unauthorized critical software. To achieve this, the remote attestation module 230 attempts to authenticate the code present in different memory areas of the SoC. This allows the SoC to be remotely queried from an attestation server to detect any changes in the code running on the SoC, whether caused by a vulnerability exploit or a fault injection attack. Remote attestation can be used to ensure that the SoC is healthy before performing sensitive operations such as digital rights management (DRM) license acquisition or key provisioning.

[0040] One way to prevent TOCTOU attacks is to verify whether the target content has changed at an unexpected time. For example, it is undesirable for a boot loader loaded into memory by a boot ROM to be overwritten before execution, or for some or all sensitive code in a TEE to be overwritten after loading and initialization. By providing some authenticated information about the last modification time of an address range as part of the authentication response, the remote authentication module 230 gives the requester the ability to check whether the address range has been modified at an unexpected time. To do this, the remote authentication module 230 can keep track of all changes to the memory space and associate the changes with a point in time.

[0041] In some instances, the remote authentication module 230 may maintain a set of write bitmaps that track the history of changes to memory content in the memory space of the SoC at a specific granularity (e.g., 1kB, 2kB, or 4kB blocks). In some instances, the remote authentication module 230 may monitor all memory writes to the memory space (e.g., CPU, DMA, and all master devices). Each time a write to a block is detected, the remote authentication module 230 sets its corresponding bit in the write bitmap to 1. The write bitmap may record the write address of the detected memory write, as well as the timestamp associated with the detected memory write.

[0042] In some instances, the remote authentication module 230 may maintain an associated list of authenticated address ranges and their corresponding authentication challenges (referred to as last modified challenges). The remote authentication module 230 may authenticate each authentication request and extract the challenge and address range therefrom. If any of the addresses in the address range has a bit set to 1 in the write bitmap, the remote authentication module 230 looks up the previous challenge corresponding to this address range in the last modified challenge associated list. If there is no challenge in the list, or the challenge value of the current request is greater than the previous challenge, the remote authentication module 230 updates the entry corresponding to this address range in the last modified challenge associated list with the challenge of the current request and clears the corresponding bit in the write bitmap. If the challenge is less than the previous challenge, the authentication request is deemed invalid and is discarded. The remote authentication module 230 may calculate an authenticated integrity code on the content of the address range with the challenge of the current request and include the last modified challenge in the authenticated response.

[0043] In some examples, the security control unit 250 can serve as a control unit for the security subsystem 202. One function of the security control unit 250 can be to receive an alarm signal 256 from the remote authentication module 230 and the execution verification module 240. The alarm signal 256 can indicate that an attack is detected (or a requested behavior is detected) by the remote authentication sequence or the execution verification sequence. The security control unit 250 can handle the detected attack / behavior accordingly, for example, by notifying the remote authentication sequence or the execution verification (e.g., a remote server) of the detected attack / behavior to the requester.

[0044] Another function of the security control unit 250 may be to accumulate all errors from the remote authentication module 230, the execution verification module 240, the RoT 216, and the SoC, and respond according to the selected error policy. In some instances, the security control unit 250 may include an error accumulator that collects errors from these components, compares the number of accumulated errors to the error policy, and takes action based on the comparison. In some instances, the action may include determining that an attack has been detected and notifying the requestor of the remote authentication sequence or execution verification of the detected attack. In a specific instance, when the number of accumulated errors is greater than a threshold, the security control unit 250 may determine that an attack has been detected and take action to reset the SoC.

[0045] Figure 3An example of an execution verification module 340 according to some embodiments of the present disclosure is shown. The execution verification module 340 may include a set of N verification cores 342, each of which is communicatively coupled to one of a set of N trace blocks 382. The trace block 382 may be physically located within the CPU subsystem and coupled to (or integrated with) the processor core. In some examples, the verification core 342 may be communicatively coupled to the trace block 382 via a set of N trace buses 324 that carry execution traces 348. In some examples, the verification core 342 may receive the execution trace 348 via the subsystem interconnect 314 of the security subsystem.

[0046] Each of the verification cores 342 may include a trace decoder 344 and a checker block 346. The trace decoder 344 receives a corresponding execution trace 348, which may include compressed data. In some instances, each packet in the execution trace 348 may include a header byte and one or more payload bytes that uniquely identify the packet. The trace decoder 344 may be able to understand and process each packet in the execution trace 348, even if the packet is simply discarded. In the event that a packet of the execution trace 348 that is not recognized by the trace decoder arrives, the packet will issue an unknown packet message to the checker block 346.

[0047] In some examples, the execution verification module 340 may include a rule block 352 that may store rules and their mappings to different context IDs. The rule block may receive the context ID as input from the checker block 346 and may output one or more rules from a set of rules 354 stored in the rule block 352. The checker block 346 may load the output rules corresponding to the context ID from the rule block 352 and perform execution verification checks on addresses in the execution trace 348 based on the rules. The rules 354 may be loaded to the rule block 352 by the RoT through the subsystem interconnect 314.

[0048] In some examples, the trace decoder 344 identifies a control transfer instruction (e.g., a control flow instruction) in the execution trace 348-1, extracts an address (e.g., a destination address) from the control transfer instruction and the context ID of the instruction, and outputs a message including the address of the control transfer instruction and the context ID of the instruction to the checker block 346. Upon receiving the message, the checker block 346 may load a rule corresponding to the context ID from the rule block 352. The checker block 346 may perform one or more checks on the execution trace 348-1 using the address and the loaded rules. In some cases, each of the loaded rules may correspond to a different check to be performed.

[0049] In some instances, the loaded rules include one or more acceptable or expected address ranges for the destination or return address, thereby allowing the checker block to perform a control flow analyzer check. The checker block 346 performs the check by comparing the destination or return address to the acceptable address range, and if the destination or return address does not fall within any of the acceptable address ranges (or if any other performed check fails), the checker block 346 outputs an alarm signal 356-1. If N>1, the alarm signals 356-1 to 356-N are passed into an OR gate to generate an overall alarm signal 356-N+1, which is passed to the security control unit 350.

[0050] Figure 4 An example of a checker block 446 according to some embodiments of the present disclosure is shown. The checker block 446 can look for error conditions in the decoder output from the trace decoder 444 and generate an alarm signal 456 that is sent to the security control unit 450. In some examples, the checker block 446 can have a pipeline design with two stages: a load rule stage and a check rule stage. In the load rule stage, the trace decoder output is retrieved from the buffer. In some examples, a data packet can be retrieved for each clock cycle. The decoder output from the trace decoder 444 (e.g., the decoder output can include a data packet) can be stored in one of the buffer entries Buf 0-n, as shown in the load rule stage.

[0051] Each decoder output can be processed by a load rule state machine (LRSM). For example, each decoder output can be checked to see if it includes a context ID. If it includes a context ID, the LRSM retrieves the rules from the SRAM in the rule block 452 and loads the rules into the rule registers rule 0-15, as shown. The size of the buffer can be set to accommodate the maximum latency in reading the SRAM without any back pressure on the trace decoder 444 or the trace bus. If the context ID in the decoder output does not match any rule in the rule block 452 or is unsafe, the check rule stage is disabled and the LRSM waits for the next decoder output.

[0052] Some of the decoder outputs may include an address data packet. The payload in this data packet (which may include a destination or return address) is forwarded to the buffer entry Buf 0-1 during the check rule phase, and a determination is made as to whether the check rule phase is enabled. If the check rule phase is not enabled, this data packet is discarded. Otherwise, the check rule phase is performed, in which all rules are loaded into the rule registers, and the address data packet is loaded into the buffer entry Buf 0-1. For all addresses in these buffers, the logic performs one or more checks using the address. For example, based on at least one of the checks, the logic may determine whether the address in the address data packet falls within any address range in the address range indicated in the loaded rule. If the address does not fall within any address range in the address range, the alarm condition is met, and therefore an alarm signal 456 is generated and output to the security control unit 450.

[0053] Figure 5 A method 500 for performing execution verification using a security subsystem (e.g., security subsystem 102, 202, 802) of an integrated circuit device (e.g., SoC 100, 200) according to some embodiments of the present disclosure is shown. The integrated circuit device may also include a CPU subsystem (e.g., CPU subsystem 104, 204, 804), the CPU subsystem including a set of processor cores, a set of trace blocks (e.g., trace blocks 182, 382) coupled to the set of processor cores, and a system interconnect (e.g., system interconnect 106, 206, 606, 706, 806). The security subsystem may include an execution verification module (e.g., execution verification module 140, 240, 340), the execution verification module including a set of verification cores (e.g., verification core 342). Each verification core in the set of verification cores may include a trace decoder (e.g., trace decoder 344, 444) and a checker block (e.g., checker block 346, 446). The integrated circuit device may further include a set of trace buses (eg, trace buses 124 , 224 , 324 ) extending between the set of trace blocks and the set of verification cores.

[0054] At step 501, the set of trace blocks may extract a set of execution traces (e.g., execution traces 348) from the set of processor cores. In some examples, each of the set of trace blocks may extract a corresponding execution trace from a corresponding processor core in the set of processor cores. The set of execution traces may indicate instructions that have been executed by the set of processor cores.

[0055] At step 503, the set of execution traces may be received (e.g., accessed) at the set of verification cores. In some examples, each execution trace in the set of execution traces may be received at a corresponding verification core in the set of verification cores. The set of execution traces may be received over the set of trace buses. The set of trace buses may be separate from a system interconnect.

[0056] Each of steps 505 to 511 may be performed for each verification core in the set of verification cores. At step 505, the verification core may identify a control transfer instruction in the execution trace. The control transfer instruction may be a control flow instruction, such as a branch instruction. In some instances, the control transfer instruction may include a conditional branch instruction, an unconditional branch instruction, a direct branch instruction, an indirect branch instruction, a function call instruction, or a function return instruction.

[0057] At step 507, the verification core may extract an address from the control transfer instruction. The address may be a destination address or a return address. In some examples, the verification core may extract a context ID from the control transfer instruction.

[0058] At step 509, the verification core may perform one or more checks on the address. The one or more checks may include a control flow analyzer check, a function pointer integrity check, a function call return address check, a control flow integrity check, or an execution signature check. In some instances, to perform the one or more checks, the verification core may retrieve a rule from a rule block (e.g., rule block 352, 452) based on a control transfer instruction. For example, in a control flow analyzer check, a rule may include an acceptable address range. A rule block may store a set of rules (e.g., rule 354). In some instances, the verification core may retrieve a rule from a rule block based on a context ID. In some instances, the verification core may compare the address with an acceptable address range. The verification core may determine that the address is within an acceptable address range, or that the address is not within an acceptable address range. If the address is a return address, the verification core may determine whether the return address corresponds to a memory location immediately after the function call. In some instances, the one or more checks may be performed on instructions or loop counts from execution tracing.

[0059] At step 511, the verification core may generate an alarm signal (e.g., alarm signal 256, 356, 456) based on the one or more checks. The alarm signal may indicate that an address in the execution trace has failed at least one of the one or more checks. For example, for a control flow analyzer check, if the address is not within an acceptable address range, the check fails and an alarm signal is generated. The alarm signal may be sent to a security control unit (e.g., security control unit 250, 350, 450). The alarm signal may be used to notify a server that an address in the execution trace has failed at least one of the one or more checks. In some instances, the alarm signal may indicate that an attack has been detected at the integrated circuit device. In some instances, the alarm signal may also include a timestamp associated with executing a control transfer instruction at the set of processor cores.

[0060] The steps of method 500 may be performed in any order and / or in parallel, and one or more steps of method 500 may be performed optionally. One or more steps of method 500 may be performed by one or more processors. Method 500 may be implemented as a computer readable medium or computer program product containing instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of method 500.

[0061] Figure 6 An example of a remote authentication module 630 according to some embodiments of the present disclosure is shown. The remote authentication module 630 may include a control register 632, a master finite state machine (FSM) 634, a LMCT FSM 662, a LMCT 664, and a bitmap FSM 660. In some instances, the remote authentication module 630 is responsible for the following two operations. For the first operation, when there is a challenge request from the RoT 616, the remote authentication module 630 may respond with the last challenge and the bitmap status of the write bitmap 622. The challenge request may consist of an address range (AR) 678 of interest and a current challenge. The remote authentication module 630 may check the bitmap status of the write bitmap 622 and clear the bits of the write bitmap 622 within the address range 678 of interest. The remote authentication module 630 may store the previous challenge in a data structure called the LMCT 664 and update / check the contents of the LMCT 664 based on the bitmap status. When the bitmap of address range 678 is non-zero, an update of LMCT 664 occurs. In some examples, LMCT 664 contains a challenge, and the corresponding address range that accompanies the challenge.

[0062] For the second operation, when the RoT 616 writes to the address monitoring range (AMR) register, the remote authentication module 630 can clear the entire write bitmap 622. In some embodiments, the RoT 616 can ensure that only the first operation or the second operation is performed at a given time. For example, after initiating the first operation with a challenge request, the RoT 616 can wait until the bitmap status of the write bitmap 622 is received, and then initiate the second operation.

[0063] In some instances, the LMCT 664 is implemented as an SRAM containing a 2-tuple (AR, LC), where AR is the address range and LC is the last challenge. For each authentication, the LMCT FSM 662 can search the incoming address range in the LMCT 664, one entry at a time, until it finds a matching entry or reaches the end without finding an entry. In some instances, the LMCT 664 can be a circular buffer, and the circular buffer wraps around when overflowing. In some instances, there may be two pointers in the LMCT FSM 662: a write pointer for storing new address ranges and a search pointer for searching addresses. The write pointer can be used to limit and narrow the search range because only the entries that have been written in the LMCT 664 need to be searched.

[0064] The bitmap FSM 660 can perform check and clear tasks. To check, the bitmap FSM 660 can read one or more write bitmaps 622 based on the address range 678, and then write zeros back to the write bitmap 622. The bitmap FSM 660 can keep track of and update the register bitmap values ​​based on the bitmap read data. The register bitmap values ​​can be accumulated based on all previous reads of the bitmap. For all data written to the write bitmap 622, the bitmap FSM 660 will first send the write data mask, wait for the write response, and then send the write data of the address.

[0065] Figure 7 An example of a write bitmap 722 according to some embodiments of the present disclosure is shown. The write bitmap 722 may include a control register 768, a sniffing logic 770, and a bitmap 776, which may be implemented by an SRAM. The write bitmap 722 may reside outside the physical boundaries of the security subsystem and may need to be materialized in the SoC. The sniffing logic 770 may extract a write address 774 in an address write channel 772. In some instances, the address write channel 772 may be an AXI address write channel from a DDR memory controller (DMC) or an on-chip SRAM. The sniffing logic 770 may then calculate the appropriate bits to be updated in the bitmap 776. Since the size and structure of the write address 774 may vary, the sniffing logic 770 may need to convert the information into an actual bitmap update.

[0066] The bitmap 776 can track all write histories at a specific granularity (e.g., 1kB). For example, in order to cover an address range of 64MB with a granularity of 1kB, the size of the SRAM can be 64kb or 8kB. At a granularity of 512B, the same 8kB SRAM can only cover an address range of 32MB. The remote authentication module can use the control register 768 to control the granularity. In some instances, the sniffing logic 770 monitors the information in the address write channel 772, detects the write address 774 based on the information, and updates the corresponding bit value in the bitmap to 1 based on the monitoring range and the physical size of the SRAM in the control register 768. In some instances, the bitmap 776 can support bit-level write masks.

[0067] In some instances, to support continuous AXI requests (e.g., 64 outstanding bursts of DDR memory), the pipeline logic may need to make one AXI address write request per clock cycle. In some instances, a buffer is used between the address write channel 772 and the sniff logic 770, and the depth may be the number of cycles required to complete one AXI AW request update to the SRAM / flops.

[0068] Figure 8 Example components of a SoC 800 that may be involved during remote attestation according to some embodiments of the present disclosure are shown. The SoC 800 may include a security subsystem 802, a system interconnect 806, a CPU subsystem 804, a memory subsystem 808, and a domain-specific accelerator 810. During remote attestation, the security subsystem 802 (e.g., a remote attestation module) communicates an address range 878 of interest (or multiple address ranges of interest) to one or more write bitmaps 822 via the system interconnect 806. The write bitmap 822 may be physically located within the SoC 800 such that it is coupled to address write channels 872 associated with various memories in the SoC 800.

[0069] In the illustrated example, write bitmap 822-1 is located within CPU subsystem 804 and is coupled to address write channel 872-1 of the SRAM of CPU subsystem 804, write bitmap 822-2 is located within memory subsystem 808 and is coupled to address write channel 872-2 of the DRAM of memory subsystem 808, and write bitmap 822-3 is located within domain-specific accelerator 810 and is coupled to address write channel 872-3 of the SRAM of domain-specific accelerator 810. Each of the write bitmaps 822 may extract a write address from address write channel 872, determine whether the write address falls within address range 878 (or within one of a plurality of address ranges of interest), and if it is determined that the write address falls within address range 878, update its internal bitmap to modify the bit associated with address range 878 to indicate this.

[0070] In various examples, the write bitmap 822 can communicate a bitmap state 880 to the security subsystem 802 via the system interconnect 806. Each bitmap state 880 can be sent periodically in response to a detected bitmap change, and / or in response to a request from the security subsystem 802 to receive the state. In some examples, the security subsystem 802 can send the address range 878 at a first time, and can thereafter begin receiving a bitmap state from the write bitmap 822 each time an extracted write address falls within the address range 878, such as receiving a first bitmap state from the write bitmap 822-1 at a second time after the first time, and receiving a second bitmap state from the write bitmap 822-2 at a third time after the second time.

[0071] Fig. 9 Various example steps of a method 900 for remote authentication using a security subsystem (eg, security subsystem 102, 202, 802) of an integrated circuit device (eg, SoC 100, 200) according to some embodiments of the present disclosure are shown. Fig. 9 As indicated, the steps of method 900 may be performed by RoT firmware (FW), remote attestation (RA) hardware (e.g., remote attestation module, write bitmap, etc.), and / or TEE firmware. In some instances, the trusted software component executing on the CPU subsystem is the TEE firmware, and the software component executing on the security subsystem is the RoT firmware. In some instances, the remote attestation server is a secure server that authenticates an untrusted remote device (e.g., SoC) before performing sensitive operations.

[0072] At step 901, the remote server, TEE firmware, and RoT firmware can negotiate a session key to avoid replay attacks. After this initial boot sequence step, the remote server can request authentication at any time.

[0073] At step 902, the RA agent executed on the CPU subsystem software may receive an authentication request from a remote server. The attestor in the TEE firmware may call an API in the RoT to process the challenge request.

[0074] At step 903, the RoT firmware may decrypt the challenge with the negotiated session key and authenticate the incoming challenge to verify the source of the request.

[0075] At step 904, the RoT firmware may return an error response due to authentication failure.

[0076] At step 905, the RoT firmware may set up a remote authentication module to handle the authentication challenge.

[0077] At step 906, the security subsystem may send the one or more address ranges of interest to a write bitmap. In some instances, by receiving the one or more address ranges of interest from the security subsystem, the write bitmap may be enabled to track all memory write operations to the one or more address ranges of interest. For example, the write bitmap may begin tracking all memory write operations to the one or more address ranges of interest, or in some instances, the write bitmap may continue to track memory write operations to the one or more address ranges of interest, and / or stop tracking memory write operations to addresses outside of the one or more address ranges of interest. The write bitmap may modify the bitmap based on the write address, such as by setting a bit in the bitmap corresponding to the write address to non-zero.

[0078] At step 907, the remote authentication module can verify whether the timestamp of the current incoming challenge is greater than (e.g., later than) the timestamp of the immediately previous challenge. This allows method 900 to avoid replay attacks of old challenges. The immediately previous challenge is the challenge sent by the server immediately before the current incoming challenge. If the timestamp of the current incoming challenge is indeed greater, then method 900 proceeds to step 909. Otherwise, method 900 proceeds to step 908.

[0079] At step 908, the RA return code may return an error. The RA return code is a return code returned from the RA hardware to the RoT firmware. It may consist of a success / error code, a challenge number looked up from the LMCT, and / or a current challenge number.

[0080] The RoT firmware will check the RA return code. If the RA return code is an error, the RoT firmware sends an error response to the server. If the RA return code is a pass code, the RoT firmware calculates the signature of the requested address range, signs the signature with the device-specific private key, and sends this to the server.

[0081] At step 909, the security subsystem can obtain a bitmap status from the write bitmap. The bitmap status can indicate that a write is detected within one or more address ranges of interest. In some instances, the bitmap status can further indicate a timestamp associated with the write address being extracted. In some instances, the remote authentication module can query the bitmap status in the address range of interest. The remote authentication module can then search the LMCT for any previous challenges for the same address range. If the bitmap status indicates that one or more writes are detected for this address range, the LMCT table is updated by creating a new entry or updating a previous entry with the same address range. If the bitmap status indicates that no write is detected for this address range, the LMCT is not updated. The RA hardware returns an RA error code of 0 to indicate a pass status. The RA hardware registers can also be updated to store the immediately previous challenge, the challenge found from the LMCT, and the current number of challenges.

[0082] At step 911, the remote authentication module may send a return response along with a timestamp to the RoT firmware.

[0083] At step 912, the RoT firmware may check the return code received from the remote attestation module.

[0084] At step 913, the RoT firmware may compute an authentication response that includes a signature of the contents of the challenged address range, as well as a timestamp and bitmap state encrypted with the session key.

[0085] At step 914, the attestor in the TEE firmware may return a challenge response to the remote server.

[0086] The steps of method 900 may be performed in any order and / or in parallel, and one or more steps of method 900 may be performed arbitrarily. One or more steps of method 900 may be performed by one or more processors. Method 900 may be implemented as a computer-readable medium or computer program product containing instructions that, when executed by one or more processors, cause the one or more processors to perform the steps of method 900. One or more steps of method 900 may be performed in parallel. Fig.10 For example, Fig.10 One or more steps of the described method may be performed during step 906 of method 900 .

[0087] Fig.10A method 1000 for remote authentication using a security subsystem (e.g., security subsystem 102, 202, 802) of an integrated circuit device (e.g., SoC 100, 200) according to some embodiments of the present disclosure is shown. The integrated circuit device may also include a group of memories, a group of write bitmaps (e.g., write bitmaps 122, 622, 722, 822) respectively associated with the group of memories, a CPU subsystem (e.g., CPU subsystem 104, 204, 804), a memory subsystem (e.g., memory subsystem 108), and a system interconnect (e.g., system interconnect 106, 206, 606, 706, 806). Each write bitmap in the group of write bitmaps may include a bitmap (e.g., bitmap 776) and logic (e.g., sniffing logic 770). The security subsystem may include a remote authentication module (e.g., remote authentication module 130, 230, 630). In some instances, the method 1000 may be performed in response to an authentication request received from a requester.

[0088] At step 1001, the security subsystem may send one or more address ranges of interest (e.g., address ranges 678, 778, 878) to a write bitmap. The write bitmap may be one of the set of write bitmaps. In some instances, the one or more address ranges of interest may be specified in an authentication request and may be referred to as challenged address ranges.

[0089] At step 1003, write addresses may be tracked in a bitmap of a write bitmap. The write addresses may be associated with detected memory write operations performed on memories in the set of memories. The detected memory write operations may be for the one or more address ranges of interest. In some instances, by receiving the one or more address ranges of interest from the security subsystem, a write bitmap may be enabled to track all memory write operations to the one or more address ranges of interest. For example, the write bitmap may begin tracking all memory write operations to the one or more address ranges of interest, or in some instances, the write bitmap may continue to track memory write operations to the one or more address ranges of interest, and / or stop tracking memory write operations to addresses outside the one or more address ranges of interest.

[0090] At step 1005, the write bitmap may extract write addresses within one or more address ranges of interest from an address write channel (e.g., address write channels 772, 872). The write addresses may be associated with a memory write operation to the memory. In some instances, logic may be used to extract the write addresses from the address write channel.

[0091] At step 1007, the write bitmap may modify the bitmap based on the write address. The bitmap may be modified by setting the bit in the bitmap corresponding to the write address to non-zero. In some examples, logic may be used to modify the bitmap based on the write address and set the bit corresponding to the write address to non-zero.

[0092] At step 1009, the security subsystem may obtain a bitmap state (e.g., bitmap state 780, 880) from the write bitmap. The bitmap state may indicate that a write address within one or more address ranges of interest was detected. In some instances, the security subsystem may maintain and update a data structure referred to as LMCT based on the bitmap state. The data structure may further use the bitmap state as well as previous updates (based on previous bitmap states) and previous timestamps to track timestamps associated with updates. The security subsystem may use the data structure to prevent TOCTOU attacks.

[0093] In some instances, the security subsystem may receive an authentication request for content of one or more address ranges of interest locally from the security subsystem or remotely from a remote server (e.g., a cloud server). In response to receiving the authentication request, the security subsystem may use the bitmap state and / or data structure to calculate a signature for the content of the one or more address ranges of interest. The security subsystem may return the calculated signature to the requestor (e.g., the security subsystem or the server). The security subsystem may further return an authentication code to the requestor.

[0094] Optionally, in some instances, the security subsystem may generate an alarm signal (e.g., alarm signal 256) based on the bitmap state. In some instances, the alarm signal may indicate detection of a write address within one or more address ranges of interest. In some instances, the alarm may be used to notify a server of detection of a write address within one or more address ranges of interest. In some instances, the alarm signal may indicate that an attack has been detected at the integrated circuit device.

[0095] The steps of method 1000 may be performed in any order and / or in parallel, and one or more steps of method 1000 may be performed optionally. One or more steps of method 1000 may be performed by one or more processors. Method 1000 may be implemented as a computer readable medium or a computer program product containing instructions, which, when executed by one or more processors, causes the one or more processors to perform the steps of method 1000.

[0096] Fig.11An example of a network device 1100 is shown. The functions and / or several components of the network device 1100 can be used with other embodiments disclosed elsewhere in the present disclosure without limitation. The network device 1100 can facilitate the processing of data packets and / or forward data packets from the network device 1100 to another device. As described herein, a "data packet" or "network data packet" can refer to a variable or fixed data unit. In some cases, a data packet can include a data packet header and a data packet payload. The data packet header can include information associated with the data packet, such as source, destination, quality of service parameters, length, protocol, routing label, error correction information, etc. In some embodiments, a data packet header can indicate information associated with a series of data packets such as burst transactions. In some embodiments, the network device 1100 can be a receiver and / or generator of a data packet. In some embodiments, the network device 1100 can modify the content of the data packet before forwarding the data packet to another device. The network device 1100 can be a peripheral device, a switch, a router, or any other suitable device that can receive and forward data packets coupled to another computer device.

[0097] In one example, network device 1100 may include processing logic 1102, configuration module 1104, management module 1106, bus interface module 1108, memory 1110, and network interface module 1112. These modules may be hardware modules, software modules, or a combination of hardware and software. In some cases, modules may be used interchangeably with components or engines without departing from the scope of the present disclosure. Network device 1100 may include additional modules not shown here, such as those related to Fig.12 1100. In some embodiments, the network device 1100 may include fewer modules. In some embodiments, one or more of the modules may be combined into one module. One or more of the modules may communicate with each other via a communication channel 1114. The communication channel 1114 may include one or more buses, grids, matrices, structures, combinations of these communication channels, or some other suitable communication channels.

[0098] Processing logic 1102 may include an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a system on a chip (SoC), a network processing unit (NPU), a processor configured to execute instructions, or any other circuit system configured to perform logical, integer, and floating point operations. Examples of processors that may be used in processing logic 1102 include: Processors developed by, for example, 1102 and 1103. In some embodiments, the processor may include multiple processing cores, wherein each processing core may be configured to execute instructions independently of other processing cores. In addition, in some embodiments, each processor or processing core may implement multiple processing threads that execute instructions on the same processor or processing core, while maintaining the logical separation between the multiple processing threads. Such processing threads executed on a processor or processing core may be exposed to software as a separate logical processor or processing core. In some embodiments, multiple processors, processing cores, or processing threads executed on the same core may share certain resources, such as a bus, a level 1 (L1) cache, and / or a level 2 (L2) cache. The instructions executed by processing logic 1102 may be stored, for example, in the form of a computer program on a computer-readable storage medium. A computer-readable storage medium may be non-temporary. In some cases, a computer-readable medium may be a part of memory 1110.

[0099] Memory 1110 may include volatile or non-volatile memory or both. Memory 1110 may, for example, include random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory, and / or some other suitable storage medium. In some cases, some or all of memory 1110 may be inside network device 1100, while in other cases, some or all of memory may be outside network device 1100. Memory 1110 may store an operating system that includes executable instructions that provide an execution environment for executing instructions that provide network functions for network device 1100 when executed by processing logic 1102. Memory may also store and maintain a number of data structures and routing tables to facilitate the functions of network device 1100.

[0100] In some embodiments, configuration module 1104 may include one or more configuration registers. Configuration registers may control the operation of network device 1100. In some embodiments, one or more bits in a configuration register may represent certain capabilities of network device 1100. Configuration registers may be programmed by instructions executed in processing logic 1102 and / or by an external entity (e.g., a host device, an operating system executed on the host device, and / or a remote device). Configuration module 1104 may further include hardware and / or software that controls the operation of network device 1100.

[0101] In some embodiments, the management module 1106 can be configured to manage different components of the network device 1100. In some cases, the management module 1106 can configure one or more bits in one or more configuration registers at power-up to enable or disable certain functions of the network device 1100. In some embodiments, the management module 1106 can use processing resources from the processing logic 1102. In other embodiments, the management module 1106 can have processing logic similar to the processing logic 1102, but be segmented or implemented on a different power plane than the processing logic 1102.

[0102] The bus interface module 1108 can realize communication with external entities (such as other components in the host device and / or computing system) through external communication media. The bus interface module 1108 may include a physical interface for connecting to a cable, a socket, a port or other connections to an external communication medium. The bus interface module 1108 may further include hardware and / or software for managing incoming and outgoing transactions. The bus interface module 1108 can implement a local bus protocol, such as a protocol based on a peripheral component interconnect (PCI), a small computer system interface (SCSI), a serial attached SCSI (SAS), a serial AT attachment (SATA), a parallel ATA (PATA), some other standard bus protocols or a proprietary bus protocol. The bus interface module 1108 may include a physical layer for any protocol in these bus protocols, including connectors, power management and error handling, etc. In some embodiments, the network device 1100 may include multiple bus interface modules for communicating with multiple external entities. These multiple bus interface modules can implement the same local bus protocol, different local bus protocols or a combination of the same bus protocol and different bus protocols.

[0103] The network interface module 1112 may include hardware and / or software for communicating with a network. This network interface module 1112 may, for example, include a physical connector or physical port for being wired to a network and / or an antenna for wirelessly communicating with a network. The network interface module 1112 may further include hardware and / or software configured to implement a network protocol stack. The network interface module 1112 may use a network protocol (e.g., TCP / IP, Infiniband, RoCE, Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless protocol, fiber distributed data interface (FDDI), etc.) to communicate with a network. In some embodiments, the network device 1100 may include multiple network interface modules, each of which is configured to communicate with different networks. For example, in these embodiments, the network device 1100 may include a network interface module for communicating with a wired Ethernet, a wireless 802.11 network, a cellular network, an Infiniband network, etc.

[0104] The various components and modules of the network device 1100 described above may be implemented as discrete components, system on chip (SoC), ASIC, NPU, FPGA, or any combination thereof. In some embodiments, the SoC or other components may be communicatively coupled to another computing system to provide various services, such as traffic monitoring, traffic shaping, computing, etc. In some embodiments of the described technology, the SoC or other components may include, for example, Fig.12 Multiple subsystems are disclosed.

[0105] Fig.12 A network 1200 is shown, the network showing Fig.11 In some embodiments, the network 1200 may be based on a switching architecture with point-to-point links. Fig.12 As shown, the network 1200 includes multiple switches 1204a-1204d, which can be arranged in the network. In some cases, the switch is arranged in a multi-layer network (such as a Clos network). The network device 1100 that filters and forwards data packets between local area network (LAN) segments can be referred to as a switch. The switch usually operates at the data link layer (layer 2) of the open system interconnection (OSI) reference model and sometimes operates at the network layer (layer 3), and can support several data packet protocols. The switch 1204a-1204d can be connected to multiple nodes 1202a-1202h and provide multiple paths between any two nodes.

[0106] The network 1200 may also include one or more network devices 1100 for connecting to other networks 1208, such as other subnets, LANs, wide area networks (WANs), or the Internet, and may be referred to as routers 1206. Routers use headers and forwarding tables to determine the best path to forward packets, and use protocols such as the Internet Control Message Protocol (ICMP) to communicate with each other and configure the best route between any two devices.

[0107] In some examples, the network 1200 may include any one or combination of many different types of networks, such as a wired network, the Internet, a wireless network, a cellular network, and other private and / or public networks. If present, the interconnected switches 1204a-1204d and routers 1206 may be referred to as a switching fabric, a fabric, a network fabric, or simply a network. In the context of computer networks, the terms "fabric" and "network" may be used interchangeably herein.

[0108] The nodes 1202a-1202h may be any combination of host systems, processor nodes, storage subsystems, and I / O chassis representing user devices, service provider computers, or third-party computers.

[0109] The user device may include a computing device that accesses an application 1232 (e.g., a web browser or a mobile device application). In some aspects, the application 1232 may be hosted, managed, and / or provided by a computing resource service or service provider. The application 1232 may allow a user to interact with a service provider computer to, for example, access network content (e.g., web pages, music, videos, etc.). The user device may be a computing device, such as a mobile phone, a smart phone, a personal digital assistant (PDA), a laptop computer, a netbook computer, a desktop computer, a thin client device, a tablet computer, an electronic book (e-book) reader, a game console, etc. In some instances, the user device may communicate with the service provider computer via other networks 1208. Additionally, the user device may be part of a distributed system that is managed, controlled, or otherwise part of a service provider computer (e.g., a console device integrated with the service provider computer).

[0110] Fig.12The node may also represent one or more service provider computers. One or more service provider computers may provide local applications configured to run on a user device, and the user may interact with the local application. In some instances, the service provider computer may provide computing resources, such as but not limited to client entities, low-latency data storage, persistent data storage, data access, management, virtualization, cloud-based software solutions, electronic content performance management, etc. The service provider computer may also be operable to provide network hosting, database establishment, computer application development and / or implementation platform, a combination of the foregoing, etc. to the user. In some embodiments, the service provider computer may be provided as one or more virtual machines implemented in a hosted computing environment. The hosted computing environment may include one or more rapidly provisioned and released computing resources. These computing resources may include computing, network and / or storage devices. The hosted computing environment may also be referred to as a cloud computing environment. The service provider computer may include one or more servers, which may be arranged in a cluster, as a server group, or as separate servers that are not associated with each other, and may host applications 1232 and / or cloud-based software services. These servers may be configured as part of an integrated distributed computing environment. In some aspects, additionally or alternatively, the service provider computer may include a computing device such as a mobile phone, a smart phone, a personal digital assistant (PDA), a laptop computer, a desktop computer, a netbook computer, a server computer, a thin client device, a tablet computer, a gaming console, etc. In some cases, the service provider computer may communicate with one or more third-party computers.

[0111] In one example configuration, nodes 1202a-1202h may include at least one memory 1218 and one or more processing units (or processors 1220). Processor 1220 may be implemented in hardware, computer executable instructions, firmware, or a combination thereof. Computer executable instructions or firmware implementations of processor 1220 may include computer executable instructions or machine executable instructions written in any suitable programming language for performing the various functions described.

[0112] In some cases, the hardware processor 1220 can be a single-core processor or a multi-core processor. A multi-core processor can include multiple processing units in the same processor. In some embodiments, the multi-core processor can share certain resources, such as a bus and a second-level cache or a third-level cache. In some cases, each core in a single-core processor or a multi-core processor can also include multiple execution logical processors (or execution threads). In such cores (e.g., a core with multiple logical processors), several stages of the execution pipeline and lower-level caches can also be shared.

[0113] The memory 1218 may store program instructions that may be loaded and executed on the processor 1220, as well as data generated during the execution of these programs. Depending on the configuration and type of the nodes 1202a-1202h, the memory 1218 may be volatile (such as RAM) and / or non-volatile (such as ROM, flash memory, etc.). The memory 1218 may include an operating system 1228, one or more data storage areas 1230, one or more application programs 1232, one or more drivers 1234, and / or services for implementing the features disclosed herein.

[0114] Operating system 1228 can support the basic functions of nodes 1202a-1202h, such as scheduling tasks, executing applications and / or controller peripherals. In some embodiments, the service provider computer can host one or more virtual machines. In these embodiments, each virtual machine can be configured to execute its own operating system. Examples of operating systems include Unix, Linux, Windows, Mac OS, iOS, Android, etc. Operating system 1228 can also be a proprietary operating system.

[0115] The data storage area 1230 may include permanent data or temporary data used and / or operated by the operating system 1228, the application 1232, or the driver 1234. Examples of such data include web pages, video data, audio data, images, user data, etc. In some embodiments, the information in the data storage area 1230 may be provided to the user device 1204 via the network 1208. In some cases, additionally or alternatively, the data storage area 1230 may include stored applications and / or drivers. Alternatively or additionally, the data storage area 1230 may store standard and / or proprietary software libraries, and / or standard and / or proprietary application user interface (API) libraries. The information stored in the data storage area 1230 may be machine-readable object code, source code, interpreted code, or intermediate code.

[0116] Driver 1234 includes programs that can provide communication between components in the node. For example, some drivers 1234 can provide communication between operating system 1228 and other storage devices 1222, network devices 1224 and / or I / O devices 1226. Alternatively or additionally, some drivers 1234 can provide communication between application 1232 and operating system 1228, and / or communication between application 1232 and peripheral devices accessible by service provider computer. In many cases, driver 1234 can include drivers (e.g., printer drivers, display drivers, hard disk drives, and solid-state device drivers) that provide easy-to-understand functions. In other cases, driver 1234 can provide proprietary or specialized functions.

[0117] The service provider computer or server may also include additional storage devices 1222, which may include removable storage devices and / or non-removable storage devices. Additional storage devices 1222 may include magnetic storage devices, optical disks, solid-state disks, flash memory, and / or tape storage devices. Additional storage devices 1222 may be housed in the same rack as nodes 1202a-1202h, or may be located in an external hard disk box. Memory 1218 and / or additional storage devices 1222 and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computing device. In some embodiments, memory 1218 may include multiple different types of memory, such as SRAM, DRAM, or ROM.

[0118] Removable and non-removable memory 1218 and additional storage devices 1222 are examples of computer-readable storage media. For example, computer-readable storage media may include volatile or non-volatile, removable or non-removable media implemented in a method or technology for storing information, the information including, for example, computer-readable instructions, data structures, program modules or other data. Memory 1218 and additional storage devices 1222 are examples of computer storage media. Other types of computer storage media that may be present in nodes 1202a-1202h may include, but are not limited to, PRAM, SRAM, DRAM, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD or other optical storage devices, cassettes, tapes, disk storage devices or other magnetic storage devices, solid-state drives, or some other media that can be used to store desired information and can be accessed by nodes 1202a-1202h. Computer-readable media also include combinations of any of the above-mentioned media types, the media types including multiple units of a media type.

[0119] Alternatively or additionally, computer-readable communication media may include computer-readable instructions, program modules, or other data transmitted within a data signal such as a carrier wave or other transmission. However, as used herein, computer-readable storage media does not include computer-readable communication media.

[0120] Nodes 1202a-1202h may also include I / O devices 1226, such as keyboards, mice, pens, voice input devices, touch input devices, displays, speakers, printers, etc. Nodes 1202a-1202h may also include one or more communication channels 1236. Communication channels 1236 may provide a medium through which the various components of nodes 1202a-1202h may communicate. One or more communication channels 1236 may take the form of a bus, a ring, a switching structure, or a network.

[0121] The nodes 1202a - 1202h may also contain a network device 1224 that allows the nodes 1202a - 1202h to communicate with a stored database, another computing device or server, a user terminal, and / or other devices on the network 1200 . Fig.12 The network device 1224 may include information about Fig.11 1100. In some embodiments, network device 1224 is a peripheral device, such as a PCI-based device.

[0122] The modules described herein may be software modules, hardware modules, or a suitable combination thereof. If the module is a software module, the module may be embodied on a non-transitory computer-readable medium and processed by a processor in any of the computer systems described herein. It should be noted that the processes and architectures described may be performed in real time or in an asynchronous mode prior to any user interaction. Fig.11 , Fig.12 The modules may be configured in the manner suggested in the specification, and / or the functions described herein may be provided by one or more modules existing as separate modules, and / or the module functions described herein may be distributed over multiple modules.

[0123] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present disclosure as set forth in the claims.

[0124] Other variations are within the spirit of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described in detail above. However, it should be understood that it is not intended to limit the present disclosure to the specific form or forms disclosed, but on the contrary, it is intended to cover all modifications, alternative constructions, and equivalents that fall within the spirit and scope of the present disclosure as defined by the appended claims.

[0125] Unless otherwise indicated herein or clearly contradicted by context, the use of the terms "a / an" and "the" and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are interpreted to cover both the singular and the plural. Unless otherwise indicated herein or clearly contradicted by context, the terms "comprising", "having", "including" and "containing" are interpreted as open-ended terms (i.e., meaning "including but not limited to") unless otherwise stated. The term "connected" is interpreted as partially or completely contained within, attached to or joined together, even in the presence of intermediates. Unless otherwise indicated herein, the recitation of ranges of values ​​herein is intended merely to serve as a shorthand method of referring individually to each individual value falling within the range, and each individual value is incorporated into the specification as if the individual value were individually recited herein. Unless otherwise indicated herein or clearly contradicted by context, all methods described herein can be performed in any suitable order. Unless otherwise stated, the use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate the embodiments of the present disclosure and is not intended to limit the scope of the present disclosure. No language in this specification should be construed as indicating any unclaimed element as being essential to the practice of the present disclosure.

[0126] Unless specifically stated otherwise, disjunctive language such as the phrase "at least one of X, Y, or Z" is intended to be understood in the context of being generally used to present an item, term, etc. that can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended to, and should not, imply that certain embodiments require that at least one of X, at least one of Y, or at least one of Z each be present.

[0127] Various embodiments of the present disclosure are described herein, including the best mode known to the inventors for performing the present disclosure. After reading the foregoing description, variations of these embodiments may become apparent to those skilled in the art. The inventors expect that the technicians will adopt such variations when appropriate, and the inventors intend to enable the present disclosure to be put into practice in other ways different from the specific description herein. Therefore, where permitted by applicable law, the present disclosure includes all modifications and equivalents of the subject matter described in the appended claims. In addition, unless otherwise indicated herein or otherwise clearly contradicted with the context, the present disclosure encompasses any combination of the above-mentioned elements in all possible variations thereof.

[0128] A list of examples of various embodiments of the present invention is provided below. As used below, any reference to a series of examples is understood to be a separate reference to each of those examples (e.g., "examples 1-4" is understood to be "examples 1, 2, 3, or 4").

[0129] Example 1 is an integrated circuit device, comprising: a system interconnect; a set of memories coupled to the system interconnect, each memory in the set of memories having an address write channel at which a write address associated with a memory write operation can be extracted; a set of write bitmaps, the set of write bitmaps being respectively associated with the set of memories, wherein each write bitmap in the set of write bitmaps comprises: a bitmap that tracks the write addresses detected for memory write operations to corresponding memories in the set of memories; and logic for extracting the write addresses associated with the memory write operations from the address write channel of the corresponding memory and modifying the bitmap based on the write addresses; and a security subsystem coupled to the system interconnect, wherein the security subsystem is configured to: receive an authentication request from a requestor; send one or more address ranges of interest to the set of write bitmaps; obtain a bitmap state from a write bitmap in the set of write bitmaps, the bitmap state indicating that a write address within the one or more address ranges of interest was detected; calculate a signature based at least in part on the bitmap state; and return the signature to the requestor.

[0130] Example 2 is an integrated circuit device according to example 1, further comprising: a central processing unit (CPU) subsystem, the CPU subsystem coupled to the system interconnect, the CPU subsystem including static random access memory (SRAM), wherein the group of memories includes the SRAM; and a memory subsystem, the memory subsystem coupled to the system interconnect, the memory subsystem including dynamic random access memory (DRAM), wherein the group of memories includes the DRAM.

[0131] Example 3 is an integrated circuit device according to Example 1 or 2, wherein after receiving the one or more address ranges of interest, one of the write bitmaps in the set of write bitmaps is configured to: set the bits in the bitmap corresponding to the one or more address ranges of interest to zero; and after extracting the write address within the one or more address ranges of interest, set the bits in the bitmap corresponding to the write address to non-zero.

[0132] Example 4 is an integrated circuit device according to any one of Examples 1 to 3, wherein in response to receiving the one or more address ranges of interest, one of the write bitmaps in the set of write bitmaps is configured to: provide the bitmap status to the security subsystem, the bitmap status indicating whether the write address within the one or more address ranges of interest is detected.

[0133] Example 5 is an integrated circuit device comprising: a memory; a write bitmap, the write bitmap comprising a bitmap that tracks write addresses detected for memory write operations to the memory; and a security subsystem, the security subsystem configured to: send one or more address ranges of interest to the write bitmap; and obtain a bitmap state from the write bitmap, the bitmap state indicating that a write address within the one or more address ranges of interest is detected.

[0134] Example 6 is an integrated circuit device of example 5, wherein the write bitmap further comprises logic for extracting the write address from an address write channel associated with the memory.

[0135] Example 7 is the integrated circuit device of example 6, wherein the logic is further configured to modify the bitmap based on the write address by setting a bit in the bitmap corresponding to the write address to non-zero.

[0136] Example 8 is an integrated circuit device according to any one of Examples 5 to 7, wherein after receiving the one or more address ranges of interest, the write bitmap is configured to: set the bits in the bitmap corresponding to the one or more address ranges of interest to zero; and after extracting the write address within the one or more address ranges of interest, set the bits in the bitmap corresponding to the write address to non-zero.

[0137] Example 9 is an integrated circuit device according to any of Examples 5 to 8, wherein the write bitmap is configured to provide the bitmap state after receiving the one or more address ranges of interest from the security subsystem.

[0138] Example 10 is an integrated circuit device according to any one of Examples 5 to 9, further comprising: a central processing unit (CPU) subsystem, the CPU subsystem including the memory, wherein the memory is a static random access memory (SRAM).

[0139] Example 11 is an integrated circuit device according to any one of examples 5 to 10, further comprising: a memory subsystem including the memory, wherein the memory is a dynamic random access memory (DRAM).

[0140] Example 12 is an integrated circuit device according to any of Examples 5 to 11, wherein the security subsystem is configured to calculate a signature using the bitmap state.

[0141] Example 13 is a computer-implemented method comprising: tracking write addresses in a bitmap of a write bitmap, wherein the write addresses are associated with detected memory write operations to a memory; sending one or more address ranges of interest to the write bitmap at a security subsystem; and obtaining a bitmap state from the write bitmap at the security subsystem, wherein the bitmap state indicates that a write address within the one or more address ranges of interest is detected.

[0142] Example 14 is the computer-implemented method of example 13, further comprising extracting the write address from an address write channel associated with the memory.

[0143] Example 15 is the computer-implemented method of example 14, further comprising modifying the bitmap based on the write address by setting a bit in the bitmap corresponding to the write address to non-zero.

[0144] Example 16 is a computer-implemented method according to any one of Examples 13 to 15, further comprising: after sending the one or more address ranges of interest to the write bitmap, setting the bits in the bitmap corresponding to the one or more address ranges of interest to zero; and after extracting the write address within the one or more address ranges of interest, setting the bits in the bitmap corresponding to the write address to non-zero.

[0145] Example 17 is a computer-implemented method according to any of Examples 13 to 16, wherein the write bitmap is configured to provide the bitmap state after receiving the one or more address ranges of interest from the secure subsystem.

[0146] Example 18 is a computer-implemented method according to any one of Examples 13 to 17, wherein the memory is included in a central processing unit (CPU) subsystem, and wherein the memory is a static random access memory (SRAM).

[0147] Example 19 is a computer-implemented method according to any one of Examples 13 to 18, wherein the memory is included in a memory subsystem, and wherein the memory is a dynamic random access memory (DRAM).

[0148] Example 20 is a computer-implemented method according to any one of Examples 13 to 19, further comprising: calculating a signature using the bitmap state at the security subsystem.

[0149] Example 21 is an integrated circuit device comprising: a system interconnect; a central processing unit (CPU) subsystem coupled to the system interconnect, the CPU subsystem comprising a set of CPU cores, the set of CPU cores configured to execute instructions; a set of trace blocks, the set of trace blocks configured to extract a set of execution traces from the set of CPU cores, the set of execution traces indicating the instructions that have been executed by the set of CPU cores; and a security subsystem coupled to the system interconnect, the security subsystem comprising: a rule block configured to store a set of rules; and a set of verification cores, the set of trace blocks configured to extract a set of execution traces from the set of CPU cores, the set of execution traces indicating the instructions that have been executed by the set of CPU cores; and a security subsystem coupled to the system interconnect, the security subsystem comprising: a rule block configured to store a set of rules; and a set of verification cores, the set of The group verification core is configured to receive the set of execution traces from the set of tracking blocks, wherein each verification core in the set of verification cores is configured to: receive an execution trace of the set of execution traces; identify a control transfer instruction in the execution trace; extract an address from the control transfer instruction, wherein the address is a destination address or a return address; check the address by: retrieving a rule of the set of rules from the rule block based on the control transfer instruction, the rule including an acceptable address range; and determining that the address is not within the acceptable address range; and generating an alarm signal based on the address not being within the acceptable address range.

[0150] Example 22 is an integrated circuit device according to Example 21, further comprising: a set of trace buses extending between the set of trace blocks and the set of verification cores, the set of trace buses being separate from the system interconnect, wherein the set of verification cores are configured to receive the set of execution traces through the set of trace buses.

[0151] Example 23 is an integrated circuit device according to example 21 or 22, wherein the control transfer instruction includes at least one of the following: a conditional branch instruction, an unconditional branch instruction, a direct branch instruction, an indirect branch instruction, a function call instruction, or a function return instruction.

[0152] Example 24 is an integrated circuit device according to any one of Examples 21 to 23, wherein each verification core in the set of verification cores is further configured to: extract a context ID from the control transfer instruction, wherein the rule is retrieved from the rule block based on the context ID.

[0153] Example 25 is an integrated circuit device, comprising: a processor core, which is configured to execute instructions; a trace block, which is configured to extract an execution trace from the processor core, the execution trace indicating the instructions that have been executed by the processor core; and a verification core, which is configured to: receive the execution trace from the trace block; extract an address from a control transfer instruction in the execution trace; perform one or more checks on the address; and generate a signal based on the one or more checks.

[0154] Example 26 is an integrated circuit device according to Example 25, wherein the one or more checks include at least one of: a control flow analyzer check, a function pointer integrity check, a function call return address check, a control flow integrity check, or an execution signature check.

[0155] Example 27 is an integrated circuit device according to example 25 or 26, wherein the control transfer instruction includes at least one of the following: a conditional branch instruction, an unconditional branch instruction, a direct branch instruction, an indirect branch instruction, a function call instruction, or a function return instruction.

[0156] Example 28 is an integrated circuit device according to any one of Examples 25 to 27, wherein the verification core is further configured to: identify the control transfer instruction in the execution trace.

[0157] Example 29 is an integrated circuit device according to any of Examples 25 to 28, wherein the verification core is further configured to retrieve a rule from a set of rules from a rule block based on the control transfer instruction, wherein the rule includes an acceptable address range.

[0158] Example 30 is the integrated circuit device of example 29, wherein the verification core is further configured to: extract a context ID from the control transfer instruction, wherein the rule is retrieved from the rule block based on the context ID.

[0159] Example 31 is an integrated circuit device according to any of Examples 25 to 30, wherein the signal is used to notify a server that the address is not within the acceptable address range, wherein the server is external to the integrated circuit device.

[0160] Example 32 is an integrated circuit device according to any one of Examples 25 to 31, further comprising: a trace bus extending between the trace block and the verification core, wherein the verification core is configured to receive the execution trace through the trace bus.

[0161] Example 33 is an integrated circuit device according to any one of Examples 25 to 32, wherein the processor core is one processor core in a group of processor cores, the trace block is one trace block in a group of trace blocks, and the execution trace is one execution trace in a group of execution traces.

[0162] Example 34 is an integrated circuit device according to any one of Examples 25 to 33, further comprising: a system interconnect; a central processing unit (CPU) subsystem, the CPU subsystem coupled to the system interconnect, the CPU subsystem including the processor core; and a security subsystem, the security subsystem coupled to the system interconnect, the security subsystem including the verification core.

[0163] Example 35 is a computer-implemented method comprising: extracting an execution trace from a processor core, the execution trace indicating instructions that have been executed by the processor core; receiving the execution trace at a verification core; extracting addresses from control transfer instructions in the execution trace at the verification core; performing one or more checks on the addresses at the verification core; and generating an alarm signal at the verification core based on the one or more checks.

[0164] Example 36 is a computer-implemented method according to example 35, wherein the one or more checks include at least one of: a control flow analyzer check, a function pointer integrity check, a function call return address check, a control flow integrity check, or an execution signature check.

[0165] Example 37 is a computer-implemented method of example 35 or 36, further comprising identifying, at the verification core, the control transfer instruction in the execution trace.

[0166] Example 38 is a computer-implemented method according to any of examples 35 to 37, further comprising: retrieving a rule from a set of rules from a rule block based on the control transfer instruction at the verification core, wherein the rule includes an acceptable address range.

[0167] Example 39 is a computer-implemented method according to any of Examples 35 to 38, wherein the verification core is configured to receive the execution trace via a trace bus extending between a trace block and the verification core.

[0168] Example 40 is a computer-implemented method according to any of Examples 35 to 39, wherein the processor core is one processor core in a group of processor cores and the execution trace is one execution trace in a group of execution traces.

[0169] Example 41 is a computer-readable medium storing instructions that, when executed by one or more processors, causes the one or more processors to perform a computer-implemented method according to any one of Examples 13 to 20 or 35 to 40.

Claims

1. An integrated circuit device comprising: Memory; a write bitmap comprising a bitmap that tracks detected write addresses of memory write operations to the memory; as well as A security subsystem, the security subsystem being configured to: sending one or more address ranges of interest to the write bitmap; and A bitmap status is obtained from the write bitmap, the bitmap status indicating detection of a write address within the one or more address ranges of interest.

2. The integrated circuit device of claim 1, wherein the write bitmap further comprises logic for extracting the write address from an address write channel associated with the memory. 3 . The integrated circuit device of claim 2 , wherein the logic is further configured to modify the bitmap based on the write address by setting a bit in the bitmap corresponding to the write address to non-zero.

4. An integrated circuit device according to any one of claims 1 to 3, wherein after receiving the one or more address ranges of interest, the write bitmap is configured to: setting bits in the bitmap corresponding to the one or more address ranges of interest to zero; and After extracting the write address within the one or more address ranges of interest, the bit in the bitmap corresponding to the write address is set to non-zero.

5. An integrated circuit device according to any one of claims 1 to 4, wherein the write bitmap is configured to provide the bitmap state after receiving the one or more address ranges of interest from the security subsystem.

6. The integrated circuit device according to any one of claims 1 to 5, further comprising: A central processing unit (CPU) subsystem includes the memory, wherein the memory is a static random access memory (SRAM).

7. The integrated circuit device according to any one of claims 1 to 6, further comprising: A memory subsystem includes the memory, wherein the memory is a dynamic random access memory (DRAM).

8. The integrated circuit device according to any one of claims 1 to 7, wherein the security subsystem is configured to calculate a signature using the bitmap state.

9. A computer-implemented method comprising: tracking write addresses in a bitmap of a write bitmap, the write addresses being associated with detected memory write operations to the memory; sending, at the security subsystem, one or more address ranges of interest to the write bitmap; and A bitmap status is obtained at the security subsystem from the write bitmap, the bitmap status indicating detection of a write address within the one or more address ranges of interest.

10. The computer-implemented method of claim 9, further comprising: The write address is extracted from an address write channel associated with the memory.

11. The computer-implemented method of claim 10, further comprising: The bitmap is modified based on the write address by setting a bit in the bitmap corresponding to the write address to non-zero.

12. The computer-implemented method of any one of claims 9 to 11, further comprising: After sending the one or more address ranges of interest to the write bitmap, setting bits in the bitmap corresponding to the one or more address ranges of interest to zero; and After extracting the write address within the one or more address ranges of interest, the bit in the bitmap corresponding to the write address is set to non-zero.

13. The computer-implemented method of any one of claims 9 to 12, wherein the write bitmap is configured to provide the bitmap state upon receiving the one or more address ranges of interest from the secure subsystem.

14. The computer-implemented method of any one of claims 9 to 13, wherein the memory is included in a central processing unit (CPU) subsystem, and wherein the memory is a static random access memory (SRAM).

15. The computer-implemented method of any one of claims 9 to 14, wherein the memory is included in a memory subsystem, and wherein the memory is a dynamic random access memory (DRAM).

Images