An authentication code generating class of instructions

Abstract

There is provided an apparatus, a method, and a computer program. The apparatus is provided with instruction decoding circuitry to decode instructions and processing circuitry to perform a processing operation in response to a decoded instruction. In response to an authentication code generating instruction, the processing circuitry is configured to generate an authentication code associated with an authentication target value. For at least one type of the authentication code generating instruction, the processing circuitry is configured to generate an authentication code, when operating in a first code generation mode, by applying a code generating function to: a key; the authentication target value; a first modifier dependent on a stack pointer, and / or a second modifier dependent on a program counter address; and a further modifier dependent on a further value obtained from an architecturally visible register different from the stack pointer register and the program counter register.

Description

[0001] AN AUTHENTICATION CODE GENERATING CLASS OF INSTRUCTIONS

[0002] The present technique relates to the field of data processing. Furthermore, the present invention relates to an apparatus, a method, and a computer program.

[0003] Some processing architectures support a class of authentication code generating instructions for generating an authentication code associated with a target value (such as an address pointer or function return address). This can help protect against return oriented programming (ROP) attacks or other attacks aimed at causing incorrect program behaviour by tampering with an address pointer or return address while it is stored in a memory system.

[0004] According to some configurations there is provide an apparatus comprising: instruction decoding circuitry to decode instructions; and processing circuitry to perform a processing operation in response to a decoded instruction decoded by the instruction decoding circuitry, wherein: in response to an authentication code generating class of instruction, the processing circuitry is configured to generate an authentication code associated with an authentication target value; the authentication code generating class of instruction comprises: an authentication code setting instruction, for which the processing circuitry is configured to write at least a portion of the generated authentication code to a destination register; and an authentication code checking instruction, for which the processing circuitry is configured to check whether at least a portion of the authentication code generated based on the authentication target value in response to the authentication code checking instruction corresponds to at least a portion of a reference authentication code obtained from a source register, and indicate a failed check 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 checking instruction, the processing circuitry is configured to generate an authentication code, when operating in a first code generation mode, by applying a code generating function to: a key; the authentication target value; at least one of a first modifier dependent on a stack pointer obtained from a stack pointer register, and a second modifier dependent on a program counter address obtained from a program counter register; and a further modifier dependent on a further value obtained from an architecturally visible register different from the stack pointer register and the program counter register.

[0005] According to some configurations there is provide a method comprising: with instruction decoding circuitry, decoding instructions; with processing circuitry, performing a processing operation in response to a decoded instruction decoded by the instruction decoding circuitry; with the processing circuitry, in response to an authentication code generating class of instruction, generating an authentication code associated with an authentication target value; the authentication code generating class of instruction comprises: an authentication code setting instruction, for which the processing circuitry writes at least a portion of the generated authentication code to a destination register; and an authentication code checking instruction, for which the processing program logic checks whether at least a portion of the authentication code generated based on the authentication target value in response to the authentication code checking instruction corresponds to at least a portion of a reference authentication code obtained from a source register, and indicates a failed check when the generated authentication code does not correspond to the reference authentication code; and with processing circuitry, for at least one of the authentication code setting instruction and the authentication code checking instruction, generating an authentication code, when operating in a first code generation mode, by applying a code generating function to: the authentication target value; a key; at least one of a first modifier dependent on a stack pointer obtained from a stack pointer register, and a second modifier dependent on a program counter address obtained from a program counter register; and a further modifier dependent on a further value obtained from an architecturally visible register different from the stack pointer register and the program counter register.

[0006] According to some configurations there is provide a computer program for controlling a host data processing apparatus to provide an instruction execution environment, the computer program comprising: instruction decoding program logic to decode instructions; and processing program logic to perform a processing operation in response to a decoded instruction decoded by the instruction decoding program logic, wherein: in response to an authentication code generating class of instruction, the processing program logic is configured to generate an authentication code associated with an authentication target value; the authentication code generating class of instruction comprises: an authentication code setting instruction, for which the processing program logic is configured to write at least a portion of the generated authentication code to a destination data structure; and an authentication code checking instruction, for which the processing program logic is configured to check whether at least a portion of the authentication code generated based on the authentication target value in response to the authentication code checking instruction corresponds to at least a portion of a reference authentication code obtained from a source data structure, and indicate a failed check 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 checking instruction, the processing program logic is configured to generate an authentication code, when operating in a first code generation mode, by applying a code generating function to: a key; the authentication target value; at least one of a first modifier dependent on a stack pointer obtained from a stack pointer data structure, and a second modifier dependent on a program counter address obtained from a program counter data structure; and a further modifier dependent on a further value obtained from an architecturally visible data structure different from the stack pointer data structure and the program counter data structure.

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

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

[0009] The present techniques will be described further, by way of example only, with reference to configurations thereof as illustrated in the accompanying drawings, in which:

[0010] Figure 1 schematically illustrates an apparatus according to some configurations of the present techniques;

[0011] Figure 2 schematically illustrates a sequence of branches that may occur in some example use cases of the present techniques;

[0012] Figure 3 schematically illustrates an authentication code setting instruction in accordance with some configurations of the present techniques;

[0013] Figure 4 schematically illustrates an authentication code checking instruction according to some configurations of the present techniques;

[0014] Figure 5 schematically illustrates an apparatus according to some configurations of the present techniques;

[0015] Figure 6 schematically illustrates an apparatus according to some configurations of the present techniques;

[0016] Figure 7 schematically illustrates an apparatus according to some configurations of the present techniques;

[0017] Figure 8 schematically illustrates generation of selection data according to some configurations of the present techniques;

[0018] Figure 9 schematically illustrates storage of selection data according to some configurations of the present techniques;

[0019] Figure 10 schematically illustrates a sequence of steps carried out according to some configurations of the present techniques; Figure 11 schematically illustrates a sequence of steps carried out according to some configurations of the present techniques;

[0020] Figure 12 schematically illustrates a sequence of steps carried out according to some configurations of the present techniques; and

[0021] Figure 13 schematically illustrates a simulator implementation according to some configurations of the present techniques.

[0022] Some configurations of the present techniques provide an apparatus comprising: instruction decoding circuitry to decode instructions; and processing circuitry to perform a processing operation in response to a decoded instruction decoded by the instruction decoding circuitry. In response to an authentication code generating class of instruction, the processing circuitry is configured to generate an authentication code associated with an authentication target value. The authentication code generating class of instruction comprises: an authentication code setting instruction, for which the processing circuitry is configured to write at least a portion of the generated authentication code to a destination register; and an authentication code checking instruction, for which the processing circuitry is configured to check whether at least a portion of the authentication code generated based on the authentication target value in response to the authentication code checking instruction corresponds to at least a portion of a reference authentication code obtained from a source register, and indicate a failed check 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 checking instruction, the processing circuitry is configured to generate an authentication code, when operating in a first code generation mode, by applying a code generating function to: a key; the authentication target value; at least one of a first modifier dependent on a stack pointer obtained from a stack pointer register, and a second modifier dependent on a program counter address obtained from a program counter register; and a further modifier dependent on a further value obtained from an architecturally visible register different from the stack pointer register and the program counter register.

[0023] The apparatus (for example, a data processing apparatus) is provided with decoder circuitry which is provided in combination with processing circuitry and is used to control the processing circuitry to perform processing operations. The decoder circuitry is responsive to instructions included in an Instruction Set Architecture (ISA). The ISA defines the set of instructions that can be used by a programmer or compiler to control the processing circuitry. Instructions included in the ISA are carefully chosen and are limited by the encoding space provided for the instructions. Often the inclusion of a new instruction may result in an existing instruction being removed and, as such, the designer of the ISA may require significant motivation to incorporate new instructions into the ISA.

