Mitigating pointer authentication code (PAC) attacks in processor-based devices

By introducing a mitigation circuit into the processor, detecting and responding to the speculative execution of pointer authentication instructions, and performing mitigation actions to prevent the leak of pointer signature verification results, the problem of PAC attack is solved and the security of the device is improved.

CN119836629APending Publication Date: 2025-04-15QUALCOMM INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202380063828.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2022-12-19
Filing Date
2023-08-18
Publication Date
2025-04-15

AI Technical Summary

Technical Problem

The prior art is difficult to effectively resist PAC attacks in processor-based devices, and attackers leak pointer signature verification results through speculative execution and microarchitecture side channels, resulting in an increase in the possibility of control flow hijacking attacks.

Method used

By introducing a mitigation circuit into the processor, the speculative execution of the pointer authentication instruction is determined and mitigation actions are performed when the pointer is invalid, including modifying the pointer signature to indicate validity and raising a microarchitecture exception to trigger a pipeline refresh, preventing information leakage of true validity.

Benefits of technology

It effectively reduces the success rate of PAC attacks, prevents attackers from successfully performing control flow hijacking attacks by exhaustive pointer signatures, and improves processor security.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119836629A_ABST
    Figure CN119836629A_ABST
Patent Text Reader

Abstract

Mitigating Pointer Authentication Code (PAC) attacks in a processor-based device is disclosed herein. In this regard, in some exemplary aspects, a processor of a processor-based device is configured to determine that a pointer authentication instruction for authenticating a pointer is being speculatively executed. The processor is further configured to, in response to determining that the pointer authentication instruction is speculatively executed, determine that the pointer is invalid based on a signature of the pointer. The processor is further configured to, in response to determining that the pointer is invalid, perform a mitigation action.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Priority declaration

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 375,331, filed on September 12, 2022, entitled “MITIGATING PACMAN ATTACKS IN PROCESSOR-BASED DEVICES,” the contents of which are incorporated herein by reference in their entirety.

[0003] This application also claims priority to U.S. patent application serial number 18 / 067,825, filed on December 19, 2022, entitled “MITIGATING POINTERAUTHENTICATION CODE (PAC) ATTACKS IN PROCESSOR-BASED DEVICES,” the contents of which are incorporated herein by reference in their entirety. Technical Field

[0004] Generally speaking, the techniques of this disclosure relate to pointer authentication in processor-based devices, and more particularly, to mitigating the potential for attacks based on authorization of repeated attempts to sign pointers during speculative execution. Background Art

[0005] Memory corruption vulnerabilities present a long-standing security issue affecting modern processor-based devices. Memory corruption vulnerabilities can include memory corruption bugs (e.g., out-of-bounds writes and reads, use-after-free and double-free bugs, and integer overflow and underflow), as well as memory corruption attacks that exploit such bugs. Of particular concern are memory corruption attacks known as "control flow hijack attacks," which modify code pointers stored in memory to alter the program flow of an executing process. An attacker using a control flow hijack attack can change the code pointers used by an executing process to redirect execution of the process, and cause potentially harmful code provided by the attacker to be executed.

[0006] To protect the integrity of pointers and defend against control flow hijacking attacks, some modern processor-based devices implement an instruction set architecture (ISA) that includes pointer signing instructions and pointer authentication instructions. Using such instructions and the associated underlying hardware, a process can sign a pointer using a cryptographic hash called a pointer authentication code (PAC), which is generated using the pointer and stored in unused bits of the pointer. The PAC can then be used later as a signature for the pointer to verify that the pointer has not been modified improperly, as well as to raise a software-visible architectural exception if the pointer has been tampered with. In this way, the difficulty faced by an attacker in performing unauthorized modifications to a pointer can be significantly increased.

[0007] However, researchers have recently proposed a type of attack, referred to in this article as a PAC attack, and also referred to as a "PACMAN attack," that allows an attacker to brute-force the signature of a pointer using techniques that can avoid invoking architectural exceptions. To achieve this, a PAC attack uses speculative execution paths to attempt to verify pointer signatures, and uses microarchitectural side channels (e.g., changes made to the contents of caches, translation lookaside buffers (TLBs), functional units, and on-chip networks that persist even if the speculative execution path is squashed) to leak the results of the attempted signature verification. In this way, an attacker using a PAC attack could theoretically perform a successful control flow hijacking attack even on processor-based devices whose ISAs provide pointer signature instructions and pointer authentication instructions. Summary of the invention

[0008] Aspects disclosed in the detailed description include mitigating pointer authentication code (PAC) attacks in processor-based devices. Related apparatus, methods, and computer-readable media are also disclosed. In this regard, in some exemplary aspects disclosed herein, a processor of a processor-based device (e.g., using a mitigation circuit) determines that a pointer authentication instruction that authenticates a pointer is being speculatively executed. When the pointer verification instruction is speculatively executed and the pointer is determined to be invalid, the processor performs a mitigation action. As used herein, as a non-limiting example, a "pointer authentication instruction" refers to an explicit authentication instruction, such as an ARM instruction AUT, and / or an instruction that includes a combination of an authentication micro-operation and another micro-operation (e.g., a load micro-operation or a branch micro-operation). The terms "PAC attack" and "PACMAN attack" are used herein to refer to attempts to verify pointer signatures using speculative execution of pointer authentication instructions, and subsequently using microarchitectural side channels to leak the results of the attempted signature verification.

[0009] In some exemplary aspects, the mitigation action includes modifying the signature of the pointer to indicate that the pointer is valid (even if the pointer is actually invalid), and also inducing a microarchitectural exception to trigger a pipeline refresh. This process will prevent any information about the true validity of the pointer from causing microarchitectural side effects that may be detected by an attacker. According to some aspects, the pipeline refresh can be triggered immediately, while some aspects can provide that the pipeline refresh is triggered when the pointer authentication instruction is ready for retirement. In some aspects, the pipeline refresh can only refresh instructions younger than the pointer authentication instruction, in which case the processor will provide a mechanism for re-executing the pointer authentication instruction to obtain a true result about the validity of the pointer. Some aspects can provide that the pointer authentication instruction itself is also refreshed. In such aspects, an indicator associated with the pointer authentication instruction is set so that the processor can determine when subsequent iterations of the pointer authentication instruction are no longer speculative. When subsequent iterations of the pointer authentication instruction are determined to be no longer speculative, if the signature of the pointer indicates that the pointer is invalid, the processor triggers an invalid address architecture exception by modifying the signature of the pointer, thereby performing pointer authentication in a traditional manner. In this way, such aspects can degrade the effectiveness of attempted PAC attacks by preventing leakage of the true validity of a pointer via microarchitectural side channels (i.e., by not marking the pointer as valid, which causes an attacker's exhaustive guesses at the pointer's signature to always return the same result, regardless of whether the guess was correct or incorrect).

