authentication code setting instruction and authentication code checking instruction

Abstract

In response to the authentication code generation class instruction, the processing circuit generates an authentication code associated with the authentication target value by applying a code generation function to the authentication target value, the key, a first modifier value and a second modifier value. For the authentication code setting instruction, the generated authentication code is written to the destination register. For the authentication code check instruction, the processing circuit checks whether an authentication code generated in response to the authentication code check instruction based on the authentication target value corresponds to a reference authentication code obtained from a source register and triggers an error response when they do not correspond. The first modifier value comprises a stack pointer related value. For at least one of the authentication code setting instruction / authentication code check instruction, the second modifier value comprises a program counter related value.

Description

[0001] This technology relates to the field of data processing.

[0002] Some processing architectures support a class of authentication code generation instructions for generating authentication codes associated with target values, such as address pointers or function return addresses. This can help prevent return-oriented programming (ROP) attacks or other attacks designed to cause incorrect program behavior by tampering with the address pointer or return address while it is stored in the memory system.

[0003] At least some examples of this technology provide an apparatus comprising: an instruction decoding circuit for decoding an instruction; and a processing circuit for performing a processing operation in response to the decoded instruction decoded by the instruction decoding circuit; wherein: in response to an authentication code generation instruction, the processing circuit is configured to generate an authentication code associated with an authentication target value by applying a code generation function to an authentication target value, a key, a first modifier value, and a second modifier value; the authentication code generation instruction includes an authentication code setting instruction, for which the processing circuit is configured to write the generated authentication code to the authentication target value provided for the authentication code setting instruction. The processing circuitry is configured to check whether the authentication code generated in response to the authentication code check instruction based on the authentication target value corresponds to a reference authentication code obtained from a source register separate from the register providing the authentication target value for the authentication code check instruction, and to trigger an error response when the generated authentication code does not correspond to the reference authentication code; wherein: the first modifier value includes a value depending on the stack pointer obtained from the stack pointer register; and for at least one of the authentication code setting instruction and the authentication code check instruction, the second modifier value includes a value depending on the program counter address obtained from the program counter register.

[0004] At least some examples of this technology provide computer-readable code for manufacturing the apparatus as discussed above. The code may be stored on a computer-readable storage medium. The storage medium may be a non-transitory storage medium.

[0005] At least some examples of this technology provide a method comprising performing processing operations in response to decoded instructions; wherein: in response to an authentication code generation instruction, the processing operations comprise generating an authentication code associated with an authentication target value by applying a code generation function to an authentication target value, a key, a first modifier value, and a second modifier value; in response to an authentication code setting instruction within the authentication code generation instruction, the processing operations comprise writing the generated authentication code to a destination register separate from the register providing the authentication target value for the authentication code setting instruction; and in response to an authentication code checking instruction within the authentication code generation instruction, the processing operations comprise checking whether the authentication code generated based on the authentication target value in response to the authentication code checking instruction corresponds to a reference authentication code obtained from a source register separate from the register providing the authentication target value for the authentication code checking instruction, and triggering an error response when the generated authentication code does not correspond to the reference authentication code; wherein: the first modifier value comprises a value depending on a stack pointer obtained from a stack pointer register; and for at least one of the authentication code setting instruction and the authentication code checking instruction, the second modifier value comprises a value depending on a program counter address obtained from a program counter register.

[0006] At least some examples provide a computer program for controlling a host data processing device to provide an instruction execution environment for executing target program code. The computer program includes: instruction decoding program logic for decoding instructions of the target program code and controlling the host data processing device to perform processing operations in response to the decoded instructions; wherein: in response to an authentication code generation instruction, the instruction decoding program logic is configured to control the host data processing device to generate an authentication code associated with the authentication target value by applying a code generation function to an authentication target value, a key, a first modifier value, and a second modifier value; the authentication code generation instruction includes: an authentication code setting instruction, for which the instruction decoding program logic is configured to control the host data processing device to apply the generated authentication code to the authentication target value. The authentication code is written to a separate analog destination register from the analog register that provides the authentication target value for the authentication code setting instruction; and an authentication code check instruction, for which the instruction decoding program logic is configured to control the host data processing device to check whether the authentication code generated based on the authentication target value in response to the authentication code check instruction corresponds to a reference authentication code obtained from a separate analog source register from the analog register that provides the authentication target value for the authentication code check instruction, and to trigger an error response when the generated authentication code does not correspond to the reference authentication code; wherein: a first modifier value includes a value depending on the stack pointer obtained from the analog stack pointer register; and for at least one of the authentication code setting instruction and the authentication code check instruction, a second modifier value includes a value depending on the program counter address obtained from the analog program counter register.

[0007] Further aspects, features, and advantages of this technology will become apparent from the following description, which is taken in conjunction with the accompanying drawings, in which:

[0008] Figure 1 An example of the device is shown;

[0009] Figure 2 An example of nested function calls is shown;

[0010] Figure 3 Examples of processing operations performed in response to authentication code setting instructions and authentication code checking instructions in authentication code generation class instructions are shown;

[0011] Figure 4 The steps for performing branch target checks are illustrated.

[0012] Figure 5 This illustrates how the immediate value specified by the authentication code check instruction provides a limited range for adjusting the program counter address;

[0013] Figure 6 An example of an instruction class for generating authentication codes by applying corrections to generate one of the first and second modifiers is shown;

[0014] Figure 7 An example is shown in which the authentication code check instruction specifies a corrected value to be applied to the stack pointer to generate the first modifier value;

[0015] Figure 8 An example is shown in which the authentication code setting instruction specifies a correction value to be applied to the program counter address to generate the second modifier value;

[0016] Figure 9 An example is shown in which the authentication code setting instruction uses a general-purpose register to specify the value of the second modifier; and

[0017] Figure 10 A simulation example is shown.

[0018] An apparatus includes: an instruction decoding circuit for decoding instructions; and a processing circuit for performing a processing operation in response to the decoded instructions decoded by the instruction decoding circuit. For example, the instruction decoding circuit and the processing circuit may support instructions defined according to a given instruction set architecture. In response to an authentication code generation instruction being decoded by the instruction decoding circuit, the processing circuit generates an authentication code associated with the authentication target value by applying a code generation function to an authentication target value, a key, a first modifier value, and a second modifier value. The authentication code generation instruction includes: an authentication code setting instruction, for which the processing circuit is configured to write the generated authentication code to a destination register separate from the register providing the authentication target value for the authentication code setting instruction; and an authentication code checking instruction, for which the processing circuit is configured to check whether the authentication code generated based on the authentication target value in response to the authentication code checking instruction corresponds to a reference authentication code obtained from a source register separate from the register providing the authentication target value for the authentication code checking instruction, and triggering an error response when the generated authentication code does not correspond to the reference authentication code. These instructions can be useful for protecting addresses or other values ​​when stored in memory (e.g., on a stack data structure). Authentication code setting instructions can be included in the software code before the point where the authentication target value (the value to be protected with the authentication code) is saved to memory, and authentication code checking instructions can be included in the software code after the point where the authentication target value is loaded back from memory. Using a separate register, separate from the register used to provide the authentication target value itself, to store the authentication code generated for the authentication code setting instructions or the reference authentication code for the authentication code checking instructions can be helpful in instruction set architectures where there are not enough spare bits in one register to hold the authentication code in the same register as the authentication target value. For example, in a 32-bit architecture, the address value to be protected as the authentication target value may exhaust all 32 bits of a register, and therefore a separate register is used to store the associated authentication code.

[0019] The code generation function used to generate authentication codes can accept the authentication target value to be protected, the key, and a first modifier value and a second modifier value as input. Using at least one modifier value in the code generation function can help reduce the risk that the value protected by a given authentication code may be used in a scenario different from its intended use. For example, a function return address may be used in a branch other than the return branch of the function that caused the function return address to be set, or a data address pointer may be used in a part of the program that is different from the part where the pointer is intended to be used. Modifier values ​​may be based on attributes associated with the current execution point for generating the authentication code.

[0020] The first modifier value may include a value dependent on the stack pointer obtained from the stack pointer register. By using a stack pointer-related value as a modifier in the code generation function, different authentication codes can be generated based on the same authentication target value when authentication code setting instructions are executed at different stack depths (e.g., corresponding to different nesting positions within a nested set of function calls). This can help detect instances where the authentication target value is used in a manner different from what is expected. For example, when protecting the function return address that is the authentication target value, a stack pointer-based modifier can be useful for more tightly binding that particular function return address to a specific instance of the function call. However, it has been recognized that relying solely on the stack pointer to distinguish different use cases of a given authentication target value may not be able to distinguish different functions called at the same stack depth. Therefore, a second modifier is also provided, for at least one of the authentication code setting instructions and authentication code checking instructions, which includes a value dependent on the program counter address obtained from the program counter register. By considering program counter-related modifiers, this allows authentication codes to be more precisely bound to specific instances of functions. This reduces the risk that attackers could circumvent authentication checks by replacing the actual authentication target value and authentication code intended for a given instance of the function with previously captured authentication target values ​​and codes captured on different instances of the function, since at least one of the stack pointer and program counter is likely to differ between different instances of the function. Therefore, by providing support in the instruction set architecture for authentication code generation instructions that allow both stack pointer-related and program counter-related values ​​to be used as modifiers in authentication code generation functions, this provides greater protection for software against attacks based on tampering with address values ​​or other authentication target values ​​stored in memory.