[0024] An apparatus implementing a given ISA has freedom to choose the precise circuitry arrangements that are provided for each instruction in the ISA and the manner in which instructions of the ISA are implemented may vary from system to system. In other words, the ISA defines the function that the apparatus should achieve in response to a given instruction, but provides freedom to the designer to implement the instruction in any way and according to particular design constraints associated with the apparatus. Provision of a carefully chosen instruction as part of an ISA provides advantages in terms of improved code density for workloads utilising the instruction which, in turn, improves the overall system efficiency.

[0025] The authentication code generating class of instructions can be useful for protecting target values (e.g., addresses or other data values) that are stored out to memory. When a target value is stored to memory, the authentication code setting instruction may be used to generate an authentication code that is associated with the target value. The authentication code may, in some architectures be stored with the target value in the destination register. In other words, the destination register may be the register storing the authentication target value with at least a portion of the authentication code written to bits of the destination register that are unused by the authentication target value, e.g., in a 64-bit architecture the authentication code may be stored in redundant bits of an address that is used as the authentication target value. Alternatively, the authentication code, or at least a portion of the authentication code may be stored separately from the address value with additional metadata generated to define an association between the authentication code and the target value.

[0026] Regardless of the mechanism for storing the authentication code, once the target value is retrieved from memory it can be compared to the authentication code. If either the authentication code or the target value have been tampered with (or otherwise modified), then the authentication code checking instruction will identify that the authentication code and the target value do not match and will indicate a failed check. Because the code generating function, the key, and the modifiers are unknown, it is extremely difficult for an attacker to modify both the authentication code and the target value in such a way that the authentication code checking instruction could be tricked. The indication of the failed check may involve triggering an error response. Alternatively, the indication may involve writing an error value in place of the authentication target value, e.g., where the target value is an address writing a bad address in place of the authentication target value.

[0027] The authentication code generating class of instructions are operable in at least a first code generation mode. In some configurations, the first code generation mode is the only code generation mode that the instructions are able to operate in. 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 the authentication code generation class of instructions are able to operate.

[0028] The code generating function used to generate the authentication code accepts, as inputs, the authentication target value to be protected, a key, a first and / or second modifier value, and a further modifier value. Use of the modifier values in the code generating function can be helpful to reduce risk of a value protected with a given authentication code being used in a different scenario from the expected use of that value. For example, a function return address might be used for a branch other than the return branch for the function which caused the function return address to be set, or a data address pointer might be used in a different part of the program from the part expected to use that pointer. The modifier value can be based on a property associated with the current point of execution at which the authentication code is generated.

[0029] The first modifier value comprises a value dependent on the stack pointer obtained from the stack pointer register. By using a stack-pointer-dependent value as a modifier in the code generating function, different authentication codes may be generated based on the same value of the authentication target value when the authentication code setting instruction is executed at different stack depths (e.g. corresponding to different nested positions within a nested set of function calls), which can be helpful for detecting cases where the authentication target value is used in a different manner to the one expected. For example, when protecting a function return address as the authentication target value, the stack pointer based modifier can be useful to tie that particular function return address more closely to a particular instance of the function call. The second modifier comprises a value dependent on a program counter address obtained from a program counter register. By considering a program-counter-dependent modifier, the authentication codes may be tied more precisely to a specific instance of a function, reducing risk that an attacker is able to circumvent the authentication check by substituting the authentication target value and authentication code actually intended to be used for a given instance of a function with a previously captured pair of authentication target value and authentication code captured on a different instance of a function.

[0030] The inventors have recognized that, in addition to the use of at least one of the first and second modifiers described above, the strength of the authentication codes can be further improved if one or more additional data values, that are associated with the function from which the authentication code generating instruction is called, are used as modifiers. In particular, in the first code generation mode, a further modifier is used which depends on a further value obtained from an architecturally visible register different from the program counter register and stack pointer register. For example, a function may be called from a same point in code multiple times, e.g., due to a loop. Where the authentication code generating instruction is used for each instance of the function, e.g., to protect the function return address, a same authentication code may be generated on each iteration of the loop because both the program counter and the stack pointer may have a same value for each instance of the function call. However, where a function is called multiple times there is a likelihood that the data held in architecturally visible registers by that function may be different on each instance. As a result, a different authentication code may be generated on each instance making it more difficult for an attacker to circumvent the authentication check through a repeat attack.

[0031] It is not essential for both the authentication code setting instruction and the authentication code checking instruction to use the combination of the first and / or second modifier along with the further modifier. In practice, to ensure that the authentication code checking instruction generates the same authentication code value as the authentication code setting instruction when the authentication target value is used within the scope of the expected use case, software would need to ensure that the modifier values for the code generating function should be the same for both the authentication code checking instruction and the authentication code setting instruction. However, the responsibility to ensure that the modifiers are the same for the corresponding setting / checking instructions would lie with the software executed on the apparatus, not the hardware platform provided by the apparatus, which does not need to provide any circuit feature to guarantee that the same modifiers would be used for both instructions. Hence, the authentication code setting instruction may trigger the processing circuitry to carry out a first set of one or more operations implementing an authentication code setting function, and the authentication code checking instruction may trigger the processing circuitry to carry out a second set of one or more operations implementing an authentication code checking function. From the point of view of the hardware platform, each instruction triggers an independent set of operations, which take input values defined using registers or other parameters of the instruction, with no particular guarantee of how those values were generated by any earlier instructions. This means that, while it is useful for at least one of the authentication code setting instruction and the authentication code checking instruction to obtain as its second modifier value a value dependent on the program counter address, it is not necessary for both the authentication code setting function triggered by the authentication code setting instruction and the authentication code checking function triggered by the authentication code checking instruction to depend on a value obtained from the program counter register. Hence, it is not essential for the apparatus itself to comprise circuitry which requires both the authentication code setting / checking instructions to support a program-counter- dependent modifier.

[0032] In some configurations the architecturally visible register is a general purpose register. For example, the set of general purpose registers may be a set of architecturally defined registers that are visible and accessible for a programmer or compiler to access and modify. The architecturally defined registers may, in some configurations, correspond to a set of physically available registers. Alternatively, in some configurations a larger set of physical registers may be provided with the architecturally defined registers mapped onto those physical registers using register renaming techniques, for example, in order to support out-of-order execution of instructions.

[0033] In some configurations the architecturally visible register is a callee saved register. A callee saved register is a register that, by convention, is saved by a callee function. Where one function (a caller function) calls another (the callee function), there is a well-established convention, that will be known to the person skilled in the art, regarding which function (the caller function or the callee function) is responsible for ensuring the state of the registers on return from the callee function to the caller function. In particular, of the set of architecturally visible registers, a first subset of these registers are caller saved registers. It is the responsibility of the caller function to save any data in the caller saved registers that will be required by the caller function subsequent to a return from the callee function. The callee function is able to write data to the caller saved registers without first saving the original contents (e.g., the contents of those registers at the point the callee function was called) and without restoring the original contents of those registers prior to the function return. Of the architecturally visible registers, a second subset are the callee saved registers. The responsibility of ensuring that the contents of the callee saved registers is correct on a function return belongs to the callee function. Where the callee function requires use of one of the callee saved registers, it is the callee function that is responsible for first saving the contents of that register to memory and, prior to the function return, restoring the contents of the callee saved registers from memory. As a result, the caller function can be confident that immediately after the function return, the data values stored in the callee saved registers will be those that were present immediately prior to the function call. In addition to the caller and callee saved registers, a third subset of the architecturally saved registers are used as scratch registers. Scratch registers are used to pass data between the callee function and the caller function and neither the callee function nor the caller function are required to save or restore the contents of these registers. The use of a further modifier obtained from one of the callee saved registers is advantageous because, in a typical use case, the authentication code checking instruction is likely to be a first instruction called by a caller function subsequent to a function return. Because the callee saved registers will, by convention, already contain the data that was stored before the function call (e.g., the data values have been restored by the callee function and do not require one or more instructions to be executed by the caller function in order to restore those data values) the authentication code checking instruction is able to 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 the reference authentication code (e.g., the one that was generated by the authentication code setting instruction prior to the function call). In some configurations the processing circuitry is configured, when operating in the first code generation mode, to apply the code generating function to both of the first modifier and the second modifier. The authentication code is therefore generated in dependence on both the stack pointer and the program counter value. This further reduces the likelihood of an attacker being able to circumvent the authentication code checking instruction because at least one of the stack pointer and program counter is likely to be different between the different instances of the function.

