Operless compatible instruction

Abstract

In one embodiment, an apparatus includes an instruction decoder to decode an instruction; processing circuitry to perform data processing by decoding by the instruction decoder in response to the instructions; and at least one control register to specify instruction function selection information. In response to a non-operation compatible instruction, the instruction decoder is configured to control the processing circuitry to: treat the non-operation compatible instruction as a non-operation instruction when the instruction function selection information specified by the at least one control register is in a first state; performing 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 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.

Description

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

[0002] A data processing device has a processing circuit 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 can be defined according to an instruction set architecture (ISA). ISA represents a framework agreed between a hardware manufacturer that manufactures processing hardware specifically implemented for a given processor and a software developer that writes code to execute on the hardware, so that the code written according to the ISA will operate correctly on the hardware that supports the ISA. There may be design challenges in selecting instructions supported by the ISA and its encoding. When planning the instruction definition of an ISA, the design decisions made by the ISA designer may have a significant impact on real-world performance that is realized by the processing hardware when executing a particular program.

[0003] At least some examples provide a device comprising: an instruction decoder to decode instructions; a processing circuit to perform data processing in response to the instructions being decoded by the instruction decoder; and at least one control register to specify 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; 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 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 comprising: decoding instructions; and performing data processing in response to the decoding of these instructions; wherein: in response to the decoding of a no-operation compatible instruction, the method comprises: when the instruction function selection information specified by at least one control register is in a first state, treating 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 second state, performing both a first operation and a second operation; and when the instruction function selection information specified by the at least one control register is in a third state, performing the first operation but not the second operation.

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

[0006] The computer program may be stored on a storage medium, which may be a non-transitory storage medium or a transient storage medium.

[0007] Other aspects, features and advantages of the present technology will be apparent from the following description of examples read in conjunction with the accompanying drawings, in which:

[0008] Figure 1 schematically illustrates an example of a data processing apparatus;

[0009] Figure 2 An example of a register showing a device;

[0010] Figure 3 An example of a no operation compatible (NOP compatible) instruction is shown;

[0011] Figure 4 Shows a method for processing NOP compatible instructions;

[0012] Figure 5 Examples showing function calls and function returns;

[0013] Figure 6 An example of a protection control stack (GCS) push operation and a GCS pop operation is shown;

[0014] Figure 7 An example of an authentication code generation operation is shown;

[0015] Figure 8 An example of an authentication code checking operation is shown;

[0016] Fig. 9 and Fig.10 An example of performing a GCS push operation and an authentication code generation operation in different orders is shown;

[0017] Fig.11 and Fig.12 An example of performing a GCS pop-up operation and an authentication code check operation in different orders is shown;

[0018] Fig.13 showing the step of checking whether memory access is allowed based on memory attribute data; and

[0019] Fig.14 A simulation example is shown.

[0020] A device includes: an instruction decoder to decode instructions; a processing circuit to perform data processing in response to the instructions decoded by the instruction decoder; and at least one control register to specify instruction function selection information. In response to a no operation compatible (NOP compatible) instruction, the instruction decoder controls the processing circuit to: when the instruction function selection information specified by the at least one control register is in a first state, 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 second state, perform both a first operation and a second operation; and when the instruction function selection information specified by the at least one control register is in a third state, perform the first operation but not the second operation.

[0021] NOP compatible instructions can be used to implement some optional operations, which, if executed, may be useful, but are not critical to the correct operation of the software program using the instructions. For example, the first operation and the second operation may be operations that provide optional security enhancements or performance hints, which may help improve security and / or performance, even if they are not necessary for obtaining the correct operation results of the program. Those enhancements may not be necessary, and it is therefore desirable to be able to control whether these operations are actually performed on a given instance of a sequence code that includes instructions for performing one or both of the first operation and the second operation. Not performing these operations can help save power or allow analysis of how the same code will run on traditional hardware that does not support optional operations. By controlling the function of the instruction based on instruction function selection information stored in at least one control register, the same program code can be executed in different usage scenarios, where depending on the current value of the instruction function selection information, the different results of the first operation and the second operation (if any) are executed by the processing circuit in response to the instruction.

[0022] When the instruction function selection information is in the first state, the instruction is presented as a NOP instruction. The NOP instruction may be an instruction for which execution does not cause any change in the architecture state except for the change in the program counter, and the change in the program counter may be implicit in the program flow (without branches) that advances in sequence from the NOP instruction to the next instruction after the NOP. Therefore, software developers have the option of turning off the feature represented by the first and second operations together. This may be useful, for example, where the first operation and the second operation correspond to features introduced in an updated ISA version, which may not be available on a conventional device supporting an older ISA version. Another use case may be that the first operation and the second operation may not always be required (for example, when executing code for a lower security use case, before executing a code sequence including a NOP compatible instruction, the security enhancement represented by the first and / or second operation may be turned off by setting the instruction function selection information to the first state to save power).

[0023] When the instruction function selection information is in the second state, the processing circuit performs both the first operation and the second operation in response to the NOP compatible instruction. When the instruction function selection information is in the third state, the processing circuit performs the first operation in response to the NOP compatible instruction, but does not perform the second operation. Usually, in order to provide whether the different combinations of the first operation and the second operation are performed by the program code sequence, each operation is expected to be encoded in a separate instruction, so that the combination of the two operations will require two different instructions, and if only one of these operations is required, only one instruction of these instructions will be included in the software code. However, using the NOP compatible instructions described above, both the first and second operations can be performed in response to the same instruction (and the option of having the same instruction being performed is that only the first operation is performed, but the second operation is not performed). Therefore, the identical code binary for the part of the program code including the NOP compatible instruction can act in different ways, depending on how the instruction function selection information has been performed before the part of the program code is executed. Compared to providing a specific implementation of two different NOP compatible instructions corresponding to the first operation and the second operation, this provides a more efficient ISA encoding. First, this avoids the need for the ISA to use up to two different instruction encodings for different NOP-compatible instructions corresponding to the first operation and the second operation, respectively, saving encodings that could be used for another type of instruction, and thus improving performance of code using the other type of instruction (compared to needing to split the operation of the other type of instruction into multiple simpler instructions). Furthermore, software code using NOP-compatible instructions will only require processing circuitry to use a single instruction slot for instructions in the fetch, decode, issue, and execute stages of the processing pipeline (as well as instructions in an instruction cache or other memory used to store program code being executed), which saves an instruction slot used by another instruction that implements a different operation, and thus can improve performance, as well as improve code storage density in caches and in memory.

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

[0025] In some examples, NOP-compatible instructions may not support the option of performing a second operation without performing a first operation. For example, any remaining encoding of the instruction function selection information (other than the first, second, and third states described above) may be used to control other features 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 to indicate that the second operation should be performed and the first operation should not be performed.

[0026] However, in other examples, when the instruction function selection information is in the fourth state, in response to the NOP compatible instruction, the instruction decoder can control the processing circuit to perform the second operation, but not the first operation. This can be particularly useful, so that the NOP compatible instruction can be used to perform the first operation but not the second operation, or perform the second operation but not the first operation, or the two operations are performed together, or can be expressed as NOP, so that the first operation and the second operation are not executable. Therefore, the instruction function selection information can be used to independently open and close each of the first operation and the second operation. This provides the same flexibility for selecting which operation is performed in the case where each of the first operation and the second operation is encoded as different NOP compatible instructions, but has a more efficient instruction encoding.

[0027] In some examples, when the instruction function selection information is in the second state, the processing circuit can control the relative order of applying the first operation and the second operation based on the instruction function selection information. For example, the first operation can be performed before the second operation, or the second operation can be performed before the first operation, or the two operations can be performed in parallel. The instruction function selection information can be used to select between two or more of these options. This can be useful because one order between the first operation and the second operation can have advantages over another order. For example, the first order can provide greater security, but the second order can be more efficient for performance. Therefore, a control state is provided, which allows the configuration of the relative order used to be used to allow the same code binary to be executed with different use cases, and different use cases can have different preferences for priority security and / or processing performance.

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