[0021] Both the authentication code setting instruction and the authentication code checking instruction do not necessarily need to use a second modifier value that depends on the program counter address. In implementation, to ensure that the authentication code checking instruction generates the same authentication code value as the authentication code setting instruction when the authentication target value is used within the scope of the intended use case, the software will need to ensure that the modifier value of the code generation function is the same for both the authentication code checking instruction and the authentication code setting instruction. However, the responsibility for ensuring that the modifier is the same for the corresponding setting / checking instruction lies with the software executing on the device, not the hardware platform provided by the device, which does not need to provide any circuit features to guarantee that the same modifier will be used for both instructions. Therefore, the authentication code setting instruction can trigger the processing circuitry to execute a first set of one or more operations that implement the authentication code setting function, and the authentication code checking instruction can trigger the processing circuitry to execute a second set of one or more operations that implement the authentication code checking function. From the hardware platform's perspective, each instruction triggers an independent set of operations that take input values ​​defined using registers or other parameters of the instruction, without any particular guarantee as to how these values ​​were generated by any earlier instruction. This means that while it is useful for at least one of the authentication code setting instruction and the authentication code checking instruction to obtain a value dependent on the program counter address as its second modifier value, it is not necessary for both the authentication code setting function triggered by the authentication code setting instruction and the authentication code checking function triggered by the authentication code checking instruction to depend on the value obtained from the program counter register. In some examples, one of the authentication code setting function and the authentication code checking function may obtain its second modifier value based on a value stored in a general-purpose register, which is not guaranteed to depend on the program counter address in the instruction set architecture. In this case, to ensure that the authentication code check passes when the authentication target value is used correctly, the software developer or compiler will need to ensure that other instructions are executed around the authentication code setting instruction or the authentication code checking instruction to set the value in the general-purpose register to a value such that the second modifier has the same value as the second modifier associated with the corresponding program counter used by the other of the authentication code setting instruction or the authentication code checking instruction. However, as noted above, the specific sequence of instructions chosen for execution by the software developer or compiler in a particular software program is not a characteristic of the hardware device. Therefore, the device itself does not necessarily need to include circuitry that requires both the authentication code setting instruction and the authentication code checking instruction to support program counter-related modifiers.

[0022] In some examples, the authentication code check instruction may specify an immediate value, and one of the first and second modifier values ​​used in the authentication code set instruction depends on the immediate value applied as an adjustment to the stack pointer or program counter address. Applying an adjustment based on an immediate value can be useful to allow the authentication code check to succeed when the expected current value of the stack pointer or program counter address differs for the authentication code set instruction and the authentication code check instruction, respectively. Using immediate values ​​(values ​​directly encoded in the instruction code rather than obtained from registers implicitly or explicitly specified by the instruction) can help save architecture registers for other purposes, which can be particularly useful in architectures with constrained availability of architecture registers for specifying instruction operands.

[0023] In some examples, one of the authentication code setting instruction and the authentication code checking instruction specifies the application of a correction to one of the stack pointer address and the program counter address to generate a corrected value for the corresponding one of the first and second modifiers. This correction can be a supplement to or alternative to adjustments based on immediate values, as previously mentioned. It may be useful to support the ability to correct one of the stack pointer address and the program counter address when generating the first or second modifier, allowing the current value of the expected stack pointer or program counter address to be different for the use cases of the authentication code setting instruction and the authentication code checking instruction, respectively.

[0024] Specifically, in some examples, correction based on the correction value allows the authentication code setting instruction and the authentication code checking instruction to be separated by instruction address offsets greater than the maximum instruction address offset that can be represented by the immediate value of the authentication code checking instruction. While it might be considered that an immediate value would be the most appropriate mechanism, allowing the program counter offset between the addresses of the authentication code setting instruction and the authentication code checking instruction to be accounted for, thus allowing code generation functions for both types of instructions to use the same modifier value, the immediate value provides a limited range of program counter addresses that it can correct, and in some use cases where relatively long code snippets are executed within functions (which can be common when the compiler uses techniques such as loop unrolling or function inlining), this range may be insufficient to account for the address offset between the instruction addresses of the authentication code setting instruction and the authentication code checking instruction. A simpler solution might be to provide an instruction for which a general-purpose register is used to define the program counter-related modifiers for the authentication code checking instruction, thereby avoiding the need to apply any correction when taking a value from that general-purpose register, since other instructions surrounding the authentication code checking instruction ensure that the same value as the program counter address associated with the corresponding authentication code setting instruction is placed in the general-purpose register. However, it has been recognized that this approach can lead to performance degradation because it may require executing more instructions to implement a given processing function. This is because, compared to using immediate values ​​to define the second modifier associated with the program counter address of the authentication code check instruction, additional instructions may be needed around the authentication code check instruction to set values ​​in general-purpose registers, ensure that the second modifier used for the authentication code check instruction matches any program counter-related second modifier values ​​used for the authentication code setting instruction, and comply with any restrictions on register availability at the end of the function. This can increase code density (the number of instructions required to perform a given program function).

[0025] Therefore, it could be helpful to provide an instruction set architecture in which one of the authentication code setting instruction and the authentication code checking instruction specifies a correction to be applied to one of the stack pointer address and the program counter address to generate a correction value for a corresponding one of the first and second modifiers. This approach can be considered counterintuitive compared to options that simply apply an immediate value to the program counter value or directly take the modifier value from a general-purpose register; specifying additional correction value operands to be applied to the value obtained from the register to generate the corresponding modifier seems unnecessarily complex. However, in cases where both the stack pointer value and the program counter value are used as modifiers in the code generation function, this correction can help improve program code density and processing performance. The correction allows the authentication code setting instruction and the authentication code checking instruction to be separated by instruction address offsets larger than the maximum instruction address offset that can be represented using the immediate value of the authentication code checking instruction.

[0026] In some examples, the authentication code check instruction specifies a correction value to be applied to the stack pointer to generate the first modifier value for the authentication code check instruction. This approach can be considered highly counterintuitive because, in general, while the program counter address might be expected to vary between corresponding instances of authentication code setting / authentication code check instructions designed to set and check the authentication code for a given target value to be protected, the stack depth is typically expected to be the same at the entry and exit of a given function. Therefore, it is surprising that providing correction to the stack pointer in the authentication code check instruction is useful. However, it is recognized that enabling the authentication code check instruction to execute at a different stack depth than the corresponding authentication code setting instruction can help reduce the code density in the architecture associated with a function calling convention that restricts which registers are allowed to be corrupted at the end of a function call (where "corrupted" means that the register is set to a different value at the end of the function call than it was specified by the register at the beginning of the function call).

[0027] In some examples, the authentication code setting instruction specifies a correction value to be applied to the program counter address to generate the second modifier value for the authentication code setting instruction. Again, this approach can be considered counterintuitive. Typically, a given function can have multiple exit points for the same function call entry point; therefore, it would be more efficient for the instruction set architecture to define instructions such that any correction applied to the second modifier, which takes into account the difference in program counter addresses between the authentication code setting instruction and the authentication code checking instruction, would be applied at the authentication code checking instruction. This would enable the development of software where authentication code checking instructions corresponding to different function call exit points specify different correction values ​​aligned with the program counter address of the same authentication code setting instruction. However, it should be recognized that, in order to address the following issues: the correction of the program counter address to generate an immediate value for the second modifier in the authentication code check instruction can provide a limited range of maximum functional distance between corresponding instances of the authentication code setting instruction / authentication code check instruction, in an architecture where register usage constraints imposed by a finite number of available registers and any function call conventions in use restrict which registers can be used as general-purpose registers by the authentication code check instruction, the program code density can provide an authentication code setting instruction that specifies the correction value to be applied to the program counter address to generate the second modifier value. Therefore, it is surprising that such an authentication code setting instruction can be justified in being included in the instruction set architecture (i.e., justifying the instruction coding space consumed by the instruction). By implementing the authentication code setting instruction to have the processing circuitry perform some work when setting the authentication code to align the value used as the second modifier value by the authentication code setting instruction / authentication code check instruction, the maximum distance between the authentication code setting instruction / authentication code check instruction can be increased, and the program code density can be improved by reducing the need to execute as many instructions as possible around the authentication code check instruction. Improved code density can help reduce memory storage overhead and associated power consumption, as well as improve processing performance.

[0028] In some examples, where the authentication code setting instruction specifies a correction value to be applied to the program counter address to generate the second modifier value for the authentication code setting instruction, the authentication code checking instruction may also specify an immediate value to be applied to the program counter address to generate the second modifier value for the authentication code checking instruction. Therefore, in this case, both the authentication code setting instruction and the authentication code checking instruction apply the correction to the program counter address to generate the corresponding second modifier value. This allows the second modifier value to take a value other than the address of the authentication code setting instruction or the authentication code checking instruction, because the second modifier value can be any other address that can be referenced by the authentication code setting instruction / authentication code checking instruction by applying their respective corrections relative to their respective program counter address values. In addition to implementing increased functional distance between the authentication code setting instruction / authentication code checking instructions included in the program code to protect a given authentication target value, providing architectural support for both the setting instruction / checking instruction to apply correction to generate the second modifier value can help achieve higher security in use cases using on-the-fly conversions. If only one of the set / check instructions applies correction, and the other is restricted to using its program counter address value as the second modifier, the just-in-time (JIT) compiler will lack the flexibility to change the address value used as the second modifier for those set / check instructions between different instances of a given function compiled using the authentication code set / check instructions at a specific program counter address. However, by implementing the set / check instructions such that both cause the processing circuitry to apply correction to the program counter address based on the correction value specified by the respective instruction, it becomes possible to specify any address within a given range of program counter addresses relative to the set / check instructions as the second modifier. Therefore, the JIT compiler will have the flexibility to change the address to be used as the second modifier value between compiling one instance of a given function and compiling the next instance of the same function. This makes it less likely that an attacker could store an authentication code computed on one instance of the function and use that code to trigger a successful authentication code check associated with a tampered authentication target value on another instance of the function. Therefore, this approach achieves higher security against JIT-compiled code.

[0029] In some examples, the correction value is specified as an immediate value. This helps avoid the need to consume general-purpose registers for the correction value, which in some use cases could risk increasing program code density due to the inclusion of additional instructions in the program code to save / restore values ​​previously specified in general-purpose registers to comply with the function calling conventions in use.

[0030] However, in other examples, the correction value can be specified as a value obtained from a general-purpose register. For example, when the authentication code setting instruction specifies a correction value, the risk of the program code becoming larger due to using a general-purpose register to provide the correction may be less (compared to when the authentication code check instruction specifies a correction value). Additionally, in some cases, it is still acceptable for the authentication code check instruction to use a general-purpose register to specify the correction value.

[0031] When either the authentication code setting instruction or the authentication code checking instruction uses a general-purpose register to specify a correction value, that general-purpose register can be a predefined general-purpose register that does not need to be explicitly identified in the instruction encoding. For example, the instruction set architecture may specify a particular general-purpose register to be used as the general-purpose register providing the correction value.

[0032] Alternatively, the authentication code setting instruction or authentication code checking instruction can specify a register field used to identify the general-purpose register that provides the correction value. This allows the software compiler to change which general-purpose register is selected as the register that provides the correction value.

