Processors, methods, and systems for preventing return-oriented programming attacks

Abstract

In one embodiment, a processor includes hardware circuitry for identifying instruction operands. The processor can execute instructions that perform operand identification speculatively and non-speculatively. During speculative execution of such instructions, the processor can perform identification such that there is no discrepancy in the processor's observable state relative to the identification result detectable via a side channel. During speculative execution, a result of the identification can be deferred until the speculative execution of the instruction and additional instructions can be completed. After resolving a condition indicating acceptance of the speculative execution, a speculative execution result can cause a processor exception and a pause in execution at the instruction to be executed.

Description

Consistent Speculation of Pointer Authentication The embodiments described herein relate to return-oriented programming (ROP) attacks that employ speculative execution and mechanisms for preventing such attacks. ROP attacks are often used by malicious programmers (e.g., "hackers") to attempt to break the security of a system and thereby gain control of the system. Typically, an ROP attack involves modifying the return address on the stack, causing execution to return to a different program location than the one indicated by the original return address. By looking for various instructions or short instruction sequences in the code on the machine (e.g., operating system code) that are followed by a return or a jump, an ROP attacker can build a list of "instructions." Once the list of instructions forms a Turing Machine, a compiler can use the list to compile code to perform the task desired by the malicious programmer. None This application claims priority to U.S. Provisional Patent Application No. 63 / 583,551, filed on September 18, 2023, entitled "Consistent Speculation of Pointer Authentication," the entire content of which is hereby incorporated herein by reference. Normal software control flow often requires multiple pairs of call and return operations. Each call operation pushes a return address onto the stack. The corresponding return operation pops the return address from the stack and jumps to the location indicated by the return address. A malicious programmer or attacker may attempt to hijack the call / return control flow to redirect the return to a target code segment desired by the attacker rather than the one intended by the original software program. One mechanism employed by such attacks is an ROP attack, in which the return address that can be used by a return instruction as the source of the return address (e.g., the stack can be popped into a link register) is overwritten on the stack and / or in a register (e.g., the link register). Pointer authentication is a method of protecting control flow integrity (CFI) in software using pointer authentication codes (PACs). In the area of ROP prevention, PACs are used to sign the return addresses pushed onto the stack. In the paired return operation, the signed return address is popped from the stack and authenticated before being used to direct the control flow. Thus, even if an attacker has the ability to overwrite the return address on the stack, they will need to overwrite it with the correct signed value. Otherwise, at the return operation, the authentication of the popped return address will fail, and the attack can be detected and terminated. The scheme for the signature return address uses a secret key value (e.g., in a hidden hardware register) combined with the value of the stack pointer and the address of the callee (e.g., the target address of the call in a call / return pair, such as the start of a function that will end with a return instruction) to form a diversified key for the cryptographic signature of the return address. The secret key may also be referred to as a cryptographic key. The cryptographic key can be unique for a given system, which can help prevent "break once, run anywhere" type of attacks. That is, even if an attacker somehow succeeds when attacking one instance of the system, due to different keys and thus signatures, even the same call / return pair will be different, and ROP-type attacks cannot be used on other instances of the system. The stack pointer is a measurement of the stack height at the time of the call and return operations and is also an indication of where the return address is stored. The address of the callee identifies the location in memory where the callee is stored and thus identifies the callee in the signature. Since the return address is associated with the call (e.g., it can point to the next subsequent instruction after the call instruction), it identifies the call code. In this way, the signature has inputs for both the caller and the callee, linking them together. It is therefore not feasible to monitor the stack contents at the same height for different call / return pairs to replace different return addresses. If a particular PAC is not modified, the authentication passes and the pointer can be used. However, if the PAC has been modified, the authentication fails and the processor signals a fault. This fault allows the attack code to be paused and the code to be detected by the system. However, the method of determining the information about the success or failure of PAC authentication can employ speculative execution of the authentication, where the processor can execute the authentication instruction while deferring the generation of the fault until the execution of the code path can be confirmed. If the execution of the speculation fails due to a misprediction of the code path, the attacker can cause the authentication operation to be executed without the risk of generating a processor fault. Thus, the attack code and infer information about the PAC and make the PAC vulnerable to brute force attacks. In one embodiment, a processor may include hardware circuitry for identifying instruction operands, such as PACs. The processor may execute instructions that perform operand identification speculatively and non-speculatively. During speculative execution of such instructions, the processor may perform the identification such that there is no difference in the observable state of the processor relative to the identification result that can be measured via a side-channel. An example of such a side-channel may be measuring the execution latency of an instruction sequence using a high-resolution timer, where differences in the microarchitectural effects of the instruction sequence on the observable state of the processor (such as through the execution of conditional load and store operations that affect the cache memory or memory subsystem content, through instruction prefetch operations, through the execution latency of individual instructions, etc.) can affect such latencies and can thus be detected by malicious software. It should be understood that these are only examples of side-channels for detecting differences in the observable state, any number of such side-channels are conceivable and these examples are not intended to be limiting. During speculative execution, a result of an identification may be deferred until speculative execution of the instruction and additional instructions can complete. After resolving the conditions indicating acceptance of speculative execution, the speculative execution result may cause the processor to encounter an exception and pause execution at the instruction corresponding to the oldest speculative execution exception to be executed. Turning now to FIG. 1, a block diagram of an embodiment of a processor that provides consistent behavior during speculative execution of pointer identification is shown. In the embodiment of FIG. 1, processor 10 may include an execution core 12 coupled to a register file 14 and optionally coupled to one or more special-purpose registers 16. Processor 10 may represent a general-purpose processor that performs computational operations. For example, processor 10 may be a central processing unit (CPU), such as a microprocessor, a microcontroller, an application-specific integrated circuit (ASIC), or a field-programmable gate array (FPGA). Processor 10 may be a stand-alone component, or may be integrated onto an integrated circuit with other components (e.g., other processors or other components in a system on a chip (SOC)). Processor 10 may be a component in a multichip module (MCM) that has other components. As illustrated in FIG. 1, the processor 10 may include an execution core 12. The execution core 12 may be configured to execute instructions defined in the instruction set architecture implemented by the processor 10. The execution core 12 may have any microarchitecture features and implementation features as needed. For example, the execution core 12 may include a superscalar or scalar implementation. The execution core 12 may include an in-order or out-of-order implementation and may include speculative execution capabilities. The execution core 12 may include any combination of the above features. In some embodiments, the implementation may include microcode. The execution core 12 may include various execution units, each execution unit being configured to perform various types of operations (e.g., integer, floating point, vector, multimedia, load / store, etc.). The execution core 12 may include a different number of pipeline stages and various other performance enhancement features, such as branch prediction. The execution core 12 may include one or more of an instruction decoding unit, a scheduler or reservation station, a reorder buffer, a memory management unit, an I / O interface, etc. The register file 14 may include a set of registers that can be used to store operands of various instructions. The register file 12 may include registers of various data types, and based on the type of the operand (e.g., integer, floating point, multimedia, vector, etc.), the execution core 12 is configured to store in the register. The register file 14 may include architected registers (i.e., those registers specified in the instruction set architecture implemented by the processor 10). Alternatively or additionally, the register file 14 may include physical registers (e.g., if register renaming is implemented in the execution core 12). The special-purpose register 16 may be a register provided in addition to the general-purpose registers. While general-purpose registers may be operands of any instruction of a given data type, special-purpose registers are typically used for operands of specific instructions or subsets of instructions. For example, in some embodiments, the program counter register may be a special-purpose register that stores the fetch address of an instruction. The link register may be a register that stores the return address and may be accessed by a branch instruction. Although the special-purpose registers 16 are shown as separate from the register file 14, in other embodiments, they may be integrated into the register file 14. In some embodiments, certain general-purpose registers may be reserved by compiler conventions or other software conventions to store specific values (e.g., stack pointer, frame pointer, etc.). Processor 10 can be configured to perform signature and authentication operations on the return address using the authorizer circuitry 11 to detect whether the address has been modified between the time it was created / stored and the time it will be used as a target. In some embodiments, the address can be signed when written to memory (such as by using the load store unit 19). For example, the return address can be written to a stack in memory. In other embodiments, the return address can be signed in the register that stores it when executing a subroutine call instruction (more simply, a "call instruction"). For example, a link register can be provided to store the return address. When the address is retrieved later for use as a return target address, processor 10 can be configured to perform an authentication operation on the address. If the authentication operation fails, error handling can be initiated instead of using the address as the fetch address. Performing a signature operation on a value can be more concisely referred to as "signing" the value in this document. Similarly, performing an authentication operation on a value can be more concisely referred to as "authenticating" in this document. In one embodiment, the authorizer circuitry 11 can implement signature generation and authentication features. Performing a signature operation or "signing" an address generally can refer to using at least one cryptographic key and applying a cryptographic function to the address using additional data. The result of the cryptographic function is the signature. By applying the cryptographic function again later and comparing the resulting value with the signature, an authentication operation can be performed on the address (or the address can be "authenticated"). That is, if the address and / or signature have not been modified, the result of the cryptographic function should equal the signature. The cryptographic key can be specific to the thread that includes the generation of the address and the execution that uses the address as a target, and thus the likelihood of undetected modification by a third party without the key can be extremely small. The cryptographic key can be generated based at least in part on a "secret" that is specific to an instance of processor 10 and is not accessible except in hardware. The cryptographic key itself also cannot be accessed by software, and thus the key can remain secret and difficult to discover by a third party. In one embodiment, the additional data used in the signature and authentication of the return address can include the address that stores the return address. For example, the virtual address of that location can be used (such as a virtual stack pointer, for storage of the address on the stack). Other embodiments can use the physical address. Additionally, the additional data can include the address of the callee (such as the first instruction of the called function). That is, the address can be the target address of the call instruction, referred to herein as the callee's program counter address or PC. As mentioned above, the signature instruction generally can specify the source operand to be signed, and the signature can be generated based on the cryptographic key, the stack pointer, and the PC of the sign instruction (plus an offset specified by the signature instruction). The cryptographic function applied to the return address may be address encryption using one or more keys. The encryption result as a whole may be a signature, or a part of the result may be a signature (e.g., the signature may be shortened by truncation or shifting). Any cryptographic algorithm may be used, including the various examples given below. It should be understood that the above description of the cryptographic signature is an example of address authentication. Another example may employ using address metadata assigned during memory allocation. In this example, metadata such as a memory tag may be allocated along with a portion of the memory. Subsequent accesses to the memory may then depend on the authentication of the memory tag. The accessor of the memory must provide the originally assigned memory tag, and the processor may then compare the original memory tag with the stored copy of the memory tag to perform the required authentication. It should be understood that these are only examples of authentication and are not intended to be limiting. Additionally, in various embodiments, the processor may employ multiple authentication techniques. An instruction may be an executable entity defined in the instruction set architecture implemented by the processor 10. There are various existing instruction set architectures (e.g., the x86 architecture originally developed by Intel, ARM from ARM Holdings, Power and PowerPC from IBM / Motorola, etc.). Each instruction is defined in the instruction set architecture, including its encoding in memory, its operation, and its effect on registers, memory locations, and / or other processor states. A given implementation of the instruction set architecture may execute each instruction directly, although its form may be changed through decoding and other manipulations in the processor hardware. Another implementation may decode at least some instructions into multiple instruction operations for execution by the execution units in the processor 10. In some embodiments, some instructions may be microcoded. Thus, the term "instruction operation" may be used herein to refer to an operation that the execution units in the processor 10 / execution core 12 are configured to execute as a single entity. An instruction may have a one-to-one correspondence with an instruction operation, and in some cases, an instruction operation may be an instruction (possibly modified in form within the processor 10 / execution core 12). An instruction may also have a one-to-more-than-one (one-to-many) correspondence with an instruction operation. An instruction operation may be more briefly referred to as an "op" herein. In one embodiment, processor 10 includes one or more registers and an execution core coupled to the one or more registers. The fetch and decode 17 circuitry of processor 10 may determine to speculatively execute an instruction using execution unit 18 based on an unresolved condition, generating a predicted instruction stream. In some embodiments, the authentication operation may be performed using fast pointer generator 13, which unconditionally generates pointer addresses that can be used by processor 10 to complete the execution of an instruction without waiting for the authentication result from authorizer 11. The authentication result from authorizer 11 may then be monitored by redirection monitor 15 such that once the resolution of the condition causes speculative execution to occur, processor 10 can report a processor exception resulting from the execution. In some embodiments, the execution of an instruction may be completed using load store unit 19 to perform memory operations using the pointer addresses generated by previous pointer generator 13. Turning now to FIG. 2, a block diagram is shown illustrating an embodiment depicting an M-bit memory location or register. M may be an integer greater than zero. More specifically, M may be the architectural size of the virtual address in processor 10. For example, some instruction set architectures currently specify 64-bit addresses. However, the actual implemented virtual address size may be smaller (e.g., 40 to 48 bits). Thus, in such implementations, some address bits are not actually used. In one embodiment, the most significant virtual address bits implemented may be replicated in the remaining virtual address bits up to the architectural maximum. In one embodiment, one or more of the most significant bits of the architectural maximum may be considered invalid, and the most significant address bits may be replicated up to the most significant valid address bits. For example, in one embodiment, the most significant bit may be considered either valid or invalid. In one embodiment, unused bits may be used to store a signature of the address. Other embodiments may store the signature in another memory location. In the embodiment of FIG. 2, a virtual address of t+1 bits (field 20) is implemented, where t is less than M and is also an integer. The remaining bits of the register / memory location store the signature (field 22). A signature such as that generated from a cryptographic algorithm may be larger than signature field 22 (e.g., greater than M-(t+1) bits). Thus, the signature actually stored for the address may be a portion of the signature. That is, the signature may be reduced in size from the signature generated by the signature operation and may replace a subset of the bits of the return address. For example, the signature may be truncated. Alternatively, the signature may be shifted to the right. Any mechanism for shortening the signature field may be used. Processor 10 may implement signature generation and authentication in hardware. For example, signature generation / authentication circuit 18 is shown in FIG. 1 and may include circuitry for signing and authenticating the return address (or more generally, signing and authenticating source operands). There may be instructions defined for the instruction set architecture that cause signature generation or authentication to be performed. FIGS. 3 and 4 respectively illustrate embodiments of instructions for signature generation and authentication. Figure 3 illustrates an embodiment of a signature generation instruction. In this embodiment, the Sign instruction takes as input operands the virtual return address stored in the link register (LR), the virtual stack pointer address stored in the stack pointer register (SP), the virtual instruction address (PC), and a key. The PC may store the address of the Sign instruction. The key may be stored in a hardware-accessible register or other storage device that is only accessible by hardware. The key may be one key or multiple keys depending on the encryption algorithm implemented by the processor 10. The encoding illustrated in Figure 3 may be an example of return address discrimination. More generally, the LR may be any source operand (e.g., any register). In one embodiment, the sign instruction may also specify an offset, such as a displacement or an immediate field. The displacement / immediate field may be added to the PC operand. The Sign instruction may apply an encryption algorithm to the data that generates a signature that can be written to a destination register (e.g., written back to the link register). The data may be combined before encryption (e.g., the return address, stack pointer, and PC may be logically combined according to any desired logical function, such as a function based on exclusive or), and the resulting data may be encrypted using the key. The data may be concatenated and encrypted using one or more rounds of a block encryption (block cipher) mechanism. Any type of encryption may be used, including any type of block cipher, such as the Advanced Encryption Standard (AES), Data Encryption Standard (DES), International Data Encryption Algorithm (IDEA), PRINCE, etc. One factor in determining the encryption algorithm to be used is the latency of the algorithm. Thus, a single-round encryption that is strong enough to protect the encrypted data to the desired security level may be selected. The signature generated by the encryption may then be truncated to match the field 22. The result in the destination register may be in the form shown in Figure 2. As mentioned above, various logical operations can be used to combine the data included in signature generation. The least significant bit (LSB) of the address may contain the most entropy, which can provide secure encryption. In one embodiment, the most significant bit (MSB) of the address differentiates between privileged memory and non-privileged memory. As mentioned above, bits 0..t may contain the address and bits t+1 to M may be replicated bits. Additionally, in one embodiment, the PC and LR registers may need to be aligned to a 32-bit boundary (e.g., the instructions may be 32-bit fixed-length instructions in the implemented ISA). The stack pointer may be aligned to a 128-bit boundary (e.g., 64-bit values are typically pushed and popped on the stack). Accordingly, the bits to be encrypted may include PC bits t to 2, LR bits t..2, and SP bits t..4. In one embodiment, the following mechanism may be used: using the 21 least significant bits from LR, PC, and SP to form a 63-bit value, and appending the bit t of the PC at bit position 63 to form a 64-bit value to be encrypted to form a first value P; using the 21 middle significant bits of LR, PC, and SP, and appending the bit t of LR at bit position 63 to form a 64-bit value to be used as a scatter value to form a scatter value D; forming a third value R by interleaving the remaining significant bits of LR, PC, and SP with 0 (e.g., up to bit t). The resulting values are replicated across 64 bits, with bit 63 reserved as zero; and the equal values are encrypted as follows, where the cryptography takes two 64-bit values to produce a single encrypted 64-bit value C = E(X,Y), where X is R XOR P, and Y is R XOR D. The resulting encrypted value C can then be truncated to produce the signature field 22. For example, M-t bits can be extracted from C and used as the signature. Figure 4 illustrates an embodiment of an authentication instruction. The Auth instruction may take the LR, SP, and PC values and a key as input operands. The Auth instruction may apply the same encryption algorithm as the Sign instruction to the return address field 20, thereby generating a signature. The resulting signature may be compared to the original signature in the signature field 22 (truncated in the same manner as the original signature is truncated). If the signatures do not match, authentication fails and a return to that address is blocked. If the signatures match, authentication passes and a return to that address is allowed. For example, a return may be blocked by taking an exception. As mentioned above, more generally, the authentication instruction may take any source operand in place of the LR register. The authentication instruction may specify an offset (e.g., a displacement or immediate field) to be added to the PC. In one embodiment, the Sign and Auth instructions can be implemented as two or more instruction operations in processor 10. For example, in one embodiment, the callee address can be specified as the PC plus offset or immediate field of the call instruction. One instruction operation can add the PC and the offset / immediate value to generate the PC to be used by the Sign and Auth instructions. Another instruction operation can obtain the PC, LR, and SP values generated by the first instruction operation and can perform a signature / authentication operation using the specified key. Turning now to FIG. 5, there is shown a flowchart of an exemplary subroutine for exploiting differences in behavior during speculative execution of pointer authentication. Although FIG. 5 uses pseudocode indicative of several high-level programming languages, it should be understood that any number of languages can be employed, including direct encodings of processor instructions implementing the concepts shown in FIG. 5. The exemplary subroutine can include a condition 24 defining conditional execution, an authentication operation 26 to be analyzed, and possible additional instructions or operations 28. The authentication operation 26 can perform authentication on the speculated pointer to produce a verified pointer when the speculated pointer passes authentication. If the speculated pointer fails authentication, there is a risk of processor failure or exception. To prevent this failure, the condition 24 can be established to always fail, resulting in bypassing the execution of the potentially failing authentication 26. Thus, in various embodiments, through speculative execution resulting from the predicted execution of 26 and 28, since the condition 24 will always evaluate to a false condition, the authentication operation 26 can be performed without the risk of processor exception. Turning now to FIG. 6, there is shown a flowchart of an exemplary subroutine that can be executed by processor 10 in the system. Although the blocks are shown in a particular order for ease of understanding, other orders can be used. Instructions executed by processor 10 and / or hardware in processor 10 can implement the operations shown in FIG. 5. Processor 10 can push the return address of the subroutine onto the stack (block 40). The push can occur in the calling code before jumping to the address of the subroutine, or can occur within the subroutine. Additional details of some embodiments regarding pushing the return address are described below with respect to FIG. 6. The subroutine can include instructions (generally denoted by reference numeral 42) that perform the operation(s) for which the subroutine is designed. The subroutine can pop the return address from the stack (block 44) and return to the return address (block 46). That is, the return address can be used as the fetch address to fetch the next instruction to be executed in processor 10. Additional details of some embodiments regarding popping the return address are described below with respect to FIG. 7. Now turning to FIG. 7, there is shown a flowchart depicting one embodiment of pushing the return address (e.g., block 40 in FIG. 5). Although the blocks are shown in a particular order for ease of understanding, other orders can be used. Instructions executed by processor 10 and / or hardware in processor 10 can implement the operations shown in FIG. 6. A signature based on the VA, return address (LR), the address of the callee (PC), and a key can be generated by applying a selected encryption algorithm to the data (block 52). The generated signature can be combined with the return address to form a signed return address (e.g., as shown in FIG. 2) (block 54). For example, the M-t bits can be extracted from S and concatenated with bits 0:t of the return address (LR) and can be written as the signed return address into LR. The signed return address from LR can be pushed onto the memory location indicated by the value of the stack pointer (block 56). As mentioned above, any encryption algorithm can be used. For example, a multi-round block encryption algorithm can be used. In one embodiment, the PRINCE algorithm can be used. Turning now to FIG. 8, a flowchart is shown depicting an embodiment of popping a return address (e.g., block 44 in FIG. 5). Although the blocks are shown in a particular order for ease of understanding, other orders can be used. Instructions executed by the processor 10 and / or hardware in the processor 10 can implement the operations shown in FIG. 7. The signed return address can be loaded from the memory location indicated by the value of the stack pointer into a target register (e.g., LR) (block 70). The signed return address can be authenticated by applying the same operations as were applied when the return address was initially signed, thereby generating a signature S'. S' can be compared with the signature field 22 (block 74). If the signature remains valid (i.e., the signature S' generated in the authentication matches the original signature S in the address) (decision block 76, "yes" branch), the return address can be used and thus the operation can continue to block 46 in FIG. 5. Otherwise (decision block 76, "no" branch), the processor 10 can signal an exception to prevent the use of the return address (block 78). In one embodiment, a method includes generating a return address for a call to a subroutine terminated by a return instruction in a processor; performing a signature operation on the return address to generate a signed return address, wherein the signature operation is based on an encryption key, the value of the stack pointer, and the address of the start instruction in the subroutine; detecting an attempt to use the signed return address for the return instruction; authenticating the signed address in response to detecting the attempt; and preventing a return in the event of a failure to authenticate the signed address. As previously mentioned, an embodiment of the encryption algorithm can be the PRINCE algorithm. The PRINCE algorithm employs a 128-bit key represented as two 64-bit keys K0 and K1. The 128-bit key is expanded to 192 bits by generating K0'. K0' is K0 rotated right by an exclusive OR with K0 shifted right by 63. PRINCE is based on the so-called FX construction [7, 30]: the first two subkeys K0 and K0' are whitening keys, and the key K1 is used for 12-round block encryption (referred to as PRINCE core A 64-bit key as in ( ). In some embodiments, the 12-round expansion can be such that the encryption latency is 1 clock cycle. Additional details of the PRINCE algorithm are provided in the paper “PRINCE - A Low-latency Block Cipher for Pervasive Computing Applications” by Borghoff et al., which was published in Advances in Cryptology - ASIACRYPT 2012 - 18th International Conference on the Theory and Application of Cryptology and Information Security, Beijing, China, December 2-6, 2012, pages 208-225, edited by Xiaoyun Wang and Kazue Sako. Turning now to FIG. 9, a block diagram of an embodiment of a processor pipeline that provides consistent behavior during speculative execution of pointer identification is shown. In various embodiments, the logic of the processor pipeline 80 can be included in one or more of the cores of a central processing unit (CPU). The processor pipeline 80 includes an instruction fetch unit (IFU) 81, which includes an instruction cache memory 82, a branch predictor 83, and a return address stack (RAS) 84. In addition to those shown, the IFU 81 can also include several data structures, such as an instruction translation lookaside buffer (ITLB), an instruction buffer, and / or other structures configured to store state related to thread selection and processing (in a multithreaded embodiment of the processor pipeline 80). The IFU 81 is coupled to an instruction processing pipeline that begins with a decode unit 85 and then proceeds through a map unit 86, a dispatch unit 87, and a release unit 88. The release unit 88 is coupled to release instructions to any of a number of instruction execution resources including the execution units 18, a load store unit (LSU) 19, and / or a floating-point / graphics unit (FGU) 92. The execution units 18 use an authorizer 11 to generate and check signatures based on at least a portion of a return address for program return. Additionally, the authorizer 11 can report results to a redirect monitor 15, which can accumulate deferred faults and execution stall sources for later reporting by a completion unit 90. The instruction execution resources are coupled to a working register file 14. Additionally, the LSU 19 is coupled to a cache memory / memory interface 93. A reorder buffer 91 is coupled to the outputs of the IFU 81, the decode unit 85, the working register file 14, and any number of instruction execution resources. It should be noted that the illustrated embodiment is only one example of how a processor pipeline 80 can be implemented. The processor pipeline 80 can include other components and interfaces not shown in FIG. 9. Alternative configurations and variations are possible and are contemplated. In one embodiment, the IFU 81 can be configured to fetch instructions from an instruction cache memory 82 and buffer them for downstream processing. The IFU 81 can also request data from the cache memory or memory through the cache memory / memory interface 93 in response to an instruction cache miss, and predict the direction and target of control transfer instructions (e.g., branches). The instructions fetched by the IFU 81 in a given clock cycle can be referred to as a fetch group, where the fetch group can include any number of instructions depending on the embodiment. A branch predictor 83 can use one or more branch prediction tables and mechanisms to determine the next fetch program counter faster than resolving the branch target address. In various embodiments, the predicted address is later verified in the pipeline by comparing it with the address calculated by the execution units 18. For the RAS 84, the predicted return address is verified when the return address (branch target address) is retrieved from a copy of the memory stack stored in the data cache memory via the LSU 19 and the cache memory interface 93. Before the branch target address is resolved, the fetched instructions can be executed speculatively by the execution units 18. During speculative execution, potential execution stalls and processor exceptions can be tracked by the redirect monitor 15. Then, when the branch target address has been resolved, the redirect monitor 15 can provide the oldest exception source for reporting by the completion unit 90. In various embodiments, prediction occurs at the granularity of an instruction fetch group, which includes multiple instructions. In other embodiments, prediction occurs at the granularity of individual instructions. In the case of a misprediction, the front end of the pipeline stage of the processor pipeline 80 can be flushed and instruction fetch can resume at a new address. The IFU 81 delivers the fetched instruction data to the decode unit 85. In one embodiment, the decode unit 85 can be configured to prepare the fetched instruction for further processing. The decode unit 85 can be configured to identify the specific nature of the instruction (e.g., as specified by its opcode), and determine the source and destination registers (if any) encoded in the instruction. The mapping unit 86 can be configured to map the decoded instruction (or uop) to physical registers within the processor pipeline 80. The mapping unit 86 can also perform register renaming to map the source register address from the uop to a source operand number identifying the renamed source register. The dispatch unit 87 can be configured to dispatch the uop to reservation stations (not shown) within various execution units. The issue unit 88 can be configured to provide instruction sources and data to various execution units for selected (i.e., scheduled or dispatched) instructions. In one embodiment, the issue unit 88 can be configured to read source operands from appropriate sources, which can vary depending on the state of the pipeline. For example, if a source operand depends on a previous instruction still executing in the pipeline, the operand can be bypassed directly from the appropriate execution unit result bus. Results can also originate from register files representing architectural (i.e., user visible) as well as non-architectural states. In the illustrated embodiment, the processor pipeline 80 includes a working register file 14, which can be configured to store instruction results (e.g., integer results, floating point results, and / or conditional signature results) that have not yet been committed to the architectural state, and can be used as a source for some operands. Various execution units can also maintain architectural integer, floating point, and conditional signature states from which operands can originate. Instructions issued from the issue unit 88 can proceed to one or more of the illustrated execution units for execution. In one embodiment, each of the execution units 18 is similarly or identically configured to execute certain integer type instructions defined in the implemented ISA, such as arithmetic, logical, and shift instructions. In some embodiments, the architectural and non-architectural register files are physically implemented within or near the execution units 18. In some embodiments, it is contemplated that the processor pipeline 80 can include any number of integer execution units, and these execution units can be functionally symmetric or asymmetric. The Load Store Unit (LSU) 19 can be configured to process data memory references, such as integer and floating point load and store instructions and other types of memory reference instructions. The LSU 19 can include a data cache memory (not shown) and logic configured to detect data cache misses and accordingly request data from the cache memory or memory through the cache memory / memory interface 93. In one embodiment, the data cache memory in the LSU 19 can be configured as a set-associative write-through cache memory, where all stores are written to a higher-level (e.g., L2) cache memory regardless of whether they hit in the data cache memory. In various embodiments, the LSU 19 can implement various structures configured to facilitate memory operations. For example, the LSU 19 can implement a data TLB to cache virtual data address translations, and a load and store buffer configured to store issued but not yet committed load and store instructions for the purposes of coherence detection and dependency checking. The LSU 19 can include a miss buffer configured to store unprocessed loads and stores that are still unable to complete (e.g., due to cache misses). In one embodiment, the LSU 19 can implement a store queue configured to store the address and data information of committed stores to facilitate load dependency checking. The LSU 19 can also include hardware configured to support atomic load-store instructions, memory-related exception detection, and read and write accesses to special-purpose registers (e.g., control registers). The Floating Point / Graphics Unit (FGU) 92 can be configured to execute certain floating point and graphics-oriented instructions defined in the implemented ISA and provide the results of such instructions. For example, in one embodiment, the FGU 92 implements single-precision and double-precision floating point arithmetic instructions that conform to the IEEE floating point standard, such as addition, subtraction, multiplication, division, and certain transcendental functions. In the illustrated embodiment, the completion unit 90 includes a reorder buffer (ROB) 91 and coordinates the transfer of speculative results to the architectural state in the processor pipeline 80. Entries in the ROB 91 can be allocated in program order. The completion unit 90 can include other components for handling instruction completion / retirement and / or storing histories including register values, etc. In some embodiments, the speculative results of instructions can be stored in the ROB 91 before being committed to the architectural state of the processor pipeline 80, and the confirmed results can be committed in program order. When the results of entries in the ROB 91 are allowed to be written to the architectural state, they can be marked as completed. The completion unit 90 can also be configured to coordinate instruction squashing and / or instruction replay with the redirect monitor 15 and coordinate the generation of processor exceptions. In various embodiments, when the decoding unit 85 determines that a procedure call to a subroutine occurs in the instructions of a software application, an indication is sent down the pipeline to the authorizer 11 for generating a cryptographic signature of the associated return address. The authorizer 11 uses one of various cryptographic algorithms. For example, in some embodiments, the authorizer 11 uses one of many variations of the relatively low-latency block cipher PRINCE algorithm. In some embodiments, the authorizer 11 uses some logic in the FPGU 92. In other embodiments, the authorizer 11 uses only the logic within itself. One or more keys stored in the secure memory, the return address, and one or more other values optionally selected by the designer are used as inputs to the cryptographic algorithm. In various embodiments, the procedure call is not completed until the signature is generated by the authorizer 11. In various embodiments, the signature and the return address are stored together as a unit to provide the value of the branch target address. In some embodiments, the signature and the return address are concatenated. In various embodiments, a first copy of the concatenated signature and return address is stored in the RAS 84, and a second copy is stored in the memory stack provided by the operating system. The second copy is sent to the data cache memory via the LSU 19 and the cache memory interface 93. Storing each of the first copy and the second copy may be referred to as "pushing" the return address. In various embodiments, when the decoding unit 85 determines that a procedure return corresponding to an earlier procedure call occurs in the instructions of a software application, an indication is sent down the pipeline to the authorizer 11 for generating a cryptographic signature of the associated return address. Additionally, the RAS 84 receives an indication such as the PC register value to provide a predicted return address. Further, the LSU 19 receives a load instruction for reading a copy of the branch target address stored in memory, such as the memory stack provided by the operating system. In various embodiments, the RAS 84 provides a predicted branch target address for instruction fetching before the LSU 19 is completed or even before the authorizer 11 has started (let alone completed). In one example, the RAS 84 provides the predicted branch target address to the instruction fetch unit 81 in one clock cycle. In some embodiments, the RAS 84 also stores the cryptographic signature along with the predicted return address. In other embodiments, the cryptographic signature is stored separately in a hardware register invisible to software. Before the authorizer 11 is completed, the instruction fetch unit 81 begins fetching the instructions stored in the memory location pointed to by the received return address. Although instruction processing continues while authentication is in progress, submission of the register indirect branch (jump) instruction corresponding to the procedure return is not allowed. Since the processor pipeline 80 uses in-order submission, instructions are not submitted until authentication is completed, although the instructions are being processed. When the LSU 19 receives a copy of the password signature and the return address from the data cache memory via interface 93, the copy of the return address is compared with the copy of the return address earlier supplied by the RAS 84. If a mismatch is detected, a branch misprediction recovery is performed. Otherwise, instruction processing continues. In some embodiments, the authorizer 11 begins to regenerate the signature based on the copy of the return address from the RAS 84. In other embodiments, the authorizer 11 begins to regenerate the signature based on the copy of the return address from the LSU 19. When the authorizer 11 finishes regenerating the password signature, this value is compared with one or more of the copies of the signature earlier retrieved from the RAS 84 and the LSU 19. If the comparison values match, instruction processing continues and the register indirect jump instruction is allowed to be committed. If a mismatch is detected during one or more comparisons of the copies of the signature, an exception is generated and the processor execution stops without committing any instructions or state. Thus, security is provided without affecting the performance during program return. Now turning to FIG. 10, there is shown a flowchart depicting the resolution of speculative execution conditions in one embodiment. A processor such as the processor 10 of FIG. 1 may speculatively execute one or more instructions based on unresolved conditions. In various embodiments, examples of such unresolved conditions are the comparison operations of processor flags in special registers (such as the special register 14 of FIG. 1) or the Boolean results of conditional checks. Since the processor may not be able to immediately determine the result of such conditions, the processor may predict the execution path or instruction flow to speculatively execute while the conditions remain unresolved. As shown at 95, the program may wait before the condition that causes speculative execution is resolved. If the condition is unresolved, as shown at the negative exit of 95, the program may return to 95. If the condition is resolved, as shown at the positive exit of 95, the program may proceed to 96. As shown at 96, the processor may then determine whether a deferred exception due to speculative execution exists, such as via the redirect monitor 15 of FIG. 1. If no deferred exception exists, as shown at the negative exit of 96, the program is completed. If a deferred exception exists, as shown at the positive exit of 96, the program may proceed to 98. As shown at 98, the oldest deferred exception may then be selected. Since some deferred exception sources may not cause the speculative execution to stall, there may be multiple deferred exceptions. Thus, only the first and oldest exception generated by the speculative execution and the corresponding instruction that generated the exception may be reported. This exception is then selected and reported as part of the last speculative execution. The program then completes. Now turning to FIG. 11, there is shown a timing diagram depicting the sequence of events implementing the identified load instruction in one embodiment. As shown at 100, the identified load or identified store instruction may be decoded for speculative execution by the execution core 12 of the processor. First, the execution core 12 may request an unsigned memory address pointer 102 from the fast pointer generator 13, where the unsigned memory address pointer will match the pointer generated by the successful identification of the signed memory address operand of the load / store instruction. The unsigned memory address pointer may then be provided as part of the request to the load / store unit 19 to perform a speculative load / store operation 104. The load / store unit 19 may then provide a load / store result 106 to the execution unit 18. Independent of the load / store operation, the execution core 12 may request an authorization 108 of the signed pointer operand of the instruction from the authorizer 11. In the event of a failure to authorize the signed pointer, the authorizer 11 may report the failure 112 to the redirect monitor 15. In the event of a successful authorization, since successful authorization was assumed in steps 104 and 106, the authorizer 11 does not need to report the authorized pointer. As shown at 120, the speculative execution of the processor may then continue for additional instructions decoded for speculative execution. Next, after resolving the speculative execution condition 130, the execution core 12 may resolve the speculative execution of various instructions by checking for a deferred failure 132 from the redirect monitor 15. If a deferred failure has been registered (such as in step 112), the failure may be passed back to the execution core 12 for subsequent reporting. Now turning to FIG. 12, there is shown a flowchart depicting the identified load instruction in one embodiment. The process begins at step 152 of identifying the next instruction to be speculatively executed. If the instruction is an identified load / store instruction, as indicated by the affirmative exit from 154, the process may proceed to 160. If the instruction is not an identified load / store instruction, as indicated by the negative exit from 154, the process may proceed to 156. As shown at 156, the process may then speculatively execute the instruction. Whether the speculative execution stalls or not, the speculative execution of the instruction may result in the generation of a deferred exception condition. If the speculative execution stalls, as indicated by the affirmative exit from 150, the process is complete. If the speculative execution does not stall, as indicated by the negative exit from 150, the process may return to 152. As shown at 160, the identification of the signed pointer operand of the instruction may then be performed. If the identification fails, as indicated by the affirmative exit from 162, an identification failure 158 may be registered with a monitor (such as the redirect monitor 15 of FIG. 1) for future reporting as discussed above in FIG. 10, and the process may proceed to 164. If the identification is successful, as indicated by the negative exit from 162, the process may proceed to 164. As shown in 164, an unsigned pointer equivalent to the pointer returned by successful authentication of the signed pointer operand can then be generated by a fast pointer generator 13 such as that of FIG. 1. This pointer can then be provided to a load / store unit (such as the load / store unit 19 of FIG. 1) to perform the load / store portion of the instruction. Since the speculative execution of the load / store authentication did not stall, the program can then return to 152. Turning now to FIG. 13, there is shown a timing diagram depicting the sequence of events for performing an authenticated load branch in one embodiment. As shown in 200, the authenticated branch instruction can be decoded for speculative execution by the execution core 12 of the processor. First, the execution core 12 can request an unsigned memory address pointer 202 from the fast pointer generator 13, where the unsigned memory address pointer will match the pointer generated by successful authentication of the signed memory address pointer operand of the load / store instruction. The unsigned memory address pointer can then be provided as part of the request to the execution core 12 to perform a speculative branch operation 204. Independent of the load / store operation, the execution core 12 can request authorization 208 of the signed pointer operand of the instruction from the authorizer 11. In the event that the authorization of the signed pointer fails, the authorizer 11 can report the failure 212 to the redirect monitor 15. In the event that the authorization is successful, since the authorization was assumed successful in step 204, the authorizer 11 does not need to report the authorized pointer. As shown in 220, the speculative execution of the processor can then continue for additional instructions decoded for speculative execution. Next, after resolving the speculative execution condition 230, the execution core 12 can resolve the speculative execution of various instructions by checking for a deferred failure 232 from the redirect monitor 15. If a deferred failure has been registered (such as in step 212), the failure can be returned to the execution core 12 for subsequent reporting. Turning now to FIG. 14, there is shown a flowchart depicting an authenticated branch instruction in one embodiment. The process begins at step 252 of identifying the next instruction to be speculatively executed. If the instruction is an authenticated branch instruction, as indicated by the positive exit from 254, the process can proceed to 260. If the instruction is not an authenticated branch instruction, as indicated by the negative exit from 254, the process can proceed to 256. As shown in 256, the process can then speculatively execute the instruction. Whether the speculative execution stalls or not, the speculative execution of the instruction can result in the generation of a deferred exception condition. If the speculative execution stalls, as indicated by the positive exit from 250, the process is complete. If the speculative execution does not stall, as indicated by the negative exit from 250, the process can return to 252. As shown at 260, authentication of the signed pointer operand of the instruction to be executed can then be performed. If the authentication fails, as indicated by the positive exit from 262, an authentication failure 258 can be registered with a monitor (such as the redirection monitor 15 of FIG. 1) for future reporting as discussed above in FIG. 10, and the program can proceed to 264. If the authentication is successful, as indicated by the negative exit from 262, the program can proceed to 264. As shown at 264, an unsigned pointer equivalent to the pointer returned by successful authentication of the signed pointer operand can then be generated by a fast pointer generator 13 such as that of FIG. 1. Execution control can be transferred to this pointer address to execute the branch portion of the instruction. Since speculative execution of the authentication branch did not stall, the program can then return to 252. Turning now to FIG. 15, a timing diagram is shown depicting the sequence of events for implementing an authentication instruction in one embodiment. As shown at 300, the authentication instruction can be decoded for speculative execution by the execution core 12 of the processor. First, the execution core 12 can request an unsigned memory address pointer 302 from the fast pointer generator 13, where the unsigned memory address pointer will match the pointer generated by successful authentication of the signed memory address pointer operand of a load / store instruction. The unsigned memory address pointer can then be provided as part of the request to the execution core 12 to perform a speculative branch operation 304. Independent of the load / store operation, the execution core 12 can request authorization 308 of the signed pointer operand of the instruction from the authorizer 11. In the event that authorization of the signed pointer fails, the authorizer 11 can report the failure 312 to the redirection monitor 15. In the event that authorization is successful, since authorization was assumed to be successful in step 304, the authorizer 11 does not need to report the authorized pointer. As shown at 320, speculative execution of the processor can then continue for additional instructions decoded for speculative execution. Next, after resolving the speculative execution condition 330, the execution core 12 can resolve speculative execution of various instructions by checking for a deferred failure 332 from the redirection monitor 15. If a deferred failure has been registered (such as in step 312), the failure can be returned to the execution core 12 for subsequent reporting. Turning now to FIG. 16, a flowchart is shown depicting an authentication instruction in one embodiment. The program begins at step 352 of identifying the next instruction to be executed speculatively. If the instruction is an authentication instruction, as indicated by the positive exit from 354, the program can proceed to 360. If the instruction is not an authentication instruction, as indicated by the negative exit from 354, the program can proceed to 356. As shown in 356, the program can then speculatively execute the instruction. Whether the speculative execution pauses or not, the speculative execution of the instruction can result in the generation of a deferred exception condition. If the speculative execution pauses, as indicated by the positive exit from 350, the program is complete. If the speculative execution does not pause, as indicated by the negative exit from 350, the program can return to 352. As shown in 360, the authentication of the signed pointer operand of the instruction can then be performed. If the authentication fails, as indicated by the positive exit from 362, an authentication failure 358 can be registered with a monitor (such as the redirection monitor 15 of FIG. 1) for future reporting as discussed above in FIG. 10, and the program can proceed to 364. If the authentication succeeds, as indicated by the negative exit from 362, the program can proceed to 364. As shown in 364, an unsigned pointer equivalent to the pointer returned upon successful authentication of the signed pointer operand can then be generated by a fast pointer generator 13 such as that of FIG. 1. This pointer can then be returned to complete the speculative execution of the instruction. Since the speculative execution of the authentication branch did not stall, the program can then return to 352. Now turning to FIG. 17, a timing diagram is shown depicting the sequence of events for implementing an authenticated memory tag instruction in one embodiment. As shown in 500, the authenticated memory tag instruction can be decoded for speculative execution by the execution core 12 of the processor. The execution core 12 can request verification 508 of the memory tag operand of the instruction from the authorizer 11. In the event that the verification fails, the authorizer 11 can report the failure 512 to the redirection monitor 15. As shown in 520, the speculative execution of the processor can then continue for additional instructions decoded for speculative execution. Next, after resolving the speculative execution condition 530, the execution core 12 can resolve the speculative execution of various instructions by checking for a deferred fault 532 from the redirection monitor 15. If a deferred fault has been registered (such as in step 512), the fault can be returned to the execution core 12 for subsequent reporting. Now turning to FIG. 18, a flowchart is shown depicting an authenticated memory tag instruction in one embodiment. The program begins at step 452 of identifying the next instruction to be speculatively executed. If the instruction is an authenticated memory tag instruction, as indicated by the positive exit from 454, the program can proceed to 460. If the instruction is not an authentication instruction, as indicated by the negative exit from 454, the program can proceed to 456. As shown in 456, the program can then speculatively execute the instruction. Whether the speculative execution pauses or not, the speculative execution of the instruction can result in the generation of a deferred exception condition. If the speculative execution pauses, as indicated by the positive exit from 450, the program is complete. If the speculative execution does not pause, as indicated by the negative exit from 450, the program can return to 452. As shown at 460, identification of the memory tag operand of the instruction to be executed can then be performed. If the identification fails, as indicated by the positive exit from 462, an identification failure 458 can be registered with a monitor (such as the redirection monitor 15 of FIG. 1) for a future report as discussed above in FIG. 10, and the program can proceed to 464. If the identification is successful, as indicated by the negative exit from 462, the program can then return to 452. Turning now to FIG. 19, a block diagram of an embodiment of a system that can include one or more of the processors depicted in FIGS. 1-18 is shown. In the illustrated embodiment, the system can be implemented as a system-on-a-chip (SOC) 810 coupled to a memory 840. As the name implies, the components of the SOC 810 can be integrated onto a single semiconductor substrate that serves as an integrated circuit “chip”. In some embodiments, the components can be implemented on two or more discrete chips in the system. However, the SOC 810 will be used as an example herein. In the illustrated embodiment, the components of the SOC 810 include a plurality of processor clusters 814a through 814n, an interrupt controller 820, one or more peripheral components 818 (more briefly, “peripherals”), a memory controller 840, and a communication mesh 816. The components 814a through 814n, 818, 820, and 840 can all be coupled to the communication mesh 816. The memory controller 840 can be coupled to the memory 840 during use. In some embodiments, there can be more than one memory controller coupled to a corresponding memory. The memory address space can be mapped across the memory controllers in any desired manner. In the illustrated embodiment, the processor clusters 814a through 814n can each include a plurality of processors (P) 830. The processors 830 can form the central processing unit (CPU) of the SOC 810. In one embodiment, one or more of the processor clusters 814a through 814n can not be used as the CPU. As mentioned above, the processor clusters 814a through 814n can include one or more processors 830 that can serve as the CPU of the SOC 810. The CPU of the system includes a processor that executes the main control software of the system, such as an operating system. Generally, the software executed by the CPU during use can control the other components of the system to achieve the desired functions of the system. The processor can also execute other software, such as application programs. Application programs can provide user functions and can rely on the operating system for lower-level device control, scheduling, memory management, etc. Thus, the processor can also be referred to as an application processor. Typically, a processor may include any circuitry and / or microcode configured to execute instructions defined in an instruction set architecture implemented by the processor. The processor may encompass a processor core implemented with other components on an integrated circuit as a system-on-chip (SOC 810) or other integrated-level. The processor may further encompass discrete microprocessors, processor cores, and / or microprocessors integrated into a multi-chip module implementation, processors implemented as multiple integrated circuits, etc. Memory controller 840 may generally include circuitry for receiving memory operations from other components of SOC 810 and for accessing memory 840 to complete the memory operations. Memory controller 840 may be configured to access any type of memory 840. For example, memory 840 may be static random access memory (SRAM), dynamic RAM (DRAM), such as synchronous DRAM (SDRAM), which includes double data rate (DDR, DRAM2, DR3D, DDR4, etc.) DRAM. Low-power / mobile versions of DDR DRAM may be supported (e.g., LPDDR, mDDR, etc.). Memory controller 840 may include queues for memory operations that are used to order (and possibly reorder) operations and submit the operations to memory 840. Memory controller 840 may further include data buffers to store write data waiting to be written to memory and read data waiting to be returned to the source of the memory operation. In some embodiments, memory controller 840 may include a memory cache memory to store recently accessed memory data. In an SOC implementation, for example, the memory cache memory may reduce power consumption in the SOC by avoiding re-accessing data from memory 840 if the data is expected to be accessed again soon. In some cases, the memory cache may also be referred to as a system cache as opposed to a private cache that serves only certain components (such as an L2 cache or a cache in a processor). Additionally, in some embodiments, the system cache memory need not be located within memory controller 840. Peripheral device 818 may include any set of additional hardware functionality included in SOC 810. For example, peripheral device 818 may include video peripherals such as an image signal processor, GPU, video encoder / decoder, scaler, rotator, fuser, display controller, etc. configured to process image capture data from a camera or other image sensor. The peripheral device may include audio peripherals such as microphones, speakers, interfaces to microphones and speakers, audio processors, digital signal processors, mixers, etc. The peripheral device may include interface controllers for various interfaces external to SOC 810, including interfaces such as Universal Serial Bus (USB), Peripheral Component Interconnect (PCI) including Express PCI (PCIe), serial and parallel ports, etc. The peripheral device may include network peripherals such as a Media Access Controller (MAC). Any set of hardware may be included. Communication fabric 816 may be any communication interconnect and protocol for communication between components of SOC 810. Communication fabric 816 may be bus-based, including a shared bus configuration, a crossbar configuration, and a hierarchical bus with bridges. Communication fabric 816 may also be packet-based and may be hierarchical, crossbar, point-to-point, or other interconnects with bridges. It should be noted that the number of components of SOC 810 (and the number of sub-components of those shown in FIG. 19, such as processors 830 in each processor cluster 814a to 814n) may vary with embodiments. Additionally, the number of processors 830 in one processor cluster 814a to 814n may be different from the number of processors 830 in another processor cluster 814a to 814n. There may be more or fewer sets of components / sub-components than shown in FIG. 19. Computer system Next, turning to FIG. 20, a block diagram of an embodiment of system 700 is shown. In the illustrated embodiment, system 700 includes at least one instance of a System-on-Chip (SOC) 706 coupled to one or more peripheral devices 704 and external memory 702. A Power Management Unit (PMU) 708 is provided, which supplies supply voltages to SOC 706 and supplies one or more supply voltages to memory 702 and / or peripheral devices 704. In some embodiments, more than one instance of the SOC may be included (and more than one memory 702 may also be included). In one embodiment, SOC 706 may include one or more instances of processor 10 shown in FIG. 1. The peripheral device 704 can include any desired circuitry depending on the type of the system 700. For example, in one embodiment, the system 704 can be a mobile device (e.g., a personal digital assistant (PDA), a smartphone, etc.), and the peripheral device 704 can include devices for various types of wireless communication such as Wi-Fi, Bluetooth, cellular, global positioning system, etc. The peripheral device 704 can also include additional storage, including RAM storage, solid-state storage, or disk storage. The peripheral device 704 can include user interface devices such as a display screen (including a touch display screen or a multi-touch display screen), a keyboard or other input devices, a microphone, a speaker, etc. In other embodiments, the system 700 can be any type of computing system (e.g., a desktop personal computer, a laptop computer, a workstation, an Internet box, etc.). The external memory 702 can include any type of memory. For example, the external memory 702 can be SRAM, dynamic RAM (DRAM) such as synchronous DRAM (SDRAM), double data rate (DDR, DDR2, DDR3, etc.) SDRAM, Rambus DRAM, low-power versions of DDR DRAM (e.g., LPDDR, mDDR, etc.). The external memory 702 can include one or more memory modules to which memory devices are mounted, such as single in-line memory modules (SIMMs), dual in-line memory modules (DIMMs), etc. Alternatively, the external memory 702 can include one or more memory devices mounted on the SOC 706 in a chip-on-chip or package-on-package implementation manner. As depicted, system 700 is shown to have applications in a wide range of fields. For example, system 700 can be used as part of the chips, circuitry, components, etc. of a desktop computer 710, laptop computer 720, tablet computer 730, cellular or mobile phone 740, or television 750 (or a set-top box coupled to a television). Also depicted are smartwatches and health monitoring devices 760. In some embodiments, a smartwatch can include a variety of general computing-related functions. For example, a smartwatch can provide email, phone service, a user calendar, and so on. In various embodiments, a health monitoring device can be a dedicated medical device or otherwise include dedicated health-related functionality. For example, a health monitoring device can monitor a user's vital signs, track a user's proximity to other users for the purpose of pandemic social distancing, contact tracing, provide communication to emergency services in the event of a health crisis. Epidemiological functions such as contact tracing, provide communication to emergency medical services, etc. In various embodiments, the smartwatches mentioned above may or may not include some or any health monitoring-related functions. Other wearable devices are also envisioned, such as devices worn around the neck, devices implantable in the human body, glasses designed to provide augmented and / or virtual reality experiences, and so on. System 700 can further be used as part of (a) cloud-based service(s) 770. For example, the previously mentioned devices and / or other devices can access computing resources in the cloud (i.e., hardware and / or software resources located remotely). Further still, system 700 can be used in one or more devices in a home 780 other than those previously mentioned. For example, appliances within a home can monitor and detect conditions of concern. For example, various devices within a home (e.g., a refrigerator, an air conditioning system, etc.) can monitor the status of the device and provide alerts to the homeowner (or, for example, a repair facility) should a specific event be detected. Alternatively, a thermostat can monitor the temperature in the home and can automatically adjust the heating / cooling system based on the homeowner's response history to various conditions. Also depicted in FIG. 8 is the application of system 700 to various modes of transportation 790. For example, system 700 can be used in the control and / or entertainment systems of airplanes, trains, buses, taxis, automobiles, watercraft from private boats to cruise ships, motorcycles (for rental or personal use), etc. In various scenarios, system 700 can be used to provide automated guidance (e.g., self-driving vehicles), general system control, and others. Any many other such embodiments are possible and envisioned. It should be noted that the devices and applications depicted in FIG. 8 are illustrative only and are not intended to be restrictive. Other devices are possible and envisioned. Computer-readable storage media Turning now to FIG. 21, a block diagram showing an example of a computer-readable storage medium 800 is presented. Generally speaking, a computer-accessible storage medium can include any storage medium that can be accessed by a computer during use to provide instructions and / or data to the computer. For example, a computer-accessible storage medium can include storage media such as magnetic or optical media, e.g., magnetic disks (fixed or removable), magnetic tapes, CD-ROMs, DVD-ROMs, CD-Rs, CD-RWs, DVD-Rs, DVD-RWs, or Blu-ray discs. The storage medium can further include volatile or non-volatile memory media, such as RAM (e.g., synchronous dynamic RAM (SDRAM)), Rambus DRAM (RDRAM), static RAM (SRAM), etc.), ROM, or flash memory. The storage medium can physically be included in the computer to provide instructions / data to the computer. Alternatively, the storage medium can be connected to the computer. For example, the storage medium can be connected to the computer via a network or a wireless link, such as a network-attached storage. The storage medium can be connected via a peripheral interface, such as a Universal Serial Bus (USB). Generally, the computer-accessible storage medium 800 can store data in a non-transitory manner, where, in this context, non-transitory can mean not transmitting instructions / data on a signal. For example, the non-transitory storage can be volatile (and lose stored instructions / data in response to power-off) or non-volatile. The computer-accessible storage medium 800 in FIG. 9 can store a database 804 representing the SOC 706. Generally, the database 804 can be a database that can be read by a program and directly or indirectly used to fabricate the hardware including the SOC 706. For example, the database can be a behavioral-level description or a register-transfer level (RTL) description of the hardware functionality in a high-level design language (HDL), such as Verilog or VHDL. The description can be read by a synthesis tool, which can synthesize the description to generate a netlist containing a gate list from a synthesis library. The netlist contains a set of gates that also represent the functionality of the hardware including the SOC 706. The netlist can then be placed and routed to generate a data set that describes the geometry to be applied to a mask. The mask can then be used in various semiconductor manufacturing steps to produce the (multiple) semiconductor circuits corresponding to the SOC 706. Alternatively, the database 804 on the computer-accessible storage medium 800 can be a netlist (with or without a synthesis library) or a data set as needed. Although the computer-accessible storage medium 800 stores a representation of the SOC 706, other embodiments can carry a representation of any part of the SOC 706 as needed, including the processor 10 or any of its subsets shown in FIG. 1. This disclosure includes references to an “embodiment” or groups of “embodiments” (e.g., “some embodiments” or “various embodiments”). Embodiments are different implementations or examples of the disclosed concepts. References to “an embodiment,” “one embodiment,” “a particular embodiment,” and the like do not necessarily refer to the same embodiment. A large number of feasible embodiments are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the spirit or scope of this disclosure. This disclosure may discuss potential advantages that may result from the disclosed embodiments. Not all implementations of these embodiments will necessarily exhibit any or all of the potential advantages. Whether the advantages realized for a particular implementation depend on many factors, some of which are outside the scope of this disclosure. In fact, there may be many reasons why implementations within the scope of the claims may not exhibit some or all of any of the disclosed advantages. For example, a particular implementation may include other circuitry outside the scope of this disclosure that, when combined with one of the disclosed embodiments, nullifies or diminishes one or more of the disclosed advantages. Additionally, sub-optimal design implementation of a particular implementation (e.g., the implementation technology or tool) may also nullify or diminish the disclosed advantages. Even assuming a skilled implementation, the realization of advantages may still depend on other factors, such as the environmental circumstances in which the implementation is deployed. For example, the input applied to a particular implementation may prevent one or more of the problems addressed in this disclosure from occurring in a particular instance, with the result that the benefits of its solution may not be realized. Given the existence of possible factors outside the scope of this disclosure, it is expressly intended that any potential advantages described herein not be construed as a requirement for claim limitations to prove infringement. Rather, the identification of such potential advantages is intended to illustrate the types of (multiple) improvements available to designers who have the benefit of this disclosure. The description of such advantages as being “may result in” (e.g., stating a particular advantage “may result in”) is not intended to convey doubt as to whether such advantages can actually be realized, but rather to recognize that the technical reality of realizing such advantages often depends on additional factors. Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the patent claims based on the present disclosure, even if only a single example regarding a specific feature is described. The disclosed embodiments are intended to be illustrative rather than restrictive, and there is no statement to the contrary in the present disclosure. Accordingly, this application is intended to allow the patent claims to cover the disclosed embodiments as well as such alternatives, modifications, and equivalents that would be apparent to one of ordinary skill in the art benefiting from the present disclosure. For example, the features in this application can be combined in any suitable manner. Accordingly, new claims can be formulated for any such combination of features during the examination of this application (or an application claiming its priority). Specifically, referring to the appended patent claims, features from independent claims can be combined with features from other independent claims, if appropriate, including claims that depend on other dependent claims. Similarly, if appropriate, features from individual dependent claims can be combined. Accordingly, although the appended dependent claims can be drafted such that each depends on a single other claim, additional dependencies are also contemplated. Any combination of the features of the dependent claims consistent with the present disclosure is contemplated and can be claimed in this application or another application. In short, the combinations are not limited to those specifically recited in the appended patent claims. If appropriate, it is also contemplated that claims drafted in one format or statutory type (e.g., apparatus) are intended to support corresponding claims in another format or statutory type (e.g., method). Because this disclosure is a legal document, various terms and phrases are subject to administrative and judicial interpretation. The paragraphs and definitions provided hereinafter and throughout the disclosure will be used to determine how to interpret the patent claims based on the present disclosure. Unless the context clearly dictates otherwise, a reference to the singular form of an item (i.e., a noun or noun phrase preceded by "a / an" or "the") is intended to mean "one or more." Thus, a reference to "an item" in a claim does not exclude additional instances of that item in the absence of an accompanying context. A "plurality" of items refers to a collection of two or more items. In this document, the word "may" is used herein with a permissive connotation (i.e., having the possibility of, being able to), and not with a mandatory connotation (i.e., must). The terms "comprising" and "including" and their forms are open-ended, meaning "including, but not limited to." When the term "or" is used in this disclosure with respect to a list of options, it will generally be understood to be used in an inclusive sense, unless the context provides otherwise. Thus, the statement "x or y" is equivalent to "x or y, or both", and thus: 1) covers x, but not y; 2) covers y, but not x; and 3) covers both x and y. On the other hand, a phrase such as "either x or y, but not both" clearly indicates that "or" is being used in an exclusive sense. The statements "w, x, y, or z, or any combination thereof" or "at least one of... w, x, y, and z" are intended to cover all possibilities involving any single element up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element of the set (e.g., w, but not x, y, or z), any two elements (e.g., w and x, but not y or z), any three elements (e.g., w, x, and y, but not z), and all four elements. Thus, the phrase "at least one of... w, x, y, and z" refers to at least one element of the set [w, x, y, z], thereby covering all possible combinations in this list of elements. This phrase is not construed as requiring at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z. In this disclosure, various "designations" may be placed before a noun or noun phrase. Unless the context provides otherwise, different designations for a feature (e.g., "first circuit", "second circuit", "specific circuit", "given circuit", etc.) refer to different instances of that feature. Additionally, unless otherwise specified, the designations "first", "second", and "third", when applied to a feature, do not imply any type of order (e.g., spatial, temporal, logical, etc.). The phrase "based on" is used to describe one or more factors that affect a determination. This term does not exclude the possibility that there may be additional factors that affect the determination. That is, a determination can be based solely on a particular factor, or based on that particular factor and other unspecified factors. Consider the phrase "determine A based on B". This phrase indicates that B is a factor used to determine A, or that B affects the determination of A. This phrase does not exclude the possibility that A can also be determined based on some other factor such as C. This phrase also intends to encompass an embodiment in which A is determined solely based on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on". The phrase "in response to / response to" describes one or more factors that trigger an effect. This phrase does not exclude the possibility that additional factors can affect or otherwise trigger the effect, either jointly with the specified factors or independently of the specified factors. That is, an effect can be solely in response to those factors, or can be in response to the specified factors and other unspecified factors. Consider the phrase "perform A in response to B". This phrase specifies that B is the factor that triggers the performance of A or triggers a particular result of A. This phrase does not exclude the possibility that A can also be performed in response to some other factor such as C. This phrase also does not exclude the possibility that A can be performed in response to B and C jointly. This phrase also intends to encompass an embodiment in which A is performed solely in response to B. As used herein, the phrase "responsive to" is synonymous with the phrase "responsive at least in part to". Similarly, the phrase "in response to" is synonymous with the phrase "at least in part in response to". In this disclosure, different entities (which may variously be referred to as "units", "circuits", other components, etc.) may be described or claimed as "configured" to perform one or more tasks or operations. This notation (an "entity" is configured to "perform one or more tasks") is used herein to refer to a structure (i.e., physical entity). Specifically, this notation is used to indicate that the structure is arranged to perform the one or more tasks during operation. Even if a structure is not currently being operated, the structure may still be said to be "configured to" perform a task. Thus, an entity that is described or recited as "configured to" perform a task refers to a physical entity such as a device, a circuit, a system having a processing unit, a memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to an intangible. In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It should be understood that these entities are "configured to" perform those tasks / operations even if not specifically recited. The phrase "configured to" is not intended to mean "configurable to". For example, an unprogrammed FPGA will not be considered "configured to" perform a particular function. However, this unprogrammed FPGA may be "configurable to" perform the function. After appropriate programming, then, the FPGA may be claimed to be "configured to" perform a specific function. For purposes of a U.S. patent application based on this disclosure, reciting in a claim that a structure is "configured to" perform one or more tasks is specifically intended not to invoke 35 U.S.C. § 112(f) to construe the claim element. If the applicant intends to invoke § 112(f) during prosecution of a U.S. patent application based on this disclosure, the claim element will be stated using the phrase "means for 'performing a function'". In the present disclosure, different "circuits" may be described. These circuits or "circuitries" constitute hardware including various types of circuit elements, such as combinational logic, time-controlled storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memories, embedded dynamic random access memories), programmable logic arrays, etc. The circuitry may be custom designed or taken from a standard library. In various embodiments, the circuitry may include digital components, analog components, or a combination of both as needed. Certain types of circuits are commonly referred to as "units" (e.g., decode units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such units also refer to circuits or circuitries. Accordingly, the circuits / units / components disclosed and other elements depicted in the figures and disclosed herein include hardware elements such as those described in the foregoing paragraphs. In many instances, the internal configuration of the hardware elements within a particular circuit may be specified by describing the function of that circuit. For example, a particular "decode unit" may be described as performing the function of "processing an opcode of an instruction and routing that instruction to one or more of a plurality of functional units", which means that the decode unit is "configured to" perform this function. The description of this function is sufficient for those of ordinary skill in the art of computer technology to imply a set of feasible structures for the circuit. In various embodiments, as discussed in the foregoing paragraphs, circuits, units, and other components are defined by the functions or operations by which they are configured to perform. The configuration of such circuits / units / components relative to one another and the manner in which they interact form the microarchitecture definition of the hardware, which is ultimately fabricated in an integrated circuit or programmed into an FPGA to form a physical implementation of the microarchitecture definition. Thus, this microhierarchical definition is recognized by those of ordinary skill in the art as a structure from which many physical implementations can be derived, all of which fall within the broad structure described by this microhierarchical definition. That is, a person of ordinary skill in the art provided with the microhierarchical definition according to the present disclosure can, without undue experimentation and in the application of ordinary skill, implement this structure by encoding a description of the circuits / units / components in a hardware description language (HDL), such as Verilog or VHDL. HDL descriptions are often expressed in a functionally representable manner. However, for a person of ordinary skill in the art, this HDL description is a way of transforming the structure of a circuit, unit, or component into the details of the next level of implementation. This HDL description can take the form of behavioral code (which is generally not synthesizable), register transfer language (RTL) code (which is generally synthesizable, as opposed to behavioral code), or structural code (e.g., a wiring对照表 specifying logic gates and their connectivity). Subsequently, the HDL description can be synthesized according to a library of components designed for a given integrated circuit manufacturing technology and can be modified for timing, power, and other reasons to produce a final design database, which is transferred to a fabrication plant to manufacture masks and finally produce an integrated circuit. Some hardware circuits or portions thereof can also be custom designed in a schematic editor and transferred to integrated circuit design along with the synthesized circuit system. An integrated circuit can include transistors and other circuit components (e.g., passive components such as capacitors, resistors, inductors, etc.) and interconnects between the transistors and circuit components. Some embodiments can implement multiple integrated circuits, which are coupled together to implement the hardware circuit, and / or in some embodiments discrete components can be used. Alternatively, the HDL design can be synthesized into a programmable logic array, such as a field programmable gate array (FPGA), and implemented in the FPGA. The decoupling between the design of this group of circuits and the subsequent lower-level implementations of these circuits typically results in a situation where, when this process is performed at a different stage of the circuit implementation process, the circuit or logic designer never specifies a particular set of structures beyond the description of what the circuit is configured to do for the lower-level implementation. In fact, many different underlying combinations of circuit components can be used to implement a circuit of the same specification, resulting in a large number of equivalent structures for that circuit. As mentioned, these underlying circuit implementations can vary depending on changes in manufacturing technology, the foundry selected to manufacture the integrated circuit, the component library provided for a particular project, etc. In many cases, the selection by different design tools or methodologies to produce these different implementations can be arbitrary. In addition, for a single implementation of a particular functional specification of a circuit, it is common for a given embodiment to include a large number of devices (e.g., millions of transistors). Accordingly, the sheer quantity of this information makes it impractical to provide a complete statement of the underlying structure for implementing a single embodiment, let alone a vast array of equivalent viable implementations. For this reason, the present disclosure describes circuit structures using functional shorthand commonly employed in the industry. For those of ordinary skill in the art, once the above disclosure has been fully understood, numerous variations and modifications will become apparent. It is intended that the following claims be construed to cover all such variations and modifications. 10: Processor 11: Authorizer Circuit; Authorizer; Authorizer Circuit System 12: Execution Core; Register File 13: Fast Pointer Generator; Past Pointer Generator 14: Register File; Working Register File; Special Register 15: Redirection Monitor 16: Special Purpose Register 17: Fetch and Decode 18: Execution Unit; Signature Generation / Authentication Circuit 19: Load Store Unit (LSU); Load / Store Unit 20: Field; Return Address Field 22: Field; Signature Field 24: Condition 26: Authentication Operation; Authentication 28: Instruction or Operation 40: Block 42: Block 44: Block 46: Block 52: Block 54: Block 56: Block 70: Block 74: Block 76: Decision Block 78: Block 80: Processor Pipeline 81: Instruction Fetch Unit (IFU) 82: Instruction Cache Memory 83: Branch Predictor 84: Return Address Stack (RAS) 85: Decode Unit 86: Mapping Unit 87: Scheduling Unit 88: Issue Unit 90: Completion Unit 91: Reorder Buffer (ROB) 92: Floating Point / Graphics Unit (FGU); FPGU 93: Cache Memory / Memory Interface; Interface 95: Block 96: Block 98: Block 100: Step 102: Step 104: Step 106: Step 108: Step 112: Step 120: Step 130: Step 132: Step 150: Block 152: Block 154: Block 156: Block 158: Block 160: Block 162: Block 164: Block 200: Step 202: Step 204: Step 208: Step 212: Step 220: Step 230: Step 232: Step 250: Block 252: Block 254: Block 256: Block 258: Block 260: Block 262: Block 264: Block 300: Step 302: Step 304: Step 308: Step 312: Step 320: Step 330: Step 332: Step 350: Block 352: Block 354: Block 356: Block 358: Block 360: Block 362: Block 364: Block 450: Block 452: Block 454: Block 456: Block 458: Block 460: Block 462: Block 464: Block 500: Step 508: Step 512: Step 520: Step 530: Step 532: Step 700: System 702: External Memory; Memory 704: Peripheral Device;System 706: System-on-Chip (SOC) 708: Power Management Unit (PMU) 710: Desktop Computer 720: Laptop Computer 730: Tablet Computer 740: Cellular or Mobile Phone 750: Television 760: Smart Watch and Health Monitoring Device 770: Cloud-Based Service 780: Home 790: Transportation Mode 800: Computer-Readable Storage Medium; Computer-Accessible Storage Medium 804: Database 810: System-on-Chip (SOC) 814a: Processor Cluster; Component 814n: Processor Cluster; Component 816: Communication Mesh 818: Peripheral Component; Component; Peripheral Device 820: Interrupt Controller; Component 830: Processor (P) 840: Memory; Memory Controller; Component; The following embodiments will refer to the accompanying drawings, and the accompanying drawings will be briefly described below. [FIG. 1] is a block diagram of an embodiment of a processor that provides consistent behavior during speculative execution of pointer identification. [FIG. 2] is a block diagram of an embodiment of a register / memory location for return / jump addresses. [FIG. 3] is an example of an instruction that signs a return / jump address. [FIG. 4] is an example of an instruction that identifies a signed return / jump address. [FIG. 5] is a flowchart of an exemplary subroutine that illustrates the use of behavioral differences during speculative execution of pointer identification. [FIG. 6] is a flowchart of an exemplary subroutine. [FIG. 7] is a flowchart of pushing a return address in an embodiment. [FIG. 8] is a flowchart of popping a return address in an embodiment. [FIG. 9] is a block diagram of an embodiment of a processor pipeline that provides consistent behavior during speculative execution of pointer identification. [FIG. 10] is a flowchart of solving speculative execution conditions in an embodiment. [FIG. 11] is a timing diagram of an event sequence for implementing an identified load instruction in an embodiment. [FIG. 12] is a flowchart of an identified load instruction in an embodiment. [FIG. 13] is a timing diagram of an event sequence for implementing an identified load branch in an embodiment. [FIG. 14] is a flowchart of an identified branch instruction in an embodiment. [FIG. 15] is a timing diagram of an event sequence for implementing an identification instruction in an embodiment. [FIG. 16] is a flowchart of an identification instruction in an embodiment. [FIG. 17] is a timing diagram of an event sequence for implementing an identified memory tag instruction in an embodiment. [FIG. 18] is a flowchart of an identified memory tag instruction in an embodiment. [FIG. 19] is a block diagram of an embodiment of a system that may include one or more processors implemented as a system-on-chip (SOC). [FIG. 20] is a block diagram of an embodiment of the system. [FIG. 21] is a block diagram of an embodiment of a computer-accessible storage medium. While the embodiments described in this disclosure may be subject to various modifications and have alternative forms, specific embodiments are presented by way of example in the drawings and will be described in detail herein. However, it should be understood that the drawings and their detailed description are not intended to limit the embodiments to the specific forms disclosed, but rather are intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the appended patent claims. The headings used herein are for purposes of arrangement only and are not intended to limit the scope of the description. 11: Authorizer Circuit; Authorizer; Authorizer Circuit System 14: Register File; Working Register File 15: Redirection Monitor 18: Execution Unit; Signature Generation / Verification Circuit 19: Load Store Unit (LSU); Load / Store Unit 80: Processor Pipeline 81: Instruction Fetch Unit (IFU) 82: Instruction Cache Memory 83: Branch Predictor 84: Return Address Stack (RAS) 85: Decoding Unit 86: Mapping Unit 87: Scheduling Unit 88: Issuing Unit 90: Completion Unit 91: Reorder Buffer (ROB) 92: Floating Point / Graphics Unit (FGU); FPGU 93: Cache Memory / Memory Interface; Interface