[0010] According to some aspects, the mitigation actions performed by the processor may include modifying the signature of the pointer to indicate that the pointer is invalid, and incrementing the value of the invalid pointer counter. The processor in such aspects may then determine whether the value of the invalid pointer counter exceeds an invalid pointer count threshold. If so, the processor raises an architectural exception to indicate a possible attack. Thus, such aspects provide protection against exhaustive PAC attacks, which typically require a large number of speculative executions of pointer authentication instructions before correctly guessing the PAC.

[0011] In another aspect, a processor-based device is provided. The processor-based device includes a processor that includes execution pipeline circuitry. The processor is configured to determine that a pointer authentication instruction for authenticating a pointer is being speculatively executed. The processor is further configured to: in response to determining that the pointer authentication instruction is being speculatively executed, determine that the pointer is invalid based on a signature of the pointer. The processor is further configured to: in response to determining that the pointer is invalid, perform a mitigation action.

[0012] In another aspect, a processor-based device is provided. The processor-based device includes means for determining that a pointer authentication instruction for authenticating a pointer is being speculatively executed. The processor-based device also includes means for determining that a pointer is invalid based on a signature of the pointer in response to determining that the pointer authentication instruction is being speculatively executed. The processor-based device also includes means for performing a mitigation action in response to determining that the pointer is invalid.

[0013] In another aspect, a method for mitigating a PAC attack is provided. The method includes: determining, by a processor of a processor-based device, that a pointer authentication instruction for authenticating a pointer is being speculatively executed. The method also includes, in response to determining that the pointer authentication instruction is being speculatively executed, determining that the pointer is invalid based on a signature of the pointer. The method also includes, in response to determining that the pointer is invalid, performing a mitigation action.

[0014] In another exemplary embodiment, a non-transitory computer-readable medium having computer-executable instructions stored thereon is provided. When executed by a processor, the computer-executable instructions cause the processor to determine that a pointer authentication instruction for authenticating a pointer is being speculatively executed. The computer-executable instructions further cause the processor to determine that the pointer is invalid based on a signature of the pointer in response to determining that the pointer authentication instruction is being speculatively executed. The computer-executable instructions further cause the processor to perform a mitigation action in response to determining that the pointer is invalid. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a block diagram of an exemplary processor-based device configured to mitigate pointer authentication code (PAC) attacks according to some aspects;

[0016] Figure 2 is a block diagram illustrating the structure of a conventional pointer with a signature and operations for signing and authenticating the pointer;

[0017] Figure 3 are different execution paths showing successful and failed pointer authentication;

[0018] Figure 4 is a flow chart illustrating example operations for mitigating PAC attacks according to some aspects;

[0019] Figure 5A and 5B is a flow chart illustrating additional exemplary operations for mitigating PAC attacks by incurring a microarchitectural exception to trigger a pipeline flush according to some aspects;

[0020] Figure 6is a flow chart illustrating additional exemplary operations for mitigating PAC attacks by tracking occurrences of invalid pointers and raising architectural exceptions when a threshold is exceeded in accordance with some aspects; and

[0021] Figure 7 is a block diagram of an exemplary processor-based device including, but not limited to Figure 1 processor-based devices. DETAILED DESCRIPTION

[0022] Referring now to the accompanying drawings, several exemplary aspects of the present disclosure are described. The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any aspect described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects.

[0023] Aspects disclosed in the detailed description include mitigating pointer authentication code (PAC) attacks in processor-based devices. Related apparatus, methods, and computer-readable media are also disclosed. In this regard, in some exemplary aspects disclosed herein, a processor of a processor-based device (e.g., using a mitigation circuit) determines that a pointer authentication instruction that authenticates a pointer is being speculatively executed. When the pointer authentication instruction is speculatively executed and the pointer is determined to be invalid, the processor performs a mitigation action. As used herein, as a non-limiting example, a "pointer authentication instruction" refers to an explicit authentication instruction, such as an ARM instruction AUT, and / or an instruction that includes a combination of an authentication micro-operation and another micro-operation (e.g., a load micro-operation or a branch micro-operation). The terms "PAC attack" and "PACMAN attack" are used herein to refer to attempts to verify pointer signatures using speculative execution of pointer authentication instructions, and subsequently using microarchitectural side channels to leak the results of the attempted signature verification.

[0024] In some exemplary aspects, the mitigation action includes modifying the signature of the pointer to indicate that the pointer is valid (even if the pointer is actually invalid), and also invoking a microarchitectural exception to trigger a pipeline refresh. This process will prevent any information about the true validity of the pointer from causing microarchitectural side effects that may be detected by an attacker. According to some aspects, the pipeline refresh can be triggered immediately, while some aspects can provide that the pipeline refresh is triggered when the pointer authentication instruction is ready for retirement. In some aspects, the pipeline refresh can only refresh instructions younger than the pointer authentication instruction, in which case the processor will provide a mechanism for re-executing the pointer authentication instruction to obtain a true result about the validity of the pointer. Some aspects can provide that the pointer authentication instruction itself is also refreshed. In such aspects, an indicator associated with the pointer authentication instruction is set so that the processor can subsequently determine when subsequent iterations of the pointer authentication instruction are no longer speculative. When subsequent iterations of the pointer authentication instruction are determined to be no longer speculative, if the signature of the pointer indicates that the pointer is invalid, the processor triggers an invalid address architecture exception by modifying the signature of the pointer, thereby performing pointer authentication in a traditional manner.

[0025] According to some aspects, the mitigation actions performed by the processor may include modifying the signature of the pointer to indicate that the pointer is invalid, and incrementing the value of the invalid pointer counter. The processor in such aspects may then determine whether the value of the invalid pointer counter exceeds the invalid pointer count threshold. If so, the processor raises an architectural exception to indicate a possible attack.

