Authentication code generation instruction

Abstract

An apparatus, a method, and a computer program are provided. The apparatus includes instruction decoding circuitry for decoding instructions and processing circuitry for performing processing operations in response to the decoded instructions. In response to an authentication code generation instruction, the processing circuitry is configured to generate an authentication code associated with an authentication target value. For at least one type of authentication code generation instruction, the processing circuitry is configured, when operating in a first code generation mode, to generate the authentication code by applying a code generation function to: a key; the authentication target value; a first modifier depending on the stack pointer, and / or a second modifier depending on the program counter address; and an additional modifier depending on an additional value obtained from a register visible on a different architecture than the stack pointer register and the program counter register.

Description

[0001] This technology relates to the field of data processing. Furthermore, this invention relates to an apparatus, a method, and a computer program.

[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] According to some configurations, an apparatus is provided, the apparatus comprising:

[0004] Instruction decoding circuit, which is used to decode instructions; and

[0005] Processing circuitry, which performs processing operations in response to decoded instructions decoded by the instruction decoding circuitry.

[0006] in:

[0007] In response to a type of authentication code generation instruction, the processing circuit is configured to generate an authentication code associated with the authentication target value;

[0008] This type of authentication code generation instruction includes:

[0009] An authentication code setting instruction is provided, for which the processing circuitry is configured to write at least a portion of the generated authentication code into a destination register; and

[0010] An authentication code verification instruction is provided. For this instruction, the processing circuit is configured to verify whether at least a portion of the authentication code generated based on the authentication target value in response to the instruction corresponds to at least a portion of a reference authentication code obtained from the source register, and to indicate verification failure when the generated authentication code does not correspond to the reference authentication code.

[0011] For at least one of the authentication code setting instruction and the authentication code verification instruction, the processing circuit is configured to generate an authentication code by applying a code generation function to the following when operating in the first code generation mode:

[0012] Key;

[0013] Authentication target value;

[0014] At least one of a first modifier and a second modifier, wherein the first modifier depends on the stack pointer obtained from the stack pointer register, and the second modifier depends on the program counter address obtained from the program counter register; and

[0015] The additional modifier depends on a different value obtained from a register visible on a different architecture than the stack pointer register and the program counter register.

[0016] Based on certain configurations, a method is provided that includes:

[0017] The instruction is decoded using an instruction decoding circuit.

[0018] The processing circuitry performs processing operations in response to the decoded instructions decoded by the instruction decoding circuitry.

[0019] Using this processing circuit, in response to a type of authentication code generation instruction, an authentication code associated with the authentication target value is generated;

[0020] This type of authentication code generation instruction includes:

[0021] An authentication code setting instruction is given, and for this instruction, the processing circuit writes at least a portion of the generated authentication code into the destination register; and

[0022] An authentication code verification instruction is provided. For this instruction, the processing logic verifies whether at least a portion of the authentication code generated based on the authentication target value in response to the instruction corresponds to at least a portion of a reference authentication code obtained from the source register, and indicates verification failure when the generated authentication code does not correspond to the reference authentication code; and

[0023] Using processing circuitry, for at least one of the authentication code setting instruction and the authentication code verification instruction, when operating in the first code generation mode, the authentication code is generated by applying a code generation function to the following:

[0024] Authentication target value;

[0025] Key;

[0026] At least one of a first modifier and a second modifier, wherein the first modifier depends on the stack pointer obtained from the stack pointer register, and the second modifier depends on the program counter address obtained from the program counter register; and

[0027] The additional modifier depends on a different value obtained from a register visible on a different architecture than the stack pointer register and the program counter register.

[0028] According to some configuration, a computer program is provided for controlling a host data processing device to provide an instruction execution environment, the computer program comprising:

[0029] Instruction decoding program logic, which is used to decode instructions; and

[0030] The processing logic is used to perform processing operations in response to a decoded instruction decoded by the instruction decoding logic.

[0031] in:

[0032] In response to a type of authentication code generation instruction, the processing logic is configured to generate an authentication code associated with the authentication target value;

[0033] This type of authentication code generation instruction includes:

[0034] An authentication code setting instruction is provided, and the processing logic is configured to write at least a portion of the generated authentication code into the destination data structure; and

[0035] An authentication code verification instruction is provided. For this instruction, the processing logic is configured to verify whether at least a portion of the authentication code generated in response to the authentication target value corresponds to at least a portion of a reference authentication code obtained from the source data structure, and to indicate verification failure when the generated authentication code does not correspond to the reference authentication code.

[0036] For at least one of the authentication code setting instruction and the authentication code verification instruction, the handler logic is configured to generate an authentication code by applying a code generation function to the following when operating in the first code generation mode:

[0037] Key;

[0038] Authentication target value;

[0039] At least one of a first modifier and a second modifier, wherein the first modifier depends on the stack pointer obtained from the stack pointer data structure, and the second modifier depends on the program counter address obtained from the program counter data structure; and

[0040] The additional modifier depends on a different value obtained from a data structure visible on a different architecture than the stack pointer data structure and the program counter data structure.

[0041] In some configurations, the computer program is stored on a computer-readable storage medium.

[0042] In some configurations, the computer-readable storage medium is a non-transitory computer-readable storage medium.

[0043] The present invention will be further described by way of example only, with reference to the configuration of the invention illustrated in the accompanying drawings, wherein:

[0044] Figure 1The apparatus is illustrated schematically with some configurations according to the present technology;

[0045] Figure 2 The sequence of branches that can occur in some example use cases of this technology is illustrated schematically;

[0046] Figure 3 The following are schematic examples of authentication code setting instructions according to some configurations of this technology;

[0047] Figure 4 The following are schematic examples of authentication code verification instructions configured according to this technology;

[0048] Figure 5 The apparatus is illustrated schematically with some configurations according to the present technology;

[0049] Figure 6 The apparatus is illustrated schematically with some configurations according to the present technology;

[0050] Figure 7 The apparatus is illustrated schematically with some configurations according to the present technology;

[0051] Figure 8 The generation of selection data according to some configurations based on this technology is illustrated schematically;

[0052] Figure 9 The storage of selection data according to some configurations of this technology is illustrated schematically;

[0053] Figure 10 The sequence of steps performed according to some configurations of this technology is illustrated schematically;

[0054] Figure 11 The sequence of steps performed according to some configurations of this technology is illustrated schematically;

[0055] Figure 12 The sequence of steps performed according to some configurations of this technology is illustrated schematically; and

[0056] Figure 13 The illustrative examples illustrate specific implementations of simulators with some configurations according to this technology.