Claims

1. A processor for preventing backtracking directed programming attacks, comprising: an authentication circuit configured to authenticate instruction operands; and an execution circuit configured to speculatively execute an instruction stream comprising a plurality of instructions in response to an unresolved condition, the plurality of instructions including an instruction that includes authentication of an instruction operand, wherein, for speculative execution of the instruction stream, the execution circuit is configured to: use an authorized circuit to execute the authentication of the instruction operand as part of speculative execution of the instruction to produce an authentication result; continue speculative execution of the instruction stream to produce an observable state of the processor independent of the generated authentication result, wherein, for continued speculative execution, the execution circuit is configured to: complete the speculative execution of the instruction; and after completing the speculative execution of the instruction, speculatively execute at least one additional instruction of the plurality of instructions; and postpone reporting the generated authentication result until the condition is resolved.

2. The processor of claim 1, wherein the execution circuitry is further configured to execute the instruction stream in response to the resolution of the unresolved condition, wherein, in order to execute the instruction stream, the execution circuitry is further configured to: in response to the authentication result indicating an authentication failure; suspend processor execution at the instruction; and generate a processor fault.

3. The processor of claim 1, wherein the observable state of the processor includes an accumulated state of the processor circuitry detectable by an instrumentation channel of the processor, and wherein the observable state of the processor is independent of the generated discrimination result based on the absence of detectable differences for different generated discrimination result values ​​in the respective accumulated states of the processor circuitry detectable by the instrumentation channel of the processor, such different generated discrimination result values ​​including a discrimination pass result value and a discrimination failure result value.