[0026] in this regard, Figure 1 is a schematic diagram of an exemplary processor-based device 100 that includes a processor 102. Processor 102 (also referred to herein as a "processor core" or "central processing unit (CPU) core") may be an in-order or out-of-order processor (OoP), and / or may be one of a plurality of processors 102 provided by processor-based device 100. Figure 1 The processor 102 provides an instruction processing circuit 104, which includes one or more instruction pipelines I0-I N , for processing the instruction memory ( Figure 1 Instruction memory 108 retrieves instructions 106 for execution. As a non-limiting example, instruction memory 108 may be provided in or as part of a system memory in processor-based device 100. Figure 1 The processor 102 also provides an instruction cache ( Figure 1The text in the figure is “INSTR cache” 112 to cache the instructions 106 fetched from the instruction memory 108 to reduce the delay in the fetch circuit 110.

[0027] exist Figure 1 In the example of FIG. 1 , the fetch circuit 110 is configured to execute the instruction 106F when the fetched instruction 106F reaches the execution circuit ( Figure 1 Before the execution of the instruction 106 as the extracted instruction 106F, the instruction 106 is provided to one or more instruction pipelines 10-10 in the instruction processing circuit 104 to be pre-processed. N In order to increase throughput before the execution circuit 114 executes the fetched instruction 106F, an instruction pipeline 100-100 is provided across different processing circuits or stages of the instruction processing circuit 104. N , to pre-process and process the fetched instructions 106F in a series of steps that can be executed concurrently.

[0028] Figure 1 The instruction processing circuit 104 also includes a decoding circuit 118, which is configured to decode the extracted instruction 106F extracted by the extraction circuit 110 into a decoded instruction 106D to determine the required instruction type and action, which can determine which instruction pipeline I0-I the decoded instruction 106D should be placed in. N In. Figure 1 In the example, decoded instruction 106D is placed in instruction pipeline I0-I N 106D and is then provided to renaming circuitry 120 in instruction processing circuitry 104. Renaming circuitry 120 is configured to determine whether any register names in decoded instruction 106D should be renamed to decouple any register dependencies that would prevent parallel or out-of-order processing.

[0029] Figure 1 The instruction processing circuit 104 in the processor 102 also includes a register access circuit ( Figure 1 The register access circuit 122 is configured to access a physical register in a physical register file (PRF) (not shown) based on a mapping entry of a logical register in a register mapping table (RMT) (not shown) mapped to a source register operand of the decoded instruction 106D to obtain a generated value from the executed instruction 106E in the execution circuit 114. The register access circuit 122 is also configured to provide the generated value obtained from the executed instruction 106E as a source register operand of the decoded instruction 106D to be executed.

[0030] Instruction processing circuit 104 further includes instruction pipelines I0-I N The scheduler circuit in Figure 1 The scheduler circuit 124 is configured to store the decoded instruction 106D in a reserved entry (not shown) until all source register operands for the decoded instruction 106D are available. The scheduler circuit 124 then issues the decoded instruction 106D ready for execution to the execution circuit 114. Write circuits 126 are also provided in the instruction processing circuit 104 to write or commit the value generated from the executed instruction 106E back to local memory, cache memory, or system memory.

[0031] Continue to refer Figure 1 The instruction processing circuit 104 also includes a branch predictor circuit 128, which is configured to speculatively predict the result of the fetched branch instruction, which controls whether the instruction corresponding to the taken path or the not-taken path in the instruction control flow path is fetched into the instruction pipeline 10-1. N The fetched branch instruction may be a branch instruction 130 that includes a condition to be resolved by the instruction processing circuitry 104 to determine which instruction control flow path should be taken. By using the speculatively predicted execution path, the result of the branch instruction 130 does not have to be resolved by the execution circuitry 114 in execution before the instruction processing circuitry 104 can proceed to process the fetched instruction 106F. The prediction made by the branch predictor circuitry 128 may be provided to the fetch circuitry 110 as a branch prediction 132 for use in determining the next instruction 106 to be fetched to be the fetched instruction 106F.

[0032] Figure 1 The instruction processing circuitry 104 is communicatively coupled to a re-order buffer (ROB) 134 that is capable of out-of-order execution of the fetched instructions 106F. The ROB 134 contains a ROB entry (not shown) that is allocated to each instruction 106 that is being processed by the instruction processing circuitry 104 but has not yet been committed. Each ROB is allocated to the instructions 106 sequentially in program order, and a ROB index identifying the location of each ROB entry in the ROB 134 for each instruction 106 is reported back to the instruction processing circuitry 104 when the ROB entry is initially allocated. The ROB 134 also includes a read pointer (not shown) that points to the ROB index of the ROB entry from which information about the oldest uncommitted instruction 106 at the time of commit is read, and a write pointer (not shown) that indicates the ROB index of the last ROB entry to which information about the youngest uncommitted instruction 106 is written.

[0033] Figure 1 The processor-based device 100 may include any of known digital logic elements, semiconductor circuits, processing cores, and / or memory structures, as well as other elements or combinations thereof. The aspects described herein are not limited to any particular arrangement of elements, and the disclosed techniques may be readily extended to various structures and layouts on a semiconductor die or package. It should be understood that some aspects of the processor-based device 100 may include in addition to Figure 1 Elements other than those shown in the figure and / or may include Figure 1 For example, the processor-based device 100 may also include one or more CPUs, processor cores, caches, controllers, communication buses, and / or persistent storage devices. For clarity, Figure 1 These are omitted.

[0034] As mentioned above, such as Figure 1 A processor-based device such as the processor-based device 100 may be vulnerable to a control flow hijacking attack, by which an attacker can modify code pointers stored in memory to change the program flow of an executing process. To protect against such attacks, the processor-based device 100 implements an instruction set architecture (ISA) that provides pointer signing instructions and pointer authentication instructions (not shown), the operation of which will be described below with reference to Figure 2 Despite the use of such pointer signing and authentication instructions, conventional processor-based devices may be susceptible to PAC attacks (or "PACMAN attacks"), which can enable an attacker to exhaustively enumerate the PAC of a pointer by using speculative execution paths to attempt to verify the PAC, and subsequently using microarchitectural side channels to leak the results of the attempted PAC verification. The use of speculative execution paths as part of a PAC attack is discussed below in relation to Figure 3 for a more detailed discussion.

[0035] Therefore, to mitigate PAC attacks, the processor 102 of the processor-based device 100 provides a mitigation circuit 136 that modifies the manner in which the pointer authentication instruction is executed. It is to be understood that although the mitigation circuit 136 is illustrated as a separate element of the processor 102, in some aspects, the mitigation circuit 136 can be integrated into one or more other elements of the processor 102, such as the instruction processing circuit 104. In an exemplary operation, the processor 102 uses the mitigation circuit 136 to determine that a pointer authentication instruction for authenticating a pointer is being speculatively executed. As a non-limiting example, this can be achieved by, for example, the mitigation circuit 136 communicating with an element of the instruction processing circuit 104. In response to determining that the pointer authentication instruction is being speculatively executed, the mitigation circuit 136 determines that the pointer is invalid based on the signature of the pointer. When the pointer is determined to be invalid, the mitigation circuit 136 performs a mitigation action.

[0036] In some exemplary aspects, the mitigation action includes the mitigation circuit 136 modifying the signature of the pointer to indicate that the pointer is valid (i.e., even if the pointer is actually invalid), and also raising a microarchitectural exception (with the text of the figure being "MICROARCH exception") 138 to trigger a pipeline flush. The pipeline flush ensures that the pointer authentication instruction is not retired due to architecturally incompatible results (i.e., indicating that the pointer is valid when the pointer is invalid). The microarchitectural exception 138 is an exception implemented by the ISA below the processor 102 in a manner that is not visible to software, and can include, for example, a signal sent by the mitigation circuit 136 to the ROB 134. By not marking the pointer as invalid (and thereby causing an attacker's exhaustive guess of the pointer signature to always return the same result, whether the guess is correct or incorrect), the mitigation circuit 136 can prevent any leakage of the true validity of the pointer via microarchitectural side channels. Some aspects may provide for triggering the pipeline flush immediately, while in some aspects, the pipeline flush is triggered when the pointer authentication instruction is ready to retire.

[0037] In some aspects, the processor 102 may hold the pointer authentication instruction in an instruction scheduler (not shown) until the pointer authentication instruction retires, at which point the processor 102 re-executes the pointer authentication instruction when the pointer authentication instruction reaches the head of the ROB 134. Some aspects may provide that when the pointer authentication instruction is at the head of the ROB 134, the processor 102 may initiate a new microcode sequence to perform the GPR correction.

[0038] Some aspects may provide that the pointer authentication instruction itself is also flushed, in which case an indicator 140 associated with the pointer authentication instruction is set (e.g., by storing an address or identifier of the pointer authentication instruction, as a non-limiting example). Using the indicator 140, the mitigation circuitry 136 may determine when a subsequent iteration of the pointer authentication instruction is no longer speculative (e.g., by checking the value of the indicator 140 when the pointer authentication instruction is encountered again). When a subsequent iteration of the pointer authentication instruction is determined to be no longer speculative, if the signature of the pointer indicates that the pointer is invalid, the mitigation circuitry 136 triggers an invalid address architectural exception by modifying the signature of the pointer, thereby performing pointer authentication in a conventional manner. In some aspects, the processor 102 may determine that a subsequent iteration of the pointer authentication instruction is no longer speculative without using an indicator such as the indicator 140, for example, by determining that the subsequent iteration of the pointer authentication instruction is the oldest instruction awaiting execution by the processor 102.

[0039] It is noted that a PAC attack may require a large number of repeated failed attempts before successfully identifying a valid signature that can be used to tamper with a pointer. Therefore, some exemplary aspects may provide that the mitigation actions performed by the mitigation circuitry 136 may include modifying the signature of the pointer to indicate that the pointer is invalid (i.e., in a conventional manner), and incrementing an invalid pointer counter ( Figure 1 In such an aspect, the mitigation circuit 136 then determines whether the value of the invalid pointer counter 142 exceeds the invalid pointer count threshold ( Figure 1 If so, the mitigation circuit 136 causes an architectural exception ( Figure 1 The text in the figure is "ARCH anomaly") 146 (i.e., software visible anomaly) to indicate a possible attack. In this way, a PAC attack can be detected before the attacker is able to identify a valid signature.

[0040] Figure 2 2 is a block diagram showing the operation of signing and authenticating a pointer using a pointer signature instruction 200 and a pointer authentication instruction 202, respectively, which are provided by an ISA (such as ARM) that supports pointer authentication. Figure 2 In the example, pointer 204 includes an address 206 that identifies a location in memory, which represents, for example, a target address of a branch instruction, or a location where data is stored in memory. To prevent unauthorized modification of pointer 204, the executing process may first execute pointer signature instruction 200 to sign pointer 204. When pointer signature instruction 200 is executed, a cryptographic hash of pointer 204 is generated and used as a signature 208 (also called a pointer authentication code or PAC) for pointer 204. Figure 2 As shown by arrow 210, signature 208 uses traditionally unused bits to be stored within pointer 204. In some exemplary aspects, signature 208 can be calculated based on address 206 of pointer 204 and a context value (not shown) consisting of a key and a program-specified salt.

[0041] Pointer 204 can then be verified by the execution process by executing pointer authentication instruction 202, as shown by arrow 212. When pointer authentication instruction 202 is executed, a recalculated signature (not shown) is generated for pointer 204 that is compared to signature 208 stored in pointer 204. If signature 208 matches the recalculated signature, the bits storing signature 208 are cleared (i.e., by setting them to a zero value (0)), and pointer 204 can be used in a conventional manner. However, if signature 208 does not match the recalculated signature, some bits within signature 208 are set to cause any de-referencing of pointer 204 (e.g., attempting to access data stored at a memory address stored in pointer 204) to trigger an invalid address architecture exception. Updating signature 208 by executing pointer authentication instruction 202 is indicated by arrow 214.

[0042] Figure 3 Different execution paths for successful and failed pointer authentication are shown, which could be performed speculatively during a PAC attack. Figure 3, code excerpt 300 includes a load register (LDR) instruction 302 that loads a potentially corrupted pointer from a location specified by register R1 into register R0; a pointer authentication (AUT) instruction 304 that attempts to authenticate a pointer stored in register R0; and an LDR instruction 306 that loads a value from the location specified by the pointer in register R0 into register R2. Box 308 shows the result if the pointer in register R0 is successfully authenticated (as indicated by the arrow with the text "passed" in the figure). In this case, the bits storing the signature 310 of the pointer stored in register R0 are cleared (i.e., by setting the signature 310 to the value 0000 as seen in box 308), and the LDR instruction 306 translates, fetches, and stores data at the location indicated by the pointer. These operations leave microarchitectural side effects, such as changes to the contents of caches, translation lookaside buffers (TLBs), functional units, and on-chip networks. In box 312, the result of a failed authentication of the pointer in register R0 is shown (as indicated by the arrow with the text "failed" in the figure). In this case, specific bits of storage signature 310 are modified (i.e., in this example, by setting signature 310 to a value of 8000, as seen in block 312) to cause a subsequent dereference of the pointer stored in register R0 to trigger an invalid address architectural exception. In addition, other microarchitectural side effects different from those produced by successful authentication of block 308 may remain.

[0043] PAC attacks exploit speculative execution to attempt to exhaustively enumerate the signatures of pointers. As described above, using pointer authentication instructions such as Figure 2 Pointer authentication instruction 202) means that the attacker must identify a valid signature (e.g., Figure 2 208 in order to modify the pointer (such as Figure 2 In addition, as described above, Figure 3 The different results shown in blocks 308 and 312 of translate into different microarchitectural side effects that an attacker may observe (e.g., changes made to the contents of caches, translation lookaside buffers (TLBs), functional units, and on-chip networks that persist even if speculative execution paths are crushed). Thus, the PAC attack causes execution of pointer authentication instructions to occur on speculative execution paths, such as those caused by mispredicted branches, to prevent the attack from being identified due to invalid address architectural exceptions caused by failed pointer authentication. The attacker can repeatedly attempt authentication (and observe the resulting microarchitectural side effects) until a valid signature is identified, at which point the attacker can use the valid signature to craft a malicious pointer.

[0044] Therefore, to illustrate Figure 1Exemplary operation of the processor-based device 100 for mitigating PAC attacks, Figure 4 A flowchart illustrating an exemplary operation 400 is provided. For clarity, in describing Figure 4 Reference Figure 1 and Figure 2 Example operation 400 from Figure 4 Initially, the processor (e.g. Figure 1 The processor 102) determines the authentication pointer (eg, Figure 2 204) of the pointer authentication instruction (for example, Figure 2 The pointer authentication instruction 202 in is being speculatively executed (block 402). The processor 102 then checks the pointer 204 based on its signature (e.g., Figure 2 The processor 102 then performs mitigation actions (block 406) in response to determining that the pointer authentication instruction 202 is being speculatively executed and determining that the pointer 204 is invalid. It is to be understood that some of the example operations 400 may be performed in different ways than Figure 4 Execute in the order shown.

[0045] In some aspects, Figure 4 The operations in block 406 for performing mitigation actions may include the processor 102 initiating a microarchitectural exception to trigger a pipeline flush. In this regard, Figure 5A and 5B Instructions are provided for performing Figure 4 406 of the mitigation action. Figure 5A and 5B Reference Figure 1 and Figure 2 It is to be understood that some of the exemplary operations in exemplary operation 500 may be performed in different Figure 5A and 5B The steps are performed in the order shown, and / or may be omitted.

[0046] exist Figure 5A , the exemplary operations 500 begin with the processor 102 modifying the signature 208 of the pointer 204 to indicate that the pointer 204 is valid (block 502). The processor 102 then raises a microarchitectural exception to trigger a pipeline flush, e.g. Figure 1The microarchitectural exception 138 of block 504 may be raised to trigger a pipeline flush. Some aspects may provide that the operation of block 504 for raising a microarchitectural exception 138 to trigger a pipeline flush may include raising a microarchitectural exception 138 to cause an immediate pipeline flush (block 506). According to some aspects, the operation of block 504 for raising a microarchitectural exception 138 to trigger a pipeline flush may include raising a microarchitectural exception 138 to cause a pipeline flush when the pointer verification instruction 202 is ready to retire (block 508).

[0047] In some aspects, the processor 102 then performs a pipeline flush (block 510). Some aspects may provide that the operations of block 510 for performing a pipeline flush may include flushing all instructions younger than the pointer authentication instruction 202 (block 512). As discussed in more detail above, such aspects may provide a mechanism for the pointer authentication instruction 202 to be re-executed to recover a correct result from an attempt to authorize the pointer 204. According to some aspects, the operations of block 510 for performing a pipeline flush may also include flushing the pointer authentication instruction 202 (block 514). Exemplary operations 500 in these aspects may be described in detail in FIG. Figure 5B Continue at block 516 of .

[0048] Reference now Figure 5B After refreshing the pointer authentication instruction 202, the exemplary operations 500 continue with the processor 102 setting an indicator associated with the pointer authentication instruction 202 (e.g., Figure 1 140) (block 516). Subsequently, in response to indicator 140 being set, processor 102 determines that subsequent iterations of pointer authentication instruction 202 are no longer speculative (block 518). After determining that subsequent iterations of pointer authentication instruction 202 are no longer speculative, processor 102 executes a series of instructions (block 520). Processor 102 determines that pointer 204 is invalid based on signature 208 of pointer 204 (block 522). In response to determining that pointer 204 is invalid, processor 102 modifies pointer 204 to trigger an invalid address architecture exception (i.e., in a conventional manner) (block 524).

[0049] Some aspects can be provided, Figure 4 The operations of block 406 for performing mitigation actions include tracking occurrences of invalid pointers and raising an architectural exception if a threshold is exceeded. In this regard, Figure 6 Instructions are provided for performing Figure 4 406 of the mitigation action. Figure 6 Reference Figure 1 and Figure 2 It is to be understood that some of the exemplary operations in exemplary operation 600 may be performed in different Figure 6The steps are performed in the order shown, and / or may be omitted.

[0050] Example operation 600 starts from Figure 6 Initially, processor 102 increments the value of the invalid pointer counter, e.g. Figure 1 The processor 102 then determines that the value of the invalid pointer counter 142 exceeds the invalid pointer count threshold, e.g. Figure 1 In response to determining that the value of the invalid pointer counter 142 exceeds the invalid pointer count threshold 144, the processor 102 causes an architectural exception (e.g., Figure 1 architectural anomalies 146) to indicate a possible attack (block 606).

[0051] The mitigation of PAC attacks according to various aspects disclosed herein can be provided in or integrated into any processor-based device. Examples include, but are not limited to, set-top boxes, entertainment units, navigation devices, communication devices, fixed location data units, mobile location data units, global positioning system (GPS) devices, mobile phones, cellular phones, smart phones, session initiation protocol (SIP) phones, tablet computers, phablets, servers, computers, portable computers, mobile computing devices, laptop computers, wearable computing devices (e.g., smart watches, health or fitness trackers, glasses, etc.), desktop computers, personal digital assistants (PDAs), monitors, computer monitors, televisions, tuners, radio units, satellite radio units, music players, digital music players, portable music players, digital video disc (DVD) players, portable digital video players, automobiles, vehicle components, avionics systems, drones, and multirotors.

[0052] in this regard, Figure 7 An example of a processor-based device 700 is shown, which may include Figure 1 The processor-based device 100 shown in FIG. In this example, the processor-based device 700 includes a processor 702, which may include Figure 1 The processor 102 includes one or more central processing units ( Figure 7 The text in the figure is "CPU") 704, which can also be called a CPU core or a processor core. Figure 7 The processor 702 also includes a mitigation circuit 706, which is functionally similar to Figure 1The processor 702 may have a cache memory 708 coupled to the processor 702 for quickly accessing temporarily stored data. The processor 702 is coupled to the system bus 710 and may mutually couple the master devices and slave devices included in the processor-based device 700. As is well known, the processor 702 communicates with these other devices by exchanging address, control, and data information on the system bus 710. For example, as an example of a slave device, the processor 702 may transmit a bus transaction request to the memory controller 712. Although Figure 7 Although not shown, a plurality of system buses 710 may be provided, wherein each system bus 710 constitutes a different structure.

[0053] Other master devices and slave devices may be connected to the system bus 710. Figure 7 As shown, as an example, these devices may include a memory system 714, which includes a memory controller 712 and a memory array 716, one or more input devices 718, one or more output devices 720, one or more network interface devices 722, and one or more display controllers 724. Input device 718 may include any type of input device, including but not limited to input keys, switches, voice processors, etc. Output device 720 may include any kind of output device, including but not limited to audio, video, other visual indicators, etc. Network interface device 722 can be any device configured to allow data to be exchanged with network 726. Network 726 can be any type of network, including but not limited to wired or wireless networks, private or public networks, local area networks (LANs), wireless local area networks (WLANs), wide area networks (WANs), Bluetooth TM Networks and the Internet. The network interface device 722 may be configured to support any type of communication protocol desired.

[0054] The processor 702 may also be configured to access a display controller 724 via the system bus 710 to control information sent to one or more displays 728. The display controller 724 sends information to the display 728 for display via one or more video processors 730, which processes the information to be displayed into a format suitable for the display 728. The display 728 may include any type of display, including but not limited to a cathode ray tube (CRT), a liquid crystal display (LCD), a plasma display, etc.

[0055] Figure 7 The processor-based device 700 may include a set of instructions ( Figure 7The instructions 732 may be stored in the memory array 716, the processor 702, and / or the cache memory 708, each of which may include an example of a non-transitory computer-readable medium. The instructions 732 may also reside completely or at least partially within the memory array 716 and / or within the processor 702 during its execution. The instructions 732 may also be sent or received over the network 726, so that the network 726 may include an example of a computer-readable medium.

[0056] Although the computer-readable medium is described as a single medium in the exemplary embodiments herein, the term "computer-readable medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) storing one or more instruction sets 732. The term "computer-readable medium" should also be considered to include any medium that can store, encode, or carry an instruction set for execution by a processing device and cause the processing device to perform any one or more of the methods of the embodiments disclosed herein. Therefore, the term "computer-readable medium" should include, but is not limited to, solid-state memories, optical media, and magnetic media.

[0057] Those skilled in the art will further appreciate that the various illustrative logic blocks, modules, circuits and algorithms described in conjunction with the various aspects disclosed herein can be implemented as electronic hardware, instructions stored in a memory or another computer-readable medium and executed by a processor or other processing device, or a combination of the two. The memory disclosed herein can be a memory of any type and size, and can be configured to store any type of information required. In order to clearly illustrate this interchangeability, the functions of various illustrative components, blocks, modules, circuits and steps are generally described above. How to implement such functions depends on specific applications, design choices and / or design constraints imposed on the entire system. The technician can implement the described functionality in an alternative manner for each specific application, but such implementation decisions should not be interpreted as causing departure from the scope of the present disclosure.

[0058] The various illustrative logic blocks, modules, and circuits described in conjunction with the aspects disclosed herein may be implemented or executed using a processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The processor may be a microprocessor, but in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).

[0059] The aspects disclosed herein may be embodied in hardware and instructions stored in hardware, and may reside in, for example, random access memory (RAM), flash memory, read-only memory (ROM), electrically programmable ROM (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, removable disks, CD-ROMs, or any other form of computer-readable medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Alternatively, the storage medium may be integrated into a processor. The processor and storage medium may reside in an ASIC. The ASIC may reside in a remote station. Alternatively, the processor and storage medium may reside in a remote station, a base station, or a server as discrete components.

[0060] It should also be noted that the operational steps described in any exemplary aspects of this article are described to provide examples and discussions. The described operations can be performed in many different sequences in addition to the sequence shown. In addition, the operations described in a single operational step can actually be performed in multiple different steps. In addition, one or more operational steps discussed in the exemplary aspects can be combined. It should be understood that the operational steps shown in the flow chart can be modified in many different ways, which is obvious to those skilled in the art. It will also be understood by those skilled in the art that information and signals can be represented using any one of a variety of different techniques and methods. For example, the data, instructions, commands, information, signals, bits, symbols, and chips mentioned throughout the description above can be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof.

[0061] The foregoing description of the present disclosure is provided to enable those skilled in the art to implement or use the present disclosure. Various modifications to the present disclosure will be apparent to those skilled in the art, and the general principles defined herein may also be applied to other variations. Therefore, the present disclosure is not intended to be limited to the examples and designs described herein, but to conform to the widest scope consistent with the principles and novel features disclosed herein.

[0062] Examples of implementations are described in the following numbered clauses.

[0063] 1. A processor-based device comprising:

[0064] A processor configured to:

[0065] determining that a pointer authentication instruction for authenticating a pointer is being speculatively executed;

[0066] determining, based on a signature of the pointer, that the pointer is invalid; and

[0067] In response to determining that the pointer authentication instruction for authenticating the pointer is being speculatively executed and determining that the pointer is invalid, performing a mitigation action.

[0068] 2. A processor-based device as described in clause 1, wherein the processor is configured to perform the mitigation action by being configured to:

[0069] modifying the signature of the pointer to indicate that the pointer is valid; and

[0070] Raise a microarchitectural exception to trigger a pipeline flush.

[0071] 3. A processor-based device as described in clause 2, wherein the processor is configured to raise the microarchitectural exception to trigger the pipeline flush by being configured to raise the microarchitectural exception to trigger an immediate pipeline flush.

[0072] 4. A processor-based device according to any of clauses 2-3, wherein the processor is configured to cause the microarchitectural exception to trigger a pipeline flush by being configured to cause the microarchitectural exception to trigger a pipeline flush when the pointer authentication instruction is ready to retire.

[0073] 5. A processor-based device according to any of clauses 2-4, wherein the processor is further configured to perform the pipeline flush.

[0074] 6. The processor-based device of clause 5, wherein the processor is configured to perform the pipeline flush by being configured to flush all instructions younger than the pointer validation instruction.

[0075] 7. A processor-based device according to any of clauses 5-6, wherein the processor is further configured to perform the pipeline flush by being configured to flush the pointer verify instruction.

[0076] 8. A processor-based device according to clause 7, wherein the processor is further configured to:

[0077] Setting an indicator associated with the pointer authentication instruction;

[0078] In response to the indicator being set, determining that a subsequent iteration of the pointer authentication instruction is no longer speculative; and

[0079] In response to determining that the subsequent iteration of the pointer authentication instruction is no longer speculative:

[0080] Based on the signature of the pointer, determining that the pointer is invalid; and

[0081] In response to determining that the pointer is invalid, the signature of the pointer is modified to trigger an invalid address architectural exception.

[0082] 9. A processor-based device according to any of clauses 1 to 8, wherein the processor is configured to perform the mitigation action by being configured to:

[0083] Increment the value of the invalid pointer counter;

[0084] determining that the value of the invalid pointer counter exceeds an invalid pointer count threshold; and

[0085] In response to determining that the value of the invalid pointer counter exceeds the invalid pointer count threshold, an architectural exception is raised to indicate a possible attack.

[0086] 10. A processor-based device as described in any of clauses 1-9, incorporated into a device selected from the group consisting of: a set-top box; an entertainment unit; a navigation device; a communications device; a fixed location data unit; a mobile location data unit; a global positioning system (GPS) device; a mobile phone; a cellular phone; a smartphone; a Session Initiation Protocol (SIP) phone; a tablet computer; a phablet; a server; a computer; a portable computer; a mobile computing device; a wearable computing device; a desktop computer; a personal digital assistant (PDA); a monitor; a computer monitor; a television set; a tuner; a radio unit; a satellite radio unit; a music player; a digital music player; a portable music player; a digital video player; a video player; a digital video disc (DVD) player; a portable digital video player; an automobile; a vehicle component; an avionics system; an unmanned aerial vehicle; and a multirotor aircraft.

[0087] 11. A processor-based device comprising:

[0088] means for determining that a pointer authentication instruction for authenticating a pointer is being speculatively executed;

[0089] means for determining that the pointer is invalid based on a signature of the pointer; and

[0090] Means for performing a mitigation action in response to determining that the pointer authentication instruction is being speculatively executed and determining that the pointer is invalid.

[0091] 12. A method for mitigating a pointer authentication code (PAC) attack in a processor-based device, the method comprising:

[0092] determining, by a processor of the processor-based device, that a pointer authentication instruction for authenticating a pointer is being speculatively executed;

[0093] determining, based on a signature of the pointer, that the pointer is invalid; and

[0094] In response to determining that the pointer authentication instruction is being speculatively executed and determining that the pointer is invalid, performing a mitigation action.

[0095] 13. The method of clause 12, wherein performing the mitigation action comprises:

[0096] modifying the signature of the pointer to indicate that the pointer is valid; and

[0097] Raise a microarchitectural exception to trigger a pipeline flush.

[0098] 14. The method of clause 13, wherein invoking the microarchitectural exception to trigger a pipeline flush comprises invoking the microarchitectural exception to trigger an immediate pipeline flush.

[0099] 15. The method of any one of clauses 13-14, wherein initiating the microarchitectural exception to trigger a pipeline flush comprises initiating the microarchitectural exception to trigger a pipeline flush when the pointer verification instruction is ready to retire.

[0100] 16. The method of any of clauses 13-15, further comprising performing the pipeline flush.

[0101] 17. The method of clause 16, wherein performing the pipeline flush comprises flushing all instructions younger than the pointer validation instruction.

[0102] 18. The method of clause 17, wherein performing the pipeline flush comprises: flushing the pointer validation instruction.

[0103] 19. The method according to clause 18, further comprising:

[0104] Setting an indicator associated with the pointer authentication instruction;

[0105] In response to the indicator being set, determining that a subsequent iteration of the pointer authentication instruction is no longer speculative; and

[0106] In response to determining that the subsequent iteration of the pointer authentication instruction is no longer speculative:

[0107] determining, based on a signature of the pointer, that the pointer is invalid; and

[0108] In response to determining that the pointer is invalid, the signature of the pointer is modified to trigger an invalid address architectural exception.

[0109] 20. A method according to any of clauses 12-19, wherein performing the mitigation action comprises:

[0110] Increment the value of the invalid pointer counter;

[0111] determining that the value of the invalid pointer counter exceeds an invalid pointer count threshold; and

[0112] In response to determining that the value of the invalid pointer counter exceeds the invalid pointer count threshold, an architectural exception is raised to indicate a possible attack.

[0113] 21. A non-transitory computer readable medium having stored thereon computer executable instructions, which when executed by a processor, provide location-based pre-fetching for a first cache memory device by causing the processor to:

[0114] determining that a pointer authentication instruction for authenticating a pointer is being speculatively executed;

[0115] determining, based on a signature of the pointer, that the pointer is invalid; and

[0116] In response to determining that the pointer authentication instruction is being speculatively executed and determining that the pointer is invalid, performing a mitigation action.

[0117] 22. The non-transitory computer-readable medium of clause 21, wherein the computer-executable instructions cause the processor to perform the subtraction action by causing the processor to:

[0118] modifying the signature of the pointer to indicate that the pointer is valid; and

[0119] Raise a microarchitectural exception to trigger a pipeline flush.

[0120] 23. The non-transitory computer-readable medium of clause 22, wherein the computer-executable instructions cause the processor to raise the microarchitectural exception to trigger a pipeline flush by causing the processor to raise the microarchitectural exception to trigger an immediate pipeline flush.

[0121] 24. A non-transitory computer-readable medium as described in any of clauses 22-23, wherein the computer-executable instructions cause the processor to cause the microarchitectural exception to trigger a pipeline flush by causing the processor to cause the microarchitectural exception to trigger a pipeline flush when the pointer authentication instruction is ready to retire.

[0122] 25. The non-transitory computer-readable medium of any of clauses 22-24, wherein the computer-executable instructions further cause the processor to perform the pipeline flush.

[0123] 26. The non-transitory computer-readable medium of clause 25, wherein the computer-executable instructions cause the processor to perform the pipeline flush by causing the processor to flush all instructions younger than the pointer validation instruction.

[0124] 27. The non-transitory computer-readable medium of clause 26, wherein the computer-executable instructions cause the processor to perform the pipeline flush by causing the processor to flush the pointer validation instructions.

[0125] 28. The non-transitory computer-readable medium of clause 27, wherein the computer-executable instructions further cause the processor to:

[0126] Setting an indicator associated with the pointer authentication instruction;

[0127] In response to the indicator being set, determining that a subsequent iteration of the pointer authentication instruction is no longer speculative; and

[0128] In response to determining that the subsequent iteration of the pointer authentication instruction is no longer speculative:

[0129] determining, based on a signature of the pointer, that the pointer is invalid; and

[0130] In response to determining that the pointer is invalid, the signature of the pointer is modified to trigger an invalid address architectural exception.

[0131] 29. The non-transitory computer-readable medium of any one of clauses 21-28, wherein the computer-executable instructions cause the processor to perform the decrement operation by causing the processor to:

[0132] Increment the value of the invalid pointer counter;

[0133] determining that the value of the invalid pointer counter exceeds an invalid pointer count threshold; and

[0134] In response to determining that the value of the invalid pointer counter exceeds an invalid pointer count threshold, an architectural exception is raised to indicate a possible attack.

Claims

1. A processor-based device comprising: A processor configured to: determining that a pointer authentication instruction for authenticating a pointer is being speculatively executed; determining, based on a signature of the pointer, that the pointer is invalid; as well as In response to determining that the pointer authentication instruction for authenticating the pointer is being speculatively executed and determining that the pointer is invalid, performing a mitigation action.

2. The processor-based device of claim 1, wherein: The processor is configured to perform the mitigation actions by being configured to: modifying the signature of the pointer to indicate that the pointer is valid; and Raise a microarchitectural exception to trigger a pipeline flush.

3. The processor-based device of claim 2, wherein: The processor is configured to raise the microarchitectural exception to trigger a pipeline flush by being configured to raise the microarchitectural exception to trigger an immediate pipeline flush.

4. The processor-based device of claim 2, wherein the processor is configured to raise the microarchitectural exception to trigger a pipeline flush by being configured to raise the microarchitectural exception to trigger a pipeline flush when the pointer authentication instruction is ready to retire.

5. The processor-based device of claim 2, wherein: The processor is further configured to perform the pipeline flush.

6. The processor-based device of claim 5, wherein: The processor is configured to perform the pipeline flush by being configured to flush all instructions younger than the pointer verify instruction.

7. The processor-based device of claim 6, wherein: The processor is further configured to perform the pipeline flush by being configured to flush the pointer verify instruction.

8. The processor-based device of claim 7, wherein: The processor is further configured to: Setting an indicator associated with the pointer authentication instruction; In response to the indicator being set, determining that a subsequent iteration of the pointer authentication instruction is no longer speculative; as well as In response to determining that the subsequent iteration of the pointer authentication instruction is no longer speculative: Based on the signature of the pointer, determining that the pointer is invalid; as well as In response to determining that the pointer is invalid, the signature of the pointer is modified to trigger an invalid address architectural exception.

9. The processor-based device of claim 1, wherein: The processor is configured to perform the mitigation actions by being configured to: Increment the value of the invalid pointer counter; determining that the value of the invalid pointer counter exceeds an invalid pointer count threshold; and In response to determining that the value of the invalid pointer counter exceeds the invalid pointer count threshold, an architectural exception is raised to indicate a possible attack.

10. The processor-based device of claim 1 , incorporated into a device selected from the group consisting of: a set-top box; an entertainment unit; a navigation device; a communication device; a fixed location data unit; a mobile location data unit; a global positioning system (GPS) device; a mobile phone; a cellular phone; a smartphone; a session initiation protocol (SIP) phone; a tablet computer; a phablet; a server; a computer; a portable computer; a mobile computing device; a wearable computing device; a desktop computer; a personal digital assistant (PDA); a monitor; a computer monitor; a television set; a tuner; a radio unit; a satellite radio unit; a music player; a digital music player; a portable music player; a digital video player; a video player; a digital video disc (DVD) player; a portable digital video player; an automobile; a vehicle component; an avionics system; an unmanned aerial vehicle; and a multirotor aircraft.

11. A processor-based device comprising: means for determining that a pointer authentication instruction for authenticating a pointer is being speculatively executed; means for determining that the pointer is invalid based on a signature of the pointer; as well as Means for performing a mitigation action in response to determining that the pointer authentication instruction is being speculatively executed and determining that the pointer is invalid.

12. A method for mitigating pointer authentication code (PAC) attacks in a processor-based device, the method comprising: A determination is made by a processor of the processor-based device that a pointer authentication instruction for authenticating a pointer is being speculatively executed. determining, based on a signature of the pointer, that the pointer is invalid; as well as In response to determining that the pointer authentication instruction is being speculatively executed and determining that the pointer is invalid, performing a mitigation action.

13. The method according to claim 12, wherein: Performing the mitigation actions includes: modifying the signature of the pointer to indicate that the pointer is valid; and Raise a microarchitectural exception to trigger a pipeline flush.

14. The method according to claim 13, wherein: Inducing the microarchitectural exception to trigger a pipeline refresh includes: inducing the microarchitectural exception to trigger an immediate pipeline refresh.

15. The method according to claim 13, wherein: Inducing the microarchitecture exception to trigger a pipeline refresh includes: when the pointer authentication instruction is ready to retire, inducing the microarchitecture exception to trigger a pipeline refresh. The method of claim 13 , further comprising performing a pipeline flush.

17. The method according to claim 16, wherein: Executing the pipeline refresh includes: refreshing all instructions younger than the pointer verification instruction.

18. The method according to claim 17, wherein: Executing the pipeline refresh includes: refreshing the pointer authentication instruction.

19. The method according to claim 18, further comprising: Setting an indicator associated with the pointer authentication instruction; In response to the indicator being set, determining that a subsequent iteration of the pointer authentication instruction is no longer speculative; as well as In response to determining that the subsequent iteration of the pointer authentication instruction is no longer speculative: determining, based on a signature of the pointer, that the pointer is invalid; as well as In response to determining that the pointer is invalid, the signature of the pointer is modified to trigger an invalid address architectural exception.

20. The method according to claim 12, wherein: Performing the mitigation actions includes: Increment the value of the invalid pointer counter; determining that the value of the invalid pointer counter exceeds an invalid pointer count threshold; and In response to determining that the value of the invalid pointer counter exceeds an invalid pointer count threshold, an architectural exception is raised to indicate a possible attack.

21. A non-transitory computer readable medium having stored thereon computer executable instructions that, when executed by a processor, provide location-based pre-fetching for a first cache memory device by causing the processor to: determining that a pointer authentication instruction for authenticating a pointer is being speculatively executed; determining, based on a signature of the pointer, that the pointer is invalid; as well as In response to determining that the pointer authentication instruction is being speculatively executed and determining that the pointer is invalid, performing a mitigation action.

22. The non-transitory computer readable medium of claim 21, wherein: The computer executable instructions cause the processor to perform the subtraction operation by causing the processor to: modifying the signature of the pointer to indicate that the pointer is valid; and Raise a microarchitectural exception to trigger a pipeline flush.

23. The non-transitory computer readable medium of claim 22, wherein: The computer executable instructions cause the processor to raise the microarchitectural exception to trigger a pipeline flush by causing the processor to raise the microarchitectural exception to trigger an immediate pipeline flush.

24. The non-transitory computer readable medium of claim 22, wherein: The computer executable instructions cause the processor to cause the microarchitectural exception to trigger a pipeline flush by causing the processor to cause the microarchitectural exception to trigger a pipeline flush when the pointer validation instruction is ready to retire.

25. The non-transitory computer readable medium of claim 22, wherein: The computer executable instructions further cause the processor to perform the pipeline flush.

26. The non-transitory computer readable medium of claim 25, wherein: The computer executable instructions cause the processor to perform the pipeline flush by causing the processor to flush all instructions younger than the pointer validation instruction.

27. The non-transitory computer readable medium of claim 26, wherein: The computer executable instructions cause the processor to perform the pipeline flush by causing the processor to flush the pointer validation instruction.

28. The non-transitory computer readable medium of claim 27, wherein: The computer executable instructions further cause the processor to: Setting an indicator associated with the pointer authentication instruction; In response to the indicator being set, determining that a subsequent iteration of the pointer authentication instruction is no longer speculative; as well as In response to determining that the subsequent iteration of the pointer authentication instruction is no longer speculative: determining, based on a signature of the pointer, that the pointer is invalid; as well as In response to determining that the pointer is invalid, the signature of the pointer is modified to trigger an invalid address architectural exception.

29. The non-transitory computer readable medium of claim 21, wherein: The computer executable instructions cause the processor to perform the subtraction operation by causing the processor to: Increment the value of the invalid pointer counter; determining that the value of the invalid pointer counter exceeds an invalid pointer count threshold; and In response to determining that the value of the invalid pointer counter exceeds the invalid pointer count threshold, an architectural exception is raised to indicate a possible attack.