[0057] Some configurations of this technology provide an apparatus including: 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. In response to a type of authentication code generation instruction, the processing circuit is configured to generate an authentication code associated with an authentication target value. The type of authentication code generation instruction includes: an authentication code setting instruction, for which the processing circuit is configured to write at least a portion of the generated authentication code into a destination register; and an authentication code verification instruction, for which the processing circuit is configured to verify whether at least a portion of the authentication code generated based on the authentication target value in response to the authentication code verification instruction corresponds to at least a portion of a reference authentication code obtained from a source register, and to indicate verification failure when the generated authentication code does not correspond to the reference authentication code. For at least one of the authentication code setting instruction and the authentication code verification instruction, the processing circuitry is configured, when operating in the first code generation mode, to generate an authentication code by applying a code generation function to: a key; an authentication target value; at least one of a first modifier and a second modifier, the first modifier depending on a stack pointer obtained from a stack pointer register, the second modifier depending on a program counter address obtained from a program counter register; and an additional modifier depending on an additional value obtained from a register visible on a different architecture than the stack pointer register and the program counter register.

[0058] The device (e.g., a data processing device) includes decoder circuitry that is integrated with processing circuitry and used to control the processing circuitry to perform processing operations. The decoder circuitry responds to instructions included in an instruction set architecture (ISA). An ISA defines a set of instructions that can be used by a programmer or compiler to control the processing circuitry. The instructions included in an ISA are carefully selected, and these instructions are subject to the limitations of the coding space provided for the instructions. Typically, including new instructions results in the removal of existing instructions, and therefore, ISA designers may need sufficient motivation to incorporate new instructions into the ISA.

[0059] A device implementing a given ISA has the freedom to choose the precise circuit arrangement provided for each instruction in the ISA, and the way the instructions of the ISA are implemented can vary from system to system. In other words, an ISA defines the function that a device should perform in response to a given instruction, but gives designers the freedom to implement the instructions in any way and according to the specific design constraints associated with the device. Providing carefully selected instructions as part of an ISA offers advantages in terms of improved code density for workloads utilizing instructions, which in turn improves overall system efficiency.

[0060] One type of authentication code generation instruction can be used to protect target values ​​(e.g., addresses or other data values) stored in memory. When a target value is stored in memory, authentication code setting instructions can be used to generate an authentication code associated with the target value. In some architectures, the authentication code can be stored together with the target value in a destination register. In other words, the destination register can be a register that stores the authenticated target value, wherein at least a portion of the authentication code is written to bits of the destination register that are not used by the authenticated target value; for example, in a 64-bit architecture, the authentication code can be stored in redundant bits of the address that are used as the authenticated target value. Alternatively, the authentication code, or at least a portion thereof, can be stored separately from the address value, wherein additional metadata is generated to define the association between the authentication code and the target value.

[0061] Regardless of the mechanism used to store the authentication code, once the target value is retrieved from memory, it can be compared with the authentication code. If the authentication code or the target value has been tampered with (or otherwise modified), the authentication code verification instruction will indicate that the authentication code and the target value do not match and will indicate that the verification has failed. Because the code generation function, key, and modifiers are unknown, it is difficult for an attacker to simultaneously modify the authentication code and the target value to deceive the authentication code verification instruction. The indication of verification failure may involve triggering an error response. Alternatively, the indication may involve writing an erroneous value instead of the authentication target value, for example, where the target value is the address to which a bad address is written instead of the authentication target value.

[0062] A class of authentication code generation instructions can operate in at least a first code generation mode. In some configurations, the first code generation mode is the only code generation mode in which the instructions can operate. However, and as will be discussed in further detail below, in some configurations, the first code generation mode is one of a plurality of code generation modes in which a class of authentication code generation instructions can operate.

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

[0064] The first modifier value depends on the stack pointer obtained from the stack pointer register. By using a stack pointer-dependent value as a modifier in the code generation function, different authentication codes can be generated based on the same authentication target value when the authentication code setting instruction is 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 way that is not expected. For example, when protecting the function return address as the authentication target value, a stack pointer-dependent modifier can be used to more tightly bind that particular function return address to a specific instance of the function call. The second modifier depends on the program counter address obtained from the program counter register. By considering a program counter-dependent modifier, the authentication code can be more precisely bound to a specific instance of the function, thereby reducing the risk that an attacker could circumvent authentication checks by replacing the authentication target value and authentication code actually intended for a given instance of the function with a previously captured pair of authentication target values ​​and authentication codes captured on different instances of the function.

[0065] The inventors have recognized that, in addition to using at least one of the first and second modifiers described above, the strength of the authentication code can be further enhanced if one or more additional data values ​​associated with the function that invokes the authentication code generation instruction are used as modifiers. Specifically, in the first code generation mode, an additional modifier is used, which depends on an additional value obtained from registers visible on a different architecture than the program counter register and stack pointer register. For example, a function may be called multiple times from the same point in the code, for example, due to a loop. In the case where the authentication code generation instruction is used for each instance of the function, for example, to protect the function return address, the same authentication code can be generated in each iteration of the loop because both the program counter and stack pointer can have the same value for each instance of the function call. However, in the case where the function is called multiple times, the data held by the function in the architecture-visible registers may be different on each instance. Therefore, different authentication codes can be generated on each instance, making it more difficult for an attacker to circumvent authentication verification through a repeat attack.

[0066] For both the authentication code setting instruction and the authentication code verification instruction, using a combination of the first and / or second modifiers with other modifiers is unnecessary. In practice, to ensure that the authentication code verification 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 values ​​used for the code generation function are identical for both the authentication code verification instruction and the authentication code setting instruction. However, the responsibility for ensuring that the modifiers of the corresponding setting / verification instructions are identical 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 two instructions use the same modifiers. Therefore, the authentication code setting instruction can trigger the processing circuitry to execute a first set of operations that implement the authentication code setting function, and the authentication code verification instruction can trigger the processing circuitry to execute a second set of operations that implement the authentication code verification 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 and authentication code verification instructions to obtain a value dependent on the program counter address as its second modifier value, neither the authentication code setting function triggered by the authentication code setting instruction nor the authentication code verification function triggered by the authentication code verification instruction needs to depend on a value obtained from the program counter register. Therefore, it is unnecessary for the device itself to include circuitry that requires both the authentication code setting and verification instructions to support modifiers dependent on the program counter.

[0067] In some configurations, the architecturally visible registers are general-purpose registers. For example, the set of general-purpose registers can be a set of architecturally defined registers that are visible and accessible to the programmer or compiler for access and modification. In some configurations, architecturally defined registers may correspond to a set of physically available registers. Alternatively, in some configurations, a larger set of physical registers may be provided, where register renaming techniques are used to map architecturally defined registers to those physical registers, for example, to support out-of-order instruction execution.