[0029] However, NOP compatible instructions may be particularly useful for function prologue operations associated with function calls. Therefore, for the function prologue variant of NOP compatible instructions, the first operation and the second operation are function prologue operations associated with function calls. For example, the function prologue operation may be a preliminary operation performed before entering the function body, before, during, or shortly after making a function call. Because the same function may be called a large number of times during execution of a given software workload, even a relatively small performance saving is achieved on a single instance of the calling function, which may lead to a significant improvement in overall software workload performance, because the improvement is seen each time the function is called. Therefore, by enabling the first operation and the second operation associated with a function call to be executed in response to a single NOP compatible instruction, rather than requiring multiple instructions, this may provide a significant performance improvement for the overall workload.

[0030] For similar reasons, NOP compatible instructions can be used for function epilogue operations associated with the return from the processing of a function. These are operations performed after the main body of the function is completed, in preparation for returning to the background processing that called the function. Such epilogue operations can be performed before, during, or after the return branch that actually returns the processing to the background processing. Therefore, for the function epilogue variant of the NOP compatible instruction, the first operation and the second operation are function epilogue operations associated with the return from the processing of the function.

[0031] 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 to generate an authentication code based on an operand and to associate the authentication code with the operand.

[0032] This authentication code generation operation can be applied to any operand, but can be particularly useful where it is applied to a function return address, which is set on a function call to indicate the instruction address to which subsequent return branches should return processing once the function body has completed, to provide defense against return-oriented programming (ROP) attacks.

[0033] ROP type attack is a common attack category on data processing systems. ROP attack is an attack that attempts to make a program act in an unexpected manner by damaging the return status information used to return from a function call or an exception. Usually, the software stores the return status information to a memory, for example, to facilitate the nesting of function calls or exceptions. Before the return status information that can be used for an internal function call or an exception overwrites the return status information for an external function call or an exception (of a nested set of function calls or exceptions) in a register, the return status information for the external function call or an exception can be stored in a memory to save it. ROP attacks can attempt to tamper with the return status information when the return status information is stored in a memory before the return status information 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 an exception return to return the program flow to an instruction other than the next instruction after the point where the function is called or the exception is taken, which can allow an attacker to control the processing circuit to perform any operation other than the sequence of operations expected by the programmer.

[0034] The 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 stored in memory can be deleted based on the mismatch between the tampered operand and the corresponding authentication code, and if the operand has been tampered with, the authentication code may no longer correspond to the operand. Although the authentication code generation operation can be used for security, it is not necessary, and in some use cases, it is preferably omitted for performance reasons. Therefore, it may be useful to provide a NOP compatible instruction that implements the selection of whether to perform the authentication code generation operation in response to an instruction, so that the same code sequence can be executed in different scenarios with different results for whether to perform the authentication code generation operation. Therefore, it may be useful that one of the first operation and the second operation includes an authentication code generation operation.

[0035] Although 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), 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 the address specified in the link register. Therefore, when the authentication code generation operation is applied to the operand in the link register, typically, the operand for the authentication code generation operation may be a function return address. This may be useful in providing defense against ROP attacks. In the case where the authentication code generation operation is applied to a function return address, then this may be an example of a function prologue operation as discussed above, as it is typically the case that this operation will be associated with a function call execution.

[0036] In the authentication code generation operation, the authentication code generated can be associated with the operand in different ways. For example, the authentication code can be stored in a specific register with a known association with the register providing the operand. However, this may be optional, and in some cases, the authentication code may be embedded in the part of the operand itself. Therefore, associating the authentication code with the operand may include embedding the authentication code in a part of the more significant bits of the operand. This may be useful, because by embedding the authentication code in the operand itself, then this means that any subsequent operation to move the operand from one position to another (for example, pushing the operand from the register to the stacked data structure in the memory) also implicitly causes the authentication code to be transferred together with the operand, without the need for separate operations to transfer the authentication code. The more significant bits of the operand can be used to represent the authentication code, because generally, although in fact the processor architecture can support addresses with a certain number of bits (for example, 64 bits), the real world data processing device may not yet need to provide memory storage using the entire 64-bit address space. Therefore, although the address may have 64 bits, in fact only a smaller number of bits are used, wherein several most significant bits correspond to zero (or some other fixed values). Therefore, since some of the upper bits are not actually used, these bits may be replaced by an authentication code (the authentication code may be inserted into any subset of these unused bits at the upper end of the address).

[0037] The authentication code generation operation may include generating the authentication code according to a cryptographic function based at least on the operand and the key. By generating the authentication code according to a cryptographically secure function (e.g., QARMA-64, QARMA-128, or SHA256), for example based on a key, the authentication code may be generated in a manner that makes it difficult for an attacker to predict the authentication code corresponding to a given address.

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

[0039] In some examples, for at least one variant of the NOP-compatible instruction, one of the first operation and the second operation includes a protection control stack (GCS) push operation to push the operand to a GCS data structure for protecting return status information. Such a GCS push operation is another example of a defensive measure against ROP attacks, but without relying on the assigned authentication code to protect the return status from tampering, a protected GCS data structure can be established, which has at least one defensive measure to limit the ability to write data in the GCS data structure, providing some additional protection relative to normal memory areas. Again, the GCS push operation can be an example of a function prologue operation because it can be used to perform a GCS push operation on a function return address when a function is called. Although such a GCS push operation can be used for security, it has a performance cost, and therefore, some use cases with lower security requirements may prefer not to perform it. Therefore, the GCS push operation is another example of an operation that can be effectively implemented using a NOP-compatible instruction so that the same program code sequence including the NOP-compatible instruction can be executed in different use cases, where the instruction function selection information controls whether the GCS push operation is actually implemented.

[0040] The NOP-compatible instruction is particularly useful for a variant of the NOP-compatible instruction, wherein one of the first operation and the second operation includes an authentication code generation operation to generate an authentication code based on an operand and associate the authentication code with the operand; and the other of the first operation and the second operation includes a protection control stack (GCS) push operation to push the operand to a GCS data structure for protecting return status information. Since the authentication code generation operation and the GCS push operation can be viewed as alternative techniques for protecting function return status from ROP attacks, those are often needed at the same program (which is associated with a function call) point, and it is therefore useful to combine those into a single instruction while also providing the option of turning off one or both of these operations. Although the two operations nominally protect against the same class of attacks, they may have different pros and cons, and therefore for "defense in depth", some developers may wish to include two measures so that they can be used to support the option of performing two operations under a function call. By using NOP-compatible instructions, only a single instruction can be executed to perform two types of operations (in the case where the instruction function selection information is in the second state).

[0041] In the case where the first operation and the second operation are respectively an authentication code generation operation and a GCS push operation (or vice versa), there may be a different order between these operations. Some specific implementations may therefore allow for a selection of which order to use, depending on the instruction function selection information.

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

[0043] In response to the NOP compatible instruction, when the instruction function selection information is in the second sub-state of the second state, the processing circuit may push the operand but not the authentication code to the GCS data structure. In this case, the authentication code generation operation and the GCS push operation may be independent of each other and may therefore be performed in parallel or in either order. This may improve performance by supporting the option of performing them in parallel, but means that the GCS data structure does not protect the authentication code.