[0034] As discussed, whilst the first code generation mode may be the only mode in which the authentication code generating class of instructions is able to operate, in some configurations the processing circuitry is configured to operate in a plurality of code generation modes, the plurality of modes comprising the first code generation mode and at least one further code generation mode, and the code generation mode is determined with reference to a control register. The control register may therefore be used to control one or more aspects of operation of the authentication code generating class of instruction. For example, the control register may be used to switch the authentication code generating class of instructions from operating in the first code generation mode as described above, into another code generation mode, e.g., a legacy mode.

[0035] In some configurations the processing circuitry is configured to operate at a plurality of exception levels, each of the exception levels having a different level of privilege; and the control register is accessible to software operating at one of the plurality of exception levels having a higher level of privilege and is inaccessible to software operating at exception levels of the plurality of exception levels having a lower level of privilege. Higher privileged software may, for example, comprise an operating system or a hypervisor. Lower level software may include, for example, one or more user applications or programs. The provision of the control register therefore allows software with the higher privilege level to control the operational mode of the authentication code generating class of instructions but prevents lower privilege level software from being able to modify the operational mode. In this way the high privilege level software may, for example, be able to cause the authentication code generating class of instructions to use higher level of security (e.g., a greater number of modifiers) in situations where software is calling an untrusted function and to use a lower level of security (e.g., a smaller number of modifiers) when software is calling a trusted function. The operational modes may be set by a system designer to control various features of the authentication code generating class of instructions. In some configurations the processing circuitry is configured, when operating in the at least one further code generation mode: to apply the code generating function to the authentication target value, and the at least one of the first modifier and the second modifier; and to exclude the further modifier when applying the code generating function. In other words, the control register can be used to switch the use of the further modifier on and off. The use of the control register to switch between different authentication modes allows for a single authentication code setting and a single authentication code checking instruction to be provided with different functionality being achieved by those instructions dependent on the value in the control register. This, in turn, reduces the demand on space in the ISA for the authentication code generating class of instructions and provides the means for future expansion of the capabilities of the authentication code generating class of instructions as additional modifiers could be incorporated based on a value of control data stored in the control register.

[0036] In some configurations the at least one further code generation mode comprises: a first further code generation mode in which the processing circuitry is configured to apply the code generation function to the authentication target value and the first modifier; and a second further code generation mode in which the processing circuitry is configured to apply the code generation function to the authentication target value, the first modifier and the second modifier. The authentication code generation class of instructions may be further operable in one or more additional modes as controlled by the control register.

[0037] In some configurations the control register defines a subset of code generation modes; and the processing circuitry is responsive to a mode selection parameter specified in the authentication code generating class of instruction to select a code generation mode from the subset of code generation modes. The control register can therefore be used to define modes supported by the hardware or to allow the higher privileged software to control the modes that are accessible to the lower privilege software. The mode selection parameter may be specified as an immediate value and can therefore be used by a programmer or compiler to specify the code generation mode from the subset of modes that are supported by the hardware or that are currently available. Where the mode selection parameter selects a mode that is disallowed by the control register, the processing circuitry may respond by signalling an error or by setting the authentication code generating mode to the mode using the greatest security level (e.g. the greatest number of modifiers).

[0038] In some configurations the control register comprises modifier identification information and the further modifier is determined based on the modifier identification information. The further modifier identification information may take any form and may be an indication that the further modifier is to be used, or an indication of where the further modifier is specified or a function or format to be used to interpret the architecturally visible register for use as the further modifier.

[0039] In some configurations the modifier identification information identifies the architecturally visible register. In general, the architecture may provide a plurality of architecturally visible registers and the modifier identification information may specify one of those architecturally visible registers as the architecturally visible register from which the further modifier is to be obtained. The identification of the architecturally visible register may be an explicit specification of the architectural register or it may be information from which a specifier of the architectural register may be derived.

[0040] In some configurations the further modifier is one of an identified set of one or more further modifiers, and the control register comprises a set size identifier to identify a size of the set. In other words, the control register specifies how many further modifiers are to be used. Including the size of the set in the control register provides the means to expand the implementations of the authentication code generating class of instructions that can be provided in future implementations without requiring future modifications to the ISA.

[0041] In some configurations the control register identifies, for each one of the further modifiers of the set, a corresponding architecturally visible register on which that one of the further modifiers depends. The control register may implement the set size identifier and the indication of the corresponding architecturally visible register using a discrete sets of bits within the control register. Alternatively, in some configurations, the control register may be provided with a set of bits, e.g., one for each architecturally visible register (or each callee saved register), the bits providing an indication as to whether that register is to be used as a modifier. In such an implementation, the set size identifier may be encoded in the same bits as those used to identify whether each architecturally visible register is to be used as a modifier, e.g., the set size is equal to the number of set bits.

[0042] Whilst the architecturally visible register may be defined either in the control register or the authentication code generating class of instructions, in some configurations the processing circuitry is configured to perform a selection of the architecturally visible register from a plurality of architecturally visible registers. The selection may therefore be performed without the direct control of the programmer.

[0043] In some configurations the selection is based on a selection value other than any register specifier encoded in the authentication code generating instruction. For example, the selection value may be controlled based on one or more selection schemes implemented within the processing circuitry. The selection value may be stored in the control register and / or controlled by higher privileged software.

[0044] In some configurations the selection value is modified by applying a modification in response to the authentication code setting instruction and by removing the modification in response to the authentication code checking instruction. The selection value may therefore be modified each time an authentication code is generated and removed each time the authentication code is checked. Modifying the selection value each time introduces a further level of variability in the codes generated making it even more difficult for an attacker to circumvent the authentication codes.

[0045] The modification may be variously defined and in some configurations the modification is based on a counter value incremented in response to the authentication code setting instruction and decremented in response to the authentication code checking instruction. The counter value may be directly used to identify the architecturally visible register, e.g., by specifying a register identifier. Alternatively, the architecturally visible register identifier may be determined based on a hash or other modification of the counter value. 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 the program counter value. The bits of the stack pointer and / or the program counter value selected may be based on the counter value and / or the counter value may be incorporated in the hash generation.

[0046] Whilst the further modifier may be directly read from the architecturally visible register or based on a hash of the value in the architecturally visible register, in some configurations the architecturally visible register is one of a plurality of selected architecturally visible registers and the further modifier is dependent on a hash of values obtained from one or more of the plurality of selected architecturally visible registers. Combining values from plural of the architecturally visible registers further reduces the likelihood of an attacker being able to circumvent the authentication codes by further reducing the likelihood that a same authentication code will be generated repeatedly.

[0047] In some configurations the processing circuitry is configured to retain an indication of the selection in a further register. Retaining the selection of the architecturally visible registers in registers, e.g., rather than storing the selection in memory, makes it difficult for an attacker to identify which selection was used by the processing circuitry when generating the authentication code.