[0068] In some configurations, the architecturally visible registers are those saved by the callee. These are registers that are conventionally saved by the callee function. When a function (the calling function) calls another function (the callee function), there are established conventions known to those skilled in the art regarding which function (the calling or the callee function) is responsible for ensuring the state of the registers upon returning from the callee function. Specifically, a first subset of the architecturally visible registers is the callee-saved registers. The callee function is responsible for saving any data it needs after returning from the callee function in the callee-saved registers. The callee function can write data to the callee-saved registers without first saving the original contents (e.g., the contents of those registers when the callee function was called) and without restoring the original contents of those registers before the function returns. A second subset of the architecturally visible registers is the callee-saved registers. The responsibility for ensuring the contents of the callee-saved registers are correct upon function return rests with the callee function. When the called function needs to use one of the registers saved by the called function, the called function is responsible for first saving the contents of that register to memory and then restoring the contents of the saved register from memory before returning. Therefore, the calling function can be confident that the data values ​​stored in the saved register after the function returns will be those values ​​that appeared immediately before the function call. In addition to the registers saved by the caller and the called function, a third subset of the architecturally saved registers is used as temporary registers. These temporary registers are used to pass data between the called and called functions, and neither the called nor the called function needs to save or restore the contents of these registers. It is advantageous to use additional modifiers obtained from one of the registers saved by the called function because, in typical use cases, the authentication code verification instruction may be the first instruction invoked by the calling function after the function returns. Because the registers saved by the callee contain data that was stored before the function call (e.g., the data values ​​have been restored by the callee function and the caller function does not need to execute one or more instructions to restore those data values), the authentication code verification instruction can use this data as a modifier (in combination with the key, the target value, and at least one of the first and second modifiers) to determine whether the authentication code generated based on this data matches a reference authentication code (e.g., the authentication code generated by the authentication code setting instruction before the function call).

[0069] In some configurations, the processing circuitry is configured to apply the code generation function to both the first and second modifiers when operating in the first code generation mode. Therefore, the authentication code is generated based on both the stack pointer and the program counter value. This further reduces the likelihood of an attacker circumventing the authentication code verification instructions, since at least one of the stack pointer and program counter may differ between different instances of the function.

[0070] As discussed, while the first code generation mode may be the only mode in which a class of authentication code generation instructions can operate, in some configurations, the processing circuitry is configured to operate in multiple code generation modes, including the first code generation mode and at least one other code generation mode, and the code generation mode is determined by a reference control register. Therefore, the control register can be used to control one or more aspects of the operation of a class of authentication code generation instructions. For example, the control register can be used to switch a class of authentication code generation instructions from operating in the first code generation mode as described above to another code generation mode, such as the legacy mode.

[0071] In some configurations, the processing circuitry is configured to operate under multiple exception levels, each with a different privilege level; and the control register is accessible by software operating under a higher privilege level among the exception levels, but not by software operating under a lower privilege level among the exception levels. The higher-privilege software may, for example, include an operating system or a hypervisor. The lower-privilege software may include, for example, one or more user applications or programs. Therefore, the provision of the control register allows higher-privilege software to control the operating mode of a class of authentication code generation instructions, but prevents lower-privilege software from modifying the operating mode. In this way, higher-privilege software can, for example, enable a class of authentication code generation instructions to use a higher security level (e.g., more modifiers) when the software calls an untrusted function, and a lower security level (e.g., fewer modifiers) when the software calls a trusted function.

[0072] Operating modes can be set by the system designer to control various characteristics of a class of authentication code generation instructions. In some configurations, the processing circuitry is configured to, when operating in at least one additional code generation mode,: apply a code generation function to at least one of a first modifier and a second modifier, as well as the authentication target value; and exclude additional modifiers when applying the code generation function. In other words, control registers can be used to enable and disable the use of additional modifiers. Switching between different authentication modes using control registers allows for the provision of a single authentication code setting instruction and a single authentication code verification instruction, where the different functions implemented by those instructions depend on the value in the control register. This, in turn, reduces the space requirements in the ISA for a class of authentication code generation instructions and provides a means for future expansion of the capabilities of a class of authentication code generation instructions, as additional modifiers can be incorporated based on the value of the control data stored in the control register.

[0073] In some configurations, at least one additional code generation mode includes: a first additional code generation mode, wherein the processing circuitry is configured to apply a code generation function to the authentication target value and a first modifier; and a second additional code generation mode, wherein the processing circuitry is configured to apply a code generation function to the authentication target value, the first modifier, and the second modifier. A class of authentication code generation instructions can also operate in one or more additional modes controlled by a control register.

[0074] In some configurations, the control register defines a subset of code generation modes; and the processing circuitry responds to a mode selection parameter specified in a class of authentication code generation instructions to select a code generation mode from the subset of code generation modes. Thus, the control register can be used to define hardware-supported modes or modes that allow higher-privilege software control that are accessible to lower-privilege software. The mode selection parameter can be specified as an immediate value and can therefore be used by a programmer or compiler to specify a code generation mode from a subset of hardware-supported or currently available modes. If the mode selection parameter selects a mode that the control register does not allow, the processing circuitry can respond by signaling an error or by setting the authentication code generation mode to the mode using the maximum security level (e.g., the maximum number of modifiers).

[0075] In some configurations, the control register includes modifier identification information, and additional modifiers are determined based on this modifier identification information. This additional modifier identification information can take any form and can indicate whether to use an additional modifier, where to specify an additional modifier, or the function or format to be used to interpret the architecture-visible registers used as additional modifiers.

[0076] In some configurations, modifier identification information identifies architecture-visible registers. Generally, the architecture may provide multiple architecture-visible registers, and modifier identification information can specify one of those architecture-visible registers as the architecture-visible register from which to derive further modifiers. The identifier of an architecture-visible register can be an explicit specification of the architecture register, or it can be information from which specifiers of the architecture register can be derived.

[0077] In some configurations, the additional modifier is one of a set of identified additional modifiers, and the control register includes a set size identifier to identify the size of the set. In other words, the control register specifies how many additional modifiers to use. Including the set size in the control register provides a means to extend the implementation of a class of authentication code generation instructions, which can be provided in future implementations without requiring future modifications to the ISA.

[0078] In some configurations, the control register identifies the corresponding architecture-visible register for each of the additional modifiers in the set, the additional modifier depending on the corresponding architecture-visible register. The control register can use a discrete set of bits within the control register to implement a set size identifier and an indication of the corresponding architecture-visible register. Alternatively, in some configurations, the control register may be set with a set of bits, for example, one bit for each architecture-visible register (or each register held by the callee), that provides an indication of whether that register will be used as a modifier. In this implementation, the set size identifier can be encoded in the same bits used to identify whether each architecture-visible register will be used as a modifier; for example, the set size is equal to the number of set bits.

[0079] While architecturally visible registers can be defined in control registers or a class of authentication code generation instructions, in some configurations, the processing circuitry is configured to perform the selection of an architecturally visible register from a pool of such registers. Therefore, this selection can be performed without direct control of the programmer.