[0044] 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 check operation to check whether an associated authentication code associated with an operand matches an expected authentication code generated based on the operand, and trigger an error handling response in response to detecting a mismatch between the associated authentication code and the expected authentication code. This operation can be used to check the validity of the authentication code generated by the authentication code generation operation described above, and although it can be performed on any operand, it can generally be performed as a function epilogue operation to check whether the return address is safe to use (such as the protection against ROP attacks mentioned above). Therefore, for the corresponding reason of the authentication code generation operation, the NOP-compatible instruction can be used for the authentication code check operation.

[0045] In some examples, the associated authentication code of the authentication code checking operation may be obtained from a portion of the more significant bits of the operand.

[0046] In a corresponding manner for an authentication code generation operation, in an authentication code checking operation, an expected authentication code may be generated according to a cryptographic function based on at least the operand and the key (and in some cases also based on modifiers (e.g., stack indicators)).

[0047] For at least one variant of the NOP-compatible instruction, one of the first operation and the second operation may include a protection control stack (GCS) pop operation to pop function return information from a GCS data structure used to protect the function return information. This may be used to obtain return status information that was previously pushed to the GCS data structure by a previous GCS push operation. For similar reasons to the GCS push operation, a GCS pop operation (an example of a function epilogue operation) may be used to implement using a NOP-compatible instruction.

[0048] Again, some variants of NOP-compatible instructions may support both an authentication code check operation and a GCS pop operation. Thus, one of the first operation and the second operation may include an authentication code check operation to check whether an associated authentication code associated with an operand matches an expected authentication code generated based on the operand, and trigger 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 operation and the second operation includes a protection control stack (GCS) pop operation to pop function return information from a GCS data structure used to protect the function return information. These operations can be used to be combined into the same NOP-compatible instruction because if both are needed, they will typically be executed at the same point in the program, such as a function epilogue operation before executing a function return, after completion of the main body of the function.

[0049] The order between the authentication code check operation and the GCS pop operation can be controlled based on the instruction function selection information. In response to the NOP compatible instruction, when the instruction function selection information is in the first sub-state of the second state, the processing circuit can perform the GCS pop operation and perform the authentication code check operation on the value popped from the GCS data structure by the GCS pop operation; and in response to the NOP compatible instruction, when the instruction function selection information is in the second sub-state of the second state, the processing circuit can perform the authentication code check operation on the value in the given register before performing the GCS pop operation, and perform the GCS pop operation to pop the function return information from the GCS data structure to the given register. Again, this provides different options for the tradeoff between performance and security.

[0050] For a case where a NOP-compatible instruction implements a GCS push operation or a GCS pop operation as one of the first / second operations, then in response to the NOP-compatible instruction, when the instruction function selection information is in a state indicating that 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 to be performed), the processing circuit may, in response to detecting that the memory area corresponding to the target address of the NOP-compatible instruction is a memory area outside the GCS area designated by the memory attribute data as a GCS area for storing the GCS data structure, reject the memory access triggered by the NOP-compatible instruction. Therefore, if the access is triggered by an instruction of the GCS access type, access to a memory area that is not designated as a GCS data structure may be rejected. This avoids GCS access type instructions (including NOP-compatible instructions when the NOP-compatible instruction performs a GCS push operation or a GCS pop operation) from being misused to access a memory area that is not intended to be used to store a GCS data structure, which may reduce the attack surface that an attacker may exploit.

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

[0052] The instruction function selection information can be represented in different ways. In some examples, the first, second and third states mentioned earlier correspond to different (possibly arbitrarily selected) encodings of the instruction function selection information. Therefore, any mapping between different combinations of the bit values ​​of the first, second and third states and the instruction function selection information can be used.

[0053] However, in some examples, it may be useful for the instruction function selection information to include a first operation indicator to indicate whether the first operation is to be performed in response to the NOP-compatible instruction; and a second operation indicator to indicate whether the second operation is to be performed in response to the NOP-compatible instruction. For example, the instruction function selection information may include a set of bits, each of which corresponds to one of the operations that may be selected to be performed in response to the NOP-compatible instruction, and indicates whether the operation needs to be performed. This encoding of the instruction function selection information may be easy for software developers to understand and easier to decode by hardware or instruction decoders of processing circuits because the selection of each operation depends only on a single indicator (e.g., a single bit) rather than requiring more complex decoding circuit logic.

[0054] In some examples, based on the instruction function selection information, the NOP compatible instruction can support the option selected from more than two operations. Therefore, the instruction function selection information can further indicate whether the processing circuit should perform a third operation in response to the NOP compatible instruction. For example, where the instruction function selection information includes a set of bits, each indicating whether the corresponding operation should be performed in response to the NOP compatible instruction, it can be relatively efficient to increase the support for the desired additional operation. Therefore, although the example discussed below shows an example with two operations, the claims are not limited thereto, and additional operations can also be supported.

[0055] The techniques discussed above may be implemented within a data processing apparatus having hardware circuitry provided for implementing the processing circuitry and instruction decoders discussed above.

[0056] However, the same technology can also be implemented in a computer program that is executed on a host data processing device to provide an instruction execution environment for the execution of the target code. Even if the host data processing device itself does not support the architecture, such a computer program can control the host data processing device to simulate the architecture environment that it will provide on the hardware device that actually supports the target code according to a certain instruction set architecture. The computer program may have an instruction decoding program logic and a register emulation program logic that controls the host data processing device to emulate the features discussed above, including support for NOP compatible instructions as described above. The instruction decoding program logic decodes the instructions of the target code and generates instructions of the 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 the storage circuit of the host data processing device to emulate the content of at least one control register, including registers storing instruction function selection information as discussed above. Therefore, when the target code including NOP compatible instructions is executed in the instruction execution environment provided by the emulation computer program executed on the host data processing device, even if the host data processing device itself does not support NOP compatible instructions, the same function as discussed above can be realized.

[0057] For example, such simulation programs may be useful when program code written for one instruction set architecture is executed on a host processor supporting a different instruction set architecture. Furthermore, since execution of software on a simulated execution environment may allow software testing to be paralleled with ongoing development of hardware devices supporting the new architecture, simulation may allow software development for a newer version of an instruction set architecture to begin before processing hardware supporting the new architecture version is ready. The simulation program may be stored on a storage medium, which may be a non-transitory storage medium.

[0058] Figure 1An example of a data processing device 2 is schematically shown. The data processing device has a processing pipeline 4 including several pipeline stages. In this example, the pipeline stages include an extraction stage 6 for extracting instructions from an instruction cache memory 8; a decoding stage 10 for decoding the extracted program instructions to produce micro-operations (decoded instructions) to be processed by the remaining stages of the pipeline; an issue stage 12 for checking whether the operands required for the micro-operation are available in the register file 14, and issuing the micro-operation for executing the required operands of the given micro-operation once as available; an execution stage 16 for executing the data processing operation corresponding to the micro-operation by processing the operands read from the register file 14 to produce a result value; and a write-back stage 18 for writing the result of the processing back to the register file 14. It should be understood that this is only one example of a possible pipeline architecture, and other systems may have additional stages or different stage configurations. For example, in an out-of-order processor, a register renaming stage for mapping architectural registers specified by program instructions or micro-operations to physical register descriptors identifying physical registers in the register file 14 may be included. In some examples, there may be a one-to-one relationship between program instructions decoded by decode stage 10 and corresponding micro-operations processed by execute stage 10. There may also be a one-to-many or many-to-one relationship between program instructions and micro-operations, such that, for example, a single program instruction may be split into two or more micro-operations, or two or more program instructions may be fused to be processed as a single micro-operation.

