Immutable execution stream

Abstract

A novel approach to computer system security integrates one-way hashing of computer system state with Active Root of Trust (ARoT) and Active Trusted Platform Module (ATPM) technologies. The hashed output is interpreted by the ARoT and ATPM to observe and verify CPU and associated software stack integrity.

Description

IMMUTABLE EXECUTION STREAMBACKGROUNDS

[0001] The current state of CPU technology, particularly in Application-Specific Integrated Circuit (ASIC) designs, has reached new heights in performance and power efficiency. Today’s modern, multi-core CPUs have advanced caching and execute billions of instructions per second that have leveled up to meet the demands of increasingly complex computational tasks. However a critical security limitation persists: there is no method to externally verify the instructions and data executed by a CPU during runtime. This gap undermines the ability to detect malware or malicious firmware, even in systems equipped with secure boot mechanisms and Trusted Platform Modules (TPM), exposing them to sophisticated runtime and post-boot attacks.

[0002] Secure boot, supported by TPMs, ensures that only cryptographically verified firmware and software are loaded during the system startup, establishing a software Root of Trust (RoT). While effective at initialization, this protection does not extend to the CPUs runtime operations. Once the initial load is complete, modern CPUs offer no functional way to monitor or validate the instructions being executed or the data in the registers. This vulnerability has been exploited in real-world incidents, such as the SolarWinds attack, where attackers compromised the software build process, injecting malicious code into updates that bypassed secure boot checks by executing post-boot. Similarly, the CVE-2024-56161 vulnerability in AMD processors, Microcode Signature Verification Vulnerability, detected September 25, 2024, revealed that firmware could be loaded without signature verification, enabling attackers to install malicious firmware capable of tampering with critical functions — like setting the random number generator to a fixed value, rendering the encryption predictable and insecure.

[0003] This lack of continuous runtime verification creates a significant security blind spot, particularly in ASIC CPU designs where hardware fixes are challenging to implement postfabrication. The inability to externally audit the CPUs execution stream hampers detection of advanced threats, such as trusted execution environment (TEE) manipulation, supply chain attacks or persistent malware, that operate after the secure boot process. As cyber threats grow more sophisticated, this limitation underscores the need for innovative security designs embedded within the CPU architecture itself.BRIEF DESCRIPTION OF THE DRAWINGS

[0004] FIG. 1 is a schematic block diagram of a computer system having a-central processing unit that incorporates an immutable execution stream block.

[0005] FIG. 2 is a schematic block diagram of the central processing unit illustrated in FIG. 1.DESCRIPTION

[0006] With reference to FIGS. 1 and 2, concepts presented herein relate to use of functionality of a computer system (FIG. 1) and central processing unit (FIG. 2) associated with use of immutable execution streams (IES). The IES approach can be used to trace and attest to both CPU execution and CPU execution state without revealing sensitive information about data being processed by the CPU. To accomplish this approach, a one-way secure hashing algorithm , e.g., SHA-256 and SHA-512, can be used to record each operation (instruction) executed by the CPU that changes the CPU state (e.g., an operation that alters register values), as well as the changed register state itself, for each register that exists in a corresponding register file.

[0007] Computer system 100 includes central processing unit (CPU) 102. Platform firmware storage 104 includes instructions sent to CPU 102 upon start up or reset. An active root of trust (ARoT) 106 and active trusted platform module (ATPM) 114 verify that operations sent to CPU 102 are expected and ensure trusted start up, storage, authentication, data protection, measurement, and verification of CPU 102. ARoT 106 communicates with firmware storage access 108, execution block 110, and ATPM 114. IES block 112 receives instructions from execution block 110 in order to produce an immutable execution stream of operations of execution block 110. ATPM 114 communicates with both execution block 110 and IES block 112 can analyze output to determine operation of CPU 102 is as expected. ATPM 114 can take independent action or communicate with system-integrity stakeholders 116. Stakeholders 116 can determine courses of action to execute based on communication from ATPM 114. In some embodiments, ATPM 114 and ARoT 106 can be in the same block or in the same device.