[0033] Similarly, it should be understood that any of the following registers can be a pre-defined register that does not need to be explicitly identified in the instruction encoding (fixed by design in the instruction set architecture), or a register with a variable identifier based on the register field identifier in the instruction encoding:

[0034] • A register that provides the authentication target value for the authentication code setting instruction;

[0035] • In response to the authentication code setting instruction, the generated authentication code is written to the destination register.

[0036] • A register that provides the authentication target value for authentication code checking instructions; and

[0037] • The source register from which the reference authentication code is obtained in response to the authentication code check instruction.

[0038] The stack pointer register, which provides a stack pointer for generating a first modifier value for an authentication code setting instruction or an authentication code checking instruction, and the program counter register, which provides a program counter address for generating a second modifier value for at least one of the authentication code setting instruction or the authentication code checking instruction, can be implicitly defined registers that do not require explicit identification using register fields. For example, the stack pointer and / or program counter address can be implicit operands of an instruction that are inferred to require an opcode from an instruction that identifies the type of instruction being executed.

[0039] The correction applied to the stack pointer or program counter address based on the correction value can be implemented in different ways. In some examples, the correction includes an arithmetic correction for adding or subtracting the correction value from either the stack pointer or the program counter address.

[0040] Alternatively, correction may include logical correction for generating a corrected value based on a logical combination of one of the stack pointer and program counter addresses with a correction value. For example, the correction value may specify a mask of bits to be applied to the stack pointer or program counter address so that one or more bits of the stack pointer or program counter address are set to specific values ​​to generate a corresponding modifier value. In some examples, the correction value and the stack pointer or program counter address may be logically combined using a given Boolean function (e.g., AND, NAND, OR, NOR, XOR, XNOR, NOT) or a combination of these Boolean functions.

[0041] In some examples, in response to a non-sequential change in program flow to a branch target address triggered when branch target checking is enabled, the processing circuitry is configured to trigger an error handling response if the instruction at the branch target address is not a member of a permitted class of branch target instructions. The authentication code setting instruction can be a branch target instruction within that permitted class of branch target instructions. Supporting branch target checking helps reduce the likelihood that an attacker could tamper with the target address of a branch to cause a branch to an arbitrary point in the program that is not intended to be a branch entry point. Security is improved by restricting valid branch entry points to the address of an instruction in a limited set of instructions that are allowed to act as branch target instructions. It can be particularly useful to allow the authentication code setting instruction to also act as a branch target instruction within a permitted class of branch target instructions, because typically in implementations that use authentication code generation instructions to protect function return addresses, the authentication code setting operation is the first operation performed after the function call, and thus having a single instruction perform the authentication code setting operation and also act as an effective "landing pad" for the branch target avoids the need for two separate instructions for this purpose, thereby improving program code density. However, in instruction set architectures with constrained register availability at the end of function calls, the need to comply with function call conventions may require additional save / restore of register contents to / from the stack. In some cases (e.g., where authentication code setting instructions / authentication code checking instructions are separated by a large distance in the program code), if one of the authentication code setting instructions / authentication code checking instructions does not support correction based on a correction value, it may make it difficult to use the authentication code setting instruction as the first instruction in the program code executed after the function call. This negates the benefit of using the combined instructions as both the authentication code setting instruction and the permitted branch target instruction. Therefore, when the combined authentication code setting instruction and branch target instruction are supported, applying a correction based on a correction value to correct the option for generating one of the first modifiers / second modifiers can be particularly useful, as the correction helps maintain the improved code density achievable using the combined authentication code setting instruction and branch target instruction (see the program code example shown later).

[0042] In some examples, in response to an authentication code check instruction, when the generated authentication code is detected to correspond to a reference authentication code, the processing circuitry is configured to trigger a branch to the address specified by the operand of the authentication code check instruction. Similar to the instructions mentioned above for supporting more efficient function entry point combinations, it can also be useful to combine multiple functionalities typically used at the end of a function call (e.g., verifying that the authentication code associated with the function return address is secure, and branching to the function return address if the verification is successful) into a single instruction. However, similarly, in instruction set architectures typically used in conjunction with function calling conventions that impose a constrained availability at the end of a function to maintain uncorrupted registers, it will be difficult to maintain the combined authentication code check instruction and return branch instruction without the ability to apply the corrections mentioned above, as intermediate instructions may be required to restore the contents of the register used to provide the authentication code check operation, ensuring that the register remains uncorrupted at the point where the return branch occurs. However, the correction operation, as discussed above, applied to the generation of either the first or second modifier, can help avoid the intermediate instruction even if the authentication code setting instruction and the authentication code checking instruction are separated by a relatively large distance in the program code. This allows the option of combining the authentication code checking instruction and the return branch instruction to be retained, and can improve the overall program code density.

[0043] Multiple options are available for defining authentication code setting instructions and authentication code checking instructions based on the instruction set architecture supported by the instruction decoding and processing circuitry. Any one or more of these options may be supported. It is possible that the instruction set architecture may support more than one of these options in combination (e.g., by supporting multiple variants of the authentication code setting and / or authentication code checking instructions, distinguished by their opcodes, variant identifier values, and / or modal control bits in registers that control whether a given instance of the authentication code setting and / or authentication code checking instructions behaves as one variant or another).

[0044] In some examples, for at least one variant of the authentication code setting instruction, the first modifier includes a stack pointer, and the second modifier includes a program counter address; and for at least one variant of the authentication code checking instruction, the first modifier includes a stack pointer, and the second modifier includes a result of correcting the program counter address based on the immediate value specified by the authentication code checking instruction. This option provides improved security by reducing the likelihood of generating the same authentication code value for different function instances, compared to implementations that use only one of the first and second modifiers. This option can be useful for function use cases where the function code is short enough that the address offset between the authentication code setting instruction and the authentication code checking instruction is small enough to be referenced within a range that can be accessed using the immediate value of the authentication code checking instruction.

[0045] In some examples, for at least one variant of the authentication code setting instruction, the first modifier includes the stack pointer, and the second modifier includes the program counter address; and for at least one variant of the authentication code checking instruction, the first modifier includes the result of correcting the stack pointer based on a correction value specified by the authentication code checking instruction, and the second modifier includes a value obtained from a general-purpose register. This approach helps to extend the range of address offsets between the addresses of the authentication code setting instruction and the authentication code checking instruction, which can be handled beyond the limits implied by immediate values ​​(because general-purpose registers allow software to set the second modifier used for the authentication code checking instruction to match the second modifier associated with the program counter used for the authentication code setting instruction). Correcting the stack pointer to generate the first modifier for the authentication code checking instruction allows the authentication code setting instruction and the authentication code checking instruction to execute at points in the program flow corresponding to different stack depths, which helps to reduce the number of instructions compared to specific implementations where the authentication code setting instruction and the authentication code checking instruction must execute at the same stack depth to allow their first modifiers to match.

[0046] In some examples, for at least one variant of the authentication code setting instruction, the first modifier includes a stack pointer, and the second modifier includes a result of correcting the program counter address based on a correction value specified by the authentication code setting instruction; and for at least one variant of the authentication code checking instruction, the first modifier includes a stack pointer, and the second modifier includes a result of correcting the program counter address based on an immediate value specified by the authentication code checking instruction. This approach provides additional benefits for improved code density by enabling the use of combined authentication code setting instructions and permitted branch target instructions, even when the setting / checking instructions are separated by relatively large address offsets, and by providing security benefits for just-in-time (JIT) compilers. The fact that both the authentication code setting and checking instructions apply correction to the program counter address to generate the second modifier value means that any intermediate address can be chosen as the second modifier, allowing different instances of the same function to be compiled using different second modifiers. This reduces the risk of an attacker capturing the authentication code generated for an older instance of the same function and reusing that code to circumvent authentication code checks on later instances. The correction value used for the authentication code setting instruction can be specified as an immediate value or using a general-purpose register.

[0047] In some examples, for at least one variant of the authentication code setting instruction, the first modifier includes a stack pointer, and the second modifier includes a value specified in a general-purpose register; and for at least one variant of the authentication code checking instruction, the first modifier includes a stack pointer, and the second modifier includes a result of correcting the program counter address based on the immediate value specified by the authentication code checking instruction. This approach simplifies the operation of the authentication code setting instruction by avoiding the need to apply arithmetic or logical operations to generate the second modifier, since the second modifier can be taken directly from a general-purpose register. However, this approach can still support improved code density when the distance between the authentication code setting instruction and the authentication code checking instruction is relatively large, and the authentication code checking instruction supports a second modifier value that depends on the program counter.

[0048] When an authentication code check performed in response to an authentication code check instruction fails (the generated authentication code does not correspond to a reference authentication code), the error response triggered by the processing circuitry can take various forms. For example, an error response may include signaling a fault, such as causing an exception or interrupt that halts the ongoing processing to switch to an exception handler executing in a higher-privileged execution state. In other examples, the error response may not necessarily interrupt processing immediately, but may include actions that will later lead to execution failure. For example, the error response may corrupt the value of the authentication target value to set it to a value expected to later cause a fault to be detected. For example, the authentication target value may typically be an address (e.g., an address used as a branch target address, which is expected to be subsequently used for fetching instructions, or a data address pointer, which is expected to be subsequently used for generating load / store operations). Therefore, one option is to set the authentication target value to an invalid address (e.g., an address value within an invalid address range that is not allowed for real instruction or data addresses) if the authentication code generated in response to the authentication code check instruction does not match the reference authentication code, such that any subsequent instruction fetch or load / store access based on the invalid address will cause a fault to be detected.

[0049] The code generation function can be a cryptographic function applied to the authentication target value based on a key and a first modifier value and a second modifier value. For example, the cryptographic function can be a cryptographic hash function, a variant of an algorithm such as SHA or QARMA. In some cases, if the authentication target value or either the first or second modifier value comprises fewer bits than the input required by these algorithms, they can be padded with any set of bit values ​​(e.g., all bits set to 0) to provide the required length. In some cases, the first and second modifier values ​​can be concatenated or otherwise combined into a combined modifier value before being input to the code generation function. This allows the application of cryptographic hash functions that could be defined using only a single modifier, but by setting the modifier based on both the first and second modifier values ​​associated with the stack pointer (depending on the program counter used for setting / checking instructions), improved security can be provided for authentication use cases by more strongly binding the generated authentication code to a specific functional instance. The key used for the cryptographic function can be obtained from one or more system registers. In some examples, the key may be updated by the processing circuitry in response to an instruction executed in a specific operating state (e.g., an operating state with higher privileges). In some examples, the instruction set architecture may support key selection from two or more alternative keys (e.g., defined in different control registers), selecting the key based on parameters of the authentication code generation (set / check) instruction and / or other architectural states (such as the current operating state of the processing circuitry or key selection information stored in system registers).

