No action swap command

Abstract

The apparatus comprises an instruction decoder for decoding instructions, processing circuitry for performing data processing in response to decoding the instructions by the instruction decoder, and at least one control register for specifying instruction function selection information, wherein in response to a no-operation compatible instruction, the instruction decoder is configured to control the processing circuitry to treat the no-operation compatible instruction as a no-operation instruction when the instruction function selection information specified by the at least one control register is in a first state, to perform both the first operation and the second operation when the instruction function selection information specified by the at least one control register is in a second state, and to perform the first operation but not the second operation when the instruction function selection information specified by the at least one control register is in a third state.

Description

[Technical Field]

[0001] The present technology relates to the field of data processing. [Background technology]

[0002] The data processing circuit has processing circuitry for performing data processing in response to instructions decoded by an instruction decoder. The format of the instruction encoding and the function represented by each instruction may be defined according to an instruction set architecture (ISA). The ISA represents an agreed-upon framework between hardware manufacturers who produce processing hardware for a given processor implementation and software developers who write code to run on that hardware, so that code written according to the ISA functions correctly on hardware that supports the ISA. Design challenges can exist in selecting the instructions and their encoding supported by an ISA. Design decisions made by ISA designers when planning the instruction definition of an ISA can have a significant impact on the real-world performance achieved by the processing hardware when executing a particular program. Summary of the Invention

[0003] At least some examples provide an apparatus comprising an instruction decoder for decoding instructions, a processing circuit for performing data processing in response to the decoding of the instructions by the instruction decoder, and at least one control register for specifying instruction function selection information, wherein in response to a no-operation compatible instruction, the instruction decoder is configured to control the processing circuit to treat the no-operation compatible instruction as a no-operation instruction when the instruction function selection information specified by the at least one control register is in a first state, to perform both a first operation and a second operation when the instruction function selection information specified by the at least one control register is in a second state, and to perform the first operation but not the second operation when the instruction function selection information specified by the at least one control register is in a third state.

[0004] At least some examples provide a method that includes decoding an instruction and performing data processing in response to the decoding of the instruction, wherein in response to a no-operation compatible instruction, the method includes treating the no-operation compatible instruction as a no-operation instruction when instruction function selection information specified by at least one control register is in a first state, performing both the first operation and the second operation when the instruction function selection information specified by the at least one control register is in a second state, and performing the first operation but not the second operation when the instruction function selection information specified by the at least one control register is in a third state.

[0005] At least some examples provide a computer program including instructions that, when executed by a host data processing apparatus, control a host data processing apparatus to provide an instruction execution environment for executing target code, the computer program including: instruction decode program logic for decoding instructions of the target code; and register emulation program logic for maintaining data in memory circuitry of the host data processing apparatus to emulate at least one control register for specifying instruction function selection information; and, in response to a no-operation compatible instruction, the instruction decode program logic is configured to control the host data processing apparatus to treat the no-operation compatible instruction as a no-operation instruction when the instruction function selection information is in a first state, to perform both the first operation and the second operation when the instruction function selection information is in a second state, and to perform the first operation but not the second operation when the instruction function selection information is in a third state.

[0006] The computer program may be stored in a storage medium, which may be a temporary or non-transitory storage medium. [Brief explanation of the drawings]

[0007] Further aspects, features, and advantages of the present technology will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] 1 illustrates a schematic diagram of an example of a data processing device; [Figure 2] 1 illustrates an example of a device register. [Figure 3] Illustrates examples of no-operation-compatible (NOP-compatible) instructions. [Figure 4] Illustrates how to handle NOP-compatible instructions. [Figure 5] 1 illustrates an example of a function call and function return. [Figure 6] 1 illustrates an example of a guarded control stack (GCS) push operation and a GCS pop operation. [Figure 7] 1 illustrates an example of an authentication code generation operation. [Figure 8] 10 illustrates an example of an authentication code check operation. [Figure 9] 10 illustrates an example of performing GCS push operations and authentication code generation operations in different orderings. [Figure 10] 10 illustrates an example of performing GCS push operations and authentication code generation operations in different orderings. [Figure 11] 10 illustrates an example of performing GCS pop and authentication code check operations in different orderings. [Figure 12] 10 illustrates an example of performing GCS pop and authentication code check operations in different orderings. [Figure 13] 1 illustrates steps for checking whether memory access is permitted based on memory attribute data. [Figure 14] An example of a simulation is illustrated. DETAILED DESCRIPTION OF THE INVENTION

[0008] The apparatus includes an instruction decoder for decoding instructions, a processing circuit for performing data processing in response to the decoding of the instructions by the instruction decoder, and at least one control register for specifying instruction function selection information, wherein in response to a no-operation compatible (NOP-compatible) instruction, the instruction decoder is configured to control the processing circuit to treat the NOP-compatible instruction as a no-operation (NOP) instruction when the instruction function selection information specified by the at least one control register is in a first state, to perform both the first operation and the second operation when the instruction function selection information specified by the at least one control register is in a second state, and to perform the first operation but not the second operation when the instruction function selection information specified by the at least one control register is in a third state.

[0009] A NOP-compatible instruction may be useful for implementing some optional operations that may be useful when performed but are not critical to correct functionality of a software program that uses the instruction. For example, the first and second operations may be operations that provide optional security enhancements or performance hint operations that may be useful for improving security and / or performance, even if they are not required to achieve a correct functional result of the program. These enhancements may not necessarily be required, and therefore it may be desirable to be able to control whether the first and second operations are actually performed in a given instance of executing a sequence of code that includes instructions for performing one or both of these operations. Not performing the operations may be useful for saving power or for enabling analysis of how the same code executes on legacy hardware that does not support the optional operations. By controlling the function of the instruction based on instruction function selection information stored in at least one control register, the processing circuitry may execute the same program code in different usage scenarios with different results as to which of the first and second operations (if any) are performed in response to the instruction and depending on the current value of the instruction function selection information.

[0010] When the instruction function selection information is in the first state, the instruction behaves as a NOP instruction. A NOP instruction may be an instruction that, when executed, does not cause any change in architectural state other than a change in the program counter that may be implicit in the program flow proceeding sequentially (without branches) from the NOP instruction to the next instruction after the NOP. Thus, software developers have the option to completely turn off the functionality represented by the first and second operations. This may be useful, for example, when the first and second operations correspond to features introduced in more recent versions of an ISA that may not be available on legacy devices supporting older ISA versions. Another use case may be when the first and second operations are not always needed (e.g., when code is executed for a less secure use case, the security enhancements represented by the first and / or second operations may be turned off to save power by setting the instruction function selection information to the first state before executing a code sequence including a NOP-compatible instruction).

[0011] When the instruction function selection information is in a second state, the processing circuit performs both the first and second operations in response to the NOP-compatible instruction. When the instruction function selection information is in a third state, the processing circuit performs the first operation but not the second operation in response to the NOP-compatible instruction. Typically, to provide different combinations of whether the first and second operations are performed by a program code sequence, each operation would be encoded in a separate instruction, such that two different instructions would be required to perform both operations in combination, but if only one of the operations is required, only one of these instructions would be included in the software code. However, with the above-mentioned NOP-compatible instruction, both the first and second operations can be performed in response to the same instruction (and the same instruction has the option of performing only the first operation and not the second operation). Thus, the exact same code binary for a portion of program code containing a NOP-compatible instruction can behave differently depending on how the instruction function selection information was executed prior to executing that portion of program code. This provides a more efficient ISA encoding compared to an implementation that provides two separate NOP-compatible instructions corresponding to the first and second operations, respectively. First, it avoids the ISA having to use up two different instruction encodings for separate NOP-compatible instructions corresponding to the first and second operations, saving encoding that could be used for other types of instructions, and thus improving performance of code that utilizes other types of instructions (improving performance compared to having to split the operations of other types of instructions into several simpler instructions). Also, software code that uses NOP-compatible instructions only requires the processing circuitry to use a single instruction slot for the instruction in the fetch, decode, issue, and execute stages of the processing pipeline (as well as in an instruction cache or other storage for storing the program code being executed), which saves instruction slots used by different instructions to perform different operations, and therefore can improve performance as well as improve code storage density in caches and memories.

[0012] Thus, the NOP compatible instructions described above can help improve the performance and efficiency of ISA encoding for use cases where there are optional operations that may not always be required.

[0013] In some examples, a NOP-compatible instruction may not support the option of performing a second operation without performing a first operation. For example, any remaining encodings of the instruction function selection information (other than the first, second, and third states described above) may be used to control other aspects of how the first or second operation is performed (e.g., control parameters that adjust the behavior of the first or second operation), rather than being used to indicate that the second operation should be performed without the first operation.