[0008] Execution block 110 operates to execute instructions for CPU 102, using system memory access 200 (which includes level-one and level-two cache memory), a memory management unit (MMU) 202 and instruction fetch 204 for accessing instructions from memory. In embodiments aNext Instruction Pointer (NIP) 206 register is provided as part of the execution unit instruction path.

[0009] Execution block 110 utilizes dedicated general purpose registers (GPRs l..n) 208. IES block 112 utilizes dedicated special purpose registers (iSPRs) comprised of execution state iSPR 216 and GPR iSPRs l..n 228. GPRs 208 can store data for use in operations performed by decode / execution unit 210. Registers 216 and 228 store a current hash produced by its associated instruction or data stream state, respectively. In one embodiment, illustrated in FIG. 2, decode / execution unit 210 provides instructions to an instruction type filter 212. The instruction type filter 212 can be fixed at manufacture or made configurable to determine whether a particular instruction should not be be hashed by an instruction hash module 214 or used to increment instruction count iSPR 222. For example, the instruction type filter 212 can send an operation code (OPCODE) and arguments (ARGS) to the instruction hash module 214. The instruction hash module 214 sends an output to execution state iSPR 216. The output can be a hash of the current and previous state of the instruction path of CPU 102. Contents of the execution state iSPR 216 can be accessed by elements internal to CPU 102 as well as external to CPU 102 (e.g., by ATPM 114). As illustrated, the instruction type filter 212 can further send an enable signal (i.e., run gate) to the instruction hash module 214 to indicate that the instruction hash module 214 should perform the hash function. In in additional embodiment, also illustrated in FIG. 2, the instruction type filter 212 can also signal an instruction adder 220, which maintains an instruction count within a corresponding instruction count iSPR 222, the instruction count indicative of a number of instructions performed by the decode / execution unit 210 while the run gate is active (enabled).

[0010] The iSPRs are accessible in read-only form both from within the CPU 102 via SPR access instructions and externally via an external hardware interface, which may be shared with other data access means. For example, as illustrated in FIG. 2, the execution state iSPR can be accessed directly by ATPM 114, which can further be connected to an ARoT 106.

[0011] In one embodiment, each hash produced by the instruction hash module 214 is an extension of the prior hash in each iSPR, plus the new data or instruction that caused a CPU 102 state change, creating a hash-chain of multiple hash outputs that can be analyzed to determine that the hashchain conforms to expected outputs. For registers specifically, when the register content does notchange, the iSPR does not change (i.e., only register state changes are recorded in the register iSPRs). Given known initialization values contained in the iSPRs, after execution of a program that does not retrieve mutable external data, it is possible to retrieve a unique one-way hash from the iSPRs that attests to the execution of that program. Due to the one-way hash, this set of iSPR values is not useful to an attacker to discover the data or program executed. If the program and data are known, however, it is possible to verify that the iSPR values match expected outputs after execution on a different CPU, for example by conducting a simulation, or by running the same program code on the same CPU 102. To avoid a potential class of program truncation attack, it is also useful for the total number of CPU state changes observed to be recorded as part of the iSPR register set using instruction count iSPR 222.

[0012] In one embodiment, the instruction type filter 212 can filter no-operation (NOP) instructions or similar delay / idle / power management instructions that do not change CPU state. As such, the contents of execution state iSPR 216 does not change when NOP instructions are executed. As such, these instructions can be used to deduce an attack if CPU 102 state is adjusted. Conversely, branch instructions, except for the special “branch until iSPR read complete” instruction, change CPU 102 state in that they alter (at minimum) the instruction pointer, therefore branch instructions will, in general, alter iSPR contents. Also, changes to the iSPRs themselves do not cause an update to the iSPRs; the iSPRs are always contained within a small set of generally known registers 228, 216, 222 on the CPU 102 for which changes are not recorded in the output of the IES block.