4. The processor of request item 1, wherein the authentication result indicates an authentication failure, wherein the deferred report of the authentication result is a speculative failure source among a plurality of speculative failure sources of the speculative execution of the plurality of instructions, and wherein, After this condition is resolved, a processor fault is generated based on the oldest fault source among the plurality of speculated fault sources.

5. The processor of claim 1, wherein, for speculative execution of one or more of the plurality of instructions, the execution circuitry is configured to halt speculative execution in response to receiving a fault signal.

6. The processor of claim 1, wherein the instruction operand is a signed memory index that includes a memory address and a signature stored in a single memory word of the processor.

7. The processor of claim 6, wherein the instruction is an authorized load instruction, and wherein the instruction is executed speculatively, the processor is configured to: generate an unsigned memory index containing the memory address of the signed memory index; and load a value based on the unsigned memory index without identifying the instruction operand.

8. The processor of claim 6, wherein the instruction is an authorized branch instruction, and wherein, in order to execute the instruction, the processor is configured to: generate an unsigned memory index containing the memory address of the signed memory index; and transfer control of execution to the memory address of the unsigned memory index.

9. The processor of claim 1, wherein the instruction operand includes a memory address and a memory tag, and wherein the identification result includes a comparison of the memory tag with an associated memory tag of a memory region containing the memory address.