[0048] The further register may be a specifically provided register. Alternatively, in some configurations the further register is one of: the stack pointer register and the selection is recorded using one or more unused bits of the stack pointer register; and the program counter register and the selection is recorded in one or more unused bits of the program counter register. Utilising the unused bits of the stack pointer register or the program counter register avoids the need for a specifically provided register whilst still allowing the selection to be recorded without being saved to memory.

[0049] In some configurations in response to a non-sequential change of program flow to a branch target address being triggered when a branch target check is enabled, the processing circuitry is configured to trigger an error handling response when the instruction at the branch target address is not a member of a permitted class of branch target instructions; and the authentication code setting instruction is one of said permitted class of branch target instructions. Supporting a branch target check can be helpful to reduce likelihood of an attacker being able to tamper with a target address of a branch to cause branching into an arbitrary point in a program not intended to be a branch entry point. By restricting valid branch entry points to addresses where the instruction at the branch target address is one of a limited set of types of instructions allowed to act as branch target instructions, security can be improved. It can be particularly useful to allow the authentication code setting instruction to also act as one of the permitted class the branch target instructions, because often in implementations employing the authentication code generating instructions to protect function return addresses, the authentication code setting operation is the first operation performed after calling the function, and so having a single instruction perform the authentication code setting operation and also act as a valid “landing pad” for a branch target avoids the need to include two separate instructions for this purpose, thus improving program code density. However, in an instruction set architecture with restricted register availability at the end of a function call, the need to comply with function calling conventions can require additional saving / restoring of register contents to / from the stack which can, in some cases (e.g. where the authentication code setting / checking instructions are to be separated by a large distance in the program code) make it difficult to use the authentication code setting instruction as the very first instruction in the program code executed after calling the function, if the correction based on the correction value was not supported by one of the authentication code setting / checking instructions. This would negate the benefit of the option of using a combined instruction as both an authentication code setting instruction and a permitted branch target instruction. Hence, the option of applying a correction based on the correction value for generating one of the first / second modifiers can be particularly useful when a combined authentication code setting and branch target instruction is supported, because the correction helps to preserve the improvements in code density achievable using the combined authentication code setting and branch target instruction.

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

[0051] Particular configurations will now be described with reference to the figures.

[0052] Figure 1 schematically illustrates an example of a data processing apparatus 2. The data processing apparatus has a processing pipeline 4 (an example of processing circuitry, which could for example form part of a CPU (Central Processing Unit)). The processing circuitry 4 is for executing instructions defined in an instruction set architecture (ISA) to carry out data processing operations represented by the instructions. The processing pipeline 4 includes a number of pipeline stages. In this example, the pipeline stages include a fetch stage 6 for fetching instructions from an instruction cache 8; a decode stage 10 (an example of instruction decoding circuitry) for decoding the fetched program instructions to generate micro-operations (decoded instructions) to be processed by remaining stages of the pipeline; an issue stage 12 for checking whether operands required for the micro-operations are available in a register file 14 and issuing micro-operations for execution once the required operands for a given micro-operation are available; an execute stage 16 for executing data processing operations corresponding to the micro-operations, by processing operands read from the register file 14 to generate result values; and a writeback stage 18 for writing the results of the processing back to the register file 14. It will be appreciated that this is merely one example of possible pipeline architecture, and other systems may have additional stages or a different configuration of stages. For example, in an out-of-order processor a register renaming stage could be included for mapping architectural registers specified by program instructions or micro-operations to physical register specifiers identifying physical registers in the register file 14. In some examples, there may be a one-to-one relationship between program instructions defined in the ISA that are decoded by the decode stage 10 and the corresponding micro-operations processed by the execute stage. It is also possible for there to be a one-to-many or many-to-one relationship between program instructions and micro-operations, so that, for example, a single program instruction may be split into two or more micro-operations, or two or more program instructions may be fused to be processed as a single micro-operation.

[0053] The execute stage 16 includes a number of processing units, for executing different classes of processing operation. 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 the registers 14; a floating point unit 22 for performing operations on floating-point values; a branch unit 24 for evaluating the outcome of branch operations and adjusting the program counter which represents the current point of execution accordingly; and a load / store unit 26 for performing load / store operations to access data in a memory system 8, 30, 32, 34. The execute stage 16 also includes a code generating unit 27 for generating an authentication code in response to the authentication code generating class of instructions. For example, the code generating unit 27 may implement a given cryptographic hash function such as SHA or QARMA.

[0054] In this example, the memory system includes a level one data cache 30, the level one instruction cache 8, a shared level two cache 32 and main system memory 34. It will be appreciated that this is just one example of a possible memory hierarchy and other arrangements of caches can be provided (and in some implementations, there may not be any such caches 30, 32 at all). The specific types of processing unit 20 to 27 shown in the execute stage 16 are just one example, and other implementations may have a different set of processing units or could include multiple instances of the same type of processing unit so that multiple micro-operations of the same type can be handled in parallel. It will be appreciated that Figure 1 is merely a simplified representation of some components of a possible processor pipeline implementation, and the processor may include many other elements not illustrated for conciseness.

[0055] In some examples, the ISA supported by the processing circuitry 4 may be a 32-bit architecture, for which scalar general purpose registers are 32-bit registers and addresses used to identify memory system locations are 32-bit addresses. The registers 14 may comprise a set of general purpose registers available for use for providing general purpose operands for instructions executed by the processing circuitry 4. The registers 14 may also comprise system registers for storing control state information. For example, the ISA may support sixteen general purpose registers R0-R15, of which R0- R3 may be conventionally used as scratch registers to pass parameters between functions, R4-R11 may be conventionally used as callee saved registers, R12 may be used as a caller saved register, and R13, R14 and R15 are also used as special purpose registers:

[0056] R13: SP (stack pointer register), for storing a stack pointer address pointing to a location on a stack data structure stored in the memory system.

[0057] R14: LR (link register), for storing a function return address for a function. The function return address is set when calling a function and represents the address to which program flow should return following completion of the function.

[0058] R15: PC (program counter register), for storing a program counter address representing an address of an instruction at a current point in program flow.

[0059] It will be appreciated that other registers could also be supported and that the above architecture is just one example of a possible ISA and that alternative examples may use a 64-bit architecture or an alternative 32-bit architecture having a different number of general purpose registers defined in a different way.

[0060] Figure 2 illustrates an example of program flow involving nested function calls. The flow begins at the instruction address “#addl” corresponding to a branch-with-link instruction BL used to make a function call to a given function, fn A. The BL instruction is a calling branch instruction, which when decoded causes the processing circuitry 4 to write a function return address (the address of the next sequential instruction after BL) to the link register (LR, an alias for R14 as noted above). In this example, instructions comprise 32 bits, so the address of the next instruction is #addl + 4 bytes. Hence, the value of #addl + 4 is pushed to the link register as a function call address. It will be appreciated that the interval between instruction addresses would depend on the number of bits used in the instructions. For example, in an instruction set with 64-bit instruction encodings, the return address could be #addl + 8 bytes.

[0061] The program flow then continues through fn A before encountering another BL instruction at the instruction address #add2 to call another function, fn B. Hence, as the BL instruction at #add2 would overwrite the link register, prior to executing the BL at #add2, the software includes at least one store instruction to save the contents of the link register (LR) (i.e. the return address #addl+4 corresponding to fn A) to a software-maintained stack data structure in memory. In some cases, if other register contents associated with fn A are at risk of being overwritten by fn B, these may also be stored to the stack before calling fn B. The stack pointer in the SP register (R13) can be used to identify the addresses in memory to which the contents of the LR and any other registers are to be written. When data is pushed to the stack, the stack pointer is updated accordingly.