[0013] In a further embodiment, as CPUs can have many registers, it may be useful to provide a aggregated hash output 234, calculated using hash module 232, that tracks all changes across an entire register file, reducing the verification process to reading three iSPRs 216, 222, and 228 (e.g., global register state, instruction state, and instruction count) instead of potentially one hundred or more. Such an approach can cause a degradation in trace capability, as isolating changes in one register versus another is no longer possible. However, for many applications (including initial boot block execution) this approach would be more than sufficient for execution verification without degradation in security.

[0014] Current CPUs allow multiple privilege levels, ranging from simple (e.g., privileged and unprivileged) through multi-tier (e.g., ultravisor, hypervisor, kernel, and user-privilege levels). These privilege levels are arranged such that a more secure level (e.g., hypervisor) has access to and control of a less secure level (e.g., kernel), but a less secure level cannot control a more secure level. This access restriction can play a significant role in operating system design, as this type of hardware-enforced privilege level allows a kernel to control and interrupt user space programs for time sharing purposes.

[0015] In one embodiment, a dedicated IES block 112 can be used for each privilege level, with a more secure level of security able to reset / directly load the iSPRs of the lower privilege levels. Furthermore, the most secure level iSPRs cannot be reset without asserting a CPU 102 reset and cannot be loaded without a CPU 102 reset. This design allows a more secure level to “swap” processes without causing an unwanted iSPR deviation, while not allowing code operating at a specific privilege level from altering its own iSPRs. As such, attestation is preserved. In this design, for unwanted CPU state changes to go undetected, software and / or firmware in the privilege level above those instructions either would have to be compromised or be malfunctioning, which would manifest a record in the iSPRs of the higher privilege level. In an additional embodiment, internal access to the iSPRs associated with a higher privilege level may be blocked or cause a trap to occur, dependent on either configuration settings previously set by a higher privilege level or the hardwired logic design. Such configuration settings, if present, are only writable from a higher privilege level, not from the current privilege level. Similarly, modern systems often use more than one CPU in a symmetric multi-processing (SMP) environment. By coordination between firmware running in the outermost security ring (e.g., ultravisor), processes can migrate between CPUs while still preserving iSPR state.

[0016] In embodiments, one or more independent IES blocks 112, not directly associated with a specific privilege level, can be used by configurable privilege levels, with a suitably high privilege level able to configure the effective operating privilege level of each set of iSPRs 228, 216, and 222. As a specific example, a single independent IES block 112 may be configured by software running at the highest privilege level of the system to be made usable by the lowest privilege level of the system. This may be used, for example, to support measurement of Just-In-Time (JIT) code running within user space, where user space and the JIT execution engine typically operate at thelowest privilege level of the system, and such JIT execution engines may include the Java Virtual Machine (JVM) or Ethereum Virtual Machine (EVM) operating in a trusted execution environment (TEE). In this specific example, the configuration register that controls the privilege level needed to set and reset the iSPRs is only writable from the highest privilege level of the system; in this manner, user space applications may request access to a set of iSPRs for measurement of a user space application from higher software privilege levels, and will only be able to use said iSPRs if higher privileged software is willing to grant access to the user space request. In general, the configuration of the independent iSPR privilege level would be restricted to at least one privilege level above the lowest privilege level in the system, to retain usefulness of the feature. As is the case with other iSPRs, software running at a higher privilege level than that configured in the iSPR privilege level configuration register is able to set and modify the iSPR content, in order to support task switching and similar functionality. In embodiments, firmware running at the highest privilege level is exclusively able to set the privilege level of independent iSPRs, with requests for access to independent iSPRs from lower privilege levels being forwarded upward to higher security levels, e.g., from user space to kernel to hypervisor before reaching system firmware at the highest security level. Any component within this chain is able to deny the request independently of higher components in the security chain.

[0017] In further embodiments, firmware clears the independent iSPRs upon allocating the independent iSPRs in response to a request from a lower privilege level, and before allowing the lower process level to access the independent iSPRs. This ensures stale data is not contained in the iSPRs upon e.g., an accepted request by user space to access an independent iSPR set for JIT measurement, and also provides protection against multiple processes attempting to use the same independent IES block without appropriate coordination from the kernel, hypervisor, or ultravisor firmware.