[0080] In some configurations, the selection is based on a selection value other than any register specifier encoded in the authentication code generation instruction. For example, the selection value can be controlled based on one or more selection schemes implemented within the processing circuitry. This selection value can be stored in a control register and / or controlled by higher-privilege software.

[0081] In some configurations, the selection value is modified by applying changes in response to an authentication code setting instruction and removing those changes in response to an authentication code verification instruction. Therefore, the selection value can be modified each time an authentication code is generated and removed each time it is verified. Each modification to the selection value introduces further variability into the generated code, making it more difficult for attackers to circumvent the authentication code.

[0082] This modification can be defined in different ways, and in some configurations, it is based on a counter value that increments in response to an authentication code setting instruction and decrements in response to an authentication code verification instruction. The counter value can be used directly to identify architecturally visible registers, for example, by specifying a register identifier. Alternatively, the architecturally visible register identifier can be determined based on a hash or other modification of the counter value.

[0083] In some configurations, the modification is based on one or more bits of the program counter or one or more bits of the stack pointer. For example, the modification may be based on a hash generated from the stack pointer and / or program counter value. The selected bits of the stack pointer and / or program counter value may be based on the counter value, and / or the counter value may be incorporated into the hash generation.

[0084] While additional modifiers can be read directly from architecturally visible registers or based on hashes of values ​​from architecturally visible registers, in some configurations, the architecturally visible registers are one of several selected architecturally visible registers, and the additional modifiers depend on hashes of values ​​obtained from one or more of these selected architecturally visible registers. Combining values ​​from multiple architecturally visible registers further reduces the likelihood of an attacker circumventing the authentication code by further reducing the probability of generating the same authentication code repeatedly.

[0085] In some configurations, the processing circuitry is configured to retain indications of the selection in a separate register. Retaining the selection of an architecturally visible register in a register, rather than storing the selection in memory, makes it difficult for an attacker to identify which selection the processing circuitry used when generating the authentication code.

[0086] The additional register may be a specially provided register. Alternatively, in some configurations, the additional register is one of the following: a stack pointer register, with one or more unused bits in the stack pointer register used to record the selection; and a program counter register, with the selection recorded in one or more unused bits in the program counter register. Utilizing unused bits in the stack pointer register or the program counter register avoids the need for a specially provided register, while still allowing the selection to be recorded without being saved to memory.

[0087] In some configurations, in response to a non-sequential change in program flow to a branch target address triggered when branch target verification is enabled, the processing circuitry is configured to trigger an error handling response when the instruction at the branch target address does not belong to a permitted class of branch target instructions; and the authentication code setting instruction is one of the permitted class of branch target instructions. Supporting branch target verification can help reduce the possibility that an attacker could tamper with the target address of a branch to cause a jump to an arbitrary point in the program that is not intended to be a branch entry point. Security can be improved by restricting valid branch entry points to addresses where the instruction at the branch target address is one of a limited set of instruction types allowed to act as a branch target instruction. Allowing the authentication code setting instruction to also act as one of the permitted class of branch target instructions is particularly useful 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 increasing program code density. However, in instruction set architectures with limited register availability at the end of a function call, the requirement to conform to function call conventions may necessitate additional saving / restoring register contents to / from the stack. In some cases (e.g., where authentication code setting / verification instructions are separated by a large distance in the program code), if one of the authentication code setting / verification instructions does not support correction based on a correction value, it can 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 a combined instruction as both the authentication code setting instruction and the allowed branch target instruction. Therefore, when combined authentication code setting and branch target instructions are supported, the option to apply correction based on the correction value used to generate one of the first / second modifiers is particularly useful, as this correction helps maintain the code density improvements achievable with combined authentication code setting and branch target instructions.

[0088] In some configurations, 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 verification 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 verification 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 is 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 verification instruction is small enough to be within a range that can be referenced using the immediate value of the authentication code verification instruction.

[0089] A specific configuration will now be described with reference to the accompanying drawings.

[0090] Figure 1 An 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 an instruction decoding circuit), 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 microoperations 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 microoperations 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 microoperations, such that, for example, a single program instruction can be split into two or more microoperations, or two or more program instructions can be merged to be processed as a single microoperation.

[0091] 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 a type of authentication code generation instruction. For example, code generation unit 27 may implement a given cryptographic hash function, such as SHA or QARMA.

[0092] 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 specific 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.

[0093] 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.

[0094] For example, ISA can support sixteen general-purpose registers R0-R15, where R0-R3 can be used as temporary registers to pass parameters between functions, R4-R11 can be used as registers saved by the callee, R12 can be used as a register saved by the caller, and R13, R14, and R15 are also used as special-purpose registers.

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

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

[0097] -R15: PC (Program Counter Register), which stores the address of the program counter, representing the address of the instruction at the current point in the program flow.

[0098] It should be understood that other registers may also be supported, and the above architecture is only one example of a possible ISA, and alternative examples may use a 64-bit architecture or an alternative 32-bit architecture with a different number of general-purpose registers defined in a different way.

[0099] Figure 2 An example of a program flow involving nested function calls is illustrated. The flow begins at instruction address "#add1", which corresponds to a linked branch instruction BL that calls a given function fn A. The BL instruction is a call branch instruction that, when decoded, causes processing circuit 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 described above). In this example, the instruction is 32 bits long, 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.

[0100] The program flow then continues through fn A until it encounters another BL instruction at instruction address #add2 to call another function fn B. Therefore, since the BL instruction at #add2 overwrites the link register, the software includes at least one store instruction before executing the BL instruction at #add2 to save the contents of the link register (LR) (i.e., the return address #add1+4 corresponding to fn A) into a software-maintained stack data structure in memory. In some cases, if the contents of other registers associated with fn A are at risk of being overwritten by fn B, these contents may also be stored on the stack before calling fn B. The stack pointer in the SP register (R13) is 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.

[0101] After saving any register contents that need to be reserved for fn A onto the stack, the BL instruction at #add2 is executed. This causes the address of the next sequential instruction (#add2+4) to be written into the link register as the return address of another function, and causes the program flow to jump to the target address of the BL instruction, corresponding 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, so when it is used, it redirects the program flow back to #add2+4. In other words, the code segment in fn A is resumed 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 other register contents can also be restored based on information saved to the stack before the call to fn B). When fn A ends, another return branch instruction is encountered, which leads to a return branch to the target address obtained from LR, i.e., the program flow now resumes from #add1+4 (the instruction after the call branch that initially called fn A).

[0102] 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 circuit 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-based code respectively. This helps the developers of both the caller and callee code understand whether they need to save or restore the contents of certain registers to or from the stack before or after a function call or function return. For example, it can be agreed that general-purpose registers R0-R3 can be used as function arguments or function return values ​​to allow the caller and callee code to pass values ​​between each other. Registers R4-R11 can be registers saved by the callee, which need 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-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 that 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 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-R15 are reserved for special purposes, serving as LR, SP, and PC as described above.

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