[0050] The techniques discussed above can be implemented within a device having hardware circuitry provided for implementing the instruction decoding and processing circuitry discussed above. However, the same techniques can also be implemented within a computer program that executes on a host data processing unit to provide an instruction execution environment for executing target code. Such a computer program can control the host data processing unit to simulate the architectural environment provided on the hardware device, which actually supports target code according to a specific instruction set architecture, even if the host data processing unit itself does not support that architecture. The computer program may have instruction decoding program logic that, for example, simulates the functionality of the instruction decoding and processing circuitry discussed above by mapping the claimed authentication code generation (setting / checking) instructions of the target code to the corresponding instruction set according to the host instruction set architecture supported by the host data processing unit. Register access specified for authentication code setting / authentication code checking instructions can be simulated by mapping simulated registers of the target instruction set architecture to registers and / or memory provided by the host device. Therefore, when referring to the corresponding software simulation implementation scheme, the reference to registers when discussing the hardware implementation scheme can be understood as referring to the mapping of the program logic registers that simulate the computer program to the simulated registers on the host storage device.

[0051] For example, such emulation programs can be useful when executing legacy code written for one instruction set architecture on a host processor that supports different instruction set architectures. Additionally, emulation can allow software development for a newer version of the instruction set architecture to begin before the processing hardware supporting the new architecture is ready, because execution of the software on the emulation environment allows software testing to be performed in parallel with ongoing development of the hardware that supports the new architecture. The emulation program can be stored on a storage medium, which can be a non-transitory storage medium.

[0052] Refer to the accompanying diagram for specific examples.

[0053] Figure 1An example of a data processing device 2 is schematically illustrated. The data processing device has a processing pipeline 4 (an example of processing circuitry, which may, for example, form part of a CPU (Central Processing Unit)). The processing circuitry 4 is used to execute instructions defined in an instruction set architecture (ISA) to perform data processing operations represented by the instructions. The processing pipeline 4 includes multiple pipeline stages. In this example, the pipeline stages include: a fetch stage 6, which fetches instructions from an instruction cache 8; a decode stage 10 (an example of instruction decoding circuitry), which decodes the fetched program instructions to generate micro-operations (decoded instructions) to be processed by the remaining stages of the pipeline; an issue stage 12, which checks whether the operands required for the micro-operation are available in a register file 14, and issues the micro-operation for execution once the operands required for a given micro-operation are available; an execution stage 16, which executes the data processing operation corresponding to the micro-operation by processing the operands read from the register file 14 to generate a result value; and a write-back stage 18, which writes the result of the processing back to the register file 14. It should be understood that this is merely one example of a possible pipelined architecture, and other systems may have additional stages or different stage configurations. For example, in an out-of-order processor, a register renaming stage may be included to map the architecture registers specified by program instructions or micro-operations to physical register specifiers in the identifier register file 14. In some examples, there may be a one-to-one relationship between program instructions defined in the ISA decoded by the decoding stage 10 and the corresponding micro-operations processed by the execution stage. It is also possible that there is a one-to-many or many-to-one relationship between program instructions and micro-operations, such that, for example, a single program instruction can be split into two or more micro-operations, or two or more program instructions can be merged to be processed as a single micro-operation.

[0054] Execution phase 16 includes multiple processing units for performing different categories of processing operations. For example, the execution units may include: a scalar arithmetic / logic unit (ALU) 20 for performing arithmetic or logical operations on scalar operands read from register 14; a floating-point unit 22 for performing operations on floating-point values; a branching unit 24 for evaluating the results of branching operations and adjusting the program counter representing the current execution point accordingly; and a load / store unit 26 for performing load / store operations to access data in memory systems 8, 30, 32, and 34. Execution phase 16 also includes a code generation unit 27 for generating authentication codes in response to authentication code generation instructions. For example, code generation unit 27 may implement a given cryptographic hash function, such as SHA or QARMA.

[0055] In this example, the memory system includes a tier-one data cache 30, a tier-one instruction cache 8, a shared tier-two cache 32, and main system memory 34. It should be understood that this is merely one example of a possible memory hierarchy, and other cache arrangements are possible (and in some implementations, no such caches 30, 32 may exist at all). The specific type of processing units 20 to 27 shown in execution phase 16 is only one example, and other implementations may have a different set of processing units or may include multiple instances of the same type of processing units, allowing multiple micro-operations of the same type to be processed in parallel. It should be understood that... Figure 1 This is merely a simplified representation of some components of a possible processor pipeline implementation, and the processor may include many other elements not shown for the sake of brevity.

[0056] In some examples, the ISA supported by processing circuitry 4 may be a 32-bit architecture, for which the scalar general-purpose registers are 32-bit registers and the addresses used to identify memory system locations are 32-bit addresses. Register 14 may include a set of general-purpose registers that can be used to provide general-purpose operands for instructions executed by processing circuitry 4. Register 14 may also include system registers for storing control status information.

[0057] For example, the ISA can support sixteen general-purpose registers R0 to R15, of which R13, R14, and R15 are also used as special-purpose registers:

[0058] -R13: SP (Stack Pointer Register), used to store the address of the stack pointer, which points to the location on the stack data structure stored in the memory system.

[0059] -R14: LR (Link Register), used to store the function return address. The function return address is set when the function is called and indicates the address where the program flow should return after the function completes.

[0060] -R15: PC (Program Counter Register), used to store the address of the program counter, which represents the address of the instruction at the current point in the program flow.

[0061] It should be understood that other registers may also be supported.

[0062] Figure 2An example of a program flow involving nested function calls is illustrated. The flow begins at the instruction address "#add1" corresponding to the linked branch instruction BL used to call a given function fnA. The BL instruction is a call branch instruction that, when decoded, causes processing circuitry 4 to write the function return address (the address of the next sequential instruction after BL) into the link register (LR, an alias for R14 as noted above). In this example, the instruction consists of 32 bits, so the address of the next instruction is #add1 + 4 bytes. Therefore, the value of #add1 + 4 is pushed into the link register as the function call address. It should be understood that the spacing between instruction addresses will depend on the number of bits used in the instruction. For example, in an instruction set with 64-bit instruction encoding, the return address could be #add1 + 8 bytes.

[0063] The program flow then continues via fn A, and then encounters another BL instruction at instruction address #add2 for calling another function fn B. Therefore, since the BL instruction at #add2 will overwrite the link register, the software includes at least one store instruction to save the contents of the link register (LR) (i.e., the return address #add1+4 corresponding to fn A) to a software-maintained stack data structure in memory before executing the BL instruction at #add2. In some cases, if the contents of other registers associated with fn A are at risk of being overwritten by fn B, these contents are also stored on the stack before calling fn B. The stack pointer in the SP register (R13) can be used to identify the address in memory where the contents of LR and any other registers will be written. The stack pointer is updated accordingly as data is pushed onto the stack.

[0064] After saving any register contents that need to be preserved for fn A onto the stack, the BL instruction at #add2 is executed. This writes the address of the next sequential instruction (#add2+4) into the link register as the return address of another function and branches the program flow to the target address of the BL instruction, which corresponds to the beginning of function fn B. At the end of fn B, a return branch instruction is encountered. The return branch obtains its target address from the link register, thus guiding the program flow back to #add2+4 when taken. In other words, the code segment in fn A resumes execution from the point after the instruction that called fn B. After returning to fn A, the software code within fn A includes at least one stack pointer-controlled load instruction to pop the previously saved return address (and any other register contents) from the software-maintained stack in memory. When data is popped from the stack, the stack pointer is updated in the opposite direction to the direction in which data was pushed onto the stack (therefore, the stack is managed as a last-in-first-out structure). The return address (#add1+4) popped from the stack is restored to the link register (and the contents of other registers can also be restored based on the information saved to the stack before the call to fn B). At the end of fn A, another return branch instruction is encountered, and this causes a return branch to the target address obtained from LR, that is, the program flow now resumes from #add1+4 (the instruction after the call branch that initially called fn A).

[0065] To ensure that "callee" function code provided by one developer can be invoked by "caller" program code provided by another developer, the ISA supported by processing circuitry 4 can define or be associated with certain function calling conventions. These conventions set agreed-upon rules regarding how general-purpose registers can be used by the callee and call-to-code respectively. This helps the developers of both the caller and callee code understand whether they need to save the contents of certain registers to or restore the contents of certain registers from the stack before or after a function call or function return. For example, general-purpose registers R0 through R3 can be agreed to be used as function arguments or function return values, allowing the caller and callee code to pass values ​​between each other. Registers R4 through R11 can be callee-saved registers, which are required to remain intact at the end of the function, so that when executing a return branch to return to the caller code, the caller code can assume that these callee-saved registers will specify the same register contents as before the corresponding function call. Therefore, if the callee code wants to modify the contents of registers R4 through R11 saved by the callee (potentially due to register pressure), it needs to include stack push instructions to save the caller-defined contents of these registers to the stack before overwriting them, and stack pop instructions to restore the caller-defined contents of these registers from the stack before executing the return branch. On the other hand, register R12 can be a caller-saved register, which is allowed to be corrupted during the function call, meaning the caller code cannot guarantee that R12 will still store the same value specified in register R12 before the function call when returning from the function. Therefore, the callee code implementing the function does not need to include any stack save / restore instructions to protect the contents of register R12, and conversely, if the caller code needs to rely on the value of R12 being saved before the function call, the caller code will need to include stack push instructions before the function call branch BL used to call the function, and stack pop instructions after the corresponding function return. Registers R13 through R15 are reserved for special purposes, serving as LR, SP, and PC as mentioned above.

[0066] Therefore, the function calling convention constrains how registers can be used by software executing on device 2. It should be understood that the specific splitting of registers into caller-stored registers and callee-stored registers is variable, and thus the example above, with R4 through R11 as callee-stored registers and register R12 as caller-stored register, is merely one possible specific implementation.