[0018] In embodiments, IES block output can be incorporated in a proof that specific CPU work has taken place, for example, as verification of smart contract execution stored in a blockchain or DAG. In embodiments, a nested approach may be taken to attest to smart contract execution, wherein the dedicated system IES engine validates the virtual machine execution environment (VMEE), and the VMEE utilizes one or more independent IES blocks to validate individual processes (i.e., contracts) that are executed within the virtual machine framework. This mixedapproach ensures that the VMEE is reloading the independent iSPRs correctly on contract start / stop / task switch, while providing granular iSPR data for each individual contract execution. iSPRs correctly on contract start / stop I task switch, while providing granular iSPR data for each individual contract execution, establishing a unique hash chain which may be compare with independent execution on other systems for validity.

[0019] In embodiments, when using independent IES blocks 112, instruction count iSPR 222 may be utilized for cycle-accurate performance measurements of instructions retired on a per-process, per-software thread, virtualized CPU (VCPU), or similarly granular level by reloading the instruction count iSPR to zero or an earlier stored accumulator value immediately before the associated process, thread, or VCPU is to be scheduled. This represents a significant advance over state of the art, which is only able to measure instructions executed on a per-CPU or per-hardware thread level.

[0020] It may be useful in one embodiment to extend the instruction set of a target CPU with hint instructions to indicate when a block of code begins and ends execution. These hint instructions could be used to independendy initialize or freeze a set of Transient iSPRs (TiSPRs), which are used to attest to execution of specific code segments. Such instructions could optionally trap to the parent privilege level or, in the case of the outermost privilege security level, send a signal (or set a flag) observable by the ARoT 106 / ATPM 114 when executed. In one example, for an ultravisor anti-malware program running on a scheduled basis, a program would record its execution in the ultravisor TiSPRs. The ATPM would observe blocks of the program being executed and the final TiSPRs for each program block, thus always validating anti-malware program state.

[0021] Hint instructions, in one embodiment, can include a unique ID value or similar identifier (e.g., a 64-bit or 512-bit value) such that an associated operating program can indicate to a higher privilege level or external ATPM 114 the exact code segment or process being executed. This indication allows ATPM 114 to better organize attestation and detect severity of compromise rather than assuming all compromise is equally damaging. Such unique ID values could be oneway hashes of process identifiers, program names, or other information that preserve the privacy of programs and data being processed on the CPU 102. For “anonymous” programs, the uniqueID could be set to a well-known, shared ID that will not reveal any information about what specific code block is running at the time beyond what is observed as part of the iSPR changes.

[0022] Another type of hint instruction also can be used as a signal that the iSPRs are “soft frozen” and can be read safely by ATPM 114. This hint instruction can be sent before CPU 102 enters a NOP loop at the current privilege level and waits for the ATPM 114 or higher privilege level to finish attesting to the state of CPU 102. Higher privilege levels would still be able to execute, while lower ones would remain blocked until the soft-freeze NOP loop is exited. In this manner, a program running on CPU 102 at any privilege level can request attestation of current state from the privilege level immediately above it, or in the case of the outermost privilege level, from the ATPM 114. Special branch instructions form the hint instructions and are hardwired to only branch on a continue signal from the higher privilege level or ATPM 114. These hint instructions, by design, would not change processor state and would, therefore, not alter the contents of the iSPRs.

[0023] In embodiments where CPU 102 supports speculative or out-of-order execution, only the final state change is recorded in the iSPRs. For example, if CPU 102 speculatively executes, then discards, a stream of several instructions A-B-C, while finally executing a different instruction stream D-E, only the D-E instruction and their associated state changes act on the iSPRs via the hashing mechanism. The iSPR logic operates on inputs of the prior iSPR value and the output of the execution stage after registers are altered — it does not operate on the input to the decoder stage or the internal logic of the execution unit 210.