[0104] 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 agreed-upon rules that software developers must follow when developing software to be executed on device 2. However, once a consensus-based function calling convention is established, the function calling convention typically used for existing software code can 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.

[0105] Figure 2 This illustrates how nested function calls can necessitate software including 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 system implementation, an attacker could gain physical access to the memory system to tamper with stored information and / or potentially 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 lead to malfunctioning programs and loss of data security.

[0106] For example, if a return address pushed from the link register is modified while stored on the stack, the corresponding return branch will jump to the wrong location in memory when it is later loaded back into the link register. This can lead to the execution of incorrect instructions, which might be from "widget" code provided by an attacker to enable malicious operations. This can be known as a "return-oriented programming" (ROP) attack. A similar attack risk exists when a data address pointer is stored from a register onto the stack and then modified while stored in memory. This could allow access to an incorrect address in memory after the pointer is subsequently restored to a register, potentially enabling access to memory locations that should not be accessed.

[0107] Therefore, it may be useful for ISA to provide countermeasures against such attacks. For example... Figure 3 and Figure 4 As shown, the instruction decoder 10 and processing circuits 4 and 16 can support one type of authentication code generation instruction, which includes at least one variant of the authentication code setting instruction and at least one variant of the authentication code verification instruction. Other types of authentication code generation instructions can also be supported.

[0108] Typically, when each variant of the authentication code generation instruction is decoded by the instruction decoding circuit 10, the control processing circuit 4 generates an authentication code corresponding to the authentication target value obtained from the source register using a code generation function based on at least one of the authentication target value, the cryptographic key, the first modifier value, and the second modifier value, as well as another modifier value.

[0109] If the authentication code generation instruction is an authentication code setting instruction (PAC instruction), such as Figure 3 As shown, at least a portion of the generated authentication code is written to the destination register. The destination register can be a general-purpose register, separate from the source register used to provide the authentication target value, or the destination register can be an unused portion of the source register that provides the authentication target value.

[0110] If the authentication code generation instruction is an authentication code verification instruction (AUT instruction), such as Figure 4 As shown, at least a portion of the generated authentication code (generated based on the authentication target value obtained from the first source register) is compared with at least a portion of a reference authentication code obtained from the source register, which can be the first source register or 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 triggers an exception or fault condition, which can cause processing to be interrupted and jump to the exception handler to handle the cause of the fault.

[0111] In some examples, variants of the PAC / AUT instruction can be provided where the source register used to provide the authentication target value is a fixed register, 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 could 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 can also be provided where 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 is used to protect a data address pointer.

[0112] 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, predefined 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 described 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 registers saved by the caller (e.g., register R12 in the example above), as this eliminates the need to restore the contents of R12 after executing the AUT instruction, which can facilitate the use of combined branch / AUT instructions 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.

[0113] 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 for cryptographic key updates—for example, write access to the register storing the key can be restricted to higher-privilege operating states). The cryptographic key can, for example, be a value with more bits than 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-bit or 128-bit. 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 distinguishing variants of the PAC / AUT function to use different keys), and / or the state of other registers stored in register 14.

[0114] The first modifier value, the second modifier value, and additional modifier values ​​are used to adjust the cryptographic hash function used as the code generation function to increase the possibility that different authentication codes can be generated in the code generation function, even if the authentication target value and key are the same for two different function call scenarios, allowing the authentication code to be specific to a particular instance of the function call. This significantly reduces the probability that an attacker can circumvent the authentication code verification of the AUT instruction by saving the authentication code generated for one instance of the function call and reusing the previously generated authentication code when attempting to seek authentication for a tampered authentication target value in another instance of the function call. The first modifier value for PAC and AUT instructions depends on the current stack pointer value specified in the stack pointer register SP when the PAC / AUT instruction is executed. For at least one of the PAC and AUT instructions (not necessarily both as shown in the following examples), the second modifier value depends on the current program counter address value from the PC register. This provides enhanced security by using one or both of the stack pointer-dependent and program counter-dependent adjustments for the code generation function. This is because, when called at a given function call depth (represented by the current value of the stack pointer), the authentication code is bound to a specific instance of the function located at a given address (represented by the program counter address). Given a reasonable security code generation function (such as SHA or QARMA), this makes it statistically impossible for an attacker to replace the current authentication code with a previously saved one and use that to circumvent authentication code verification. Including additional modifiers based on values ​​obtained from registers that are architecturally visible, but not the stack pointer register or the program counter register, provides further variability in the generated authentication code. Specifically, for repeated instances of function calls at a given address at a specific call depth (e.g., due to loops), the first and second modifiers will be the same and will not introduce variation into repeated authentication code generation. On the other hand, using additional modifiers that depend on data stored in architecturally visible registers (which may change even if the program counter value and call stack depth remain unchanged) allows the generated authentication code to vary.

[0115] The specific way modifier values ​​are used to adjust a cryptographic hash function can vary depending on the specific algorithm used. However, in general, 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 / or a second modifier value, as well as additional modifier values. For example, the first, second, and additional 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 combined bit width of the first, second, and additional 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 modifier values.

[0116] In the intended use case, at least one instance of the PAC directive will be included when entering the callee function or shortly thereafter (e.g., in...). Figure 2 In the program code marked as fn A or fn B (or shortly thereafter), and at least one instance of the AUT instruction will be included at or shortly before the return branch of the called function (e.g., at the point where the AUT instruction is marked as fn A or fn B). Figure 2 The code returns to or before the return branch of #add2+4 or #add1+4. After the authentication code has been generated 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 may make the authentication code itself vulnerable to attack, the cryptographic hash function can be designed to make it virtually impossible for an attacker to modify both the authentication target value (e.g., the function return address or data address pointer) and the corresponding authentication code, making it difficult for the authentication code generated from the tampered authentication target value to match the tampered authentication code used as the reference authentication code for the AUT instruction during authentication code verification.

[0117] Figure 5The apparatus, according to some configurations of the present technology, is schematically illustrated. The apparatus can operate in several different code generation modes, which are controlled by control data 54 provided in a control register. Control data 54 controls switch circuits 48, 50, and 52 to determine which modifiers will be provided to authentication code generation circuit 56. Authentication code generation circuit 56, under the control of control data 54, receives a target value 42, an authentication key 60, and one or more modifiers from switch circuits 48, 50, and 52. Authentication code generation circuit 56 uses a security code generation function (such as SHA or QARMA) to generate an authentication code 58 using the input value and modifiers.