10. A method for preventing backtracking programming attacks, comprising: in response to an unresolved condition, speculatively executing an instruction stream comprising a plurality of instructions, the plurality of instructions including an instruction comprising authentication of an instruction operand, the speculative execution comprising: executing the authentication of the instruction operand as part of speculatively executing the instruction to produce an authentication result; continuing speculative execution of the instruction stream to produce an observable state of the processor independent of the generated authentication result, wherein continuing speculative execution comprises: completing the speculative execution of the instruction; and after completing the speculative execution of the instruction, speculatively executing at least one additional instruction of the plurality of instructions; and deferring the reporting of the generated authentication result until the condition is resolved.

11. The method of claim 10, further comprising executing the instruction stream in response to resolution of the condition indicating that the instruction stream will be executed, the execution comprising: in response to the authentication result indicating an authentication failure; suspending processor execution at the instruction; and generating a processor fault.

12. The method of claim 10, wherein the observable state of the processor includes an accumulated state of the processor circuitry detectable by an instrumentation channel of the processor, and wherein the observable state of the processor is independent of the generated discrimination result based on the absence of undetectable differences for different generated discrimination result values ​​in the respective accumulated states of the processor circuitry detectable by the instrumentation channel of the processor. Such different generated discrimination result values ​​include a discrimination pass result value and a discrimination failure result value.