[0059] The execution stage 16 (an example of processing circuitry) includes a number of 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 the program counter, which indicates the current execution point accordingly; and a load / store unit 26 for performing load / store operations to access data in the memory system 8, 30, 32, 34. A memory management unit (MMU) 28, which is an example of memory management circuitry, is provided for performing address translation between virtual addresses specified by the load / store unit 26 based on operands of data access instructions and physical addresses identifying storage locations of data in the memory system. The MMU has a translation lookaside buffer (TLB) 29 for caching address translation data from a paging table stored in the memory system, wherein a paging table entry defines an address translation mapping and access permissions, which (for example) govern whether a given program executing on the pipeline is allowed to read or write data or execute instructions from a given memory area. The MMU 28 may have circuitry to request memory accesses during a paging table walk when the paging table structure is traversed to locate a paging table entry corresponding to a desired address.

[0060] In this example, the memory system includes a level 1 data cache memory 30, a level 1 instruction cache memory 8, a shared level 2 cache memory 32, and a main system memory 34. It will be understood that this is only one example of a possible memory hierarchy, and other configurations of cache memories may be provided. The specific type of processing units 20-26 shown in the execution stage 16 is only one example, and other implementations may have different groups of processing units or may include multiple instances of the same type of processing unit so that multiple micro-operations of the same type can be processed in parallel. It should be understood that Figure 1 This is only a simplified representation of some components of a possible processor pipeline implementation, and the processor may include many other elements that are not shown for the sake of brevity. Figure 1 While shown with a single processor core having access to the memory 34 , the device 2 may also have one or more further processor cores that share access to the memory 34 , with each core having a respective cache memory 8 , 30 , 32 .

[0061] Figure 2 An example of some registers 14 of the device 2 is shown. It should be understood that Figure 2 Not all registers are shown - the apparatus may also 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 addressed using one of the general register identifiers (e.g., register X30). The registers also include a stack pointer (SP) register 52 for storing a stack pointer. The apparatus also has a number of control registers 56 for storing control information for controlling the operation of the processor. For example, the control registers 56 may include a protection control stack (GCS) stack pointer register 58 for controlling access to the GCS, as described below in relation to Figure 6 Further discussion; and at least one register that provides instruction function selection information 60 to control the behavior of NOP compatible instructions as discussed further below. Although Figure 2 The instruction function selection information 60 is shown as a single register, but this information may also be split into two or more registers.

[0062] Figure 3An example of a NOP compatible instruction 70 is shown. The instruction encoding includes an opcode 72 identifying the instruction type, and one or more operand fields 74, 76 for specifying operands of the instruction. The operands 74, 76 may be specified using immediate values, or using register identifiers specifying registers 14 in which the operands are stored, or a combination of at least one immediate value and at least one register identifier. In some cases, the instruction may also specify an additional destination field identifying a register to which the result of the instruction is to be written, or alternatively for one of the registers specified by one of the operand fields that may also serve as a destination register. Although Figure 3 Two operands are shown for the sake of example, but other examples of NOP-compatible instructions may have a greater or lesser number of operands.

[0063] Within a single instruction encoding having the same opcode 72 and the same definition of operand fields 74, 76, a NOP-compatible instruction represents the option of performing no operation at all (so 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). Which combination of operations is selected to be performed in response to the NOP-compatible instruction (by the instruction decoder 10 and / or the execution stage 16 of the processing pipeline 4) is based on the instruction function selection information 60 stored in the control register 56. This information can be set by the instruction executed by the processor. For example, a system register modification instruction (which can be restricted to execution in certain execution states or priority levels) can be used to set the instruction function selection information 60. Alternatively, there can be a dedicated type of instruction for setting the instruction function selection information, which is different from the system register modification instruction used to modify other control registers 56. In the use case of executing a section of code that includes a NOP-compatible instruction, some examples can use an earlier instruction of the same section of code to set the instruction function selection information 60. In other examples, instruction function selection information 60 may be set by supervisory code that manages execution of program code including NOP-compatible instructions (eg, by an operating system managing execution of application programs, or a supervisor managing execution of an operating system).

[0064] Figure 4 1 is a flow chart showing a method for processing NOP-compatible instructions. At step 100, the instruction decoding circuit 10 determines whether the NOP-compatible instruction has been decoded. If not decoded, the instruction decoding circuit 10 decodes another type of instruction, controls the processor to perform the operation represented by the instruction, and continues to wait for a decoded NOP-compatible instruction.

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

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

[0067] If the instruction function selection information 60 is in the second state, then at step 106, processing depends on whether the instruction function selection information is the first substate or the second substate of the second state. If the instruction function selection information 60 is the first substate of the second state, then at step 108, the processing circuit 16 is controlled to perform both the first operation and the second operation (in a first order between the first operation and the second operation). If the instruction function selection information 60 is the second substate of the second state, then at step 110, the processing circuit 16 is controlled to perform both the first operation and the second operation (in a second order between the first operation and the second operation, which is different from the first order). The first and second orders may differ in whether the first and second operations are performed sequentially or in parallel, or in which of the first and second operations is performed first and which is performed second. The order may also differ in whether there is any dependency between the first operation and the second operation (i.e., whether one operation depends on the result of the other or whether the two operations are independent).

[0068] Support for controlling the order between the first operation and the second operation is optional, and in some examples, steps 106 and 110 may be omitted so that when the instruction function selection information is in the second state, then the method proceeds to step 108 to perform the first operation and the second operation in the first order selected by default.

[0069] The following is about Figures 9 to 12 A specific example of describing the order between control operations.

[0070] At step 102 , if the instruction function selection information 60 is in the third state, then at step 112 , the processing circuit 16 is controlled to perform the first operation but not the second operation.

[0071] If the instruction function select information is in the fourth state, then at step 114, the processing circuit 16 is controlled to perform the second operation but not the first operation. Supporting step 140 may be optional, and in some examples, it is not 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 unique space for four different states for the instruction function select information (e.g., because only 2 bits are used for this information 60), then some specific implementations may prefer to use a fourth encoding of the instruction function select information 60 to allow two different sub-states of the second state, as shown in steps 108 and 110, so that the order of operations can be controlled. Other examples may support Figure 3 and thus instruction function select information having 3 or more bits may be used to allow for these additional encodings of instruction function select information.

[0072] One possible encoding of the instruction function selection information (without support for controlling the order between the first operation and the second operation) may be as follows:

[0073] 0b00 - first operation disabled, second operation disabled - the instruction behaves as a NOP (first state);

[0074] 0b01—the first operation is enabled and the second operation is disabled (third state);

[0075] 0b10—the first operation is disabled and the second operation is enabled (the fourth state);

[0076] 0b11—First operation enabled, second operation enabled (second state).

[0077] Such encoding may provide different bits for each operation, which independently indicate whether the operation is enabled or disabled. This may be extended to a third operation or further operations by providing an additional bit per operation (respectively enabling / disabling any additional operation).

[0078] Another example encoding of the instruction function selection information assigns the ability to perform the second operation without performing the first operation, but uses the fourth encoding of the instruction function selection information 60 to indicate the desired order between the first operation and the second operation when performing both operations:

[0079] 0b00 - first operation disabled, second operation disabled - the instruction behaves as a NOP (first state);

[0080] 0b01—the first operation is enabled and the second operation is disabled (third state);

[0081] 0b10—first operation enabled, second operation enabled, first order between first operation and second operation (second state—first substate);

[0082] 0b11—first operation enabled, second operation enabled, second order between the first operation and the second operation (second state—second substate);

[0083] Another example encoding might use more than 2 bits and leave some encodings for future use, for example, when adding support for additional operations or configuration options:

[0084] 0bX00 - first operation disabled, second operation disabled - instruction behaves as NOP (first state);

[0085] 0bX01—the first operation is enabled, and the second operation is disabled (third state);

[0086] 0bX10—the first operation is disabled and the second operation is enabled (the fourth state);

[0087] 0b011—first operation enabled, second operation enabled, first sequence between first operation and second operation (second state—first substate);