[0067] It should also be understood that the function calling convention may not necessarily be reflected in any particular circuit of device 2, and may simply be a set of rules to be understood by the software developer when developing software to be executed on device 2. However, once the understood function calling convention is established, the function calling convention commonly used in existing software code may be a constraint to be considered when designing future updates to the ISA supported by processing circuitry 4, as it may be preferable that legacy code written according to the function calling convention continues to function even when new instructions are supported.

[0068] Figure 2 This illustrates how nested function calls can require software to include instructions for saving register contents to / recovering register contents from a stack structure in the memory system. When information is stored in the memory system, it is more vulnerable to attack than when it is stored in register 14 because, depending on the specific system implementation, an attacker may gain physical access to the memory system to tamper with the stored information and / or may be able to compromise program code involving memory usage errors or other security vulnerabilities, resulting in the incorrect overwriting of data stored in the stack structure. Such attacks can pose a risk of program malfunction and loss of data security.

[0069] For example, if a return address pushed from the link register is modified while stored on the stack, when that return address is later loaded back into the link register, the corresponding return branch will branch to the wrong location in memory, resulting in the execution of incorrect instructions. These incorrect instructions could potentially be from "gadget" code provided by an attacker, leading to malicious operations. This is known as a "return-oriented programming" (ROP) attack. Similar attacks can be risky when a data address pointer is stored from a register onto the stack and modified while stored in memory, such that a load / store operation is subsequently performed on the wrong address in memory after the pointer is restored to the register, potentially allowing access to memory locations that should not be accessed.

[0070] Therefore, it can be useful for ISA to provide countermeasures against such attacks. For example... Figure 3 As shown, the instruction decoder 10 and processing circuits 4 and 16 can support an authentication code generation instruction class, which includes at least one variant of an authentication code setting instruction and at least one variant of an authentication code checking instruction. It is also possible that other types of authentication code generation instructions can be supported.

[0071] Generally speaking, each variant of the authentication code generation instruction, when decoded by the instruction decoding circuit 10, controls the processing circuit 4 to generate an authentication code corresponding to the authentication target value obtained from the source register based on the code generation function applied to the authentication target value, the password key, the first modifier value, and the second modifier value.

[0072] If the authentication code generation instruction is an authentication code setting instruction (PAC instruction), the generated authentication code is written to the destination register, which is a general-purpose register separate from the source register used to provide the authentication target value.

[0073] If the authentication code generation instruction is an authentication code check instruction (AUT instruction), the generated authentication code (generated based on the authentication target value obtained from the first source register) is compared with a reference authentication code obtained from a second source register, which is a general-purpose register different from the register providing the authentication target value. If the generated authentication code does not match the reference authentication code, an error response is triggered. For example, processing circuit 4 may trigger an exception or fault condition that could cause processing interruption and branch to the exception handler to handle the cause of the fault.

[0074] In some examples, variants of the PAC / AUT instruction may be provided where the source register used to provide the authentication target value is a fixed register, which is implicitly defined as part of the ISA instruction definition, thus eliminating the need for a register field to identify the source register providing the authentication target value. For example, in one variant, the authentication target value may be implicitly a link register (LR), making the authentication target value, which is protected against tampering using an authentication code, the function return address. At least one variant of the PAC / AUT instruction may also be provided, in which the register field instruction encoding specifies which source register provides the authentication target value. This can be used, for example, in situations where an authentication code will be used to protect a data address pointer.

[0075] Similarly, the destination register for a PAC instruction or the second source register providing the reference authentication code for an AUT instruction can be an implicitly defined, pre-determined general-purpose register that does not require specific register fields in the instruction, or it can be variably selected by software using register fields encoded in the instruction. Given the function calling conventions mentioned above, it can be useful if the register used for the destination register of a PAC instruction or the second source register of an AUT instruction is one of the caller-saved registers (e.g., register R12 in the example above), as this avoids any need to restore the contents of R12 after the AUT instruction is executed. This can facilitate the use of combined branch / AUT instructions, as discussed later. Therefore, in some examples, the destination register for a PAC instruction and the second source register for an AUT instruction can be fixed to register R12 by default.

[0076] The cryptographic key used for the code generation function is obtained from at least one system register, which can be updated by instructions executed in at least one operating state of the processing circuitry (not all operating states allow updates to the cryptographic key; for example, write access to the register storing the key may be restricted to higher-privileged operating states). The cryptographic key can be a value with, for example, more bits than the number of bits in a general-purpose register. For example, the authentication target value, the first modifier value, and the second modifier value can be 32-bit values, but the key can be a longer value, such as 64 bits or 128 bits. In some cases, the cryptographic key can be selected from two or more alternative keys based on the processor's current operating state, information specified in the PAC / AUT instruction itself (e.g., a key selection field or an opcode that distinguishes variants of the PAC / AUT function that will use a different key), and / or the state of other registers stored in register 14.

[0077] The first and second modifier values ​​are used to adjust the cryptographic hash function used as the code generation function to increase the likelihood that different authentication codes can be generated in the code generation function, allowing the authentication code to be specific to a particular instance of the function call, even if the authentication target value and key are the same for two different function call scenarios. This significantly reduces the probability that an attacker could circumvent the authentication code check of the AUT instruction by saving the authentication code generated for one instance of the function call and then reusing that previous authentication code when attempting to seek authentication for a tampered authentication target value in another instance of the function call. The first modifier value used for PAC and AUT instructions depends on the current stack pointer value specified in the stack pointer register SP when executing the PAC / AUT instruction. For at least one of the PAC and AUT instructions (not necessarily both as shown in subsequent examples), the second modifier value depends on the current program counter address value from the PC register. This provides enhanced security by using both stack pointer-related and program counter-related adjustments to the code generation function, because the authentication key is bound to a specific instance of the function at a given address (represented by the program counter address) when called at a given function call depth (represented by the current value of the stack pointer). Given a reasonably secure code generation function (such as SHA or QARMA), this makes it statistically unlikely that an attacker would replace the current authentication key with a previously saved authentication key and use that previously saved authentication key to circumvent authentication key checks.

[0078] The specific way modifier values ​​are used to adjust a cryptographic hash function can vary depending on the specific algorithm used. However, generally speaking, a cryptographic hash function can accept at least one modifier value as input. Therefore, at least one modifier value of the cryptographic hash function can be set based on bits obtained from a first modifier value and a second modifier value. For example, the first and second modifier values ​​can be concatenated to form a modifier for the cryptographic hash function (and, if necessary, the concatenated values ​​can be expanded to the desired bit width, filled with additional bits equal to a given value (such as 0 or 1) or any arbitrary sequence of bits). Alternatively, if the bit width of the combination of the first and second modifier values ​​is greater than the modifier width supported by the cryptographic hash function used, some bits can be omitted, or logical operations such as Boolean functions can be used to combine the bits from the first and second modifier values.

[0079] In the intended use case, at least one instance of the PAC directive will be included in the program code, either at the entry point of the callee function or shortly thereafter (e.g., in...). Figure 2 At or shortly thereafter at the point marked fn A or fn B in the code, and at least one instance of the AUT instruction will be included in the software code at or shortly before the return branch at the end of the callee function (e.g., in...). Figure 2 The return path is either to the return branch of #add2+4 or #add1+4, or just before the return branch. After generating the authentication code in response to the PAC instruction, if it is necessary to free the register for other values, a subsequent stack push instruction can push the generated authentication code onto the stack, and a stack restore instruction can restore the authentication code to the register before executing the corresponding AUT instruction. Although this makes the authentication code itself vulnerable, the cryptographic hash function can be designed so that an attacker can modify the authentication target value (e.g., a function return address or data address pointer) and the corresponding authentication code in a way that makes it sufficiently impossible for both to be matched in the authentication code check, such that the authentication code generated from the tampered authentication target value and the tampered authentication code used as a reference authentication code for the AUT instruction can be matched in the authentication code check.

[0080] Figure 4Another security measure for implementing branch target checking is illustrated. Program code can be written such that branch instructions are expected to branch only to certain specified function entry points. However, an attacker might attempt to compromise the branch target address of a function calling branch BL or other types of branches, causing a non-sequential change in program flow. This results in branches pointing to different addresses that the software developer would not have expected as the target of that branch. An attacker could use this to attempt to circumvent certain protections implemented in the software near the beginning of a function by branching to arbitrary points in the middle of the function. Therefore, it might be desirable to restrict addresses to those to which valid branches are allowed to proceed. Processing circuitry 4 can therefore support the option to enable branch target checking to be performed after a non-sequential change in program flow. Such non-sequential changes in program flow can be caused by explicit branch instructions (e.g., instructions with opcodes indicating the branch type), but can also be triggered by other types of instructions (e.g., arithmetic or load instructions) that are not specifically branch instructions, but whose program counter (PC) register R15 is designated as its destination register for an encoding of a register field such that an update to the PC causes the next instruction to be fetched from an address that is not contiguous with the address of the previously executed instruction (e.g., the address of the next instruction may not be contiguous if the offset relative to the previous address is an amount corresponding to the size of an instruction (e.g., 4)). In some cases, branch target checking can be considered permanently enabled. In other examples, branch target checking may not always be enabled. For example, whether branch target checking is enabled for a given instance of a branch or other non-sequential changes in program flow may depend on the type of instruction executed to cause a non-sequential change in program flow and / or on control state information stored in register 14 (e.g., information defining the current operating state or mode).

[0081] Therefore, as Figure 4As shown, if, at step 50, a non-sequential change in program flow to a given branch target address is detected when branch target checking is enabled, then at step 52, processing circuit 4 determines whether the instruction at the branch target address is a member of the permitted branch target instruction class. The ISA may support at least one branch target instruction that is specified as being permitted as the target of a non-sequential change in program flow when branch target checking is enabled. Other instructions may not be considered members of the permitted branch target instruction class. For example, in some cases, a permitted branch target instruction may be an instruction that has no other architectural function besides marking a valid branch entry point and is architecturally behaved as a No-Operation (NOP) instruction, thus leaving all architectural states unchanged. The permitted class of branch target instructions may also include at least one type of branch target instruction that also has architectural function that causes the processing circuit to perform an associated processing operation. For example, a variant of the PAC instruction indicated as the PACBTI instruction (Pointer Authentication Code / Branch Target Instruction) can not only be used as the previously mentioned PAC instruction but may also be considered a valid branch target when branch target checking is enabled. The ISA may also support at least one non-BTI variant of the PAC instruction that is not used as a branch target instruction in a permitted branch target instruction class. Therefore, if the instruction at the branch target address is a branch target instruction in a permitted branch target instruction class (e.g., PACBTI or another type of permitted branch target instruction), then at step 54, the branch target check is considered to have passed, and no error handling response needs to be triggered. Program flow can continue from the instruction at the branch target address. If the instruction at the branch target address is not a branch target instruction in a permitted class of branch target instructions, then the branch target check is considered to have failed, and an error handling response is triggered (e.g., signaling a failure) to prevent execution from continuing beyond the point where the failed branch target check was detected (because a failed branch target check is an indication that an attack may already exist).