[0118] The modifiers that can be provided to the authentication code generation circuit include a first modifier, a second modifier, and an additional modifier. The first modifier is obtained from the stack pointer (SP) value held in the stack pointer register 44(13). In the illustrated configuration, the stack pointer register 44(13) is the general-purpose register R13. The second modifier is obtained from the program counter (PC) value, which is obtained from the program counter register 44(15). In the illustrated configuration, the program counter register 44(15) is R15. The additional modifier is obtained from one of the registers saved by the callee. As discussed above, the registers saved by the callee include general-purpose registers R4 44(4) through R11 44(11). The select circuit 46 determines the callee-saved register from which the additional modifier is selected based on n-bit (e.g., 3-bit) select data. The n-bit select data selects one of the registers stored in the callee. For example, when using 3-bit select data, the 3-bit select data can take 8 different values, thus distinguishing 8 different registers stored in the callee.

[0119] The device can operate in at least a first code generation mode, in which control data 54 triggers switching circuit 48 to forward one of the callee-stored registers selected by selection circuit 46 to authentication code generation circuit 56. Control data 54 also causes at least one of switching circuits 50 and 52 to forward one of the corresponding registers to authentication code generation circuit 56 to generate authentication code 58. The device can also operate in at least one additional mode depending on the value of control data, which can be selected independently and combined with 3-bit selection data to select different combinations of stack pointer register 44 (13), program counter register 44 (15), and callee-stored registers R4 44 (4) to R11 44 ​​(11) to forward the different combinations to authentication code generation circuit in response to decoding of a class of authentication code generation instructions by decoder circuitry.

[0120] Figure 6 Modifications to the apparatus according to some configurations of the present technology are schematically illustrated. The apparatus includes an authentication code generation circuit 56, as described above. Figure 5 As described, the authentication code generation circuit receives a target value 42, a key 60, and a set of modifiers. The authentication code generation circuit 56 generates an authentication code 58 based on these inputs. (See also: Regarding...) Figure 5 As described, the modifiers provided to the authentication code generation circuit 56 are controlled by control data 54 stored in the control register in combination with additional control data 62. The control data controls selection circuit 64, switching circuit 50, and switching circuit 52 to determine which modifiers will be provided to the authentication code generation circuit 56.

[0121] The modifiers that can be provided to the authentication code generation circuit include at least one of a first modifier and a second modifier, and an additional modifier. The first modifier is obtained from the stack pointer (SP) value held in the stack pointer register 44 (13). In the illustrated configuration, the stack pointer register 44 (13) is a general-purpose register R13. The second modifier is obtained from the program counter (PC) value, which is obtained from the program counter register 44 (15). In the illustrated configuration, the program counter register 44 (15) is R15. The additional modifier is obtained from one of the registers held by the callee. As discussed above, the registers held by the callee include general-purpose registers R4 44 (4) to R11 44 ​​(11). The select circuit 64 determines the callee-held register from which the additional modifier is selected by combining the value N provided by control data 54 and additional control data 62. The parameter N provided by control data 54 defines the number of modifiers to be passed from the select circuit 64 to the authentication code generation circuit 56. Additional control data 62 identifies N specific modifiers that will be passed from selection circuit 64 to authentication code generation circuit 56. Specifically, the additional control data provides indications for additional modifier 1, additional modifier 2, ..., and additional modifier N. Selection circuit 64 receives N additional modifier identifiers (which may each identify different registers saved by the callee, or alternatively may include two or more additional modifier identifiers identifying the same registers saved by the callee) and passes those registers to the authentication code generation circuit.

[0122] Figure 7 Further variations of a device according to some configurations of the present technology are illustrated schematically. The device is provided with an authentication code generation circuit 56 for generating an authentication code 58 based on a target value 42 and a key 60. The authentication code generation circuit 56 also generates an authentication code based on a set of modifiers. See reference... Figure 5 and Figure 6The additional modifiers discussed depend on control data 54 and may include at least one of the first and second modifiers, as well as other modifiers. The first modifier is obtained from the stack pointer (SP) value held in the stack pointer register 44 (13). In the illustrated configuration, the stack pointer register 44 (13) is the general-purpose register R13. The second modifier is obtained from the program counter (PC) value, which is obtained from the program counter register 44 (15). In the illustrated configuration, the program counter register 44 (15) is R15.

[0123] The selection of additional modifiers is controlled by the switching circuit 70 based on control data 54. These additional modifiers are identified by n-bit selection data (e.g., 8-bit selection data), which identifies multiple callee-saved registers. For example, in the case of using 8-bit selection data, each bit can be used to identify one of the callee-saved registers and indicate whether to select that register to form part of the additional modifier. Based on the value of the n-bit selection data, the selection circuit 66 can select one or more callee-saved registers to facilitate the additional modifier. The selected register from the callee-saved registers is passed by the selection circuit 66 to the hash circuit 68, which generates a hash value based on the combination of callee-saved registers received from the selection circuit. The output of the hash circuit 70 is provided to the authentication code generation circuit 56 to generate an authentication code 58.

[0124] Figure 8 The generation of selection data is illustrated schematically, for example, Figure 5 or Figure 7 The n-bit selection data can be used to select which register stored in the callee will trigger another modifier value. Figure 8 (A) illustrates a first method for generating selection data based on the stack pointer value received from the program counter value 80. The stack pointer of the program counter value 80, along with the old value of the selection data 82, is passed to a lossless hash generation circuit 84. The lossless hash circuit 84 combines the old selection data 82 with the stack pointer of the program counter value 80 to generate new selection data 86. For example, the lossless hash generation circuit 84 may include an XOR circuit configured to receive the corresponding bit of the stack pointer or program counter value 80 for each bit of the old selection data 82 and generate an XOR of those bits. The resulting bit values ​​can be inverted by passing the output selection data 86 along with the same stack pointer value or program counter value 80 to the hash generation circuit 84. Modifications are made in response to each instance of the authentication code setting instruction and each instance of the authentication code verification instruction. Figure 8The selection data described in (A) allows the selection data to cycle through a set of values ​​in response to an authentication code generation instruction, and to reverse the cycle in response to an authentication code verification instruction.

[0125] Figure 8 (B) schematically illustrates an alternative configuration in which hash generation circuitry 94 receives stack pointer value 90 and program counter value 98, as well as old select data 92, and generates select data 96 based on the combination of stack pointer 90m, program counter value 98, and old select data 92. (See also...) Figure 8 In case (A), the hash algorithm is a lossless hash algorithm, which makes it possible to reverse modifications to the selected data so that the selected data cycles through the set of values ​​in response to the authentication code generation instruction, and reverses the cycle in response to the authentication code verification instruction.

[0126] Figure 9 The illustration schematically illustrates the storage of selection data 100 in unused bits of the stack pointer or program counter register 102. For example, both the most significant and least significant bits of the stack pointer or program counter register may be omitted. This may be the case, for example, when a 64-bit register is provided for the stack pointer and / or program counter register, and when not all 64 bits are needed to uniquely identify the address within the range of available addresses. Similarly, the stack pointer or program counter value 102 may, for example, coarsely specify a region of memory based on the cache line size. Therefore, the least significant bit of the stack pointer and program counter register may be unused. Storing selection data 100 in unused bits of the stack pointer and / or program counter register 102 avoids the need to provide a dedicated register for selection data 100 or to store selection data 100 in memory.