[0014] However, in other examples, in response to a NOP-compatible instruction, the instruction decoder may control the processing circuit to perform the second operation but not the first operation when the instruction function select information is in a fourth state. This may be particularly useful so that the NOP-compatible instruction can be used to perform the first operation without the second operation, or the second operation without the first operation, or both operations together, or behave as a NOP such that neither the first operation nor the second operation can be performed. This allows the instruction function select information to be used to independently turn on and off each of the first and second operations. This provides the same flexibility in selecting which operations are performed as if each of the first and second operations were encoded as separate NOP-compatible instructions, but with a more efficient instruction encoding.

[0015] In some examples, when the instruction function selection information is in a second state, the processing circuit may control the relative order in which the first and second operations are applied based on the instruction function selection information. For example, the first operation may be performed before the second operation, or the second operation may be performed before the first operation, or both operations may be performed in parallel. The instruction function selection information may be used to select from two or more of these options. This may be useful because one ordering between the first and second operations may be more advantageous than another ordering. For example, the first ordering may provide higher security, while the second ordering may be more efficient in terms of performance. Thus, providing a control state that allows configuration of the relative ordering used may be useful in allowing the same code binary to be executed in different use cases that may have different preferences for prioritizing security and / or processing performance.

[0016] A wide range of processing operations may be implemented as the first and second operations, respectively.

[0017] However, NOP-compatible instructions may be particularly useful for function prologue operations associated with function calls. Thus, for function prologue variants of NOP-compatible instructions, the first and second operations are function prologue operations associated with the function call. For example, function prologue operations may be preliminary operations performed before entering the body of the function, before making the function call, during the function call, or immediately after making the function call. Because the same function may be called many times during the execution of a given software workload, even a relatively small performance savings achieved for a single instance of calling the function can result in a significant improvement in performance across the entire software workload, as the improvement is seen every time the function is called. Thus, by allowing the first and second operations associated with a function call to be performed in response to a single NOP-compatible instruction, rather than requiring multiple instructions, this can provide a significant performance improvement across the entire workload.

[0018] For similar reasons, NOP-compatible instructions may be useful for function epilogue operations associated with a return from processing of a function. These may be operations performed after the body of the function has completed in preparation for returning to the background process that called the function. Such epilogue operations may be performed before, during, or after the return branch that actually returns processing to the background process. Thus, for function epilogue variants of NOP-compatible instructions, the first operation and the second operation are function epilogue operations associated with a return from processing of the function.

[0019] In some examples, for at least one variant of the NOP compatible instruction, one of the first operation and the second operation includes an authentication code generation operation for generating an authentication code based on an operand and associating the authentication code with the operand.

[0020] Such authentication code generation operations can be applied to any operand, but can be particularly useful when applied to function return addresses that are set on function calls to represent the instruction address to which a subsequent return branch should return after the function body completes, in order to provide defense against return-oriented programming (ROP) attacks.

[0021] ROP-based attacks are a general class of attacks against data processing systems. ROP attacks attempt to cause a program to behave in an unexpected way by corrupting the return state information used to return from a function call or exception. Software often stores return state information in memory, for example, to facilitate the nesting of function calls or exceptions. The return state information for an outer function call or exception (of a nested set of function calls or exceptions) can be saved to memory for maintenance before it can be overwritten in a register with the return state information for the inner function call or exception. A ROP attack can attempt to tamper with the return state information while it is stored in memory before it is restored to a register and used to control the function return or exception return. A successful ROP attack can cause a function return or exception return that returns program flow to an instruction other than the next instruction after the point at which the function was called or the point at which the exception occurred, allowing an attacker to control the processing circuitry to perform any sequence of operations other than the one intended by the programmer.

[0022] An authentication code generation operation can help protect against such ROP attacks by generating an authentication code corresponding to an operand (e.g., a function return address), so that subsequent attempts to tamper with the operand while it is stored in memory can be detected based on a mismatch between the tampered operand and a corresponding authentication code that may no longer correspond to the operand if the operand is tampered with. While an authentication code generation operation can be useful for security, it is not required, and in some use cases, it may be preferable to omit the authentication code generation operation for performance reasons. Therefore, it may be useful to provide a NOP-compatible instruction that allows selection of whether or not the authentication code generation operation is performed depending on the instruction, so that the same code sequence can be executed in different scenarios with different results depending on whether the authentication code generation operation is performed. Therefore, it may be useful for one of the first and second operations to include an authentication code generation operation.

[0023] The operand for the authentication code generation operation may be any operand (e.g., an operand obtained from a register specified by a NOP-compatible instruction), but in some examples, the operand includes a value obtained from a link register. In response to a function return branch instruction, the instruction decoder may control the processing circuit to branch to a specified address in the link register. Thus, when an authentication code generation operation is applied to an operand in a link register, it may be common for the operand for the authentication code generation operation to be a function return address. This may be useful in providing a defense against ROP attacks. When an authentication code generation operation is applied to a function return address, the authentication code generation operation may be an example of a function prologue operation as described above, since this operation is often performed in association with a function call.

[0024] In an authentication code generation operation, the generated authentication code may be associated with the operand in different ways. For example, the authentication code may be stored in a specific register that has a known association with the register that provides the operand. However, this is not required, and in some cases, the authentication code may be embedded in part of the operand itself. Thus, associating the authentication code with the operand may include embedding the authentication code in some of the upper bits of the operand. This may be useful because, by embedding the authentication code in the operand itself, this means that any subsequent operation that moves the operand from one location to another (e.g., pushing the operand from a register to a stack data structure in memory) also causes the authentication code to be implicitly transferred along with the operand, without requiring a separate operation to transfer the authentication code. The upper bits of the operand may be available to represent the authentication code. This is because, while a processor architecture may support addresses with a particular number of bits (e.g., 64 bits), in practice, it may be common for real-world data processing devices not to yet have a need to provide memory storage that uses the entire 64-bit address space. Thus, although an address may have 64 bits, in practice only a smaller number of bits may actually be used, with the number of most significant bits corresponding to 0 (or some other fixed value). Therefore, there are some high-order bits that are not actually used, and these bits may be replaced with an authentication code (which may be inserted into any subset of these unused bits at the top of the address).

[0025] The authentication code generation operation may include generating the authentication code according to a cryptographic function based on at least an operand and a cryptographic key. For example, generating the authentication code according to a cryptographically secure function such as QARMA-64, QARMA-128, or SHA256 based on a secret key may generate the authentication code in a manner that makes it difficult for an attacker to predict the authentication code corresponding to a given address.

[0026] In some examples, the authentication code may also depend on a modifier input to the cryptographic function. The modifier may be a value associated with the current point of processing, such as the current value of a stack pointer. This can help protect against reuse attacks, in which an attacker attempts to obtain a valid operand-authentication code pair used at one point in a program and replace that operand with a different operand used at a different point in the program.

[0027] In some examples, for at least one variant of the NOP-compatible instruction, one of the first operation and the second operation includes a guarded control stack (GCS) push operation to push an operand into a GCS data structure to protect return state information. Such a GCS push operation is another example of a defense against ROP attacks; however, rather than relying on assigning an authentication code to protect the return state from tampering, a protected GCS data structure having at least one defense that restricts the ability to write data to the GCS data structure may be established, providing some additional protection over normal memory areas. Again, the GCS push operation may be an example of a function prologue operation, since it may be useful to perform a GCS push operation on a function return address when calling a function. While such a GCS push operation may be useful for security, it has a performance cost, and therefore, some use cases with lower security requirements may not prefer to perform a GCS push operation. Thus, a GCS push operation is another example of an operation that may be usefully implemented using NOP-compatible instructions, whereby the exact same program code sequence containing NOP-compatible instructions may be executed in different use cases with instruction function selection information controlling whether the GCS push operation is actually performed.