[0082] The use of combined PACBTI instructions (which function as both authentication code generation instructions and effective landing pads, enabling branch target checks after non-sequential changes in program flow) can help reduce the total number of instructions required in program code that uses both authentication code generation instructions and branch target checks.

[0083] Similarly, such as Figure 3As shown by the dashed lines, variants of the AUT instruction (represented as indirect branch AUT instructions or BXAUT instructions) are supported. These variants combine the authentication code check operation described above for the AUT instruction with a branch instruction to the branch target address specified by the operand of the BXAUT instruction. For example, the operand defining the branch target address can be the same as the authentication target value provided for the AUT operation, such that the BXAUT operation both checks whether the return address provided as the authentication target value matches the corresponding reference authentication code provided as the second operand, and triggers a branch to the return address provided as the authentication target value if the authentication code verification is successful. Similarly, the use of combined BXAUT instructions can help improve code density by reducing the number of instructions required to perform both the authentication code check functionality and the branching.

[0084] Therefore, in an example use case, the combined PACBTI and BXAUT instructions can be used in the following sequence of program code:

[0085] Program code example 1

[0086]

[0087] in:

[0088] - Instruction 1 is the PACBTI instruction, which (implicitly or explicitly) specifies the destination register r12 as the destination register to be updated using the generated authentication code based on the authentication target value (the function return address in the link register lr), the key, the first modifier (equal to the stack pointer sp), and the second modifier (equal to the program counter pc).

[0089] Instruction 2 pushes the contents of registers (including the function return address in the link register lr) onto the stack to prevent these registers from being modified within the function body code.

[0090] - Instruction 3 represents the function body code, which may include any arbitrary instructions depending on the purpose of the function.

[0091] - Instruction 4 restores the link register by popping the return address from the stack.

[0092] Instruction 5 is a BXAUT instruction that compares the reference authentication code obtained from the second source register r12 with a generated authentication code based on: the restored return address in the link register lr (the authentication target value in the first source register), the stack pointer as the first modifier value, and the immediate offset (from the mnemonic above). <label>This represents the second modifier value derived from the current program counter value. If the generated authentication code matches the reference authentication code, a branch is triggered based on the function return address in the link register. If the generated authentication code does not match the reference authentication code, an error response is taken.

[0093] If the number of instructions at point 3 in the function code body is small enough, then the number of instructions used to define the BXAUT instruction is... <label>If the immediate value has enough bits such that the second modifier value of the BXAUT instruction matches the program counter value PC from the PACBTI instruction, then Example 1 above is optimal for execution.

[0094] However, as Figure 5 As shown, the immediate value #imm defined in the instruction encoding of a BXAUT instruction can have a limited range because there may only be a limited number of bits available for encoding immediate values ​​in the instruction encoding. In practice, compilation techniques such as loop unrolling (explicitly defining the instruction set multiple times for the corresponding loop iterations of the same high-level program code loop to reduce the overhead of loop control instructions) and function inlining (explicitly inserting the instruction corresponding to the called function into the middle of the corresponding caller sequence, so that the caller-callee-caller sequence is processed using sequential instructions without branching to eliminate the overhead of function calls / returns) mean that the address offset between the PC address of the PACBTI instruction and the PC address of the BXAUT can exceed the range available for referencing using the immediate value of the BXAUT instruction.

[0095] One might argue that the solution to this problem would be to use a general-purpose register in the BXAUT instruction to identify the second modifier value, allowing instructions to be included before execution of the BXAUT instruction to set that register to the value corresponding to the program counter used for the second modifier value in the corresponding PACBTI instruction. However, the problem with this approach is that the function calling convention used may limit the number of registers that can be corrupted at the end of the function code. As noted above, in some cases, only R0 through R3 (which may be needed for function arguments or return values ​​and therefore may not always be available) and R12 (which may already be needed to provide the reference authentication code for the BXAUT instruction) are allowed to remain corrupted when the function return branch is triggered. Therefore, this leaves no spare registers allowed to remain uncorrupted if R0 through R3 are needed for the function return value generated by the function code body to be available to the caller after the return branch.

[0096] Therefore, in the absence of support for variants of the PACBTI / BXAUT instructions discussed further below, this could result in the inability to use combined PACBTI and BXAUT instructions, and software developers / compilers might have to resort to using separate instructions to represent the branch entry point (BTI) and authentication code setting operation (PAC), and separate instructions to represent the authentication code checking operation (AUT) and subsequent return branch (BX). For example, this could lead to the following code implementation:

[0097] Program code example 2

[0098]

[0099]

[0100] in:

[0101] - Instructions 2 through 4 are the same as in Example 1.

[0102] - The previous instruction 1 (PACBTI) has been replaced by 3 instructions:

[0103] ○1a: BTI instruction, which indicates the valid branch entry point.

[0104] ○1b: Store instruction, which preserves the contents of register R2 by saving them onto the stack;

[0105] ○1c: A standalone PAC instruction that performs the PAC operation as described in instruction 1 above, but does not also act as a valid branch target instruction.

[0106] - The previous instruction 5 (BXAUT) has been replaced by 4 instructions:

[0107] ○5a: ADR instruction, which generates an immediate offset <label>The address calculated using the program counter address associated with the ADR instruction is used as the second modifier value to be used in subsequent AUT instructions. Although the ADR instruction is shown as immediately preceding the AUT instruction, it can be moved earlier in the function code if needed to ensure that the address offset between PAC instruction 1c and ADR instruction 5a is within the immediate value of the ADR instruction. <label>Within the specified range. If register R2 will be needed for other purposes between points including ADR instructions and points using register R2 to provide modifiers for AUT instructions, this may require additional instructions for saving / restoring the generated address values.

[0108] ○5b: AUT instruction, which performs an authentication code check as in the BXAUT instruction above, but does not trigger a branch if the check is successful.

[0109] ○5c: LDR instruction, which is used to restore the contents of register R2 from the stack (previously saved by the store instruction STR at 1b).

[0110] ○5d: BX instruction, which triggers a return branch to the return address in the link register LR, which was previously verified using the AUT instruction at 5b.

[0111] Therefore, in this case, the PAC / AUT instructions are separated by an immediate value greater than the value obtained from the immediate value. <label>The maximum range of supported use cases, as well as those where there is no spare register to be corrupted at the end of the function, require five additional instructions per function call because, in this example, the two instructions 1 and 5 in the previous example have been replaced by seven instructions 1a to 1c and 5a to 5d (at least as noted above, depending on the location of the inserted ADR instruction 5a, additional instructions may be needed to push / pop register R2 onto the stack to preserve the generated second modifier value for later use by the AUT instruction).

[0112] Figure 6 Examples of coding options that enable the solution to this problem are shown. Figure 6 This illustrates the functionality of an authentication code generation instruction, which can be an authentication code setting instruction (PAC or PACBTI) or an authentication code checking instruction (AUT or BXAUT). For example, in... Figure 3 In this process, the generated authentication code is generated by applying a code generation function to the authentication target value, key, first modifier value, and second modifier value obtained from the source register. Similarly, the first modifier value depends on the current stack pointer value in the SP register, and the second modifier value used for at least one of the PAC[BTI] and [BX]AUT instructions depends on the current program counter address in the PC register (here, the symbol PAC[BTI] refers to the PAC instruction, which may optionally also act as a branch target instruction, and the symbol [BX]AUT refers to the AUT instruction, which may optionally also act as an indirect branch instruction; i.e., PAC[BTI] is an abbreviation for PAC or PACBTI, and [BX]AUT is an abbreviation for AUT or BXAUT). However, in Figure 6 In the example, for one of the PAC / AUT directives, one of the first modifier value and the second modifier value is corrected by applying a correction based on the correction value specified by that one of the PAC / AUT directives. This correction can be based on the correction value specified by the PAC / AUT directive. Figure 5 The [BX]AUT instruction discussed here is an alternative or supplement to the adjustment of the program counter by the immediate value #imm. In general, it is a correction applied such that the first and second modifiers are equal for corresponding instances of the PAC[BTI] and [BX]AUT instructions, even when the PAC[BTI] and [BX]AUT instructions are separated by address offsets larger than the address offsets referenced by a single immediate value in the [BX]AUT instruction. The correction can be applied arithmetically (e.g., by adding the correction value to one of the corrected stack pointer (SP) and program counter (PC), or subtracting the correction value from one of the corrected SP and PC), or logically, for example, by using the correction value as a bitmask indicating the bits of the SP / PC to be masked, or by otherwise combining the correction value with the SP or PC according to a Boolean function or a combination of one or more Boolean functions.

[0113] Figures 7 to 9 Several alternative variants of the authentication code setting instruction (PAC or PACBTI) and authentication code checking instruction (AUT or BXAUT) are shown, which can be supported to achieve improved code density for specific implementations addressing the issues of limited immediate value range and constrained register availability discussed above. In each of these examples, the functionality of the PAC[BTI] and [BX]AUT instructions is the same as previously discussed, except for the manner in which the first and second modifier values ​​are generated based on the instruction operands.