[0024] In embodiments where shared-memory multiprocessing (SMP) is employed, coherent fabric becomes a potential source of attack, as it is possible to inject outer-level security state commands in certain implementations. To prevent this type of attack, the entire coherent fabric can be encrypted. Symmetric encryption blocks (e.g., Advanced Encryption Standard [AES] 256 Galois / Counter Mode [GCM] blocks) can be used on each SMP link between nodes, including between the CPU(s) and the fabric. By ensuring a random key generated by the boot block, ARoT 106, or other secure hardware device — and therefore only ever known by member nodes — is used to set up the encryption engines on each SMP link and by ensuring the low-level boot block is not exited prior to SMP finalization, it is possible to attest to proper setup of the encrypted cluster using the iSPRs of all CPUs 102 on the coherent fabric.

[0025] Encrypting the fabric provides many benefits, ranging from protecting all data transfer between nodes to providing transparent memory encryption without additional hardware. Encryption can thus disable a new class of physical attack whereby a hostile SMP node or data-tamper device could be silently added between physical CPUs on, for example, a mainboard, thus enabling data exfiltration or corruption while simultaneously addressing the known attack vector of data extraction from external dynamic random access memory (DRAM) devices (e.g., dual in-line memory modules [DIMMs]).

[0026] Using IES block 112 described herein (set of iSPR values for a given code execution) has high value for firmware boot block execution verification, as ARoT 106 can not only hash and attest firmware entering CPU 102, but also can attest to the execution sequence on CPU 102, and take appropriate action ranging from reporting the iSPR value to potentially intervening in a compromised or malfunctioning system (e.g., where the iSPRs do not match the expected postexecution values). This approach of using an execution-verification (“feed back”) signal complements the traditional firmware hash check (“feed forward”) signal. Stated another way, the feed forward signal is the command channel, and the feed-back signal is the read-back on a different channel that verifies the command was executed as intended.

[0027] In one embodiment, in the field of high availability I redundant / non-stop computing (e.g., for aviation flight computers), it can be difficult to have high-speed instruction-by-instruction lockstep (i.e., parallel) execution without slowing down corresponding lockstep cores, as it is impractical to transfer state at full-core clock rates for comparison by an external device. Using IES block 112, two (or more) processors can execute in lockstep. Provided these processors are functioning correctly, the iSPR values will match when accessed. If a CPU 102 mis-executes even a single instruction, the next time the iSPR values are polled, there will be an immediate discrepancy, and an external device can take appropriate action on the corresponding CPU 102.

[0028] Embodiments disclosed herein also can be used to implement CPU 102 verification prior to bringing a critical or secure computer system online. By feeding a complex test program to CPU 102 via ARoT 106 — allowing execution for a defined period of time, then reading the iSPRs back out — comprehensive CPU 102 functionality checks can be performed on each and every platform start. By catching a faulty or intermittent CPU 102 prior to system start (or at regular intervalsduring operation), chances for data corruption or CPU 102 misfunction in critical applications can be significantly reduced.

[0029] As illustrated in FIG. 2, timing between an ARoT-verified command path (command path shown from ARoT 106 to CPU 102), hash(es) within the IES block 112, and the verification-path IES output (verification path shown by the GPR iSPRs within IES block 112 to the ATPM 114) can be measured. ATPM 114 can measure and verify timing between these two paths as a form of CPU 102 presence / CPU 102 type verification, forcing a bad actor tapping into those two paths to meet precise timing to establish an attack surface. This attack surface can be further minimized by setting a register or other program variable to a random value only known by the ARoT 106 and forcing the ATPM 114 to only take a measurement in a short (likely known, based on CPU 102 type) timeframe before a bad actor could potentially calculate the correct IES hash(es). The random value would allow a verification system to take time to calculate what the IES hash(es) should have been, and subsequendy check the measurement previously stored in ATPM 114 in order to determine if CPU 102 had actually executed the correct program.

[0030] Protection against voltage glitching and other forms of physical attack currently used by advanced threat actors can be prevented using embodiments disclosed herein. If voltage glitching attempts are made, CPU 102 would immediately cause a verification path failure, allowing ATPM 114 to take appropriate action to reset the machine, clear keys, or perform another action determined by system integrity stakeholders 116.