[0088] 0b111—first operation enabled, second operation enabled, second order between the first operation and the second operation (second state—second substate);

[0089] It should be appreciated that all of these examples are merely some of the ways in which the operations to be performed for a NOP instruction may be encoded by the instruction function select information 60 .

[0090] Various processing operations may be used as the first and second operations. However, one particular use case may be when a function prologue or epilogue operation is performed on a function call or function return, respectively. Specifically, it may be useful for the first operation and the second operation to be alternative operations on a function return state for protection against return-oriented programming (ROP) attacks. For example, the first operation and the second operation may be an indicator authentication / check operation or a GCS push / pop operation, described further below.

[0091] Figure 5 An example of calling a function (labeled fn1 for ease of reference) and returning from the function is shown. A function (also called a procedure) is a sequence of instructions that can be called from another part of a program, and when completed it returns processing to the part of the program flow where the function was called. The same function can be called from multiple different locations in a program, and therefore the function return address is stored when the function is called so that the function return can distinguish which address the program flow should return to.

[0092] For example, Figure 5As shown, a branch with a link instruction BLR may be executed at the point where the function is to be called (indicated by address #add1) to cause program flow to branch to the instruction at the branch target address #add2 specified using the operand of the branch with the link instruction. The branch with the link instruction also causes the processing circuit to set a link register (a designated register for tracking the function return address, e.g., a general register as shown above) to the address of the next instruction after the branch with the link instruction (in this example, the function return address is #add+4). After the branch has been taken, several instructions (e.g., LD, MUL, ADD, etc.) are executed in the function code, and when the function is completed, a return branch instruction RET is executed, which causes the branch to the instruction indicated by the return address stored in the link register.

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

[0094] However, typically, the first function fn1 called by the background code may itself call another function (i.e., fn2) in a nested manner, and in this case, the function call to fn2 will overwrite the return address stored in the link register, and therefore before calling the other function, the function code of the first function fn1 should include instructions to store 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), and after returning from fn2, the function code of fn1 should restore the return address to the link register before executing the return branch. The responsibility for storing and restoring function return states (e.g., return addresses) will typically lie with software (there may be no architecturally mandatory hardware mechanism for storing return addresses).

[0095] However, when the function return address is stored in memory, it may be vulnerable to an attacker modifying the data, for example using another thread executing on another processor core, or by interrupting the calling function and executing other code at the same time, which overwrites the return address stored in memory. Alternatively, the attacker may execute instructions whose goal is to modify the address operand of the instruction that restores the return address from memory to a register so that the data loaded from memory is different from the return address originally stored to memory before calling the nested function. If the attacker can cause the return branch to branch to a point in the program flow that is not the instruction after the function call branch, the attacker may be able to cause the software to behave incorrectly, and may be able to bypass certain security protections or cause unexpected operations to be performed.

[0096] Function call is an example of operation, which generates return status information, which provides information about the state to which the processing circuit will be restored later. Another context in which the return status information can be retrieved can be when taking an exception, wherein the exception handling circuit provided in the hardware, or the software exception handler can retrieve the exception return status information, such as indicating the exception return address of the address of the instruction to be executed after returning from the processing exception, and / or indicating the stored processor state information of the mode or execution state to be executed by the processor after returning from the exception. For example, the stored processor state information can indicate the exception level of taking the exception, and other information about the operating state of the processor when taking the exception. Like function call, the exception can be nested, and therefore when taking another exception, the exception return state retrieved for the exception can be stored in the memory (automatically in hardware, or by the software exception handler), and therefore when it is stored in the memory, it may be easily tampered by the attacker. These types of attacks can be called return-oriented programming (ROP) attacks. It may be desirable to provide architectural countermeasures for such attacks.

[0097] Figure 6 A method is shown for protecting from ROP attacks using a protected data structure 120 in memory called a "Guardian Control Stack (GCS)." The location of the GCS data structure within the memory address space can be selected by software, but the hardware provides architectural features designed to protect the GCS data structure from tampering by malicious attackers.

[0098] like Figure 2 As shown, registers 14 include control registers 56, which include one or more protected control stack pointer (GCS pointer) registers 58 for storing a stack pointer, which indicates an address on a GCS data structure. In some examples, the GCS pointer registers 58 may be a stacked register group, each provided for at least two execution states (e.g., exception levels) to enable software operating in different execution states to refer to different GCS structures in memory without reprogramming a shared stack pointer register after each transition of the execution state. Other examples may use a single GCS pointer register, and the software may update the stack pointer stored in the GCS pointer register 58 when transitioning between execution states.

[0099] like Figure 6 As shown, the GCS data structure 120 is stored in memory regions designated as GCS regions of memory by memory attributes specified directly or indirectly by associated page table entries of a page table used by a memory management unit (MMU) 28 for controlling address translation and access permission checking. The GCS region attributes may be specified directly within the encoding of the corresponding page table entry, or may be indirectly referenced within a register referenced by the page table entry.

[0100] When a memory region is identified as a GCS region, then write access to the region is limited to write requests triggered by the processing circuit 16 when executing a specific subset of GCS access instructions. General storage instructions used by software for general storage operations without the intention of accessing GCS structures are not considered to be one of the restricted subsets of GCS access instructions. The MMU 28 may still allow the use of general load instructions to read GCS structures, which general load instructions cause read requests that are not GCS memory access requests to be issued. When a memory access request requests access to a GCS region, the request is a write request, and the request is not a GCS memory access request triggered by one of the restricted subsets of GCS access instructions, then the memory access request is denied and an error is signaled. The subset of GCS access instructions may include at least one GCS push instruction, which causes return state information (e.g., a function return address from a link register, or an exception return address or a stored processor state retrieved when an exception is taken) to be pushed to a location on a GCS structure determined using a stack pointer indicated in the GCS pointer register 58. The GCS access instructions may also include at least one form of a GCS pop instruction that pops protected return information from the GCS structure.

[0101] Conversely, GCS access instructions may not be allowed to access memory regions that are not designated as GCS region types by the paging table attributes. Thus, an error may be signaled if a GCS access is attempted when the target memory region for the access is not marked as a GCS region type. By prohibiting the use of GCS access instructions to access non-GCS regions, this discourages programmers from using GCS access instructions unless a GCS access is truly intended, thereby reducing the attack surface available to attackers.

[0102] The GCS structure is separate from any data structures used by software to maintain stored return status information in memory to handle nesting of function calls or exceptions. Thus, the GCS structure is not intended to eliminate the need for software itself to track storage and restoration of return status information when function calls or exceptions are nested (software-triggered storage of return status may continue in the same manner as on processors that do not support architectural measures for GCS protection discussed above). Instead, the GCS structure provides an area of ​​protected memory that is protected from tampering by compromising program code that can be used to provide information for verifying return status information that is intended to be used by software to return from the handling of function calls or exceptions.

[0103] In some implementations, the GCS pop instruction that causes the protected return state information to be popped from the GCS structure may also cause the processing circuit 16 to compare the popped return state with the current return state information stored in a register (e.g., the link register 54 for function returns, or the exception return address register and / or the stored processor state register for exception returns), and signal an error if there is a mismatch between the return state information popped from the GCS structure 120 and the expected return state information that the software expected for the function / exception return. Thus, software may be protected from tampering by including instances of the GCS push and GCS pop instructions within program code that is executed upon function call / return or exception entry / return.

[0104] Other implementations may define separate instructions for verifying that the expected return status information is valid, distinct from the instructions for popping the return status information from the GCS structure 120 .

[0105] Alternatively, a GCS pop instruction may pop the protected return status from the GCS directly into one or more registers used to specify the return status for an exception return or function return (or may be combined with an exception / function return instruction to pop the protected return status and use that status for controlling the exception / function return), in which case no verification of whether the expected return status information provided by software is valid is necessary because, in such implementations, the GCS protected return status 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 place therein based on its own managed stack structure.