[0114] Figure 7 A variant of the PAC[BTI] instruction is shown where SP is used as the first modifier value and PC is used as the second modifier value (without correction in either case). In this example, the [BX]AUT instruction uses an immediate value to specify the correction value and applies correction based on the correction value to the stack pointer to generate the first modifier value. The second modifier value used for the [BX]AUT instruction is a value obtained from a general-purpose register, which can be a fixed general-purpose register (e.g., register R2 as defined by the ISA) or a variablely defined register selected based on the register fields of the [BX]AUT instruction. In code example 3 below, the general-purpose register is R2. Therefore, for the [BX]AUT instruction, the operation corresponding to the [BX]AUT instruction does not require the second modifier value to be program counter-dependent (there is nothing in the hardware circuitry that will do anything to ensure, for the [BX]AUT instruction, that the value in the referenced general-purpose register has been previously set based on the program counter value). Although in the intended software use case, it is expected that the developer or compiler will have one or more other instructions preceding the [BX]AUT instruction that correspond the value in the general-purpose register to the PC value used as the second modifier value by the previous PAC[BTI] instruction, this is not enforced in the hardware.

[0115] Perhaps counterintuitively, when supporting general-purpose registers for the second modifier in the [BX]AUT instruction, correction of the stack pointer would help address the limited range of immediate values ​​used to represent the offset between the PAC[BTI] instruction and the lack of available registers around the AUT instruction.

[0116] However, as indicated in Example 3 below, by correcting the SP of the AUT instruction, the PAC[BTI] instruction and the [BX]AUT instruction can be executed at different stack depths, thereby eliminating the need to execute the stack push instruction (STR instruction 1b from Example 2) before the PAC instruction, and thus enabling the use of combined PACBTI instructions to improve program code density:

[0117] Program code example 3

[0118]

[0119] In this example, instructions 1, 2, 3, and 4 are the same as in Example 1, and instructions 5a through 5d are the same as in Example 2. Instruction 1b, which is needed before PAC instruction 1c to preserve the contents of register R2 in Example 2, can be moved down to execute after the PAC instruction because the AUT instruction at 5b no longer needs to be executed at the same stack depth (with the same current value of the stack pointer SP) as the PACBTI instruction at 1. By moving instruction 1b after the PAC instruction at 1, the branch entry point and the PAC instruction no longer need to be different instructions, and therefore a combined PACBTI instruction can be used, thereby improving program code density.

[0120] Therefore, ISA support for the AUT instruction that applies correction to the stack pointer to generate the first modifier value helps improve code density relative to Example 2, as a total of one instruction is eliminated (excluding the instruction in the function loop body at 3, which would be the same in both cases; the number of function call / return wrapper instructions is 9 in Example 2 and 8 in Example 3). While saving one instruction may not seem like much, the frequency of function call / return events is so high that this equates to significant savings in memory storage overhead, instruction fetch / decode events, and micro-operations performed across the entire software workload, and thus this helps save power and improve processor performance.

[0121] Figure 8 Another example of variants of the PAC[BTI] and [BX]AUT instructions that can be used is shown. These variants also utilize correction values ​​to apply corrections to address the issues of limited immediate value ranges and limited register availability, as discussed above. In this example, corrections are applied when generating the second modifier value for both the PAC[BTI] and [BX]AUT instructions. For both the PAC[BTI] and [BX]AUT instructions, the first modifier value is the current stack pointer from the SP register, and no correction is applied.

[0122] For the PAC[BTI] instruction, the second modifier value is program counter-related and is obtained by applying a correction to the program counter address in the PC register based on a correction value specified using an immediate value or using a general-purpose register (again, the general-purpose register can be fixed or can be variably selected according to the register field of the PAC[BTI] instruction).

[0123] For the [BX]AUT instruction, the second modifier value is program counter-dependent and is obtained by applying a correction to the current program counter address specified by the PC register for the point in the program flow corresponding to the [BX]AUT instruction, based on a correction value designated as an immediate value.

[0124] Therefore, in Figure 8 In the example, both the PAC[BTI] and [BX]AUT instructions apply corrections to their respective PC values ​​to obtain the corresponding second modifier values.

[0125] As shown in code example 4 below, this achieves a further increase in code density, allowing the number of function call / return wrapper instructions to return to the number shown in Example 1, even when the PACBTI and BXAUT instructions are separated by too large a range to be referenced using only the immediate value of the BXAUT instruction. This is useful because by designing PACBTI and BXAUT in the ISA so that both apply a correction to the PC, the value used as the second modifier becomes an intermediate address in the middle of the function call, rather than being forced to be the PC value corresponding to the PACBTI instruction:

[0126] Program code example 4 :

[0127]

[0128]

[0129] (Here, instructions 3a and 3b are the same as function body 3 in the previous example. The number of instructions in the function body has not increased, but the function body is split to indicate that the address referenced by the corresponding correction applied to the PC by the PACBTI instruction and the BXAUT instruction is an intermediate address in the middle of the function code.)

[0130] Besides increasing the maximum range at which PACBTI and BXAUT instructions can be separated, this method of defining instructions supported by the ISA also has safety benefits for use cases where function code is compiled via Just-In-Time (JIT) compilation. This allows instructions defined by the ISA to be compiled just-in-time based on high-level program code during program execution, rather than being pre-compiled statically and then stored as assembly code for later execution. With JIT compilation, there is flexibility to compile the same high-level function into different sequences of assembly code for different instances calling the same function. When using... Figure 8 The method shown, using correction at both the PACBTI and BXAUT instructions, implies flexibility in adjusting which address is referenced as an "intermediate" address from one instance of the compiled function to another (the compiler can change the PACBTI...).<correction factor> The immediate value of the BXAUT instruction changes which intermediate address is used as the second modifier. This means that even when the same function is called at the same stack depth, different authentication code values ​​can be generated for different instances of the function because the second modifier is different for each instance, thus providing further protection against attackers attempting to reuse old authentication code values ​​in later function calls.

[0131] Figure 9 Another example is shown, where the [BX]AUT instruction is... Figure 8 The same applies to the PAC[BTI] instruction, but instead of applying correction to the PC to generate a second modifier value, the second modifier value for the PAC[BTI] instruction is specified in a general-purpose register. As shown in Example 5 below, although this may require several additional instructions compared to Example 4, it still reduces the total number of instructions compared to Example 2, while supporting the increased address range between PACBTI and BXAUT instructions.

[0132] Program code example 5 :

[0133]

[0134]

[0135] In this example, instructions 2 through 5 are the same as in Example 4, but the PACBTI instruction 1 in Example 4 is replaced with separate BTI instructions 1a and PAC instructions 1c as in Example 2, with an address generation instruction ADR 1b' in between. This ADR instruction places a value in general-purpose register r12 to be used as a second modifier value for the PAC instruction. This value is derived by applying a correction factor to the PC to generate a value corresponding to the intermediate address to be placed in general-purpose register r12, referenced by the BXAUT instruction. While this option slightly increases code density relative to Example 4, it simplifies hardware implementation by simplifying PAC operations and helps support other use cases where the ability to support arbitrary modifier values ​​using general-purpose registers can be helpful.

[0136] Therefore, to summarize, the above discussion covered various examples, among which the different options for defining the first and second modifier values ​​for the PAC[BTI] and [BX]AUT instructions are as follows:

[0137]

[0138] The concepts described herein may be embodied in computer-readable code used to manufacture devices embodying the described concepts. For example, the computer-readable code may be used in one or more stages of the semiconductor design and manufacturing process, including the electronic design automation (EDA) stage, to manufacture integrated circuits including devices embodying these concepts. The aforementioned computer-readable code may additionally or alternatively enable the definition, modeling, simulation, verification, and / or testing of devices embodying the concepts described herein.

[0139] For example, computer-readable code for manufacturing a device embodying the concepts described herein may be embodied in code that defines the hardware description language (HDL) representation of these concepts. For instance, the code may define a register-transfer level (RTL) abstraction of one or more logic circuits for defining a device embodying these concepts. The code may define an HDL representation of one or more logic circuits embodying the device using Verilog, SystemVerilog, Chisel, or VHDL (Very High Speed ​​Integrated Circuit Hardware Description Language) and intermediate representations such as FIRRTL. Computer-readable code may provide definitions of the concepts or other behavioral representations of the concepts embodying the concepts using system-level modeling languages ​​such as SystemC and SystemVerilog, which can be interpreted by a computer to enable simulation, functional and / or formal verification and testing of the concepts.

[0140] Additionally or alternatively, computer-readable code may define a low-level description of an integrated circuit component embodying the concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. One or more netlists or other computer-readable representations of the integrated circuit component may be generated by applying one or more logic synthesis processes to the RTL representation to generate a definition for manufacturing a device embodying the invention. Alternatively or additionally, one or more logic synthesis processes may generate a bitstream from the computer-readable code to be loaded into a field-programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purpose of verifying and testing the concepts prior to manufacturing integrated circuits, or the FPGA may be deployed directly in a product.

[0141] Computer-readable code may include a mixture of code representations for manufacturing apparatus, such as one or more of RTL representations, netlist representations, or other computer-readable definitions used in the semiconductor design and manufacturing process for manufacturing apparatus embodying the present invention. Alternatively or additionally, the concept may be defined in a combination of computer-readable definitions used in the semiconductor design and manufacturing process for manufacturing apparatus and computer-readable code defining instructions that will be executed by the defined apparatus once manufactured.

[0142] Such computer-readable code can be contained in any known transient computer-readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductors, magnetic disks, or optical disks. Integrated circuits made using computer-readable code may include components such as one or more of the following: a central processing unit, a graphics processing unit, a neural processing unit, a digital signal processor, or other components that embody the concept independently or collectively.

[0143] Figure 10 Examples of emulator implementations that can be used are illustrated. While the previously described embodiments implement the invention in terms of means and methods for operating specific processing hardware supporting the technologies involved, it is also possible to provide an instruction execution environment according to the embodiments described herein, which is implemented using a computer program. Such computer programs are generally referred to as emulators, in part because they provide a software-based implementation of a hardware architecture. Types of emulator computer programs include simulators, virtual machines, models, and binary converters, including dynamic binary converters. Typically, the emulator implementation can run on a host processor 730, which optionally runs a host operating system 720, thereby supporting the emulator program 710. In some arrangements, multiple emulation layers may exist between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors were required to provide emulator implementations that execute at a reasonable speed, but such approaches may be reasonable in certain situations, such as when it is desirable to run code native to another processor for compatibility or reuse reasons. For example, the emulator implementation may provide additional functionality to the instruction execution environment that is not supported by the host processor hardware, or provide an instruction execution environment that is typically associated with a different hardware architecture. An overview of the simulation is given in the following literature: "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0144] With respect to embodiments previously described with reference to specific hardware constructions or features, equivalent functionality may be provided in simulated embodiments by suitable software constructions or features. For example, specific circuitry may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware such as registers or cache memory may be implemented as software data structures in simulated embodiments. Where one or more of the hardware elements referenced in the previously described embodiments are present in an arrangement on host hardware (e.g., host processor 730), some simulated embodiments may utilize the host hardware where appropriate.