[0028] The NOP-compatible instruction is particularly useful for variants of the NOP-compatible instruction in which one of the first and second operations includes an authentication code generation operation that generates an authentication code based on an operand and associates the authentication code with the operand, and the other of the first and second operations includes a protection control stack (GCS) push operation that pushes the operand into a GCS data structure to protect return state information. Because the authentication code generation operation and the GCS push operation can be considered alternative techniques for protecting function return state against ROP attacks, these operations are often required at the same point in a program (associated with a function call), and therefore it may be useful to combine these operations into a single instruction while also providing the option to turn off one or both of these operations. While both operations nominally provide protection against the same class of attacks, these operations may have advantages and disadvantages, and therefore, for "defense in depth," some developers may wish to include both measures so that it is useful to support the option of performing both operations in a function call. By using the NOP-compatible instruction, only a single instruction may be executed to perform both types of operations (when the instruction's function selection information is in the second state).

[0029] If the first and second operations are an authentication code generation operation and a GCS push operation, respectively (or vice versa), different orderings between these operations are possible. Thus, some implementations may allow selection of which ordering is used depending on the instruction function selection information.

[0030] In response to the NOP-compatible instruction when the instruction function selection information is in the first substate of the second state, the processing circuit may push both the operand and the authentication code into the GCS data structure (e.g., this may correspond to first performing an authentication code generation operation to embed the authentication code into the operand, and then performing a GCS push operation on the result of the authentication code generation operation). This approach may improve security by protecting the authentication code using the GCS data structure.

[0031] In response to a NOP-compatible instruction when the instruction function selection information is in the second substate of the second state, the processing circuit may push operands into the GCS data structure without an authentication code. In this case, the authentication code generation operation and the GCS push operation may be independent of each other and therefore may be performed in parallel or in either order. By supporting the option to perform these operations in parallel, this may improve performance, but it means that the GCS data structure does not protect the authentication code.

[0032] In another example, for at least one variant of the NOP-compatible instruction, one of the first operation and the second operation includes an authentication code checking operation for checking whether an associated authentication code associated with an operand matches an expected authentication code generated based on the operand, and for triggering an error handling response in response to detecting a mismatch between the associated authentication code and the expected authentication code. This operation may be used to check the validity of the authentication code generated by the authentication code generation operation described above, and may be performed for any operand, but is often performed as a function epilogue operation to check whether a return address is safely used (defending against ROP attacks, as described above). Thus, for reasons corresponding to the authentication code generation operation, the NOP-compatible instruction may be useful for the authentication code checking operation.

[0033] In some examples, the associated authentication code for an authentication code check operation may be obtained from a portion of the most significant bits of the operand.

[0034] In a manner corresponding to the authentication code generation operation, in the authentication code check operation, an expected authentication code may be generated according to a cryptographic function based on at least the operands and the cryptographic key, and possibly also on modifiers (such as a stack pointer).

[0035] In at least one variant of the NOP-compatible instruction, one of the first operation and the second operation may include a guarded control stack (GCS) pop operation to pop function return information from a GCS data structure to protect the function return information, which may be used to obtain return state information previously pushed into the GCS data structure by a previous GCS push operation. For similar reasons as the GCS push operation, the GCS pop operation (an example of a function epilogue operation) may be useful to implement using a NOP-compatible instruction.

[0036] Again, some variants of a NOP-compatible instruction may support both an authentication code check operation and a GCS pop operation. Thus, one of the first and second operations may include an authentication code check operation that checks whether an associated authentication code associated with an operand matches an expected authentication code generated based on the operand and triggers an error handling response in response to detecting a mismatch between the associated authentication code and the expected authentication code, and the other of the first and second operations includes a guarded control stack (GCS) pop operation that pops function return information from a GCS data structure to protect the function return information. These operations, as well as cases where both are needed, are usefully combined into the same NOP-compatible instruction and are typically performed at the same point in a program, as a function epilogue operation following completion of the body of the function, before the function return is performed.

[0037] The ordering between the authentication code check operation and the GCS pop operation may be controlled based on the instruction function select information. In response to a NOP-compatible instruction when the instruction function select information is in a first substate of the second state, the processing circuit may perform a GCS pop operation and perform an authentication code check operation on a value popped from the GCS data structure by the GCS pop operation, and in response to a NOP-compatible instruction when the instruction function select information is in a second substate of the second state, the processing circuit may perform an authentication code check operation on a value in a given register before performing the GCS pop operation and perform a GCS pop operation to pop function return information from the GCS data structure into the given register. Again, this provides different options for trading off security against performance.

[0038] When a NOP-compatible instruction performs a GCS push operation or a GCS pop operation as one of the first and second operations, when the instruction function selection information is in a state indicating that an access to a GCS data structure is performed in response to the NOP-compatible instruction (i.e., when one of a GCS push operation and a GCS pop operation is performed), the processing circuit may deny a memory access triggered by the NOP-compatible instruction in response to detecting that a memory region corresponding to the target address of the NOP-compatible instruction is designated by the memory attribute data as a memory region other than a GCS region for storing a GCS data structure. Thus, access to a memory region not designated as a memory region for a GCS data structure may be denied if the access is triggered by a GCS access type instruction. This prevents GCS access type instructions (including a NOP-compatible instruction when performing a GCS push operation or a GCS pop operation) from being misused to access a region of memory not intended to store a GCS data structure, which may reduce the attack surface available for an attacker to exploit.

[0039] Similarly, the processing circuit may reject write memory accesses triggered by non-GCS access type instructions in response to detecting that the memory region corresponding to the target address of the non-GCS access type instruction is designated as a GCS region by the memory attribute data. By limiting the ability to write to GCS regions to GCS access type instructions (including NOP-compatible instructions when the instruction function selection information is in a state indicating a GCS access should be performed), other, more common memory access instructions cannot tamper with the contents of the GCS data structure, providing greater security guarantees for the protected return state information stored in the GCS data structure. Again, this reduces the attack surface available for an attacker to exploit when attempting to launch a ROP attack.

[0040] The instruction function selection information may be represented in different ways. In some examples, the aforementioned first, second, and third states may correspond to different (potentially arbitrarily chosen) encodings of the instruction function selection information. Thus, any mapping between the first, second, and third states and different combinations of bit values of the instruction function selection information may be used.

[0041] However, in some examples, it may be useful for the instruction function selection information to include a first operation indicator indicating whether a first operation should be performed in response to a NOP compatible instruction, and a second operation indicator indicating whether a second operation should be performed in response to a NOP compatible instruction. For example, the instruction function selection information may include a set of bits, each bit corresponding to one of the operations that may potentially be selected for performance in response to a NOP compatible instruction and indicating whether that operation needs to be performed. This encoding of the instruction function selection information may be easier for software developers to understand and easier to decode by processing circuitry or instruction decoder hardware, because selection of each operation depends only on a single indicator (e.g., a single bit) rather than requiring more complex decoding circuitry logic.

[0042] In some examples, the NOP-compatible instruction may support the option of selecting from among three or more operations based on the instruction function selection information. Thus, the instruction function selection information may further indicate whether the processing circuit should perform a third operation in response to the NOP-compatible instruction. For example, if the instruction function selection information includes a set of bits that each indicate whether a respective operation should be performed in response to the NOP-compatible instruction, it may be relatively efficient to add support for additional operations as needed. Thus, although the examples described below show examples having two operations, the scope of the claims is not so limited and additional operations may also be supported.

[0043] The techniques described above may be implemented in a data processing apparatus having hardware circuitry provided for implementing the processing circuitry and instruction decoder described above.

[0044] However, the same technique may also be implemented in a computer program that runs on a host data processing device to provide an instruction execution environment for the execution of target code. Such a computer program can control the host data processing device to simulate an architectural environment provided on a hardware device that actually supports target code according to a particular instruction set architecture, even if the host data processing device itself does not support that architecture. The computer program can have instruction decoding program logic and register emulation program logic that controls the host data processing device to emulate the above-mentioned features, including support for the NOP-compatible instruction described above. The instruction decoding program logic decodes instructions of the target code and generates instructions of a native architecture supported by the host to emulate the function represented by the decoded instruction in the target code. The register emulation program logic maintains data in storage circuitry of the host data processing device to emulate the contents of at least one control register, including the register(s) that store the instruction function selection information described above. Thus, when target code including the NOP-compatible instruction is executed in the instruction execution environment provided by the simulation computer program running on the host data processing device, functionality similar to that described above can be achieved, even if the host data processing device itself does not support the NOP-compatible instruction.

[0045] Such a simulation program may be useful, for example, when program code written for one instruction set architecture is being executed on a host processor that supports a different instruction set architecture. Also, running software on a simulation execution environment may enable testing of software in parallel with ongoing development of hardware devices that support the new architecture, so that simulation may allow software development of a new version of an instruction set architecture to begin before processing hardware that supports the new architecture version. The simulation program may be stored on a storage medium, which may be a non-transitory storage medium.

[0046] FIG. 1 schematically illustrates an example of a data processing apparatus 2. The data processing apparatus has a processing pipeline 4 including several 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 for decoding the fetched program instructions to generate micro-operations (decoded instructions) that are processed by the remaining stages of the pipeline; an issue stage 12 for checking whether operands required for the micro-operation are available in a register file 14 and for issuing the micro-operation for execution once the operands required for a given micro-operation are available; an execute stage 16 for performing the data processing operation corresponding to the micro-operation by processing operands read from the register file 14 to generate a result value; and a writeback stage 18 for writing the results of the processing back to the register file 14. It will be understood that this is just one example of a possible pipeline architecture, and other systems may have additional stages or different configurations of stages. For example, an out-of-order processor may include a register rename stage for mapping architectural registers specified by a program instruction or micro-operation to physical register specifiers that identify physical registers in the register file 14. In some examples, there may be a one-to-one relationship between the program instructions decoded by the decode stage 10 and the corresponding micro-operations processed by the execute stage. There may also be a one-to-many or many-to-one relationship between program instructions and micro-operations, for example, a single program instruction may be split into two or more micro-operations, or two or more program instructions may be fused together and processed as a single micro-operation.

[0047] Execution stage 16 (an example of a processing circuit) includes several processing units for performing different classes of processing operations. For example, the execution units may include a scalar arithmetic / logic unit (ALU) 20 for performing arithmetic or logic operations on scalar operands read from registers 14, a floating-point unit 22 for performing operations on floating-point values, a branch unit 24 for evaluating the results of branch operations and adjusting a program counter representing the current execution point accordingly, and a load / store unit 26 for performing load / store operations that access data in memory systems 8, 30, 32, 34. A memory management unit (MMU) 28, an example of a memory management circuit, is provided for performing address translation between a virtual address specified by load / store unit 26 based on the operands of a data access instruction and a physical address that identifies the storage location of the data in the memory system. The MMU has a translation lookaside buffer (TLB) 29 for caching address translation data from page tables stored in the memory system, whose page table entries define address translation mappings and may also specify access permissions that govern, for example, whether a given process executing on the pipeline is allowed to read, write, or execute instructions from a given memory region. The MMU 28 may have circuitry for requesting memory accesses during a page table walk as the page table structure is traversed to identify the page table entry corresponding to a required address.

[0048] In this example, the memory system includes a level 1 data cache 30, a level 1 instruction cache 8, a shared level 2 cache 32, and a main system memory 34. It will be understood that this is only one example of a possible memory hierarchy and that other arrangements of caches can be provided. The particular types of processing units 20-26 shown in execution stage 16 are merely one example; other implementations may have different sets of processing units or may include multiple instances of the same type of processing unit such that multiple micro-operations of the same type can be processed in parallel. It will be understood that FIG. 1 is only a simplified representation of some components of a possible processor pipeline implementation, and that a processor may include many other elements not shown for the sake of brevity. While FIG. 1 shows a single processor core with access to memory 34, device 2 may also have one or more additional processor cores that share access to memory 34, each core having its own cache 8, 30, 32.

[0049] FIG. 2 illustrates some example registers 14 of unit 2. It will be understood that FIG. 2 does not show all of the registers and that the unit may include other registers. A set of general-purpose registers 50 is provided for storing general-purpose operands and results of processing operations. Some of these general-purpose registers may also have more specific functions, such as a link register (LR) for storing a function return address, which may be addressable using one of the general-purpose register identifiers (e.g., register X30). The registers also include a stack pointer (SP) register 52 for storing a stack pointer. The unit also has several control registers 56 for storing control information used to control operation of the processor. For example, the control registers 56 may include a protection control stack (GCS) stack pointer register 58 used to control access to the GCS, as described further below with respect to FIG. 6, and at least one register providing instruction function selection information 60 used to control the behavior of NOP-compatible instructions, as described further below. While FIG. 2 illustrates instruction function selection information 60 as a single register, it is also possible to split this information into two or more registers.

[0050] FIG. 3 illustrates an example embodiment of a NOP system 70. The instruction encoding includes an opcode 72 that identifies the type of instruction and one or more operand fields 74, 76 for specifying the instruction's operands. The operands 74, 76 may be specified using immediate values, register identifiers that specify registers 14 that store the operands, or a combination of both at least one immediate value and at least one register identifier. In some cases, the instruction may specify an additional destination field that identifies a register to which the result of the instruction is to be written, or alternatively, one of the registers specified for one of the operand fields may serve as the destination register. While FIG. 3 illustrates two operands as an example, other examples of NOP-compatible instructions may have more or fewer operands.

[0051] A NOP-compatible instruction represents the option of either performing no operation at all (such that the instruction behaves as a NOP instruction) or performing one or more of at least two different processing operations, including at least a first operation and a second operation, within a single instruction encoding having the same opcode 72 and the same definitions of operand fields 74, 76. Which combination of operations is performed in response to a NOP-compatible instruction is selected (by the instruction decoder 10 and / or the execution stage 16 of the processing pipeline 4) based on instruction function selection information 60 stored in the control register 56. This information may be set by an instruction executed by the processor. For example, a system register modifying instruction (which may be restricted to execute in a particular execution state or privilege level) may be used to set the instruction function selection information 60. Alternatively, there may be a dedicated type of instruction for setting the instruction function selection information, separate from the system register modifying instructions for modifying other control registers 56. In a use case of executing code containing a NOP-compatible instruction, a previous instruction of the same code may be used to set the instruction function selection information 60. In another example, the instruction function selection information 60 may be set by supervisory code that manages the execution of program code that includes NOP-compatible instructions (e.g., by an operating system that manages the execution of an application, or a hypervisor that manages the execution of an operating system).

[0052] 4 is a flow diagram illustrating a method for processing a NOP-compatible instruction. In step 100, instruction decode circuit 10 determines whether a NOP-compatible instruction has been decoded. If not, instruction decode circuit 10 controls the processor to decode another type of instruction and perform the operation represented by that instruction, and continues to wait for a NOP-compatible instruction to be decoded.

[0053] When a NOP compatible instruction is decoded, in step 102 the instruction decoder 10 checks the state of the instruction function selection information 60 stored in the control register 56 (or controls another part of the processor, such as the execution stage 16, to check the state of the instruction function selection information 60).

[0054] If the instruction function selection information 60 is in the first state, then in step 104 the instruction decoder 10 controls the execution stage 16 to treat the NOP compatible instruction as a NOP instruction. Thus, in response to the NOP compatible instruction, the processing circuitry does not cause any change in the architectural state (other than advancing the program counter to point to the next sequential instruction after the NOP instruction).

[0055] If the instruction function selection information 60 is in the second state, then in step 106, processing depends on whether the instruction function selection information is in a first substate or a second substate of the second state. If the instruction function selection information 60 is in the first substate of the second state, then in step 108, processing circuitry 16 is controlled to perform both the first and second operations using a first ordering between the first and second operations. If the instruction function selection information 60 is in a second substate of the second state, then in step 110, processing circuitry 16 is controlled to perform both the first and second operations using a second ordering between the first and second operations that differs from the first ordering. The first and second orderings may differ with respect to whether the first and second operations are performed sequentially or in parallel, or with respect to which of the first and second operations is performed first and which is performed second. The ordering may also differ with respect to whether there is any dependency between the first and second operations (i.e., whether one operation depends on the outcome of the other operation, or whether the two operations are independent).

[0056] Support for controlling the ordering between the first and second operations is optional, and in some examples, steps 106 and 110 may be omitted such that when the instruction function selection information is in the second state, the method proceeds directly to step 108 and performs both the first and second operations using the first ordering selected by default.

[0057] Specific examples of controlling the ordering between operations are described below with respect to FIGS.

[0058] If, in step 102, instruction function selection information 60 is in a third state, then, in step 112, processing circuitry 16 is controlled to perform the first operation but not the second operation.

[0059] When the instruction function select information is in the fourth state, in step 114, processing circuit 16 is controlled to perform the second operation but not the first operation. Support of step 140 may be optional; in some examples, it may not be possible for a NOP-compatible instruction to perform the second operation but not the first operation. For example, in some use cases, if there is only space for four different states of instruction function select information (e.g., there is only space for four different states because only two bits are used for this information 60), some implementations may prefer to use a fourth encoding of instruction function select information 60 to enable two different sub-states of the second state, as shown in steps 108 and 110, so that the ordering of operations can be controlled. Other embodiments may support all of the states and sub-states of FIG. 3 and therefore use three or more bits of instruction function select information to enable these additional encodings of the instruction function select information.

[0060] One possible encoding of the instruction function selection information (without support for controlling the ordering between the first and second operations) can be done as follows: 0b00 - The first action is disabled, the second action is disabled, and the instruction behaves as a NOP (first state). · 0b01 - The first action is enabled and the second action is disabled (third state). · 0b10 - The first action is disabled and the second action is enabled (fourth state). · 0b11 - The first action is enabled and the second action is enabled (second state).

[0061] Such encoding may provide a separate bit for each operation that independently indicates whether the operation is enabled or disabled. This may be extended to third or further operations by providing additional bits per operation, each of which turns on / off any additional operations.

[0062] Another example of encoding the instruction function selection information obviates the ability to perform a second operation without a first operation, but uses a fourth encoding of the instruction function selection information 60 to indicate a desired ordering between the first operation and the second operation when both are performed. 0b00 - The first action is disabled, the second action is disabled, and the instruction behaves as a NOP (first state). · 0b01 - The first action is enabled and the second action is disabled (third state). 0b10 - The first action is enabled, the second action is enabled, and the first and second actions are performed in a first ordering (second state - first sub-state). · 0b11 - The first action is enabled, the second action is enabled, and the first and second actions are performed in a second ordering (second state - second substate).

[0063] Another exemplary encoding may use more than two bits, leaving some encodings reserved for future use, e.g., when adding support for additional operation or configuration options. 0bX00 - The first action is disabled, the second action is disabled, and the instruction behaves as a NOP (first state). · 0bX01 - The first action is enabled and the second action is disabled (third state). · 0bX10 - The first action is disabled and the second action is enabled (fourth state). · 0b011—The first action is enabled, the second action is enabled, and the first and second actions are performed in a first ordering (second state—first substate). 0b111 - The first action is enabled, the second action is enabled, and the first and second actions are performed in a second ordering (second state - second substate).

[0064] It will be appreciated that all of these examples are merely a few of the ways in which the action performed for a NOP instruction may be encoded by instruction function selection information 60.

[0065] A wide variety of processing operations can be used as the first and second operations. However, in one particular use case, a function prologue or epilogue operation can be performed on a function call or function return, respectively. In particular, it can be useful for the first and second operations to be alternative operations to protect against return-oriented programming (ROP) attacks on the function return state. For example, the first and second operations can be pointer validation / check operations or GCS push / pop operations, which are described further below.

[0066] Figure 5 illustrates an example of calling and returning from a function (labeled fn1 for ease of reference). A function (also known as a procedure) is a sequence of instructions that can be called from another part of a program and, upon completion, returns processing to the part of the program flow from which the function was called. Because the same function can be called from many different locations in a program, the function return address is remembered when calling a function so that the function return can distinguish to which address the program flow should return.

[0067] 5, a branch-with-link instruction BLR may be executed at the point where a function is called (represented by address #add1), causing the function to branch program flow to an instruction at a branch target address #add2 specified using an operand of the branch-with-link instruction. The branch-with-link instruction also causes the processing circuitry to set a link register (a designated register used to track function return addresses, e.g., a general-purpose register as shown above) to the address of the next instruction after the branch-with-link instruction (in this example, the function return address is #add1+4). After the branch is taken, a number of instructions (e.g., LD, MUL, ADD, etc.) are executed within the function code, and when the function is completed, a return-branch instruction RET is executed, which causes a branch to the instruction pointed to by the return address stored in the link register.

[0068] If no other functions are called from within fn1 and no exceptions occur before the final return branch of fn1 is reached, the address in the link register should still be the same as it was set to when fn1 was called.

[0069] However, since the first function fn1 called by the background code often itself calls a further function (fn2) in a nested manner, in which case the function call to fn2 overwrites the return address stored in the link register, the function code for the first function fn1 should include instructions to save the return address from the link register to a data structure in memory (e.g., a stack structure operating in a last-in-first-out (LIFO) manner) before calling that further function, and after returning from fn2, the function code for fn1 should restore the return address to the link register before executing the return branch. The responsibility for saving and restoring function return state, such as the return address, typically lies with software (there may not be an architecturally mandated hardware mechanism for saving the return address).

[0070] However, while the function return address is stored in memory, it may be vulnerable to an attacker modifying that data, for example, using another thread running on another processor core, or by interrupting the called function and executing other code that overwrites the return address stored in memory in the meantime. Alternatively, an attacker could execute some instructions aimed at modifying the address operand of the instruction that restores the return address from memory to a register, so that the data loaded from memory is no longer the same as the return address originally saved in memory before calling the nested function. If an attacker can cause the return branch to branch to a point in the program flow other than the instruction after the function call branch, the attacker may be able to cause the software to behave incorrectly, circumventing certain security protections or performing undesirable actions.

[0071] A function call is an example of an operation in which a processing circuit generates return state information that provides information about a state to be restored later. Another scenario in which return state information may be obtained may be when an exception occurs, at which point a hardware-provided exception handling circuit or a software exception handler may obtain exception return state information, such as an exception return address indicating the address of the instruction to be executed after returning from the exception, and / or saved processor state information indicating the mode or execution state the processor should be in after returning from the exception. For example, the saved processor state information may indicate at which exception level the exception occurred, as well as other information about the operating state of the processor at the time the exception occurred. Similar to function calls, exceptions may be nested, so the exception return state obtained for one exception may be saved to memory (either automatically in hardware or by a software exception handler) when another exception occurs and may be vulnerable to tampering by an attacker while stored in memory. These types of attacks are sometimes referred to as return-oriented programming (ROP) attacks. It may be desirable to provide architectural countermeasures against such attacks.

[0072] 6 illustrates an approach to protecting against ROP attacks using a protected data structure 120 in memory called a "guarded control stack" (GCS). While the location of the GCS data structure in memory address space may be selected by software, the hardware provides architectural features designed to protect the GCS data structure from tampering by a malicious attacker.

[0073] 2, registers 14 include control registers 56, which include one or more guarded control stack pointer (GCS pointer) registers 58 for storing stack pointers that point to addresses in GCS data structures. In some examples, GCS pointer registers 58 may be a bank set of registers provided separately for at least two execution states (e.g., exception levels), allowing software operating in different execution states to reference different GCS structures in memory without having to reprogram a shared stack pointer register after each transition between execution states. In other examples, a single GCS pointer register may be used, and software may update the stack pointer stored in GCS pointer register 58 upon transitions between execution states.

[0074] 6, GCS data structure 120 is stored in a memory region designated as a GCS region of memory by memory attributes specified directly or indirectly by an associated page table entry in a page table used by memory management unit (MMU) 28 to control address translation and access permission checking. The GCS region attributes may be specified directly in the encoding of the corresponding page table entry or may be referenced indirectly in a register referenced by the page table entry.

[0075] Once a memory region is identified as a GCS region, write access to that region is restricted to write requests triggered by processing circuitry 16 when executing a specific subset of GCS access instructions. Generic store operations used by software for general store instructions not intended to access the GCS structure are not considered one of the restricted subset of GCS access instructions. MMU 28 may still allow the GCS structure to be read using a generic load instruction, which causes a read request to be issued that is not a GCS memory access request. If a memory access request requires access to a GCS region, is a write request, and is not a GCS memory access request triggered by one of the restricted subset of GCS access instructions, the memory access request is denied and a failure is signaled. The subset of GCS access instructions may include at least a GCS push instruction that causes return state information (such as a function return address from the link register, or an exception return address, or saved processor state obtained at the time of an exception) to be pushed to a location on the GCS structure determined using a stack pointer indicated in GCS pointer register 58. The GCS access instructions may also include at least one form of GCS pop instruction that pops protected return information from the GCS structure.

[0076] Conversely, GCS access instructions may not be permitted to access memory regions that are not designated as GCS region types by page table attributes. Thus, if an attempt is made to perform a GCS access when the memory region targeted by the access is not marked as a GCS region type, a failure may be signaled. By prohibiting the use of GCS access instructions to access non-GCS regions, this prevents programmers from using GCS access instructions to reduce the attack surface available to an attacker unless the access was actually intended to be a GCS access.

[0077] The GCS structure is separate from any data structures software uses to maintain return state information saved in memory for handling nested function calls and exceptions. Thus, the GCS structure is not intended to eliminate the need for software to track the saving and restoring of return state information itself when function calls and exceptions are nested (software-triggered saving of return state may continue in the same manner as in processors that do not support the GCS protection architectural measures described above). Instead, the GCS structure provides a protected area of memory, protected from tampering by compromised program code, that can be used to provide information for verifying return state information intended to be used by software to return from handling a function call or exception.

[0078] In some implementations, the GCS pop instruction that pops the protected return state information from the GCS structure may also cause processing circuitry 16 to compare the popped return state with current return state information stored in a register (e.g., link register 54 for a function return, or an exception return address register for an exception return, and / or a saved processor state register) and signal a failure if there is a mismatch between the return state information popped from GCS structure 120 and the intended return state information that the software intends to use for the function / exception return. Thus, by including instances of GCS push and GCS pop instructions in program code that executes around function calls / returns and exception entry / returns, software can be protected from tampering.

[0079] In other implementations, a separate instruction may be defined to verify whether the intended return state information is valid, apart from the instruction to pop the return state information from the GCS structure 120.

[0080] Alternatively, the GCS pop instruction may pop the protected return state directly from the GCS into one or more registers used to specify the return state for an exception or function return (or may be combined with an exception / function return instruction to pop the protected return state and use that state to control the exception / function return), in which case, in such an implementation, it is not necessary to perform steps to verify whether the intended return state information provided by software is valid, since the GCS-protected return state is used directly to control the exception / function return. For example, for GCS protection of a function return address, the function return address may be popped directly into link register 54, replacing any software-managed function return address that software may have placed in link register 54 based on its own managed stack structure.

[0081] Other types of GCS access instructions may also be supported. Some instructions that have other functionality in modes in which GCS use is disabled may cause processing circuitry 16 to perform additional functionality (such as additional GCS mode-specific security checks) when executed when GCS mode is enabled (a control state in control register 56 may control whether GCS mode is enabled).

[0082] In general, by providing architectural support for defining GCS memory region types to use for GCS structure 120 and restricting write access to GCS region types to a limited subset of GCS access instructions (which may not be permitted to access memory regions other than the GCS region type), this can reduce the attack surface available to an attacker attempting to tamper with protected return state information stored on GCS structure 120.

[0083] GCS provides one defense against ROP attacks. Another option for protecting against ROP attacks is the use of authentication codes associated with return state information. FIG. 7 illustrates an example of an authentication code generation operation performed in response to an authentication code generation instruction based on a first source operand, src1. While the source operand can be any value, it is particularly useful to apply the authentication code generation operation to an address pointer, such as a function return address. The source operand may specify an address containing a certain number of bits, X, (e.g., by referencing a source register, such as a link register), but in reality, only a certain number, Y, of those bits may be used for the effective address (e.g., X may equal 64, and Y may equal 48 or 52). Therefore, the XY most significant bits of the address may be set to 0 by default.

[0084] In an authentication code generation operation, a source operand may be passed to encryption / decryption circuitry of processing circuitry 16 (e.g., execution stage 16 may include encryption / decryption function units similar to the other execution units 20, 22, 24, 26 shown in FIG. 1 ), and the encryption / decryption circuitry may apply authentication code generation function 140 to a first source value based on an encryption key retrieved from encryption key storage and at least one modifier value. The resulting authentication code (PAC) is inserted into the unused upper bits of the pointer address to generate a result of the instruction. The result may, for example, be written back to the same register that stored the source operand. For example, if the instruction is executed with the source operand being the current function return address stored in link register 54, the result is written back to link register 54. The authentication code generation function 40 may use a cryptographic hash function (e.g., SHA256, SHA128, QARMA-128, QARMA-256, etc.), which makes it computationally infeasible to guess the authentication code associated with a particular address without knowledge of the cryptographic key. The modifier value may be a value used to tie a particular instance of an authentication code generated by an operation to a particular execution point reached in the program code, reducing the risk of a re-use attack in which a valid address / PAC pair from one part of code is fraudulently substituted for use in another part of the code. For example, a stack pointer from stack pointer register 52 or a call path indicator representing the history of function calls taken to reach the current processing point may be used as a modifier.

[0085] FIG. 8 illustrates a corresponding authentication code check operation performed on the second source operand src2. The second source operand is expected to be a pointer address that was previously authenticated by inserting an authentication code PAC into its most significant bits in the authentication code generation operation shown in FIG. 7; however, if an attacker modifies the pointer, the authentication code (PAC) may not be valid. In the authentication code check operation, processing circuit 16 applies the same authentication code generation function 140 to the address bits of the second source operand (excluding the authentication code PAC) using an encryption key and modifier value that corresponds to the encryption key and modifier value expected to have been used when the authentication code represented by the most significant bits of the address was generated. The expected authentication code PAC′ is then compared with the associated authentication code PAC extracted from the most significant bits of the second source operand src2 to determine whether the expected authentication code and the associated authentication code match. If so, processing is allowed to continue, whereas if there is a mismatch between the expected code and the associated code, an error handling response is triggered, for example, by triggering an exception or setting the high order bits of a source register to a value corresponding to the invalid address, so that a subsequent access or instruction fetch to that address will trigger the MMU 28 to trigger a memory fault due to accessing the invalid address (this means that if an address with an invalid PAC is used for a function return, a subsequent attempt to fetch instructions from that address following the return branch will trigger a fault, preventing the processing circuitry from continuing program execution beyond the invalid function return).

[0086] 7 and 8, this allows pointers to be authenticated, thereby making it more difficult for an attacker to inject an unauthorized pointer and cause the code to successfully branch to the location identified by that pointer, protecting against ROP attacks. Using a cryptographic function as the authentication code generation function 140 can make it difficult to brute-force guess the authentication code associated with a particular address. Instructions to perform the authentication code generation operation can be included in the code at the point where the pointer address is generated (e.g., between setting the link register in response to a function call and saving the function return address from the link register to memory), and an authentication code check instruction AUT can be included later when the address is actually used (e.g., before the function return branch) to double-check the authentication code before actually branching to the address.

[0087] The authentication code generation function 140 may vary from implementation to implementation or may be configurable on a given implementation based on the control state in the control register 56. The modifier values to be used for the authentication code generation function may also be configurable or may differ for different variants of the instruction that performs the authentication code generation / checking operation.

[0088] While both the GCS operation and the authentication code operation described above with respect to Figures 6-8 can be viewed as defenses against ROP attacks, some users may prefer to use one form of defense and others may use the other. Some users may prefer to use both in combination for a defense-in-depth approach. Also, it may be desirable to sometimes omit these operations in scenarios where a portion of code that is sometimes used in use cases requiring the security of ROP defense may also be executed in use cases that do not require this security, in which case omitting these operations may be better for performance. Thus, these operations may be useful examples of the first and second operations of the NOP-compatible instruction described above.

[0089] In some cases, it may be desirable to provide program binaries that are backward compatible with older hardware that does not support the GCS and authenticator features, while also supporting newer features when run on newer hardware that does support these features. Thus, the opcode 72 selected for the NOP compatible instruction may be one that can be treated as a NOP instruction on older hardware.

[0090] Typically, when a new architectural feature is added to an ISA, a control register may be used to indicate whether the feature is supported, and software may need to check whether the feature is implemented before using it. While this is acceptable for many functions, for functions that are expected to be executed very frequently, such as functions used in function prologues and epilogues, this is not feasible for performance reasons. For such features, it may be useful to provide a set of NOP instruction encodings that perform no operation, at least until some functionality is added to the encodings for newer hardware that supports the updated architecture. As more features are added to the architecture, more NOP-compatible instructions may be added to the function prologues and epilogues corresponding to each additional feature, but this would make the function much larger as more NOP-compatible instructions are added, incurring costs in caching structures and instruction throughput and thus reducing performance.

[0091] Thus, the NOP compatible instructions described above allow multiple operations to be overloaded into a single NOP-compatible encoding, using instruction function selection information 60 in one or more control registers 56 provided to turn each function on / off independently.

[0092] For example, as noted above, for the guarded control stack function where it is desired to push the contents of the link register (e.g., a function return address) onto a protected stack on function entry, and the authentication code generation operation (PAC function) mentioned above for signing a pointer such as a function return address, this typically involves two instructions to perform a GCS push operation (GCSPUSH) and a signing operation (PACIASP). Similarly, on function return, there are corresponding instructions to perform a GCS pop operation (GCSPOP) and an authentication code check operation (AUTIASP).

[0093]

number

[0094] In contrast, by using the NOP compatible instruction described above to provide both functionality, this allows for a smaller function and also allows the function to work on old and new hardware (old hardware can treat this function as a NOP, and even on newer hardware there is a configuration option to disable both behaviors by setting the instruction function selection information to the first state).

[0095] For example, if a combined instruction (assumed to have PACIASP encoding in this example) performs all the operations, it can have a smaller function.

[0096]

number

[0097] Note that AUTIASP is the complement of PACIASP, and in the above example, is also the complement of GCSPUSH by performing a GCSPOP operation.

[0098] For example, two control bits can be provided to govern the behavior of these encodings. 00-PAC is disabled and GCS is disabled. 01-PAC is enabled and GCS is disabled. 10-PAC is disabled and GCS is enabled. 11-PAC is enabled and GCS is enabled.

[0099] This can be expanded in the future with new capabilities to add control bits to turn off / on functions all performed by a single encoding. It is also possible for the control state to control the relative ordering in which operations are performed.

[0100] Thus, multiple new features can be turned on and off for the same instruction encoding without rebuilding the program binary.

[0101] The above example shows the case where the first and second actions are either: For function prologue variants, respectively, the GCS push operation and the authentication code generation operation, or vice versa, or For function epilogue variants, GCS pop action and authentication code check action, or vice versa, respectively.

[0102] Both variants may be supported in the same ISA, using different encodings of the opcode field 72 for the function prologue and function epilogue variants, respectively.

[0103] However, in other embodiments, it is possible to provide a NOP-compatible instruction that combines a GCS push operation with another type of operation other than an authentication code generate operation, or that combines an authentication code generate operation with another type of operation other than a GCS push operation.Similarly, it is possible to provide a NOP-compatible instruction that combines a GCS pop operation with another type of operation other than an authentication code check operation, or that combines an authentication code check operation with another type of operation other than a GCS pop operation.

[0104] 9-12 show different examples of controlling the sequencing between PAC / AUT and GCS operations, where both operations are performed in response to NOP-compatible instructions.

[0105] FIG. 9 illustrates an example in which a NOP-compatible instruction (executed as a function prologue) performs both an authentication code generation operation (PAC) and a GCS push operation, where the GCS push operation depends on the result of the authentication code generation operation, such that both the function return address and its associated authentication code are pushed to the GCS. In other words, this is equivalent to performing a PAC operation followed by a GCS push operation, with the destination register of the PAC operation being the same as the source register of the GCS push operation. In contrast, FIG. 10 illustrates performing the PAC and GCS push operations in a different ordering, where the GCS push operation is independent from the PAC operation. This allows the push of the function return address into the GCS structure to be initiated in parallel with the computation of the authentication code by the PAC operation. This can be useful because both the PAC generation function 140 and the memory access for the GCS push operation can be relatively slow; therefore, parallelizing these operations can improve performance compared to the ordering of FIG. 9. On the other hand, the example of FIG. 9 may have improved security because the generated authentication code, not just the function return address, is protected on the GCS.

[0106] Similarly, FIGS. 11 and 12 show alternative orderings for an example in which a NOP-compatible instruction (executed as a function epilogue) implements a GCS pop operation and an authentication code check (AUT) operation as first and second operations (the first operation can be a GCS pop operation and the second operation can be an AUT operation, or vice versa). FIG. 11 shows an ordering in which the AUT operation depends on the result of the GCS pop operation, because the value popped from the GCS by the GCS pop operation is used as input for the AUT operation. This approach can be used in an example in which a corresponding NOP-compatible instruction executed as a function prologue uses the approach shown in FIG. 9. Again, this has the advantage of greater security, because the authentication code is protected against tampering using GCS memory region protection implemented by the MMU 28. On the other hand, FIG. 12 shows an ordering in which the AUT operation and the GCS pop operation are independent, so that both operations can be initiated in parallel. In this case, an authentication code check may be applied to the value in the link register, and then separately, the GCS pop operation may also pop the value (without the associated authentication code) into the destination register. Assuming the old value in the link register is read for the AUT operation before the value popped from the GCS structure is returned from memory, the destination register for the GCS pop operation may still be the same register used for the source operand for the AUT operation, in which case if the AUT operation detects a mismatch, a failure or other error response action is taken; if the codes match, the GCS pop operation is allowed to complete, and the address popped by the GCS pop operation may then be used for the function return.Alternatively, the GCS pop operation may pop the protected return address from the GCS structure in memory into a register other than the register checked by the AUT operation, and then the value checked by the AUT operation may be compared with the value popped from the GCS structure to see if the GCS protected address matches the AUT checked address, and based on the address, may provide a further check of whether it is safe to proceed with the function return.

[0107] Therefore, it may be useful for the instruction decoder 10 and execution stage 16 to support the following: a first NOP-compatible instruction, for use in a function prologue, one of its first and second operations being a generate authentication code (PAC) operation and the other of its first and second operations being a GCS push operation; and A second NOP-compatible instruction (having a different encoding than the first NOP-compatible instruction) for use in a function epilogue, one of the first and second operations being an authentication code check operation (AUT) and the other of the first and second operations being a GCS pop operation.

[0108] The instruction function selection information 60 may specify which of the first and second operations (if any) should be performed depending on the instruction, and may also control the relative ordering of the operations, as shown in Figures 9-12.

[0109] 13 is a flow diagram illustrating the steps performed by MMU 28 to check memory access permissions for a memory access request. In step 200, an instruction that triggers a load / store operation is decoded. The above-described NOP-compatible instructions that support a GCS push or pop operation are considered to be load / store instructions if the instruction function selection information 60 specifies that a GCS push or pop operation is to be performed.

[0110] In step 202, it is determined whether the instruction that triggers the load / store operation is a GCS access instruction (one of the restricted subset of GCS access instructions that are permitted to access a GCS region of memory, as described above). A NOP-compatible instruction is treated as a GCS access instruction if the instruction function selection information indicates that a GCS push or pop operation is required. Other types of instructions may also be treated as GCS access instructions. In some cases, if the instruction function selection information is in a state that indicates that a GCS push or pop operation is not required, the NOP-compatible instruction is not treated as a GCS access instruction. Alternatively, if a GCS push or pop operation is the only operation that can generate a load / store operation in response to a NOP-compatible instruction (e.g., the PAC / AUT operation described above may not generate a load / store request), the NOP-compatible instruction may always be treated as a GCS access instruction, regardless of the value of the instruction function selection information 60.

[0111] If the decoded instruction is a GCS access instruction, then in step 204, the MMU 28 checks whether memory attribute data corresponding to the target address being accessed for the load / store operation specifies that the memory address space region corresponding to the target address is a GCS region. This memory attribute data may be derived from the page table entry corresponding to the target address or the indirection register specified by the page table entry (which may be cached in the translation lookaside buffer (TLB) of the MMU 28). If the instruction is a GCS access instruction but the memory attribute data specifies that the region corresponding to the target address is not a GCS region, then in step 206, the load / store operation is rejected and a failure is signaled. This prevents the GCS access instruction from being used to access non-GCS memory, which may be safer in reducing the attack surface available to an attacker. Otherwise, if the GCS access instruction is accessing a GCS region, then in step 212, the MMU 28 checks whether other access permission checks were passed by the load / store operation. If these other checks fail, the load / store operation is denied and the failure is signaled in step 214. If these other checks pass, the load / store operation is allowed in step 216. These other checks may, for example, check read / write permissions that indicate whether reading or writing to the memory region is allowed, or may check other security attributes unrelated to GCS region checks (e.g., attributes that limit the execution states of the processor in which the memory region is allowed to be accessed).

[0112] If the instruction that triggered the load / store operation is not a GCS-accessing instruction, then in step 208, the MMU 28 checks whether the memory attribute data corresponding to the target address being accessed for the load / store operation specifies that the memory address space region corresponding to the target address is a GCS region. However, in this case, the response is reversed compared to step 204: the load / store request may potentially be allowed if the non-GCS-accessing instruction does not access a GCS region, but may be denied if it does access a GCS region. More specifically, if the memory attribute data for the region corresponding to the target address specifies a GCS region, then in step 205, the MMU checks whether the memory access is a write memory access. If so, then in step 210, the MMU 28 denies the load / store operation and signals a failure. By restricting write access to the GCS region to a dedicated class of GCS-accessing instructions, this prevents the majority of normal store instructions in the program code from tampering with the protected return state on the GCS data structure. This reduces the opportunity for an attacker to modify the operands of a normal store instruction in an attempt to corrupt the protected return state on the GCS.

[0113] On the other hand, if the non-GCS access instruction is not attempting to access the GCS region (N in step 208), or is attempting to access the GCS region but is a read request (N in step 205), the method again proceeds to step 212 to apply other access permission checks and then controls whether the load / store operation is denied or allowed depending on the results of these checks, similar to those described above for steps 212, 214, and 216.

[0114] FIG. 14 illustrates a simulator implementation that may be used. While the above embodiments implement the invention in terms of apparatus and methods for operating specific processing hardware supporting the technology, it is also possible to provide an instruction execution environment according to the embodiments described herein 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. Various 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 1330, optionally running a host operating system 1320 and supporting the simulator program 1310. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or there may be multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such an approach may be justified in certain situations, such as when it is desirable to execute code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or may 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, pp. 53-63.

[0115] While embodiments have been described above with reference to particular hardware constructs or features, equivalent functionality may be provided in the simulated embodiments by suitable software constructs or features. For example, particular circuits may be implemented as computer program logic in the simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in the simulated embodiments. In arrangements where one or more of the hardware elements referenced in the foregoing embodiments reside in host hardware (e.g., host processor 1330), some simulated embodiments may use the host hardware where suitable.

[0116] Simulator program 1310, which may be stored on a computer-readable storage medium (which may be a non-transitory medium), provides a program interface (an instruction execution environment) to target code 1300 (which may include applications, an operating system, and a hypervisor) that is the same as the interface of the hardware architecture being modeled by simulator program 1310. Thus, program instructions of target code 1300, including the NOP-compatible instructions described above, may be executed from within the instruction execution environment using simulator program 1310, thereby enabling a host computer 1330 that does not actually have the hardware functions of device 2 described above to emulate these functions. Similarly, the memory management check function of FIG. 13 may be emulated using memory management program logic 1318 of simulator program 1310.

[0117] Thus, simulator program 1310 may have processing program logic 1312 that simulates the processing states described above for hardware device 2. For example, processing program logic 1312 may control transitions of execution states (e.g., exception levels) in response to events occurring during simulated execution of target code 1300. Instruction decode program logic 1314 emulates the behavior of instruction decoder 10, decodes instructions of target code 1300, and maps these instructions to corresponding instructions in the native instruction set of host device 1330. Register emulation program logic 1316 maps register accesses requested by the target code to accesses to corresponding data structures maintained on the host hardware of host device 1330, such as by accessing registers of host device 1330 or data in memory 1332. The memory manager logic 1318 implements address translation, page table walks, and access control checks in a manner corresponding to the MMU 28 described in the hardware implementation embodiment above, but with the additional functionality of mapping simulated physical addresses resulting from address translation based on page tables defined for the target code 1300 to host virtual addresses used to access host memory 1332. These host virtual addresses may themselves be translated to host physical addresses using standard address translation mechanisms supported by the host (the translation of host virtual addresses to host physical addresses is outside the scope of what is controlled by the simulator program 1310).

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

[0119] Although illustrative embodiments of the present invention are described in detail herein with reference to the accompanying drawings, it will be understood that the invention is not limited to these precise embodiments, and that various changes and modifications can be made to the embodiments by those skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

1. An instruction decoder for decoding instructions, A processing circuit for performing data processing in response to the decoding of the instruction by the instruction decoder, At least one control register for specifying instruction function selection information, Equipped with, In response to a non-operation compatible instruction, the instruction decoder, When the instruction function selection information specified by the at least one control register is in a first state, the non-operation compatible instruction is treated as a non-operation instruction. When the instruction function selection information specified by the at least one control register is in the second state, both the first and second operations are performed. A device configured to control the processing circuit so as not to perform the second operation when the instruction function selection information specified by the at least one control register is in a third state, while performing the first operation.

2. The apparatus according to claim 1, wherein, in response to the non-operation compatible instruction, the instruction decoder is configured to perform the second operation when the instruction function selection information is in the fourth state, but controls the processing circuit so as not to perform the first operation.

3. The apparatus according to claim 1 or 2, wherein the processing circuit is configured to control the relative order in which the first operation and the second operation are applied based on the instruction function selection information when the instruction function selection information is in the second state.

4. Whether the first and second actions are function prologue actions associated with a function call, The apparatus according to claim 1 or 2, wherein the first operation and the second operation are function epilogue operations associated with the return from the processing of the function.

5. The apparatus according to claim 1 or 2, wherein for at least one variant of the non-operation compatible instruction, one of the first operation and the second operation includes an authentication code generation operation that generates an authentication code based on an operand and associates the authentication code with the operand.

6. The operand includes a value obtained from the link register, The apparatus according to claim 5, wherein the instruction decoder is configured to control the processing circuit to branch to a specified address in the link register in response to a function return branch instruction.

7. The apparatus according to claim 5, wherein associating the authentication code with the operand includes embedding the authentication code in some of the higher bits of the operand.

8. The apparatus according to claim 5, wherein the authentication code generation operation includes generating the authentication code according to an encryption function based on at least the operands and the encryption key.

9. The apparatus according to claim 1 or 2, wherein for at least one variant of the non-operation compatible instruction, one of the first operation and the second operation includes a guarded control stack (GCS) push operation for pushing the operand into a GCS data structure to protect return state information.

10. For at least one variant of the aforementioned non-operation compatible instruction One of the first operation and the second operation includes an authentication code generation operation that generates an authentication code based on an operand and associates the authentication code with the operand. The apparatus according to claim 1 or 2, wherein the other of the first operation and the second operation includes a guarded control stack (GCS) push operation for pushing the operand into a GCS data structure in order to protect the return state information.

11. The processing circuit is configured to push the operand and the authentication code to the GCS data structure in response to the non-operation compatible instruction when the instruction function selection information is in the first sub-state of the second state, and The apparatus according to claim 10, wherein the processing circuit is configured to push the operand to the GCS data structure without the authentication code in response to the no-operation compatible instruction when the instruction function selection information is in a second sub-state of the second state.

12. For at least one variant of the aforementioned non-operational compatible instruction, The apparatus according to claim 1 or 2, wherein one of the first operation and the second operation includes an authentication code checking operation that checks whether an authentication code associated with an operand matches an expected authentication code generated based on the operand, and triggers an error handling response in response to the detection of a mismatch between the associated authentication code and the expected authentication code.

13. The apparatus according to claim 12, wherein the associated authentication code is obtained from a portion of the upper bits of the operand.

14. The apparatus according to claim 1 or 2, wherein for at least one variant of the non-operation compatible instruction, one of the first operation and the second operation includes a guarded control stack (GCS) pop operation for popping the function return information from a GCS data structure in order to protect the function return information.

15. For at least one variant of the aforementioned non-operational compatible instruction, Either the first operation or the second operation includes an authentication code checking operation to check whether the authentication code associated with an operand matches an expected authentication code generated based on the operand, and to trigger an error handling response in response to the detection of a mismatch between the associated authentication code and the expected authentication code. The apparatus according to claim 1 or 2, wherein the other of the first operation and the second operation includes a guarded control stack (GCS) pop operation for popping the function return information from a GCS data structure in order to protect the function return information.

16. The processing circuit is configured to perform the GCS pop operation in response to the no-operation compatible instruction when the instruction function selection information is in the first sub-state of the second state, and to perform the authentication code check operation on the value popped from the GCS data structure by the GCS pop operation, and The apparatus according to claim 15, wherein, when the instruction function selection information is in a second sub-state of the second state, the processing circuit is configured to perform the authentication code check operation on a value in a given register before performing the GCS pop operation in response to the no-operation compatible instruction, and to perform the GCS pop operation in order to pop the function return information from the GCS data structure to the given register.

17. When the instruction function selection information is in a state indicating that access to the GCS data structure will be performed in response to the non-operation compatible instruction, The apparatus according to claim 9, wherein the processing circuit is configured to reject the memory access triggered by the non-operation compatible instruction in response to detection that the memory area corresponding to the target address of the non-operation compatible instruction is designated by memory attribute data as a memory area other than the GCS area for storing the GCS data structure.

18. The apparatus according to claim 17, wherein the processing circuit is configured to reject a write memory access triggered by the non-GCS access type instruction in response to detection that a memory area corresponding to the target address of a non-GCS access type instruction is designated as the GCS area by memory attribute data.

19. The apparatus according to claim 1 or 2, wherein the instruction function selection information includes a first operation indicator indicating whether or not the first operation is performed in response to the no-operation compatibility instruction, and a second operation indicator indicating whether or not the second operation is performed in response to the no-operation compatibility instruction.

20. The apparatus according to claim 1 or 2, wherein the instruction function selection information further indicates whether the processing circuit should perform a third operation in response to the no-operation compatible instruction.

21. It is a method, Decoding the instructions, This includes performing data processing in response to decoding the aforementioned instruction, In response to decoding the non-operational compatible instruction, the method When the instruction function selection information specified by at least one control register is in a first state, the non-operation compatible instruction is treated as a non-operation instruction, When the instruction function selection information specified by the at least one control register is in the second state, both the first and second operations are performed. A method comprising performing the first operation but not the second operation when the instruction function selection information specified by the at least one control register is in a third state.

22. A computer program that includes instructions to control the host data processing device to provide an instruction execution environment for executing target code when executed by the host data processing device, wherein the computer program Instruction decoding program logic for decoding the instructions of the target code, Includes register emulation program logic that maintains data in the storage circuit of the host data processing device in order to emulate at least one control register for specifying instruction function selection information, In response to a non-operation compatible instruction, the instruction decoding program logic, When the instruction function selection information is in the first state, the non-operation compatible instruction is treated as a non-operation instruction. When the instruction function selection information is in the second state, both the first operation and the second operation are performed. A computer program configured to control the host data processing device so as not to perform the second operation when the instruction function selection information is in a third state, while performing the first operation.

23. A storage medium for storing the computer program described in claim 22.

Images