[0106] In addition, other types of GCS access instructions may also be supported. When GCS mode is enabled (the control state in control register 56 may control whether GCS mode is enabled), some instructions (which have other functions in a mode that disables the use of GCS) when executed may cause processing circuitry 16 to perform additional functions (e.g., additional GCS mode specific security checks).

[0107] In general, by providing architectural support for defining GCS memory region types for use with GCS structure 120, and restricting write access to GCS region types to a limited subset of GCS access instructions (which may not be allowed to access memory regions other than GCS region types), this reduces the attack surface available to attackers attempting to tamper with protected return status information stored on GCS structure 120.

[0108] GCS provides a defense against ROP attacks.Another option for protecting against ROP attacks is to use an authentication code associated with the return status information. Figure 7An example of an authentication code generation operation performed in response to an authentication code generation instruction based on a first source operand src1 is shown. The source operand may be any value, but it is particularly useful for applying the authentication code generation operation to an address pointer, such as a function return address. The source operand may specify (e.g., by reference to a source register, such as a link register) an address that includes a certain number of bits X, but only a certain number Y of those bits are actually available for an effective address (e.g., X may be equal to 64 and Y may be equal to 48 or 52). Therefore, the XY high bits of the address may be set to zero by default.

[0109] In the authentication code generation operation, the source operand may be passed to the encryption / decryption circuitry of the processing circuitry 16 (e.g., the execution stage 16 may include a circuit similar to Figure 1 The encryption / decryption function unit of the other execution units 20, 22, 24, 26 shown) can apply the authentication code generation function 140 to the first source value based on the key from the key memory and at least one modifier value. The resulting authentication code (PAC) is inserted into the unused high bits of the pointer address to generate the result of the instruction. The result can be written back to the same register storing the source operand, for example. For example, if the source operand is the current function return address stored in the link register 54, then the result is written back to the link register 54. The authentication code generation function 40 can use a cryptographic hash function (e.g., SHA256, SHA128, QARMA-128, QARMA-256, etc.) that makes it infeasible to guess the authentication code associated with a specific address without knowing the key. The modifier value can be a value used to connect the specific instance of the authentication code generated by the operation to a specific execution value reached in the program code, thereby reducing the risk of reuse attacks, in which the effective address / PAC pair from one part of the code is incorrectly replaced and used 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.

[0110] Figure 8 Displays the corresponding authentication code check operation performed on the second source operand src2. The second source operand is expected to be a pointer address, which has been previously passed in Figure 7The authentication code generation operation shown inserts the authentication code PAC into its high bit for authentication, but if the attacker has modified the indicator, the authentication code (PAC) may not be valid. In the authentication code check operation, the 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 the key and modifier values ​​corresponding to the key and modifier values ​​expected to have been used when the authentication code represented by the high bit of the address was generated. Then, the expected authentication code PAC is compared with the associated authentication code PAC extracted from the high bit of the second source operand src2, and it is determined whether the expected authentication code matches the associated authentication code. If so, then processing is allowed to continue, whereas if there is a mismatch between the expected and associated code, then an error handling response is triggered, such as triggering an exception or setting the upper bits of a source register to a value corresponding to an invalid address, so that subsequent accesses or instruction fetches to that address will trigger the MMU 28 to trigger a memory fault due to accessing an invalid address (this means that if an address with an incorrect PAC is used for a function return, then subsequent attempts to fetch instructions from that address after the return branch will trigger a fault, preventing the processing circuitry from continuing to execute the program beyond the incorrect function return).

[0111] By using Figure 7 and Figure 8 Authentication code generation and checking operations are performed, which allow the indicator to be authenticated, making it more difficult for an attacker to inject an unauthenticated indicator and successfully cause the code to branch to the location identified by the indicator, protecting against ROP attacks. By using a cryptographic function as the authentication code generation function 140, brute force guessing of the authentication code associated with a specific address can be made difficult. Instructions for performing authentication code generation operations can be included in the code at the point when the indicator address is generated (for example, between setting a link register in response to a function call and storing a function return address from the link register to memory), and when the address is actually to be used later (for example, before a function return branch), an authentication code check instruction AUT can be included to double-check the authentication code before actually branching to the address.

[0112] The authentication code generation function 140 may vary from implementation to implementation, or may be configurable on a given implementation based on control states in control registers 56. Modifier values ​​for the authentication code generation function may also be configurable or may differ for different variants of instructions implementing the authentication code generation / checking operations.

[0113] The above article about Figures 6 to 8Both the GCS operation and the authentication code operation described can be viewed as defenses against ROP attacks, but some users may prefer to use one form of defense and other users may use another form. Some users may prefer to use a combination of both defenses in a deep approach. In addition, in situations where a piece of code that is sometimes used in a use case that requires the security of ROP defenses may also be executed in a use case that does not require such security, it may sometimes be desirable to omit these operations, in which case it may be better to omit these operations for performance. Therefore, these operations may be useful examples for the first and second operations of the NOP-compatible instructions described above.

[0114] In some cases, it may be desirable to provide a program binary that is backward compatible with older hardware that does not support the GCS and authentication code features, and supports new functionality when running on newer hardware that supports these features. Therefore, the opcode 72 selected for the NOP-compatible instruction may be one that can be considered a NOP instruction on the older hardware.

[0115] Typically, when a new architecture feature is added to an ISA, a control register may be used to indicate whether the feature is supported, and the software may need to check whether the feature is implemented before use. For many features, this is acceptable, but for features that are expected to be executed very frequently, such as features for function prologues and epilogues, this is not feasible due to performance reasons. For such features, it may be useful to provide a set of NOP instruction encodings that perform no operations, at least until some functionality is added to the encoding for newer hardware that supports updated architectures. 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 will make the function larger, because adding more NOP compatible instructions incurs the cost of cache structures and instruction throughput, and therefore reduces performance.

[0116] Thus, using the NOP-compatible instructions described above, multiple operations may be overloaded onto a single NOP-compatible encoding, wherein instruction function selection information 60 provided in one or more control registers 56 independently turns each feature on / off.

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

[0118] myfunc():

[0119] PACIASP LR

[0120] GCSPUSH LR

[0121] ... / / My function content

[0122] GCSPOP LR

[0123] AUTIASP LR

[0124] RET

[0125] In contrast, two-stage functionality is provided by using the NOP-compatible instructions described above, which allows for smaller functions and also allows them to work on both old and new hardware (because old hardware can see them as NOPs, and even on newer hardware, there is a configuration option to disable both operations by setting the instruction function select information to a first state).

[0126] For example, if the combined instructions (in this example, assuming PACIASP encoding) perform all operations, you can have a smaller function:

[0127] myfunc():

[0128] PACIASP LR / / Also performs GCSPUSH

[0129] ... / / My function content

[0130] AUTIASP LR / / Also performs GCSPOP

[0131] RET

[0132] It should be noted that AUTIASP is the complement of PACIASP, and in the above example, by performing the GCSPOP operation, is also the complement of GCSPUSH.

[0133] For example, two control bits may be provided to manage the behavior of these codes.

[0134] 00-PAC disabled, GCS disabled

[0135] 01-PAC enabled, GCS disabled

[0136] 10-PAC disabled, GCS enabled

[0137] 11-PAC enabled, GCS enabled

[0138] This could be extended with new features in the future, adding control bits to turn functionality on / off, all performed by a single code. Additionally, the control state would likely control the relative order in which operations are performed.

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

[0140] The above examples show the case where the first operation and the second operation are any of the following:

[0141] · For function prologue variants, a GCS push operation and an authentication code generation operation, or vice versa; or