[0145] The simulator program 710 can be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code 700 (which may include applications, operating systems, and management programs), the same as the interface of the hardware architecture modeled by the simulator program 710. Therefore, the program instructions of the target code 700 described above (including the previously described authentication code generation instructions) can be executed from within the instruction execution environment using the simulator program 710, enabling a host computer 730, which does not actually possess the hardware features of the device 2 discussed above, to emulate these features.

[0146] The emulator 710 may include instruction decoding logic 712 for decoding the instructions of the target code 700 to map them to corresponding instruction sequences defined according to the native instruction set architecture supported by the host hardware 730. Therefore, the instruction decoding logic 712 may include logic for generating host instruction sequences corresponding to the previously described PAC / AUT instructions. The register emulation logic 714 of the emulator 710 may simulate access to registers by the target code 700, for example, by maintaining a data structure in the registers or memory of the host hardware 730 that simulates the set of architecture registers 14 expected to be provided in the ISA associated with the target code 700. For example, register references to the operands and results of the previously mentioned PAC / AUT instructions may be remapped by the register emulation logic 714 to access requests referencing specific locations in host storage provided by the host hardware 730.

[0147] In this application, the phrase "configured as..." is used to mean that the elements of the device have a configuration capable of performing the defined operation. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, the device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured as" does not imply that the elements of the device need to be changed in any way to provide the defined operation.

[0148] In this application, a list of features beginning with the phrase "at least one of" means that any one or more of those features can be provided independently or in combination. For example, "at least one of [A], [B], and [C]" covers any of the following options: A only (without B or C), B only (without A or C), C only (without A or B), a combination of A and B (without C), a combination of A and C (without B), a combination of B and C (without A), or a combination of A, B, and C.

[0149] While exemplary embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise embodiments, and various changes and modifications can be made therein by those skilled in the art without departing from the scope of the invention as defined in the appended claims.< / label> < / label> < / label> < / label> < / label>

Claims

1. An apparatus, the apparatus comprising: An instruction decoding circuit, wherein the instruction decoding circuit is used to decode instructions; and Processing circuitry, the processing circuitry being configured to perform processing operations in response to a decoded instruction decoded by the instruction decoding circuitry; wherein: In response to an authentication code generation instruction, the processing circuit is configured to generate an authentication code associated with the authentication target value by applying a code generation function to the authentication target value, the key, the first modifier value, and the second modifier value; The authentication code generation instructions include: An authentication code setting instruction is provided, wherein the processing circuitry is configured to write the generated authentication code into a destination register separate from the register that provides the authentication target value for the authentication code setting instruction; and An authentication code check instruction is provided, wherein the processing circuitry is configured to check whether the authentication code generated based on the authentication target value in response to the authentication code check instruction corresponds to a reference authentication code obtained from a source register separate from the register that provides the authentication target value for the authentication code check instruction, and to trigger an error response when the generated authentication code does not correspond to the reference authentication code. in: The first modifier value includes a value that depends on the stack pointer obtained from the stack pointer register; and For at least one of the authentication code setting instruction and the authentication code checking instruction, the second modifier value includes a value that depends on the program counter address obtained from the program counter register.

2. The apparatus of claim 1, wherein the authentication code check instruction specifies an immediate value, and one of the first modifier value and the second modifier value used for the authentication code setting instruction depends on the immediate value applied as an adjustment to the stack pointer or the program counter address.

3. The apparatus according to any one of claims 1 and 2, wherein one of the authentication code setting instruction and the authentication code checking instruction specifies the application of a correction to one of the stack pointer and the program counter address to generate a correction value for a corresponding one of the first modifier and the second modifier.

4. The apparatus of claim 3, wherein the correction based on the correction value enables the authentication code setting instruction and the authentication code checking instruction to be separated by an instruction address offset greater than the maximum instruction address offset that can be represented by the immediate value of the authentication code checking instruction.

5. The apparatus according to any one of claims 3 and 4, wherein the authentication code check instruction specifies the correction value as a correction to be applied to the stack pointer to generate the first modifier value for the authentication code check instruction.

6. The apparatus according to any one of claims 3 to 5, wherein the authentication code setting instruction specifies the correction value as a correction to be applied to the program counter address to generate the second modifier value for the authentication code setting instruction.

7. The apparatus of claim 6, wherein the authentication code check instruction further specifies an immediate value to be applied to the program counter address to generate a correction for the second modifier value of the authentication code check instruction.

8. The apparatus according to any one of claims 3 to 7, wherein the correction value is specified as an immediate value by one of the authentication code setting instruction and the authentication code checking instruction.

9. The apparatus according to any one of claims 3 to 7, wherein the correction value is specified as a value obtained from a general-purpose register.

10. The apparatus of claim 9, wherein one of the authentication code setting instruction and the authentication code checking instruction specifies an identifier that provides the correction value in the register field of the general-purpose register.

11. The apparatus according to any one of claims 3 to 10, wherein the correction comprises an arithmetic correction for adding or subtracting the correction value from one of the stack pointer and the program counter address.

12. The apparatus of any one of claims 3 to 10, wherein the correction includes a logical correction for generating a corrected value based on a logical combination of the stack pointer and the program counter address with the correction value.

13. The apparatus according to any of the preceding claims, wherein: In response to a non-sequential change in program flow to a branch target address triggered when branch target checking is enabled, the processing circuitry is configured to trigger an error handling response when the instruction at the branch target address is not a member of a permitted branch target instruction class; and The authentication code setting instruction is a branch target instruction in the permitted branch target instruction class.

14. The apparatus according to any of the preceding claims, wherein: In response to the authentication code check instruction, when the generated authentication code is detected to correspond to the reference authentication code, the processing circuit is configured to trigger a branch to the address specified by the operand of the authentication code check instruction.

15. The apparatus according to any of the preceding claims, wherein: For at least one variant of the authentication code setting instruction, the first modifier includes the stack pointer, and the second modifier includes the program counter address; and For at least one variant of the authentication code check instruction, the first modifier includes the stack pointer, and the second modifier includes a result of correcting the program counter address based on an immediate value specified by the authentication code check instruction.

16. The apparatus according to any of the preceding claims, wherein: For at least one variant of the authentication code setting instruction, the first modifier includes the stack pointer, and the second modifier includes the program counter address; and For at least one variant of the authentication code check instruction, the first modifier includes the result of correcting the stack pointer based on a correction value specified by the authentication code check instruction, and the second modifier includes a value obtained from a general-purpose register.

17. The apparatus according to any of the preceding claims, wherein: For at least one variant of the authentication code setting instruction, the first modifier includes the stack pointer, and the second modifier includes a result of correcting the program counter address based on a correction value specified by the authentication code setting instruction; and For at least one variant of the authentication code check instruction, the first modifier includes the stack pointer, and the second modifier includes a result of correcting the program counter address based on an immediate value specified by the authentication code check instruction.

18. The apparatus of claim 17, wherein the correction value is specified as an immediate value by the authentication code setting instruction.

19. The apparatus of claim 17, wherein the correction value for the authentication code setting instruction is specified in a general-purpose register.

20. The apparatus according to any of the preceding claims, wherein: For at least one variant of the authentication code setting instruction, the first modifier includes the stack pointer, and the second modifier includes a value specified in a general-purpose register; and For at least one variant of the authentication code check instruction, the first modifier includes the stack pointer, and the second modifier includes a result of correcting the program counter address based on an immediate value specified by the authentication code check instruction.

21. A computer-readable code for manufacturing an apparatus according to any of the preceding claims.

22. A method, the method comprising: Perform processing operations in response to decoded instructions; wherein: In response to the decoded instruction being an authentication code generation instruction, the processing operation includes generating an authentication code associated with the authentication target value by applying a code generation function to the authentication target value, the key, the first modifier value, and the second modifier value; In response to the decoded instruction being an authentication code setting instruction within the authentication code generation class of instructions, the processing operation includes writing the generated authentication code to a destination register separate from the register that provides the authentication target value for the authentication code setting instruction; and In response to the decoded instruction being an authentication code check instruction in the authentication code generation class instruction, the processing operation includes checking whether the authentication code generated based on the authentication target value in response to the authentication code check instruction corresponds to a reference authentication code obtained from a source register separate from the register that provides the authentication target value for the authentication code check instruction, and triggering an error response when the generated authentication code does not correspond to the reference authentication code; in: The first modifier value includes a value that depends on the stack pointer obtained from the stack pointer register; and For at least one of the authentication code setting instruction and the authentication code checking instruction, the second modifier value includes a value that depends on the program counter address obtained from the program counter register.

23. A computer program for controlling a host data processing device to provide an instruction execution environment for executing target program code, the computer program comprising: The instruction decoding program logic is used to decode the instructions of the target program code and control the host data processing device to perform processing operations in response to the decoded instructions; wherein: In response to an authentication code generation instruction, the instruction decoding program logic is configured to control the host data processing device to generate an authentication code associated with the authentication target value by applying a code generation function to the authentication target value, the key, the first modifier value, and the second modifier value; The authentication code generation instructions include: An authentication code setting instruction, wherein the instruction decoding program logic is configured to control the host data processing device to write the generated authentication code into a separate analog destination register from the analog register that provides the authentication target value for the authentication code setting instruction; and An authentication code check instruction, wherein the instruction decoding program logic is configured to control the host data processing device to check whether the authentication code generated based on the authentication target value in response to the authentication code check instruction corresponds to a reference authentication code obtained from a separate analog source register from the analog register that provides the authentication target value for the authentication code check instruction, and to trigger an error response when the generated authentication code does not correspond to the reference authentication code; in: The first modifier value includes a value that depends on the stack pointer obtained from the simulated stack pointer register; and For at least one of the authentication code setting instruction and the authentication code checking instruction, the second modifier value includes a value that depends on the program counter address obtained from the simulated program counter register.

24. A storage medium storing computer-readable code according to claim 21 or a computer program according to claim 23.

Images