[0127] Figure 10The sequence of steps executed in response to an authentication code generation instruction is illustrated schematically. The process begins at step S100, where it is determined whether an authentication code generation instruction has been received. If it is determined at step S100 that an authentication code generation instruction has been received, the process proceeds to step S102. At step S102, the authentication key is retrieved before the process proceeds to step S104. At step S104, the authentication target value is retrieved before the process proceeds to step S106. At step S106, before the process proceeds to step S108, at least one of a first modifier and a second modifier is retrieved. The first modifier depends on the stack pointer obtained from the stack pointer register, and the second modifier depends on the program counter obtained from the program counter register. At step S108, before the process proceeds to step S110, an additional modifier is retrieved from a register visible on a different architecture than the stack pointer register and the program counter register. In step S110, an authentication code is generated based on at least one of the first modifier and the second modifier, the key, the authentication target value, and the other modifier.

[0128] Figure 11 The diagram schematically illustrates a sequence of steps performed according to some configurations of the present technology in response to receiving an authentication code generation instruction. The process begins at step S120, where the type of authentication code generation instruction is determined. If the type of authentication code generation instruction determined at step S120 is an authentication code setting instruction, the process proceeds to step S132. At step S132, an authentication code is generated (e.g., following...). Figure 10 (The process described in steps S102 to S110). Then, at least a portion of the authentication code is stored in a register. If, at step S120, it is determined that a type of authentication code generation instruction is an authentication code verification instruction, the process proceeds to step S122. At step S122, an authentication code is generated (e.g., following...). Figure 10 (The process described in steps S102 to S110). Then, the flow proceeds to step S124, where, before proceeding to step S126, a reference authentication code is retrieved from the source register. At step S126, at least a portion of the reference authentication code is compared with at least a portion of the generated authentication code, and it is determined whether the reference authentication code corresponds to the generated authentication code. If it is determined at step S126 that the reference authentication code corresponds to the generated authentication code, the flow proceeds to step S128, where the processing circuit executes further instructions. If it is determined at step S126 that the reference authentication code corresponds to the generated authentication code, the flow proceeds to step S130, where authentication verification failure is indicated. For example, authentication verification failure can be indicated by triggering an error or, for example, by storing data in the authentication target value so that an error is triggered at a subsequent point.

[0129] Figure 12 The sequence of steps performed by the device according to some configurations of the present technology is illustrated schematically. The process begins at step S140, where it is determined whether a type of authentication code generation instruction has been received. If it is determined at step S140 that a type of authentication code generation instruction has not been received, the process stops at step S140. If it is determined at step S140 that a type of authentication code generation instruction has been received, the process proceeds to step S142. At step S142, before the process proceeds to step S144, control data is retrieved, for example, from the control register.

[0130] At step S144, it is determined whether the control data indicates that the first code generation mode should be used. If it is determined at step S144 that the first code generation mode should be used, the process proceeds to step S150. At step S150, the modifier is set to at least one of the following: a first modifier based on the stack pointer, a second modifier based on the program counter, and an additional modifier based on a register visible on a different architecture than the stack pointer register and the program counter register. The process then proceeds to step S158, in which the code generation function is applied to generate an authentication code based on the target value, the key, and the modifier.

[0131] If it is determined at step S144 that the control data does not indicate a first code generation mode, the process proceeds to step S146, where it is determined whether the control data indicates the use of a first alternative code generation mode. If it is determined at step S146 that the first alternative code generation mode should be used, the process proceeds to step S152. At step S152, the modifier is set to a first modifier based on the stack pointer. The process then proceeds to step S158, where a code generation function is applied to generate an authentication code based on the target value, the key, and the modifier.

[0132] If it is determined at step S146 that the control data does not indicate a first alternative code generation mode, the process proceeds to step S148, where it is determined whether the control data indicates the use of a second alternative code generation mode. If it is determined at step S148 that the second alternative code generation mode should be used, the process proceeds to step S154. At step S154, the modifiers are set to a first modifier based on the stack pointer and a second modifier based on the program counter value. The process then proceeds to step S158, where a code generation function is applied to generate an authentication code based on the target value, the key, and the modifiers.

[0133] If it is determined at step S148 that the control data does not indicate a second, alternative code generation mode, the process proceeds to step S156, where the modifier is set to the default minimum level. The process then proceeds to step S158, where a code generation function is applied to generate an authentication code based on the target value, the key, and the modifier.

[0134] Figure 13 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.

[0135] 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.

[0136] 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). This program interface is identical to the interface of the hardware architecture modeled by the simulator program 710. Therefore, the program instructions of the target code 700 as described above (including the aforementioned type of authentication code generation instructions) can be executed from within the instruction execution environment using the simulator program 710, enabling the host computer 730, which does not actually possess the hardware features of the aforementioned device 2, to emulate these features.

[0137] The emulator 710 may include instruction decoding logic 712 for decoding the instructions of the target code 700 and mapping them to corresponding instruction sequences defined according to a 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 emulates the set of architecture registers 14 expected to be provided in the ISA associated with the target code 700. For example, register references for operands and results of the previously mentioned PAC / AUT instructions may be remapped by the register emulation logic 714 to access requests for references to specific locations in host memory provided by the host hardware 730.

[0138] In general, an apparatus, a method, and a computer program are provided. The apparatus includes instruction decoding circuitry for decoding instructions and processing circuitry for performing processing operations in response to the decoded instructions. In response to an authentication code generation instruction, the processing circuitry is configured to generate an authentication code associated with an authentication target value. For at least one type of authentication code generation instruction, the processing circuitry is configured, when operating in a first code generation mode, to generate the authentication code by applying a code generation function to: a key; the authentication target value; a first modifier depending on the stack pointer, and / or a second modifier depending on the program counter address; and an additional modifier depending on a further value obtained from a register visible on a different architecture than the stack pointer register and the program counter register.

[0139] In this application, the phrase "configured as..." is used to mean that the elements of the device are configured to perform the defined operations. 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 operations, 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 operations.

[0140] 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.