[0142] For the function epilogue variants, a GCS pop operation and an authentication code check operation, or vice versa.

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

[0144] However, in other examples, NOP-compatible instructions may be provided that combine a GCS push operation with another operation other than an authentication code generation operation, or that combine an authentication code generation operation with another operation other than a GCS push operation. Similarly, NOP-compatible instructions may be provided that combine a GCS pop operation with another operation other than an authentication code check operation, or that combine an authentication code check operation with another operation other than a GCS pop operation.

[0145] Figures 9 to 12 Different examples of controlling the order between PAC / AUT and GCS operations are shown where both operations are performed in response to a NOP compatible instruction.

[0146] Fig. 9 An example is shown in which a NOP-compatible instruction (executed as a function prologue) performs 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, so 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 and then proceeding to perform a GCS push operation, where the destination register of the PAC operation is the same as the source register for the GCS push operation. In contrast, Fig.10 The PAC and GCS push operations are shown to be performed in a different order, with the GCS push operation being independent of the PAC operation. This allows the push of the function return address to the GCS structure to begin in parallel with the calculation of the authentication code for the PAC operation. This can be useful because the PAC generation function 140 and memory access for the GCS push operation can be relatively slow and therefore slower than the PAC generation function 140. Fig. 9 order, making these operations in parallel can have improved performance. On the other hand, Fig. 9 The example can improve security because the generated authentication code is protected on the GCS, not only the function return address is protected.

[0147] Similarly, Fig.11 and Fig.12 An alternative order is shown in which a NOP-compatible instruction (executed as a function epilogue) implements a GCS pop operation and an authentication code check (AUT) operation as an example of a first operation and a second operation (either way - the first operation can be a GCS pop operation and the second operation can be an AUT operation, or vice versa). Fig.11 A sequence is shown in which an AUT operation depends on the result of a GCS pop row operation because the value popped from the GCS by the GCS pop operation is used as the input of the AUT operation. This method can be used in examples where the corresponding NOP-compatible instruction executed as a function prologue uses Fig. 9 Again, this has the advantage of greater security because the authentication code is protected from tampering using the GCS memory region protection implemented by the MMU 28. On the other hand, Fig.12 A sequence is shown in which the AUT operation and the GCS pop operation are independent so that they can be started in parallel. In this case, the authentication code check may be applied to the value in the link register, and then separately, the GCS pop operation may also pop to the value of the destination register (without the associated authentication code). Assuming that 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 of the GCS pop operation may still be the same register as the source operand for the AUT operation, in which case if the AUT operation detects a mismatch, an error or other error response action is taken, and if the codes match, then the GCS pop operation is allowed to complete, and then the address popped by the GCS pop operation may be used for the function return. Alternatively, the GCS pop operation may pop the protected return address of the GCS structure from memory to a register other than the register checked by the AUT operation, and then a comparison between the value checked by the AUT operation and the value popped from the GCS structure may then be performed to confirm whether the GCS protection address matches the AUT check address, thereby providing a further check whether it is safe to perform a function return based on that address.

[0148] It is therefore useful that the instruction decoder 10 and the execution stage 16 support:

[0149] - a first NOP-compatible instruction is used for a function prologue, wherein one of the first / second operations is the authentication code generation operation (PAC), and the other of the first / second operations is a GCS push operation; and

[0150] - A second NOP-compatible instruction is used for a function epilogue (having a different encoding than the first NOP-compatible instruction), wherein one of the first / second operations is the authentication code check operation (AUT) and the other of the first / second operations is a GCS pop operation.

[0151] The instruction function selection information 60 may specify which of the first operation and the second operation (if any) is to be performed in response to the instruction, and may also control the operation of the instruction. Figures 9 to 12 The relative order of operations shown.

[0152] Fig.13 Flowchart showing the steps performed by the MMU 28 to check the memory access rights of a memory access request. At step 200, an instruction that triggers a load / store operation is decoded. If the instruction function selection information 60 specifies that a GCS push or pop operation is to be performed, then the above-mentioned NOP-compatible instructions that support the GCS push or pop operation are treated as load / store instructions.

[0153] At step 202, it is determined whether the instruction that triggers the load / store operation is a GCS access instruction (a restricted subset of the restricted subset of GCS access instructions that are allowed to access the GCS area of ​​the memory). When the instruction function selection information indicates that a GCS push or pop operation is required, the NOP compatible instruction is considered as a GCS access instruction. Other types of instructions may also be considered as GCS access instructions. In some cases, if the instruction function selection information is in a state indicating that a GCS push or pop operation is not required, the NOP compatible instruction is not considered as a GCS access instruction. Alternatively, if the 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 cannot generate any load / store request), the NOP compatible instruction may always be considered as a GCS access instruction, regardless of the value of the instruction function selection information 60.