[0031] It should be appreciated that IES output may be recorded in persistent memory for logging purposes. Such logging may take place at fixed intervals and be incorporated into a permanent record, such as a blockchain or a directed acyclic graph (DAG). If system inputs and program information are known, such log output may then be used to detect the exact timing and nature of a fault that occurred on a critical system. For example, in a life support or aviation computer, it is often practical to simulate all inputs and compare against logged operation in a post-mortem failure analysis. In further embodiments, such log output may be incorporated in a proof that CPU work has taken place, for example, to support proof-of-CPU-work operations of blockchains, workbased or time-based billing operations in a cloud or other leased-system environment.

[0032] In various embodiments, the CPU 102, ARoT 106, and ATPM 114 may be placed within a tamper-resistant enclosure, with the ATPM 114 / ARoT 106 able to act on tamper events in such a way as to protect command and verification pathways.

[0033] Various embodiments of the invention have been described above for purposes of illustrating the details thereof and to enable one of ordinary skill in the art to make and use the invention. The details and features of the disclosed embodiment(s) are not intended to be limiting, as many variations and modifications will be readily apparent to those of skill in the art. Accordingly, the scope of the present disclosure is intended to be interpreted broadly and to include all variations and modifications coming within the scope and spirit of the appended claims and their legal equivalents.

Claims

CLAIMS1. A central processing unit, comprising: a decode / execution unit; an instruction type filter configured to receive instructions from the decode / execution unit; and a hash module configured to perform a hash function on the received instructions.

2. The central processing unit of claim 1, wherein the hash module is configured to store an output of the hash function in an execution state register.

3. The central processing unit of claim 1, wherein the hash function is a secure hash algorithm that produces a fixed-size output.

4. The central processing unit of claim 1, wherein the hash module is further configured to perform the hash function based on a current state stored within the execution state register.

5. The central processing unit of claim 4, wherein the hash module is further configured to perform the hash function based on arguments associated with the instructions.

6. The central processing unit of claim 1, further comprising an adder connected to the instruction type filter and configured to store an instruction count in an instruction count register.

7. The central processing unit of claim 1, further comprising.: one or more data registers; one or more data hash modules configured to perform a hash function on data from an associated subset of the one or more data registers.

8. A method of operating a processor, comprising: accessing instructions including an operation code and arguments associated with the operation code; accessing current instruction path state of the processor; performing one or more hash functions using the operation code, arguments, execution state register, and current instruction path state to produce a hash output; andstoring the hash output in an execution state register, said hash output being indicative of a subsequent current state of the processor.

9. The method of claim 8, further comprising: using an instruction type filter to transmit the instructions and an enable signal to a hash module that performs the hash function.

10. The method of claim 9, further comprising: using the instruction type filter to transmit an enable signal to an adder; storing an instruction count value in an instruction count register based on the enable signal to the adder.

11. The method of claim 8, further comprising: transmitting the subsequent current state from the execution state register to a delay buffer; and using the subsequent current state to perform a hash function using a subsequent operation code, subsequent arguments, and the subsequent current state to produce a subsequent hash output said subsequent hash output being indicative of a second subsequent current state of the processor.

12. The method of claim 11, further comprising: assembling the current state, the subsequent current state, and the second subsequent current state into a hash chain of state information for the processor.

13. The method of claim 8, further comprising: transmitting the subsequent current state from the execution state to an active .trusted platform module; andcomparing the subsequent current state with an expected current state using the active trusted platform module, said expected current state based on prior knowledge of expected execution.

14. The method of claim 8, further comprising: performing a hash function on data from an associated subset of one or more data registers.

15. A computer system, comprising: an active root of trust module, said active root of trust module configured to access and transmit operating instructions; a central processing unit including an immutable execution stream block configured to produce hash output from the transmitted operating instructions; and an active trusted platform module configured to compare the hash output to an expected hash output..

Images