[0141] While exemplary configurations 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 configurations, and various changes, additions, and modifications can be made therein by those skilled in the art without departing from the scope of the invention as defined by the appended claims. For example, features of the dependent claims can be combined with features of the independent claims in various ways without departing from the scope of the invention.

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. in: In response to a type of authentication code generation instruction, the processing circuit is configured to generate an authentication code associated with an authentication target value; The type of authentication code generation instructions include: An authentication code setting instruction is provided, wherein the processing circuit is configured to write at least a portion of the generated authentication code into a destination register; and An authentication code verification instruction is provided, wherein the processing circuit is configured to verify whether at least a portion of the authentication code generated based on the authentication target value in response to the authentication code verification instruction corresponds to at least a portion of a reference authentication code obtained from the source register, and to indicate verification failure when the generated authentication code does not correspond to the reference authentication code; and For at least one of the authentication code setting instruction and the authentication code verification instruction, the processing circuit is configured to generate an authentication code by applying a code generation function to the following when operating in the first code generation mode: Key; The authentication target value; At least one of a first modifier and a second modifier, wherein the first modifier depends on the stack pointer obtained from the stack pointer register, and the second modifier depends on the program counter address obtained from the program counter register; and Additional modifiers, which depend on additional values ​​obtained from registers visible on a different architecture than the stack pointer register and the program counter register.

2. The apparatus of claim 1, wherein the architecture-visible registers are general-purpose registers.

3. The apparatus of claim 1 or claim 2, wherein the architecture-visible register is a register stored by the callee.

4. The apparatus according to any of the preceding claims, wherein the processing circuitry is configured to apply the code generation function to both the first modifier and the second modifier when operating in the first code generation mode.

5. The apparatus according to any one of the preceding claims, wherein the processing circuitry is configured to operate in a plurality of code generation modes, the plurality of modes including the first code generation mode and at least one other code generation mode, and the code generation mode is determined by reference to a control register.

6. The apparatus according to claim 5, wherein: The processing circuitry is configured to operate under multiple exception levels, each with a different privilege level; and The control register can be accessed by software operating at a higher privilege level among the plurality of exception levels, but cannot be accessed by software operating at a lower privilege level among the plurality of exception levels.

7. The apparatus of claim 5 or claim 6, wherein the processing circuitry is configured to operate in the at least one additional code generation mode: The code generation function is applied to at least one of the first modifier and the second modifier, and the authentication target value; and The additional modifiers are excluded when the code generation function is applied.

8. The apparatus according to any one of claims 5 to 7, wherein the at least one additional code generation mode comprises: A first alternative code generation mode, wherein the processing circuitry is configured to apply the code generation function to the authentication target value and the first modifier; and A second alternative code generation mode, wherein the processing circuitry is configured to apply the code generation function to the authentication target value, the first modifier, and the second modifier.

9. The apparatus according to any one of claims 5 to 8, wherein: The control register defines a subset of code generation modes; and The processing circuit responds to the mode selection parameters specified in the type of authentication code generation instruction to select a code generation mode from the subset of code generation modes.

10. The apparatus according to any one of claims 5 to 9, wherein the control register includes modifier identification information, and the additional modifier is determined based on the modifier identification information.

11. The apparatus of claim 10, wherein the modifier identification information identifies a register visible on the architecture.

12. The apparatus of claim 10 or claim 11, wherein the additional modifier is one of a set of identified additional modifiers, and the control register includes a set size identifier for identifying the size of the set.

13. The apparatus of claim 12, wherein the control register identifies a corresponding architecture-visible register for each of the additional modifiers in the set, the additional modifiers depending on the corresponding architecture-visible register.

14. The apparatus according to any of the preceding claims, wherein the processing circuitry is configured to perform a selection of one of a plurality of architecturally visible registers.

15. The apparatus of claim 14, wherein the selection is based on a selection value other than any register specifier encoded in the authentication code generation instruction.

16. The apparatus of claim 15, wherein the selection value is modified by applying the modification in response to the authentication code setting instruction and by removing the modification in response to the authentication code verification instruction.

17. The apparatus of claim 16, wherein the modification is based on a counter value that increments in response to the authentication code setting instruction and decrements in response to the authentication code verification instruction.

18. The apparatus of claim 16 or claim 17, wherein the modification is based on one or more bits of the program counter or one or more bits of the stack pointer.

19. The apparatus of any one of claims 10 to 18, wherein the architecture-visible register is one of a plurality of selected architecture-visible registers, and the additional modifier depends on a hash of a value obtained from one or more of the plurality of selected architecture-visible registers.

20. The apparatus according to any one of claims 14 to 19, wherein the processing circuitry is configured to retain an indication of the selection in a separate register.

21. The apparatus of claim 20, wherein the additional register is one of the following: The stack pointer register, and uses one or more unused bits of the stack pointer register to record the selection; and The program counter register, and the selection is recorded in one or more unused bits of the program counter register.

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

23. 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 verification instruction, the first modifier includes the 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 verification instruction.

24. A method, the method comprising: The instruction is decoded using an instruction decoding circuit. The processing circuitry performs processing operations in response to the decoded instructions decoded by the instruction decoding circuitry. Using the processing circuit, in response to a type of authentication code generation instruction, an authentication code associated with the authentication target value is generated; The type of authentication code generation instructions include: An authentication code setting instruction is provided, in which the processing circuit writes at least a portion of the generated authentication code into the destination register; and An authentication code verification instruction is provided. For this instruction, the processing logic verifies whether at least a portion of the authentication code generated based on the authentication target value in response to the instruction corresponds to at least a portion of a reference authentication code obtained from the source register, and indicates verification failure when the generated authentication code does not correspond to the reference authentication code. Using processing circuitry, for at least one of the authentication code setting instruction and the authentication code verification instruction, when operating in the first code generation mode, the authentication code is generated by applying a code generation function to the following: The authentication target value; Key; At least one of a first modifier and a second modifier, wherein the first modifier depends on the stack pointer obtained from the stack pointer register, and the second modifier depends on the program counter address obtained from the program counter register; and Additional modifiers, which depend on additional values ​​obtained from registers visible on a different architecture than the stack pointer register and the program counter register.

25. A computer program for controlling a host data processing device to provide an instruction execution environment, the computer program comprising: Instruction decoding program logic, which is used to decode instructions; and The processing logic is configured to perform processing operations in response to a decoded instruction decoded by the instruction decoding logic. in: In response to a type of authentication code generation instruction, the processing logic is configured to generate an authentication code associated with the authentication target value; The type of authentication code generation instructions include: An authentication code setting instruction is provided, wherein the processing logic is configured to write at least a portion of the generated authentication code into a destination data structure; and An authentication code verification instruction is provided, wherein the processing logic is configured to verify whether at least a portion of the authentication code generated based on the authentication target value in response to the authentication code verification instruction corresponds to at least a portion of a reference authentication code obtained from the source data structure, and to indicate verification failure when the generated authentication code does not correspond to the reference authentication code; and For at least one of the authentication code setting instruction and the authentication code verification instruction, the processing logic is configured to generate an authentication code by applying a code generation function to the following when operating in the first code generation mode: Key; The authentication target value; At least one of a first modifier and a second modifier, wherein the first modifier depends on the stack pointer obtained from the stack pointer data structure, and the second modifier depends on the program counter address obtained from the program counter data structure; and The additional modifier depends on a different value obtained from a data structure visible on a different architecture than the stack pointer data structure and the program counter data structure.

Images