[0154] If the decoded instruction is a GCS access instruction, then at step 204, the MMU 28 checks whether the memory attribute data corresponding to the target address accessed by 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 an indirect register specified by the page table entry (and 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 at step 206, the load / store operation is rejected and an error is signaled. This prevents GCS access instructions from being used to access non-GCS memory, which is safer to reduce the attack surface available to attackers. Otherwise, if the GCS access instruction accesses the GCS region, then at step 212, the MMU 28 checks whether any other access permission checks are passed by the load / store operation. If these other checks fail, then at step 214, the load / store operation is rejected and an error is signaled. If these other checks pass, then the load / store operation is allowed at step 216. These other checks may, for example, check for read / write permissions indicating whether reading or writing to the memory region is allowed, or may check other security attributes not related to the GCS region check (e.g., attributes that restrict the execution state of the processor that is allowed to access the memory region).

[0155] If the instruction that triggers the load / store operation is not a GCS access instruction, then at step 208, the MMU 28 checks whether the memory attribute data corresponding to the target address accessed by the load / store operation specifies that the memory address space region corresponding to the target address is a GCS region. However, in this case, compared to step 204, the response is opposite, if the non-GCS access instruction does not access the GCS region, the load / store request may be accepted, and if it accesses the GCS region, it may be rejected. More specifically, if the memory attribute data of the region corresponding to the target address specifies the GCS region, then at step 205, the MMU checks whether the memory access is a write memory access, and if so, the load / store operation is rejected at step 210 and an error is signaled. By limiting write access to the GCS region to a dedicated category of GCS access instructions, this prevents most regular storage instructions in the program code from tampering with the return state of the protection on the GCS data structure. This reduces the opportunity for an attacker to modify the operands of regular storage instructions when attempting to damage the return state of the protection on the GCS.

[0156] On the other hand, if the non-GCS access instruction does not attempt to access the GCS region (No at step 208) or attempts to access the GCS region but is a read request (No at step 205), then the method continues again to step 212 to apply any other access permission checks, and then control whether the load / store operation is denied or allowed depending on the results of these checks, the same as discussed above for steps 212, 214, and 216.

[0157] Fig.14 A usable simulator is shown as being implemented. Although the embodiments described earlier implement the present invention with devices and methods for operating specific processing hardware supporting the technology of interest, it is also possible to provide an instruction execution environment according to the embodiments described herein, which is implemented by using a computer program. Such computer programs are often referred to as simulators because they provide software-based implementations of hardware architectures. The types of simulator computer programs include emulators, virtual machines, models, and binary translators (including dynamic binary translators). In general, simulator implementations can be run on a host processor 1330 that optionally runs a host operating system 1320 and supports simulator programs 1310. In some configurations, there may be multiple layers of simulation between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, a powerful processor is required to provide a simulator implementation that is executed at a reasonable speed, but such an approach may be justified in some cases, such as when another processor native code needs to be executed because of compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional functionality that is not supported by the host processor hardware, or provide an instruction execution environment that is generally associated with different hardware architectures. A review of simulation is given in "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0158] Where embodiments have been previously described with reference to particular hardware architectures or features, equivalent functionality may be provided in simulated embodiments by suitable software architectures or features. For example, particular circuits may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware (e.g., registers or caches) may be implemented as software data structures in simulated embodiments. Where one or more of the hardware elements mentioned in previously described embodiments are present in a configuration on host hardware (e.g., host processor 1330), some simulated embodiments may utilize host hardware (where appropriate).

[0159] The simulator program 1310 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provide a program interface (instruction execution environment) to the target code 1300 (which may include an application, an operating system, and a hypervisor) that is the same as the interface of the hardware architecture modeled by the simulator program 1310. Therefore, program instructions of the target code 1300 including NOP-compatible instructions as described above may be executed within the instruction execution environment using the simulator program 1310, so that a host computer 1330 that does not actually have the hardware features of the device 2 discussed above may emulate these features. Similarly, Fig.13 The memory management check function can be simulated using the memory management program logic 1318 of the simulator program 1310.

[0160] Thus, the simulator program 1310 may have a handler logic 1312 that simulates the state of the above-described process for the hardware device 2. For example, the handler logic 1312 may control the transition of the execution state (e.g., the exception level) in response to events occurring during the simulated execution of the target code 1300. The instruction decoder logic 1314 simulates the behavior of the instruction decoder 10, and decodes the instructions of the target code 1300, and maps these instructions to corresponding instruction sets in the native instruction set of the host device 1330. The register simulator logic 1316 maps register accesses requested by the target code into accesses to corresponding data structures maintained on the host hardware of the host device 1330, such as by accessing data in a register of the host device 1330 or a 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 above, but also has additional functions to map emulated physical addresses (obtained by address translation based on the page tables defined for the object code 1300) to host virtual addresses used to access host memory 1332. These host virtual addresses may themselves be translated into host physical addresses using standard address translation mechanisms supported by the host (the translation of host virtual addresses into host physical addresses is outside the control of the emulator program 1310).

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

[0162] Although illustrative embodiments of the present invention have been described herein in detail with reference to the accompanying drawings, it should be understood that the invention is not limited to these precise embodiments and that various changes and modifications may be effected therein by one skilled in the art without departing from the scope of the invention as defined in the appended claims.

Claims

1. A device, comprising: an instruction decoder to decode the instruction; processing circuitry to perform data processing in response to decoding of the instruction by the instruction decoder; and at least one control register to specify instruction function selection information; in: In response to a no-operation-compatible instruction, the instruction decoder is configured to control the processing circuit to: treating 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; When the instruction function selection information specified by the at least one control register is in a second state, performing both the first operation and the second operation; and When the instruction function selection information designated by the at least one control register is in a third state, the first operation is performed but the second operation is not performed. 2 . The apparatus according to claim 1 , wherein when the instruction function selection information is in a fourth state, in response to the no-operation compatible instruction, the instruction decoder is configured to control the processing circuit to execute the second operation but not to execute the first operation. 3 . The apparatus of claim 1 , wherein when the instruction function selection information is in the second state, the processing circuit is configured to control a relative order of applying the first operation and the second operation based on the instruction function selection information.

4. An apparatus according to any preceding claim, wherein the first operation and the second operation are function prologue operations associated with a function call; or The first operation and the second operation are function epilogue operations associated with a return from a processing function.

5. An apparatus according to any preceding claim, wherein for at least one variant of the no-operation-compatible instruction, one of the first operation and the second operation comprises an authentication code generation operation to generate an authentication code based on an operand and to associate the authentication code with the operand.

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

7. The apparatus of any one of claims 5 and 6, wherein associating the authentication code with the operand comprises embedding the authentication code in a portion of more significant bits of the operand.

8. The apparatus according to any one of claims 5 to 7, wherein the authentication code generation operation comprises generating the authentication code according to a cryptographic function based at least on the operand and a key.

9. An apparatus according to any preceding claim, wherein for at least one variant of the no-op compatible instruction, one of the first operation and the second operation comprises a protection control stack (GCS) push operation to push the operand to a GCS data structure for protection return status information.

10. An apparatus according to any preceding claim, wherein: For at least one variant of the no-op-compatible instruction: One of the first operation and the second operation includes an authentication code generation operation to generate an authentication code based on an operand and to associate the authentication code with the operand; The other of the first operation and the second operation includes a protection control stack (GCS) push operation to push the operand to a GCS data structure for protection return status information.

11. The device according to claim 10, wherein: In response to the no-op compatible instruction, when the instruction function selection information is in a first sub-state of the second state, the processing circuit is configured to push the operand and the authentication code to the GCS data structure; and In response to the no-op compatible instruction, when the instruction function selection information is in a second sub-state of the second state, the processing circuit is configured to push the operand but not the authentication code to the GCS data structure.

12. An apparatus according to any preceding claim, wherein for at least one variant of the no-op compatible instruction: One of the first operation and the second operation includes an authentication code checking operation to check whether an associated authentication code associated with an operand matches an expected authentication code generated based on the operand, and triggering an error handling response in response to detecting a mismatch between the associated authentication code and the expected authentication code.

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

14. An apparatus according to any preceding claim, wherein for at least one variant of the no-operation compatible instruction, one of the first operation and the second operation comprises a protection control stack (GCS) pop operation to pop function return information from a GCS data structure used to protect the function return information.

15. Apparatus according to any preceding claim, wherein for at least one variant of the no-op compatible instruction: One of the first operation and the second operation includes an authentication code checking operation to check whether an associated authentication code associated with an operand matches an expected authentication code generated based on the operand, and triggering 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 operation and the second operation includes a protection control stack (GCS) pop operation to pop function return information from a GCS data structure used to protect the function return information.

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

17. The device according to any one of claims 9, 10, 11, 14, 15 and 16, wherein: In response to the no-op compatible instruction, when the instruction function selection information is in a state indicating that access to the GCS data structure is to be performed in response to the no-op compatible instruction: The processing circuit is configured to deny memory access triggered by the no-op compatible instruction in response to detecting that a memory region corresponding to a target address of the no-op compatible instruction is a memory region other than a GCS region specified by memory attribute data as being used to store the GCS data structure.

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

19. The apparatus according to any preceding claim, wherein the instruction function selection information comprises: a first operation indicator to indicate whether the first operation is to be performed in response to the no-operation compatible instruction; and a second operation indicator to indicate whether the second operation is to be performed in response to the no-operation compatible instruction.

20. An apparatus as claimed in any preceding claim, wherein the instruction function selection information further indicates whether the processing circuitry should perform a third operation in response to the no-op compatible instruction.

21. A method comprising: Decode instructions; as well as performing data processing in response to decoding of the instruction; wherein: In response to decoding of a no-op compatible instruction, the method comprises: treating 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; When the instruction function selection information specified by the at least one control register is in a second state, performing both the first operation and the second operation; and When the instruction function selection information designated by the at least one control register is in a third state, the first operation is performed but the second operation is not performed.

22. A computer program comprising instructions, which, when executed by a host data processing device, controls the host data processing device to provide an instruction execution environment for executing target code, the computer program comprising: Instruction decoding program logic to decode instructions of the target code; as well as register emulation program logic to maintain data in a storage circuit of the host data processing device to emulate at least one control register for specifying instruction function selection information; in: In response to a no-operation-compatible instruction, the instruction decoding program logic is configured to control the host data processing device to: When the instruction function selection information is in a first state, treating the no-operation compatible instruction as a no-operation instruction; When the instruction function selection information is in a second state, performing both the first operation and the second operation; and When the instruction function selection information is in a third state, the first operation is performed but the second operation is not performed.

23. A storage medium storing the computer program according to claim 22.

Images