13. The method of claim 12, wherein the identification result indicates an identification failure, wherein the delayed report of the identification failure is a speculative failure source among a plurality of speculative failure sources of the speculative execution of the plurality of instructions, and wherein a processor failure is generated based on the oldest failure source among the plurality of speculative failure sources.

14. The method of claim 12, wherein one or more of the plurality of instructions are speculatively executed, including pausing speculative execution in response to receiving a fault signal.

15. The method of claim 12, wherein the instrumentation channel of the processor includes another instruction stream executed on the processor to measure the delay of the execution of the instruction stream.

16. The method of claim 10, wherein the instruction operand is a signed memory index that includes a memory address and a signature stored in a single memory word of the processor.

17. The method of claim 16, wherein the instruction is an authorized load instruction, and wherein speculatively executing the instruction comprises: generating an unsigned memory index containing the memory address of the signed memory index; and loading a value based on the unsigned memory index without identifying the instruction operand.

18. The method of claim 16, wherein the instruction is an authorized branch instruction, and wherein speculatively executing the instruction comprises: generating an unsigned memory index that includes the memory address of the signed memory index; and transferring control of execution to the memory address of the unsigned memory index.

19. A system for preventing backtracking directed programming attacks, comprising: a memory configured to store a plurality of instructions; and a processor comprising: an authentication circuit configured to authenticate instruction operands; and an execution circuit configured to: speculatively execute an instruction stream comprising a plurality of instructions in response to an unresolved condition, the plurality of instructions including an instruction comprising authentication of an instruction operand, wherein, for speculative execution of the instruction stream, the execution circuit is configured to: use an authorization circuit to execute the authentication of the instruction operand as part of speculative execution of the instruction, to produce an authentication result; continue speculative execution of the instruction stream to produce an observable state of the processor independent of the generated authentication result, wherein, for continued speculative execution, the execution circuit is configured to: Complete the speculative execution of the instruction; and after the speculative execution of the instruction is completed, speculatively execute one or more of the plurality of instructions; and execute the instruction stream in response to the resolution of the condition indicating that the instruction stream will be executed, wherein, in order to execute the instruction stream, the execution circuitry is configured to: in response to the discrimination result indicating a discrimination failure; suspend processor execution at the instruction; and generate a processor fault.

20. The system of claim 19, wherein the instruction operand includes a memory address stored in a single memory word of the processor and a signed memory index, wherein the instruction is an authorized load instruction, and wherein, for speculative execution of the instruction, the processor is configured to: generate an unsigned memory index including the memory address of the signed memory index; and load a value based on the unsigned memory index without identifying the instruction operand.

Images