[0062] After saving any register contents that need to be preserved for fn A to the stack, the BL instruction at #add2 is executed which causes the address (#add2 + 4) of the next sequential instruction to be written to the link register as another function return address, and causes the program flow to branch to the target address of that BL instruction, corresponding to the start 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 taken directs the program flow back to #add2 + 4. In other words, the section of code in fn A is resumed from the point after the instruction that called fn B. Having returned 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 the stack pointer is updated when pushing data to the stack (hence, the stack is managed as a last-in- first-out structure). The return address (#addl+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 calling fn B). At the end of fn A, another return branch instruction is encountered and this causes a return branch to a target address obtained from the LR, i.e., program flow now resumes from #addl + 4, the instruction after the calling branch which originally called fn A.

[0063] To ensure that “callee” function code provided by one developer can be called by “caller” program code provided by another developer, the ISA supported by the processing circuitry 4 may define, or be associated with, certain function calling conventions setting agreed rules on how the general purpose registers can be used by the caller code and callee code respectively. This helps the developers of both the caller code and the callee code understand whether it is necessary for them to save or restore contents of certain registers to / from the stack before or after a function call or function return. For example, it may be agreed that general purpose registers R0-R3 are available for use as function arguments or function return values, for allowing the caller and callee code to pass values between each other. Registers R4-R11 may be callee-saved registers which are required to remain uncorrupted at the end of the function, so that upon 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 was made. Hence, if the callee code wishes to modify the contents of the callee-saved registers R4-R11 (relatively likely 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 the caller-defined contents, 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 may be a caller-saved register which is allowed to be corrupted during the function call, so that the caller code cannot guarantee that, on returning from the function, R12 still stores the same value that was specified in register R12 before calling the function. Hence, the callee code implementing the function does not need to include any stack save / restore instructions for protecting the contents of register R12, and instead if the caller code needs to rely on retaining the value of R12 from before the function call, the caller code would need to include a stack push instruction before the function calling branch BL for calling the function, and include a stack pop instruction after the corresponding function return. Registers R13-R15 are reserved for special purposes, as the LR, SP and PC respectively as mentioned above.

[0064] Hence, the function calling convention constrains the way in which registers can be used by the software executing on the apparatus 2. It will be appreciated that the particular split of registers into caller-saved registers and callee-saved registers may vary and so the example above with R4-R11 as callee-saved registers and register R12 as caller-saved register is just one possible implementation .

[0065] It will also be appreciated that the function calling convention may not necessarily be reflected in any particular circuitry of the apparatus 2, and may merely be an understood set of rules to be observed by software developers when developing software to execute on the apparatus 2. However, once an understood function calling convention is established, the function calling convention commonly in use for existing software code may be a constraint to be considered when designing future updates to the ISA supported by the 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.

[0066] Figure 2 shows how nesting of function calls may require software to include instructions for saving / restoring register contents to / 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 the registers 14, because depending on the system implementation an attacker may be able to gain physical access to the memory system to tamper with the stored information and / or may be able to compromise program code involving memory usage errors or other security vulnerabilities to cause data stored out in the stack structure to be overwritten incorrectly. Such attacks may risk incorrect program function and loss of data security.

[0067] For example, if the return address pushed from the link register is modified while stored on the stack, then when it is later loaded back into the link register the corresponding return branch will branch to the wrong location in memory, causing execution of an incorrect instruction which could potentially be an instruction from “gadget” code provided by the attacker to cause malicious operations to be performed. This can be known as a “return oriented programming” (ROP) attack. Similar attacks may be a risk when a data address pointer is stored to the stack from a register, and is modified while stored in the memory system, so that after subsequently restoring that pointer to the registers, a load / store operation is performed to the wrong address in memory, potentially allowing access to a memory system location that should not have been accessed.

[0068] Therefore, it can be useful for the ISA to provide a countermeasure against such attacks. As shown in Figures 3 and 4, the instruction decoder 10 and processing circuitry 4, 16 may support a class of authentication code generating instructions which includes at least one variant of an authentication code setting instruction and at least one variant of an authentication code checking instruction. It is possible that other types of authentication code generating instructions could also be supported.

[0069] In general, each variant of authentication code generating instruction, when decoded by the instruction decoding circuitry 10, controls the processing circuitry 4 to generate an authentication code corresponding to an authentication target value obtained from a source register, based on a code generating function applied to the authentication target value, a cryptographic key, at least one of a first modifier value and a second modifier value, and a further modifier value.

[0070] If the authentication code generating instruction is an authentication code setting instruction (PAC instruction), as illustrated in figure 3, at least a portion of the generated authentication code is written to a destination register. The destination register may be a general purpose register separate from the register used as the source register providing the authentication target value or an unused portion of the source register providing the authentication target value.

[0071] If the authentication code generating instruction is an authentication code checking instruction (AUT instruction), as illustrated in figure 4, at least a portion of the generated authentication code (generated from the authentication target value obtained from a first source register) is compared with at least a portion of a reference authentication code obtained from a source register which may be the first source register or a different general purpose register to the register providing the authentication target value, and if the generated authentication code does not match the reference authentication code, then an error response is triggered. For example, the processing circuitry 4 triggers an exception or fault condition which may cause interruption of processing and branching to an exception handler to deal with the cause of the fault.

[0072] In some examples, a variant of the PAC / AUT instructions can be provided where the source register used to provide the authentication target value is a fixed register which is implicit as part of the ISA instruction definition, so does not require a register field to identify the source register providing the authentication target value. For example, for one variant, the authentication target value could implicitly be the link register (LR) so that the authentication target value protected against tampering using the authentication code is a function return address. It is also possible to provide at least one variant of the PAC / AUT instructions for which a register field instruction encoding specifies which source register provides the authentication target value. This could be used, for example, for cases where a data address pointer is to be protected using an authentication code.

[0073] Similarly, the destination register of the PAC instruction or the second source register providing the reference authentication code for the AUT instruction could be either an implicitly defined predetermined general purpose register not requiring a specific register field in the instruction, or could be variably selected by software using a register field encoded in the instruction. Given the function calling convention mentioned above, it can be useful if the register used for the destination register of the PAC instruction or the second source register of the AUT instruction is one of the caller-saved registers, e.g. register R12 in the example above, as this avoids any need to restore contents of R12 after executing the AUT instruction, which could be helpful to enable use of combined branch / AUT instructions as discussed later on. Hence, in some examples the destination register of the PAC instruction and second source register of the AUT instruction may be fixed to be register R12 by default.

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

[0075] The first, second and further modifier values are used to tweak the cryptographic hash function used as the code generating function, to increase the likelihood that even if the authentication target value and key are the same for two different function call scenarios, different authentication codes can be generated in the code generating function to allow the authentication code to be specific to a particular instance of a function call. This greatly reduces the probability that an attacker can circumvent the authentication code check of the AUT instruction by saving an authentication code generated for one instance of a function call and reusing that previously generated authentication code when trying to seek authentication of a tampered authentication target value in another instance of a function call. The first modifier value for the PAC and AUT instructions depends on a current stack pointer value specified in the stack pointer register SP at the time the PAC / AUT instructions are executed. For at least one of the PAC and AUT instructions (not necessarily both as shown in subsequent examples), the second modifier value depends on a current program counter address value from the PC register. By using one or both stack-pointer- dependent and program-counter-dependent tweaks to the code generating function, this can provide greater security because the authentication code is tied to a specific instance of a function at a given address (represented by the program counter address) when called at a given function call depth (represented by current value of the stack pointer), which given a reasonable secure code generating function (such as SHA or QARMA) makes it statistically improbable that an attacker can substitute a previously saved authentication code for a current authentication code and use that to circumvent authentication code checks. The inclusion of the further modifier based on a value obtained from an architecturally visible register different to the stack pointer register and different to the program counter register provides a further degree of variation in the authentication codes generated. In particular, for repeated instances of a function call from a given address at a particular call depth (e.g., due to a loop), the first and second modifiers would be the same and would not introduce variation into the repeated generation of the authentication codes. On the other hand, the use of the further modifier which is dependent on the data stored in the architecturally visible register (something that may vary even when the program counter value and the call stack depth have not changed) enables a variation in the generated authentication codes.

[0076] The particular way in which the modifier values are used to tweak the cryptographic hash function can vary depending on the particular algorithm used. However, in general a cryptographic hash function may accept as an input at least one modifier value. Hence, the at least one modifier value of the cryptographic hash function may be set based on bits obtained from the first modifier value and / or second modifier value, and the further modifier value. For example, the first modifier value, the second modifier value, and the further modifier value can be concatenated to form the modifier for the cryptographic hash function (and if necessary to expand the concatenated value to the required bit width, padded 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 modifier value, the second modifier value, and the further modifier value is greater than the modifier width supported by the cryptographic hash function used, some bits could be omitted or bits from the modifier values could be combined using a logical operation such as a Boolean function. In an expected use case, at least one instance of the PAC instruction would be included in program code at, or shortly after, entry into a callee function (e.g. at or shortly after the points marked fn A or fn B in Figure 2), and at least one instance of an AUT instruction would be included in software code at, or shortly before, the return branch at the end of a callee function (e.g. at or just before the return branch back to #add2 + 4 or #addl + 4 in Figure 2). Having generated the authentication code in response to the PAC instruction, if necessary to free up the register to be used for other values, a subsequent stack push instruction may push the generated authentication code to the stack and a stack restore instruction may restore the authentication code to a register before executing the corresponding AUT instruction. Although this may make the authentication code itself vulnerable to attack, the cryptographic hash function may be designed to make it sufficiently improbable that the attacker can modify both the authentication target value (e.g. function return address or data address pointer) and the corresponding authentication code in a manner which enables the authentication code generated from the tampered authentication target value and the tampered authentication code used as reference authentication code for the AUT instruction to match in the authentication code check.

[0077] Figure 5 schematically illustrates an apparatus according to some configurations of the present technique. The apparatus is operable in a plurality of different code generation modes which are controlled by control data 54 provided in a control register. The control data 54 controls switch circuitry 48, switch circuitry 50, and switch circuitry 52 to determine which modifiers will be provided to the authentication code generation circuitry 56. The authentication code generation circuitry 56 receives a target value 42, an authentication key 60, and one or more modifiers from switch circuitry 48, switch circuitry 50, and switch circuitry 52 under control of the control data 54. The authentication code generation circuitry 56 generates an authentication code 58 using the input values and modifiers using a secure code generating function (such as SHA or QARMA).

[0078] The modifiers that may be provided to the authentication code generation circuitry include a first modifier, a second modifier, and a further modifier. The first modifier is obtained from a stack pointer (SP) value held in a stack pointer register 44(13). In the illustrated configuration, the stack pointer register 44(13) is general purpose register R13. The second modifier is obtained from a program counter (PC) value obtained from a program counter register 44(15). In the illustrated configuration, the program counter register 44(15) is R15. The further modifier is obtained from one of the callee saved registers. As discussed above, the callee saved registers comprise general purpose registers R444(4) to R11 44(11). The callee saved registers from which the further modifier is selected is determined by selection circuitry 46 based on n-bit (e.g., 3 -bit) selection data. The n-bit selection data selects one of the callee saved registers, for example, where 3-bit selection data is used, the 3 -bit selection data is able to take 8 different values and is therefore used to distinguish between the 8 different callee saved registers.

[0079] The apparatus is operable in at least a first code generation mode in which the control data 54 triggers the switch circuitry 48 to forward one of the callee saved registers, as selected by the selection circuitry 46, to the authentication code generation circuitry 56. The control data 54 also causes at least one of the switch circuitry 50 and the switch circuitry 52 to forward one of the corresponding registers to the authentication code generation circuitry 56 to generate the authentication code 58. The apparatus is also operable in at least one further mode dependent on the value of the control data which can independently select which, in combination with the 3 -bit selection data, is able to select different combinations of the stack pointer register 44(13), the program counter register 44(15), and the callee saved registers R4 44(4) to Rll 44(11) to be forwarded to the authentication code generation circuitry in response to an authentication code generating class of instruction being decoded by decoder circuitry.

[0080] Figure 6 schematically illustrates a modification to the apparatus according to some configurations of the present techniques. The apparatus comprises authentication code generation circuitry 56 which, as described in relation to figure 5 receives a target value 42, a key 60, a set of modifiers. The authentication code generation circuitry 56 generates an authentication code 58 based on these inputs. As described in relation to figure 5, the modifiers provided to the authentication code generation circuitry 56 are controlled by control data 54 stored in a control register in combination with further control data 62. The control data controls selection circuitry 64, switch circuitry 50, and switch circuitry 52 to determine which modifiers will be provided to the authentication code generation circuitry 56.

[0081] The modifiers that may be provided to the authentication code generation circuitry include at least one of a first modifier and a second modifier, and a further modifier. The first modifier is obtained from a stack pointer (SP) value held in a stack pointer register 44(13). In the illustrated configuration, the stack pointer register 44(13) is general purpose register R13. The second modifier is obtained from a program counter (PC) value obtained from a program counter register 44(15). In the illustrated configuration, the program counter register 44(15) is R15. The further modifier is obtained from one of the callee saved registers. As discussed above, the callee saved registers comprise general purpose registers R4 44(4) to Rll 44(11). The callee saved registers from which the further modifier is selected is determined by selection circuitry 64 based, in combination on the value N provided by the control data 54, and the further control data 62. The parameter N, provided by the control data 54, defines the number of modifiers to be passed by the selection circuitry 64 to the authentication code generation circuitry 56. The further control data 62 identifies the N specific modifiers that are to be passed by the selection circuitry 64 to the authentication code generation circuitry 56. In particular, the further control data provides an indication of further modifier 1, further modifier 2, ... , and further modifier N. The selection circuitry 64 receives the N further modifier identifiers (which may each identify a different callee saved register or, alternatively, may include 2 or more of the further modifier identifiers identifying a same callee saved register) and passes those registers to the authentication code generation circuitry.

[0082] Figure 7 schematically illustrates a further variation on the apparatus according to some configurations of the present techniques. The apparatus is provided with authentication code generation circuitry 56 to generate an authentication code 58 based on a target value 42 and a key 60. The authentication code generation circuitry 56 also generate the authentication code based on a set of modifiers. As discussed with reference to figures 5 and 6, the further modifiers are dependent on the control data 54 and may include at least one of a first modifier and a second modifier, and a further modifier. The first modifier is obtained from a stack pointer (SP) value held in a stack pointer register 44(13). In the illustrated configuration, the stack pointer register 44(13) is general purpose register R13. The second modifier is obtained from a program counter (PC) value obtained from a program counter register 44(15). In the illustrated configuration, the program counter register 44(15) is R15. The selection of the further modifier is controlled by switch circuitry 70 in dependence on the control data 54. The further modifier is identified by n-bit selection data (e.g., 8-bit selection data) which identifies plural ones of the callee saved registers. For example, where 8-bit selection data is used, each bit may be used to identify one of the callee saved registers and indicating whether that one of the callee saved registers is selected to form part of the further modifier. Based on the values of the n-bit selection data one or multiple of the callee saved registers may be selected by selection circuitry 66 to contribute to the further modifier. Selected registers of the callee saved registers are passed, by the selection circuitry 66, to the hash circuitry 68 which generates a hash value based on the combination of callee saved registers received from the selection circuitry. The output of the hash circuitry 70 is provided to the authentication code generation circuitry 56 for use in the generation of the authentication code 58.

[0083] Figure 8 schematically illustrates the generation of selection data, for example, the n-bit selection data of figure 5 or figure 7 that may be used to select which of the callee saved registers contribute to the further modifier value. Figure 8(A) illustrates a first method of generating selection data based on receipt of a stack pointer value of a program counter value 80. The stack pointer of program counter value 80 is passed to lossless hash generation circuitry 84 along with the old value of the selection data 82. The old selection data 82 is combined with the stack pointer of program counter value 80 using the lossless hash circuitry 84 to generate new selection data 86. For example, the lossless hash generation circuitry 84 may comprise XOR circuitry configured, for each bit of the old selection data 82, to receive a corresponding bit of the stack pointer or program counter value 80, and to generate an XOR of those bits. The resulting bit value could be reversed by passing the output selection data 86 to the hash generation circuitry 84 along with a same value of the stack pointer or the program counter value 80. Modifying the selection data as set out in figure 8(A) in response to each instance of the authentication code setting instruction and each instance of the authentication code checking instruction allows the selection data to cycle through a set of values in response to the authentication code generating instructions and that cycle to be reversed in response to the authentication code checking instructions.

[0084] Figure 8(B) schematically illustrates an alternative configuration in which the hash generation circuitry 94 receives a stack pointer value 90 and a program counter value 98 along with the old selection data 92 and, based on a combination of the stack pointer 90m the program counter value 98, and the old selection data 92 generates selection data 96. As in the case of figure 8(A), the hash algorithm is a lossless hash algorithm that enables the modification to the selection data to be reversed to allow the selection data to cycle through a set of values in response to the authentication code generating instructions and for that cycle to be reversed in response to the authentication code checking instructions.

[0085] Figure 9 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 bits and the least significant bits of the stack pointer or the program counter register may not be used. This may be the case, e.g., where a 64-bit register is provided for the stack pointer and / or the program counter register and where the range of available addresses does not require all 64-bits to uniquely identify an address. Similarly, the stack pointer or the program counter value 102 may specify regions of memory in a coarse manner, for example, based on a cache line size. Hence, the least significant bits of the stack pointer and the program counter register may be unused. Storing the selection data 100 in the unused bits of the stack pointer and / or the program counter register 102 avoids the need to either provide a dedicated register for the selection data 100, or to store the selection data 100 to memory.

[0086] Figure 10 schematically illustrates a sequence of steps carried out in response to an authentication code generating class of instruction. Flow begins at step S100 where it is determined whether an authentication code generating class of instruction has been received. If, at step S100, it is determined that an authentication code generating class of instruction has been received, then flow proceeds to step S 102. At step S 102, the authentication key is retrieved before flow proceeds to step S 104. At step S 104, the authentication target value is retrieved before flow proceeds to step S106. At step S106, at least one of a first modifier and a second modifier is retrieved before flow proceeds to step S108. The first modifier is dependent on a stack pointer obtained from a stack pointer register, and the second modifier is dependent on a program counter obtained from a program counter register. At step S108, a further modifier is retrieved form an architecturally visible register that is different from the stack pointer register and the program counter register before flow proceeds to step SI 10. At step SI 10, the authentication code is generated based on the key, the authentication target value, at least one of the first modifier and the second modifier and the further modifier. Figure 11 schematically illustrates a sequence of steps carried out in accordance with some configurations of the present techniques in response to receipt of an authentication code generating class of instructions. Flow begins at step S120 where a type of the authentication code generating class of instructions is determined. If, at step S120, it is determined that the type of the authentication code generating class of instructions is an authentication code setting instruction, then flow proceeds to step S132. At step S132, the authentication code is generated (for example, following the process set out in steps S102-S110 of figure 10). At least a portion of the authentication code is then stored to a register. If, at step S120, it was determined that the authentication code generating class of instruction is an authentication code checking instruction, then flow proceeds to step S122. At step S122, the authentication code is generated (for example, following the process set out in steps S102-S110 of figure 10). Flow then proceeds to step S124 where a reference authentication code is retrieved from a source register before flow proceeds to step S126. At step S126, at least a portion of the reference authentication code is compared to at least a portion of the generated authentication code and it is determined if the reference authentication code corresponds to the generated authentication code. If, at step S126, it is determined that the reference authentication code corresponds to the generated authentication code, then flow proceeds to step S128 where the processing circuitry proceeds with further instructions. If, at step S126, it is determined that the reference authentication code corresponds to the generated authentication code, then flow proceeds to step S130 where the failed authentication check is indicated. The failed authentication check may be indicated, for example, through an error being triggered, or data being stored, e.g., in the authentication target value, to cause an error to be triggered at a subsequent point.

[0087] Figure 12 schematically illustrates a sequence of steps carried out by an apparatus in accordance with some configurations of the present techniques. Flow begins at step S140 where it is determined if an authentication code generating class of instructions has been received. If, at step S 140, it is determined that the authentication code generating class of instruction has not been received, then flow remains at step S140. If, at step S140, it is determined that an authentication code generating class of instruction has been received, then flow proceeds to step S142. At step S142 control data is retrieved, for example, form a control register, before flow proceeds to step S144. At step S144, it is determined whether the control data indicates that the first code generating mode is to be used. If, at step S 144, it is determined that the first code generating mode is to be used, then flow proceeds to step SI 50. At step S150, the modifiers are set to include at least one of a first modifier based on the stack pointer and a second modifier based on the program counter, and a further modifier and a further modifier based on an architecturally visible register different from the stack pointer register and the program counter register. Flow then proceeds to step S158 where a code generating function is applied to generate the authentication code based on a target value, a key, and the modifiers.

[0088] If, at step S144, it was determined that the control data does not indicate the first code generating mode, then flow proceeds to step S 146 where it is determined whether the control data indicates that the first further code generating mode is to be used. If, at step S 146, it is determined that the first further code generating mode is to be used, then flow proceeds to step S 152. At step S152, the modifiers are set to the first modifier which is based on the stack pointer. Flow then proceeds to step S158 where a code generating function is applied to generate the authentication code based on a target value, a key, and the modifiers.

[0089] If, at step S146, it was determined that the control data does not indicate the first further code generating mode, then flow proceeds to step S 148 where it is determined whether the control data indicates that the second further code generating mode is to be used. If, at step S148, it is determined that the second further code generating mode is to be used, then flow proceeds to step S154. At step S154, the modifiers are set to the first modifier which is based on the stack pointer and the second modifier which is based on the program counter value. Flow then proceeds to step S158 where a code generating function is applied to generate the authentication code based on a target value, a key, and the modifiers.

[0090] If, at step S148, it was determined that the control data does not indicate the second further code generating mode, then flow proceeds to step S156 where modifiers are set to a default minimal level. Flow then proceeds to step S158 where a code generating function is applied to generate the authentication code based on a target value, a key, and the modifiers. Figure 13 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 730, optionally running a host operating system 720, supporting the simulator program 710. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, Pages 53 - 63.

[0091] To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 730), some simulated embodiments may make use of the host hardware, where suitable. The simulator program 710 may 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 a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 710. Thus, the program instructions of the target code 700 described above, including the authentication code generating class of instructions described earlier, may be executed from within the instruction execution environment using the simulator program 710, so that a host computer 730 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features.

[0092] The simulation program 710 may include instruction decoding program logic 712 for decoding instructions of the target code 700 to map them to corresponding sequences of instructions defined according to the native instruction set architecture supported by the host hardware 730. Hence, the instruction decoding program logic 712 may include logic for generating sequences of host instructions corresponding to the PAC / AUT instructions described earlier. Register simulating program logic 714 of the simulator program 710 may simulate access to registers by the target code 700, e.g. by maintaining a data structure in registers or memory of the host hardware 730 which emulates the set of architectural 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 PAC / AUT instructions mentioned earlier can be remapped by the register simulating program logic 714 to access requests which reference particular locations in host storage provided by host hardware 730.

[0093] In brief overall summary there is provided an apparatus, a method, and a computer program. The apparatus is provided with instruction decoding circuitry to decode instructions and processing circuitry to perform a processing operation in response to a decoded instruction. In response to an authentication code generating instruction, the processing circuitry is configured to generate an authentication code associated with an authentication target value. For at least one type of the authentication code generating instruction, the processing circuitry is configured to generate an authentication code, when operating in a first code generation mode, by applying a code generating function to: a key; the authentication target value; a first modifier dependent on a stack pointer, and / or a second modifier dependent on a program counter address; and a further modifier dependent on a further value obtained from an architecturally visible register different from the stack pointer register and the program counter register.

[0094] In the present application, the words “configured to.. .” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation.

[0095] In the present application, lists of features preceded with the phrase “at least one of’ mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination.

[0096] Although illustrative configurations of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise configurations, and that various changes, additions and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims. For example, various combinations of the features of the dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.

Claims

WE CLAIM:

1. An apparatus comprising: instruction decoding circuitry to decode instructions; and processing circuitry to perform a processing operation in response to a decoded instruction decoded by the instruction decoding circuitry, wherein: in response to an authentication code generating class of instruction, the processing circuitry is configured to generate an authentication code associated with an authentication target value; the authentication code generating class of instruction comprises: an authentication code setting instruction, for which the processing circuitry is configured to write at least a portion of the generated authentication code to a destination register; and an authentication code checking instruction, for which the processing circuitry is configured to check whether at least a portion of the authentication code generated based on the authentication target value in response to the authentication code checking instruction corresponds to at least a portion of a reference authentication code obtained from a source register, and indicate a failed check 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 checking instruction, the processing circuitry is configured to generate an authentication code, when operating in a first code generation mode, by applying a code generating function to: a key; the authentication target value; at least one of a first modifier dependent on a stack pointer obtained from a stack pointer register, and a second modifier dependent on a program counter address obtained from a program counter register; and a further modifier dependent on a further value obtained from an architecturally visible register different from the stack pointer register and the program counter register.

2. The apparatus of claim 1, wherein the architecturally visible register is a general purpose register.

3. The apparatus of claim 1 or claim 2, wherein the architecturally visible register is a callee saved register.

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

5. The apparatus of any preceding claim, wherein the processing circuitry is configured to operate in a plurality of code generation modes, the plurality of modes comprising the first code generation mode and at least one further code generation mode, and the code generation mode is determined with reference to a control register.

6. The apparatus of claim 5, wherein: the processing circuitry is configured to operate at a plurality of exception levels, each of the exception levels having a different level of privilege; and the control register is accessible to software operating at one of the plurality of exception levels having a higher level of privilege and is inaccessible to software operating at exception levels of the plurality of exception levels having a lower level of privilege.

7. The apparatus of claim 5 or claim 6, wherein the processing circuitry is configured, when operating in the at least one further code generation mode: to apply the code generating function to the authentication target value, and the at least one of the first modifier and the second modifier; and to exclude the further modifier when applying the code generating function.

8. The apparatus of any of claims 5 to 7, wherein the at least one further code generation mode comprises: a first further code generation mode in which the processing circuitry is configured to apply the code generation function to the authentication target value and the first modifier; anda second further code generation mode in which 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 of any of claims 5 to 8, wherein: the control register defines a subset of code generation modes; and the processing circuitry is responsive to a mode selection parameter specified in the authentication code generating class of instruction to select a code generation mode from the subset of code generation modes.

10. The apparatus of any of claims 5 to 9, wherein the control register comprises modifier identification information and the further modifier is determined based on the modifier identification information.

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

12. The apparatus of claim 10 or claim 11, wherein the further modifier is one of an identified set of one or more further modifiers, and the control register comprises a set size identifier to identify a size of the set.

13. The apparatus of claim 12, wherein the control register identifies, for each one of the further modifiers of the set, a corresponding architecturally visible register on which that one of the further modifiers depends.

14. The apparatus of any preceding claim, wherein the processing circuitry is configured to perform a selection of the architecturally visible register from 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 generating instruction.

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

17. The apparatus of claim 16, wherein the modification is based on a counter value incremented in response to the authentication code setting instruction and decremented in response to the authentication code checking 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 of claims 10 to 18, wherein the architecturally visible register is one of a plurality of selected architecturally visible registers and the further modifier is dependent on a hash of values obtained from one or more of the plurality of selected architecturally visible registers.

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

21. The apparatus of claim 20, wherein the further register is one of: the stack pointer register and the selection is recorded using one or more unused bits of the stack pointer register; 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 preceding claim, in which: in response to a non- sequential change of program flow to a branch target address being triggered when a branch target check is enabled, the processing circuitry is configured to trigger an error handling response when the instruction at the branch target address is not a member of a permitted class of branch target instructions; and the authentication code setting instruction is one of said permitted class of branch target instructions.

23. The apparatus according to any preceding claim, in which: for at least one variant of the authentication code setting instruction, the first modifier comprises the stack pointer and the second modifier comprises the program counter address; and for at least one variant of the authentication code checking instruction, the first modifier comprises the stack pointer and the second modifier comprises a result of correcting the program counter address based on an immediate value specified by the authentication code checking instruction.

24. A method comprising: with instruction decoding circuitry, decoding instructions; with processing circuitry, performing a processing operation in response to a decoded instruction decoded by the instruction decoding circuitry; with the processing circuitry, in response to an authentication code generating class of instruction, generating an authentication code associated with an authentication target value; the authentication code generating class of instruction comprises: an authentication code setting instruction, for which the processing circuitry writes at least a portion of the generated authentication code to a destination register; and an authentication code checking instruction, for which the processing program logic checks whether at least a portion of the authentication code generated based on the authentication target value in response to the authentication code checking instruction corresponds to at least a portion of a reference authentication code obtained from a source register, and indicates a failed check when the generated authentication code does not correspond to the reference authentication code; and with processing circuitry, for at least one of the authentication code setting instruction and the authentication code checking instruction, generating an authentication code, when operating in a first code generation mode, by applying a code generating function to: the authentication target value; a key; at least one of a first modifier dependent on a stack pointer obtained from a stack pointer register, and a second modifier dependent on a program counter address obtained from a program counter register; anda further modifier dependent on a further value obtained from an architecturally visible register different from the stack pointer register and the program counter register.

25. A computer program for controlling a host data processing apparatus to provide an instruction execution environment, the computer program comprising: instruction decoding program logic to decode instructions; and processing program logic to perform a processing operation in response to a decoded instruction decoded by the instruction decoding program logic, wherein: in response to an authentication code generating class of instruction, the processing program logic is configured to generate an authentication code associated with an authentication target value; the authentication code generating class of instruction comprises: an authentication code setting instruction, for which the processing program logic is configured to write at least a portion of the generated authentication code to a destination data structure; and an authentication code checking instruction, for which the processing program logic is configured to check whether at least a portion of the authentication code generated based on the authentication target value in response to the authentication code checking instruction corresponds to at least a portion of a reference authentication code obtained from a source data structure, and indicate a failed check 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 checking instruction, the processing program logic is configured to generate an authentication code, when operating in a first code generation mode, by applying a code generating function to: a key; the authentication target value; at least one of a first modifier dependent on a stack pointer obtained from a stack pointer data structure, and a second modifier dependent on a program counter address obtained from a program counter data structure; and a further modifier dependent on a further value obtained from an architecturally visible data structure different from the stack pointer data structure and the program counter data structure.

Images