Technique for controlling manipulation of pointers

Abstract

An apparatus is disclosed comprising decoder circuitry to decode instructions, wherein the decoder circuitry is responsive to a sequence of instructions to generate control signals, and processing circuitry responsive to the control signals to perform operations defined by the sequence of instructions. The decoding circuitry is responsive to a pointer control prefix instruction in the sequence of instructions to generate one or more control signals to cause the processing circuitry to incorporate a pointer control operation in association with a data processing operation defined by a given data processing instruction subsequent to the pointer control prefix instruction in the sequence, to control whether the data processing operation produces a result operand that is to be considered valid in a situation where a given input operand for the given data processing instruction is a pointer operand identifying a pointer used to determine an address to access memory.

Description

[0001] TECHNIQUE FOR CONTROLLING MANIPULATION OF POINTERS

[0002] BACKGROUND

[0003] The present technique relates to the field of data processing.

[0004] Within a data processing system, instructions to be executed, and data values to be processed during execution of such instructions, are typically stored within a memory system. In order to access the memory system, an address may be generated to identify the location in memory containing the instruction or data value of interest. Pointers can be used by the system to generate such addresses. For example, a pointer may directly identify an address to be accessed, or may be used in combination with some other information, such as a base address or an offset, to identify an address to be accessed. Data processing instructions defining associated data processing operations can be employed in order to manipulate data values, and pointers may be treated in the same way as general purpose data during such data processing operations. Hence, when it is desired to alter the value of a pointer, a data processing instruction may be executed specifying that pointer as an input operand, and the associated data processing operation may be performed in exactly the same way as it would be performed if the input operand was a general purpose data value. By such an approach it is possible to alter the value of a specified pointer, for example by performing an addition operation to adjust the value of the pointer by some determined amount.

[0005] Given that pointers are used to access memory, it is often desirable to provide some restrictions on how pointers are updated. However, as noted above, when executing data processing instructions the apparatus will not typically distinguish between general purpose data and pointers, and will perform the same operation independent of whether the input data specified is general purpose data or data defining a pointer. This can potentially lead to pointers being manipulated in a way that should not be allowed.

[0006] To seek to provide pointer specific variants of the various data processing instructions that could usefully be used in association with pointer values may not be practical, due for example to the limited instruction encoding space available to define all of the various instructions required to be executed by the system. Hence, it would be desirable to provide a mechanism for controlling manipulation of pointers when performing data processing operations, without needing to provide dedicated pointer-specific data processing instructions. SUMMARY

[0007] In accordance with a first example arrangement, there is provided an apparatus comprising: decoder circuitry to decode instructions, wherein the decoder circuitry is responsive to a sequence of instructions to generate control signals; and processing circuitry responsive to the control signals to perform operations defined by the sequence of instructions; wherein: the decoding circuitry is responsive to a pointer control prefix instruction in the sequence of instructions to generate one or more control signals to cause the processing circuitry to incorporate a pointer control operation in association with a data processing operation defined by a given data processing instruction subsequent to the pointer control prefix instruction in the sequence, to control whether the data processing operation produces a result operand that is to be considered valid in a situation where a given input operand for the given data processing instruction is a pointer operand identifying a pointer used to determine an address to access memory.

[0008] In accordance with another example arrangement, there is provided a method of controlling manipulation of pointers by an apparatus, comprising: decoding, using decoding circuitry, a sequence of instructions to generate control signals; performing, using processing circuitry, in response to the control signals, operations defined by the sequence of instructions; and causing the decoding circuitry to be responsive to a pointer control prefix instruction in the sequence of instructions to generate one or more control signals to cause the processing circuitry to incorporate a pointer control operation in association with a data processing operation defined by a given data processing instruction subsequent to the pointer control prefix instruction in the sequence, to control whether the data processing operation produces a result operand that is to be considered valid in a situation where a given input operand for the given data processing instruction is a pointer operand identifying a pointer used to determine an address to access memory.

[0009] In accordance with a still further example arrangement, there is provided a computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for executing target program code, the computer program comprising: instruction decoding program logic to decode instructions, wherein the instruction decoding program logic is responsive to a sequence of instructions to generate control signals; and data processing program logic responsive to the control signals to perform operations defined by the sequence of instructions; wherein: the instruction decoding program logic is responsive to a pointer control prefix instruction in the sequence of instructions to generate one or more control signals to cause the data processing program logic to incorporate a pointer control operation in association with a data processing operation defined by a given data processing instruction subsequent to the pointer control prefix instruction in the sequence, to control whether the data processing operation produces a result operand that is to be considered valid in a situation where a given input operand for the given data processing instruction is a pointer operand identifying a pointer used to determine an address to access memory. Such a computer program can be disposed in any known transitory computer-readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. In a yet further example arrangement, there is provided a computer-readable medium to store computer-readable code for fabrication of an apparatus in accordance with the first example arrangement discussed above. The computer-readable medium may be a transitory computer-readable medium or a non-transitory computer-readable medium.

[0010] BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which:

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

[0013] Figure 2A is a flow diagram illustrating steps taken upon decoding a pointer control prefix instruction, in accordance with one example implementation;

[0014] Figure 2B is a flow diagram illustrating steps taken upon decoding a data processing instruction that is of a type whose execution can be affected by a pointer control prefix instruction, in accordance with one example implementation;

[0015] Figure 3 schematically illustrates one form of pointer control operation that may be performed in one example implementation;

[0016] Figure 4 is a flow diagram illustrating steps taken in one example implementation upon decoding a pointer control prefix instruction;

[0017] Figure 5 is a flow diagram illustrating steps that may be taken in situations where the pointer control prefix instruction applies to multiple associated subsequent instructions, in accordance with one example implementation;

[0018] Figure 6 is a flow diagram illustrating steps taken on exception entry, and return from an exception, in order to maintain state indication information, in accordance with one example implementation;

[0019] Figure 7 is a flow diagram illustrating how setting of an override value can affect the steps taken upon decoding a pointer control prefix instruction, in accordance with one example implementation;

[0020] Figure 8 shows an example of a tag-guarded memory access operation comprising checking whether an address tag matches a guard tag;

[0021] Figure 9 is a flow diagram showing a method of performing a tag-guarded memory access operation;

[0022] Figure 10 illustrates an addition with a carry value;

[0023] Figure 11 illustrates an example of how incorporation of a pointer control operation in association with a data processing operation may influence the result produced by the data processing operation, in accordance with one example implementation;

[0024] Figure 12 is a flow diagram illustrating a tag preserving implementation of a pointer control operation, in accordance with one example implementation; Figure 13 is a flow diagram illustrating a tag preserving implementation of a pointer control operation, in accordance with an alternative example implementation;

[0025] Figure 14 illustrates examples of invalid address pointers that may be generated when employing one example implementation of a pointer control operation;

[0026] Figure 15 is a flow diagram illustrating a method of executing an arithmetic instruction for which a pointer check has been indicated by a preceding pointer control prefix instruction, in accordance with one example implementation;

[0027] Figure 16 is a flow diagram illustrating a method of executing a memory access instruction; and

[0028] Figure 17 illustrates a simulator implementation.

[0029] DESCRIPTION OF EXAMPLES

[0030] In accordance with one example implementation, an apparatus is provided that has decoder circuitry for decoding instructions. In particular, the decoder circuitry is responsive to a sequence of instructions to generate control signals. The apparatus further has processing circuitry that is responsive to those control signals to perform operations defined by the sequence of instructions.

[0031] One or more of those instructions may be data processing instructions that perform associated data processing operations on data values specified as input operands for those data processing instructions. Sometimes execution of such a data processing instruction can be used to alter the value of a pointer specified as an input operand, and typically the processing circuitry will perform the same associated data processing operation required by that data processing instruction irrespective of whether the data processing operation is being used to modify a pointer or to modify a general purpose data value. As noted earlier, this can potentially lead to pointers being manipulated in a way that should not be allowed.

[0032] In order to alleviate this issue, in accordance with the techniques described herein the sequence of instructions may include a pointer control prefix instruction. The decoding circuitry can then be arranged to be responsive to such a pointer control prefix instruction in the sequence of instructions to generate one or more control signals that cause the processing circuitry to incorporate a pointer control operation in association with the data processing operation defined by a given data processing instruction subsequent to the pointer control prefix instruction in the sequence. Hence, the presence of the pointer control prefix instruction can be used to cause the sequence of steps undertaken when subsequently executing the given data processing instruction to be modified, by incorporating a pointer control operation when that given data processing instruction is executed. The pointer control operation can take a variety of forms, but in general terms is arranged to control whether the data processing operation performed when executing the given data processing instruction produces a result operand that is to be considered valid in a situation where a given input operand for the given data processing instruction is a pointer operand identifying a pointer used to determine an address to access memory.

[0033] Hence, by incorporating the pointer control operation, it is possible to control whether the result operand will be considered a valid pointer were that result operand to be subsequently used as a pointer for determining an address in memory. Such a scenario may arise when an input operand for the data processing instruction is a pointer operand, and execution of the data processing instruction is being used to produce a modified pointer to be used subsequently when accessing memory.

[0034] As noted earlier, the processing circuitry may not distinguish, when executing such a data processing instruction, between an input operand that identifies a pointer and an input operand that identifies general purpose data, but when using the pointer control prefix instruction, this can be used to influence the result operand produced by performance of the data processing operation so as to control whether the result operand would be considered valid or not were it subsequently to be used as a pointer.

[0035] Through use of the technique described herein, it is possible to selectively modify the behaviour of one or more data processing instructions to account for situations where those one or more data processing instructions are used to manipulate pointers, without needing to provide a dedicated set of equivalent pointer specific data processing instructions. Further, in some implementations, this can be achieved in a way that allows backwards compatibility with existing systems, since there are no new pointer specific data processing instructions that need to be decoded. For example, it may be the case that the pointer control prefix instruction can use an encoding that is treated as a “no operation” (NoP) instruction in an existing system not supporting the use of such a pointer control prefix instruction, whereby such an existing system would merely treat that pointer control prefix instruction as a “no operation”, and hence take no action in response to encountering such a pointer control prefix instruction.

[0036] A pointer operand can take a variety of forms, but in one example implementation comprises a pointer portion to identify the pointer and a metadata portion to provide metadata associated with the pointer. The metadata represented in the metadata portion may take a variety of forms, for example an address tag to be associated with a target address derived from the pointer, where that address tag can then be used in a tag-guarded memory access operation to perform a comparison of that address tag with a guard tag stored in the memory system in association with a block of one or more memory locations which includes the addressed location identified by the target address. In another example, the metadata may take the form of garbage collection data associated with a region of memory accessible using the pointer in the associated pointer portion of the pointer operand, such garbage collection data being referred to when performing garbage collection procedures to seek to free up memory regions that are no longer being used. The pointer control operation can take a variety of forms, but in one example implementation is used to detect when a portion in the result operand corresponding to at least one of the pointer portion and the metadata portion takes a value which is to be considered invalid when the given input operand is a pointer operand. In such an implementation, the pointer control operation may hence seek to check whether a particular portion in the result operand would be considered valid or not were that result operand to be used as a pointer (as for example may be the case when the given input operand is a pointer operand and the data processing operation is being used to generate a modified pointer operand for subsequent use when accessing memory).

[0037] In one example implementation, when the given input operand is a pointer operand, the result operand generated through performance of the data processing operation defined by the given data processing instruction is considered valid when the value of the portion in the result operand corresponding to the metadata portion matches a value of the metadata portion of the given input operand. In such an example, the pointer control operation may be used to detect when there is a mismatch between the value of the portion in the result operand corresponding to the metadata portion and the value of the metadata portion of the given input operand. Such a mismatch could for example arise where the data processing operation is intended to merely adjust the pointer value in the pointer portion, but an overflow condition arises that causes a propagation of one or more bits into the metadata portion, thereby altering the metadata portion. Such a scenario may arise unintentionally, or intentionally so as to seek to update the value in the metadata portion when that value should not have been modified. Considering the earlier example where the metadata may be providing an address tag, such an intentional attack could be used to seek to compromise the security benefits offered by the tag-guarded memory access mechanism, by potentially allowing a block of software to access a region of memory that it should not be allowed to access. However, by using the technique described herein, whereby a pointer control operation is incorporated in association with the data processing operation, it is possible to detect such situations, and to take an appropriate action.

[0038] In the above example, the pointer control operation is used to detect when the metadata portion has been altered in a manner that should not be allowed. However, in an alternative implementation, the pointer control operation could be used to detect when the pointer portion has been modified in a way which should be considered invalid. For example, when the data processing operation is a combined multiplication and add operation, it may be appropriate when manipulating a pointer operand using such a data processing operation that the result of the multiply operation does not overflow, and the pointer control operation could be used to detect when such an overflow does occur, and then taken appropriate action. There are a variety of actions that could be taken. However, in one example implementation, when performance of the pointer control operation identifies that the result operand is to be considered invalid in a situation where the given input operand is a pointer operand, the processing circuitry may be arranged to set at least a given portion of the result operand to an error-indicating value.

[0039] One might think that an appropriate response to detecting that the result operand has been updated in a way that should be considered invalid would be to raise an exception. However, there can be a significant performance cost associated with raising a processor exception, and this may not be justified in all cases. For example, the result operand may not ever be used as an address pointer, in which case the detection of the result operand being invalid if used as a pointer may not be problematic. The above approach of setting at least a given portion of the result operand to an error-indicating value does not incur such a high performance cost. This approach can then, for example, make it possible to detect, at a later stage, that the error occurred, without incurring the performance cost associated with raising an exception immediately.

[0040] In the above discussed example of the pointer control operation, performance of the pointer control operation involves performing a check to determine when the result operand has been updated in a way that should be considered invalid were that result operand to be used as a pointer, but the pointer control operation can take a variety of other forms. For instance, in one example implementation no specific check may be performed, and instead performance of the pointer control operation may cause a portion of the result operand to be set to a value matching a value of a corresponding portion of the given input operand. Hence, in situations where performance of the data processing operation should not alter the value of a particular portion of the given input operand when generating the result operand in instances where the given input operand represents a pointer, this can effectively be enforced merely by replicating the relevant portion of the given input operand within the result operand, without needing to explicitly check whether the relevant portion of the result operand would otherwise differ from the corresponding portion of the given input operand.

[0041] Such an approach can provide a particularly simple and effective mechanism for providing appropriate control when updating pointer values. It should also be noted that such an approach provides further potential benefits. For instance, in situations where the given input operand already represents an invalid pointer, then the marking of the pointer as invalid can be propagated on to the pointer generated as the result operand, hence ensuring that the invalid state is cumulative.

[0042] As noted earlier, the pointer operand may comprise a pointer portion to identify the pointer and a metadata portion to provide metadata associated with the pointer. In such an implementation, the performance of the pointer control operation of the above form may be arranged to cause the processing circuitry to set the value of the portion of the result operand corresponding to the metadata portion to match the value of the metadata portion of the given input operand. Hence, it can be ensured that the value of the metadata portion is not updated when performing data processing operations on an input pointer operand in order to generate a modified pointer operand.

[0043] The given data processing instruction may take a variety of forms. In one example implementation, the given data processing instruction is an arithmetic instruction, and performance of the data processing operation defined by the arithmetic instruction is arranged, when the given input operand is a pointer operand, to manipulate a value of the pointer identified by the pointer operand in order to produce, as the result operand, a modified pointer operand. The arithmetic instruction could take a variety of forms, but in one example implementation the data processing operation defined by the arithmetic instruction may be an arithmetic operation involving addition, and hence by way of example the arithmetic instruction could be an addition instruction, a multiply / add instruction, etc. However, it should be noted that the pointer control prefix instruction can be used in association with a variety of instructions, and in some instances may be used in association with instructions that are not arithmetic instructions. For example, the pointer control prefix instruction may be used in association with an instruction defining a logical operation such as an OR operation or an AND operation, for example where it is envisaged that such instructions could be used to modify pointer operands.

[0044] There are a number of ways in which the control signals generated by the decoding circuitry upon decoding a pointer control prefix instruction can be used to trigger performance of the pointer control operation when the data processing operation defined by the given data processing instruction is performed. However, in one example implementation the apparatus further comprises state storage to store state indication information, and the decoding circuitry is responsive to the pointer control prefix instruction to generate the one or more control signals to cause the state indication information to be set to a first state identifying that the pointer control operation is to be incorporated in association with the data processing operation defined by the given data processing instruction. Hence, the presence of the state indication information being in the first state can be used to trigger incorporation of the pointer control operation in association with the relevant data processing operation.

[0045] In one example implementation, the processing circuitry may be arranged, responsive to the state indication information having the first state, to incorporate the pointer control operation in association with the data processing operation defined by the given data processing instruction, and to change the state indication information to a second state. In one example implementation, the second state may indicate that no pointer control operation is required, and hence returns the system to the default state where the data processing operations defined by subsequent data processing instructions are performed in the standard manner without incorporating any pointer control operation. However, in an alternative implementation, as will be discussed in more detail later, it is possible for a single instance of the pointer control prefix instruction to be used to associate the pointer control operation with multiple subsequent data processing instructions. In that case, the second state may differ to the first state, but may still identify the need for one or more further applications of the pointer control operation. For example, the first state may identify the number of subsequent data processing instructions for which a pointer control operation needs to be applied, and the second state may indicate a reduced number, to take account of the fact that the application of the pointer control operation has been performed.

[0046] In one example implementation, the given data processing instruction is an instruction of a given type and is expected to be a next instruction executed after the pointer control prefix instruction. In such an example implementation, the processing circuitry may be arranged to respond to the next instruction executed after the pointer control prefix instruction being other than the given data processing instruction, to take one of a number of actions. For instance, it may be arranged to preserve the state indication information in the first state until the given data processing instruction is executed. Alternatively, it may be arranged to clear the state indication information to the second state (for example if it is considered appropriate not to incorporate a pointer control operation with execution of the given data processing instruction if the given data processing instruction is not encountered as the next instruction executed after the pointer control prefix instruction). As another alternative approach, it may be considered appropriate to generate an exception, given that the expected behaviour has not been observed (i.e. the next instruction was not the anticipated given data processing instruction). As a yet further alternative approach, an indication of the unexpected behaviour could be stored in a storage element for subsequent reference, which would provide a less invasive approach than raising an exception, and may be considered sufficient in some implementations. The storage element could take a variety of forms, but in one example implementation could take the form of a status register, so that a value can be set in that status register to indicate when a situation has arisen where a pointer control prefix instruction was not immediately followed by the expected given data processing instruction.

[0047] As mentioned earlier, it is possible for one instance of the pointer control prefix instruction to affect multiple subsequent data processing instructions. In particular, in one example implementation, the decoding circuitry may be responsive to the pointer control prefix instruction in the sequence of instructions to generate one or more control signals to cause the processing circuitry to perform the pointer control operation for associated data processing operations defined by multiple given data processing instructions subsequent to the pointer control prefix instruction in the sequence. In such an implementation, the earlier-mentioned first state may be arranged to indicate a number of given data processing instructions for which the pointer control operation is to be performed by the processing circuitry for the associated data processing operations, and the processing circuitry may be arranged to update the state indication information each time the pointer control operation is performed so as to identify a remaining number of given data processing instructions for which the pointer control operation is to be performed.

[0048] In implementations which use the earlier-mentioned state indication information to keep track of whether a pointer control operation needs to be incorporated when performing one or more subsequent data processing operations, then in one example implementation the processing circuitry may be arranged to cause the state indication information to be preserved when taking an exception and to be restored on a return from the exception. Hence, this can ensure that the state indication information is preserved when taking an exception so that it can be referred to again when a return from the exception takes place. There are various ways in which the state indication information can be preserved. For example, it may be preserved as an entry within a saved processor state register that is populated on an exception entry, and which is then used subsequently to restore processor state on a return from the exception.

[0049] Whilst in some implementations the given data processing instruction that the pointer control prefix instruction is associated with may be predetermined, as indeed may other related information such as the form of pointer control operation to be performed, and the action to be taken dependent on the outcome of that pointer control operation, in an alternative implementation one or more of these aspects may be configurable. For example, in one example implementation the apparatus may further comprise configuration storage to provide at least one of: instruction indicating information to enable the processing circuitry to identify the given data processing instruction for which the pointer control operation is to be performed; control indicating information to enable the processing circuitry to identify a form of the pointer control operation to be performed; action indicating information to identify the action to be taken in the event that performance of the control operation results in a determination that the result operand is to be considered invalid. Such action indicating information could for example identify how the result operand should be modified in order to incorporate the earlier-mentioned error indicating value in the event that the pointer check operation identifies that the result operand should be considered invalid were it to be used as a pointer.

[0050] The configuration storage could take a variety of forms dependent on implementation. For example, the configuration storage may be a system control register, and the above information may be set within the system control register by any suitable means, for example through execution of one or more earlier instructions. Alternatively, the configuration storage could take the form of the earlier-mentioned state storage used to store the state indication information, and the above-mentioned information may be identified by the pointer control prefix instruction and stored in the state storage upon decoding the pointer control prefix instruction. In instances where the pointer control prefix instruction is associated with multiple subsequent data processing instructions, there could be a finer granularity of information stored within the state storage, for example to capture on an instruction-by-instruction basis the form of pointer control operation to be performed, the action to be performed in the event that performance of the pointer control operation results in a determination that the result operand is to be considered invalid, etc.

[0051] Irrespective of the form of configuration storage used, in one example implementation the form of check operation performed may be dependent on the type of data processing instruction with which the pointer control prefix instruction is associated.

[0052] In one example implementation, the given data processing instruction is a predetermined instruction subsequent to the pointer control prefix instruction in the sequence, for example the next instruction in the sequence after the pointer control prefix instruction, the next instruction of a particular type, etc. Accordingly, in such an implementation there is no need for any configuration storage to identify the given data processing instruction with which the pointer control prefix instruction is to be associated.

[0053] In one example implementation, if desired, application of the pointer control operation may be made configurable. For example, the apparatus may comprise configuration storage which when storing a predetermined value causes the decoder circuitry to be responsive to the pointer control prefix instruction to cause no operation to be performed as a result of the pointer control prefix instruction, rather than generating one or more control signals to cause the processing circuitry to incorporate the pointer control operation in association with the data processing operation defined by the given data processing instruction. This provides additional flexibility in the use of the pointer control prefix instruction.

[0054] As mentioned earlier, one example use case for the pointer control prefix instruction is in systems that employ a tag-guarded memory access mechanism. Hence, the apparatus may be arranged such that the processing circuitry is responsive to a memory access instruction identifying a pointer operand to issue a memory access request comprising a request to access data stored at a memory location identified by a memory address determined based on a pointer portion of the pointer operand. The apparatus may further comprise access control circuitry that is responsive to the memory access request to compare a tag value determined based on a tag portion of the pointer operand with an allocation tag associated with the memory location identified by the memory address and, in response to the comparison indicating a given result, to perform a tag error response. In such a system, the performance of the pointer control operation by the processing circuitry may be configured to control a value of a portion of the result operand which would be used as the tag portion if the result operand was used as the pointer operand for the memory access instruction. Hence, in situations where the result operand generated by the data processing operation may be used as a pointer for a subsequent memory access instruction, the earlier described technique can allow the security benefits of a tag-guarded memory access mechanism to be maintained, by ensuring that when the result operand is generated as a result of performing the data processing operation, the value of the tag portion can be controlled to ensure that it is not modified in a manner that should not be allowed.

[0055] In one example implementation, multiple different variants of the above-mentioned pointer control prefix instruction could be defined if desired, each causing different behaviour. For example, different forms of the pointer control prefix instruction could be defined that are for use with different associated data processing instructions, and / or that apply different forms of pointer control operation, and / or that take different actions in dependence on the outcome of the pointer control operation.

[0056] In some example implementations, different behaviours could be defined for scenarios where multiple instances of a pointer control prefix instruction (which may be instances of the same type of pointer control prefix instruction, or instances of different types of pointer control prefix instruction) are encountered before a suitable data processing instruction. In one example implementation, the action of the later pointer control prefix instruction could supersede the action of the earlier pointer control prefix instruction, such that when the suitable data processing instruction is encountered, it is the pointer check operation as defined by the later pointer control prefix instruction that is incorporated. Alternatively, an opposite approach could be taken such that a later pointer control prefix instruction is effectively ignored, so as to retain the defined action of the earlier pointer control prefix instruction. As a further alternative, the actions defined by multiple pointer control prefix instructions could be additive (for example in the case where more than one instruction can be affected by the pointer control prefix instructions). As a yet further example, an exception could be raised in such a scenario, or an error status condition could be generated for storing in a status register for future reference.

[0057] Particular example implementations will now be described with reference to the figures.

[0058] Figure 1 schematically illustrates an example of a data processing apparatus 2. It will be appreciated that this is simply a high level representation of a subset of components of the apparatus and the apparatus may include many other components not illustrated. The apparatus 2 comprises processing circuitry 4 for performing data processing in response to instructions decoded by an instruction decoder 6. The instruction decoder 6 decodes instructions fetched from an instruction cache 8 to generate control signals 10 for controlling the processing circuitry 4 to perform corresponding processing operations represented by the instructions. The processing circuitry 4 may include one or more execution units for performing operations on values stored in registers 14 to generate result values to be written back to the registers. For example the execution units could include an arithmetic / logic unit (ALU) for executing arithmetic operations or logical operations, a floating-point unit for executing operations using floating-point operands and / or a vector processing unit for performing vector operations on operands including multiple independent data elements. The processing circuitry also includes a memory access unit (or load / store unit) 15 for controlling transfer of data between the registers 14 and the memory system. In this example, the memory system includes the instruction cache 8, a level 1 data cache 16, a level 2 cache 17 shared between data and instructions, and main memory 18. It will be appreciated that other cache hierarchies are also possible - this is just one example. A memory management unit (MMU) 20 is provided for providing address translation functionality to support memory accesses triggered by the load / store unit 15. The MMU has a translation lookaside buffer (TLB) 22 for caching a subset of entries from page table stored in the memory system 16, 17, 18. Each page table entry may provide an address translation mapping for a corresponding page of addresses and may also specify access control parameters, such as access permissions specifying whether the page is a read only region or is both readable and writable, or access permissions specifying which privilege levels can access the page.

[0059] The apparatus may also provide a number of process state registers 30 whose contents can be referenced by the processing circuitry 4 when performing data processing operations, for example to track certain state information used by the processing circuitry when performing data processing operations. In one example, the state storage that may be used to store state indication information used to determine whether a pointer control operation should be incorporated in association with one or more data processing operations defined by data processing instructions can be provided by one or more of the process state registers 30.

[0060] As also shown in Figure 1 , the apparatus may provide one or more system control registers 32 for providing system control information used to control the operation of the apparatus, and one or more status registers 34 into which status information generated by the apparatus during operation can be stored for future reference.

[0061] As discussed earlier, in accordance with the techniques described herein, the instruction set architecture can be arranged to include one or more pointer control prefix instructions that, when encountered, can be used to modify the processing performed by the processing circuitry 4 upon encountering one or more subsequent data processing instructions. Figure 2A is a flow diagram illustrating an example of steps taken upon decoding a pointer control prefix instruction, in accordance with one example implementation. When at step 100 a pointer control prefix instruction is decoded, then at step 105 the instruction decoder circuitry 6 is arranged to generate one or more control signals to cause a pointer control operation to be included when executing one or more following associated data processing instructions. The control signals generated can take a variety of forms, but in one example may be used to cause one or more state indication bits to be set within the process state registers 30, with those state indication bits being referenced by the processing circuitry 4 in due course when performing a data processing operation required by a subsequent data processing instruction in a sequence of instructions being executed by the apparatus.

[0062] Figure 2B illustrates the steps that may be taken upon decoding such a data processing instruction, dependent on the value of the state indication bit or bits set in response to decoding a previous pointer control prefix instruction. At step 110 it is determined whether a data processing instruction that has been decoded is of a type that can be affected by a pointer control prefix instruction. If the decoded data processing instruction is not of that type, then the process proceeds to step 115 where the processing circuitry 4 is caused to execute the data processing instruction in the normal manner, i.e. by performing the required data processing operation with no associated pointer control operation being performed.

[0063] If however it is determined at step 110 that the data processing instruction that has been decoded is of a type that can be affected by a pointer control prefix instruction, then at step 120 it is determined whether the relevant state indication bit(s) has been set, i.e. the state indication bit(s) that would be set upon decoding a pointer control prefix instruction. The assessment at step 120 can be performed in a variety of ways, but in one example implementation the processing circuitry 4 may be arranged to access the process state registers 30 in order to determine whether the state indication bit(s) is set, when it is to perform the data processing operation defined by the data processing instruction that has been determined to have been decoded at step 110.

[0064] If the relevant state indication bit(s) is not set, then the process proceeds to step 115 where the processing circuitry is caused to execute the data processing instruction in the normal manner. However, if the relevant state indication bit(s) is set, then the process proceeds to step 125 where the processing circuitry is arranged to incorporate a pointer control operation in association with the data processing operation performed when executing the data processing instruction. As indicated by step 130, the pointer control operation causes a predetermined action to be taken when executing the data processing instruction. That action can take a variety of forms, but in one example implementation may involve replicating certain bits of the input operand in corresponding bits of the output operand. Alternatively, it may involve setting a given portion of the result operand to an error-indicating value if it is determined that the result operand should be considered invalid in a situation where the data processing instruction is being used to manipulate a pointer operand, and hence the result operand may in due course be used as a pointer to determine an address to access in memory.

[0065] Incorporation of the pointer control operation enables general data processing instructions to be used to manipulate pointers, whilst allowing certain steps to be taken to ensure a pointer operand is not updated in a way that is not intended, or should not be permitted. By way of example, pointer operands may include a metadata portion that includes certain metadata information. It is often the case that it is desired to perform a data processing operation on the pointer operand in order to alter the value of the pointer, with the intention being that the contents of the metadata portion are not changed. When using the approach of replicating certain bits of the input operand in corresponding bits of the output operand, the metadata portion can be replicated hence preventing that metadata portion from being altered, as might otherwise occur in certain instances when a data processing operation is performed on a pointer operand, for instance if a value is added to the pointer portion that causes the contents of the pointer portion to overflow and hence may cause a bit to be propagated into the metadata portion thereby altering the value in the metadata portion.

[0066] When using the alternative approach of evaluating the result operand to determine whether it should be considered invalid in situations where that result operand were to represent a pointer operand, and setting a given portion of the result operand to an errorindicating value if it is determined that the result operand should be considered invalid, the presence of the error-indicating value can be used in downstream processes to determine appropriate action to take. Purely by way of example, if the result operand is used as an input operand for a memory access operation, and the error-indicating value is set, then a pointer error condition can be detected at that point and an appropriate action taken, for example raising an exception or recording a value in a status register.

[0067] Figure 3 schematically illustrates performance of the pointer control operation in accordance with one example implementation, where an evaluation of the result operand is performed in order to determine whether to modify a given portion of the result operand to identify an error indicating value or not. The input pointer operand 150 may include a metadata portion 155 and a pointer portion 160. The pointer portion is used to identify the pointer, and the metadata portion 155 may include a variety of information dependent on implementation. In one example implementation, the metadata portion contains an address tag that is used in a tag-guarded memory access mechanism to perform a comparison with a guard tag associated with an accessed block of memory in order to evaluate whether the memory access should be allowed to proceed, as will be discussed in more detail later with reference to Figures 8 and 9. However, other forms of metadata could instead be provided in the metadata portion, for example the metadata may take the form of garbage collection data associated with a region of memory accessible using the pointer in the associated pointer portion of the pointer operand, such garbage collection data being referred to when performing garbage collection procedures to seek to free up memory regions that are no longer being used.

[0068] In the example of Figure 3, a data processing operation 165 is performed using the input pointer operand 150 as an input. There may, dependent on the data processing operation, be one or more further operands also provided as inputs. The data processing operation can take a variety of forms, and could for example be an arithmetic operation or a logical operation. As a result of performing the data processing operation, a result operand 170 is produced that represents a modified pointer. This hence also has a pointer portion 180 defining the modified pointer, and a metadata portion 175 comprising metadata.

[0069] As mentioned earlier, when the processing circuitry is performing data processing operations, it may be arranged to treat pointer operands in the same way as general purpose data value operands. In the example illustrated in Figure 3, the intention when using a data processing operation to modify the input pointer in order to generate a result pointer is to operate on the pointer portion, leaving the metadata portion unchanged. However, in certain situations it is possible for the application of the data processing operation to result in the metadata portion being altered, for example if there is an overflow out of the pointer portion due to the data processing operation performed. By incorporating the earlier mentioned pointer control operation when performing the data processing operation, such a situation can be detected and appropriate action taken. In the example of Figure 3, the pointer control operation causes a comparison operation 185 to be performed in respect of the metadata portion 155 of the input pointer operand 150 and the metadata portion 175 of the result operand 170. If the comparison operation detects a mismatch between these two values, then the processing circuitry can be arranged to take a defined action, for example to update a given portion of the result operand to indicate the earlier mentioned error-indicating value.

[0070] Whilst in the example of Figure 3 the pointer control operation is arranged to look for a mismatch in the metadata portions, the checks performed by the pointer control operation could take a variety of forms, dependent on implementation. For instance, the pointer control operation could be used to detect when the pointer portion has been modified in a way which should be considered invalid. For example, when the data processing operation is a combined multiplication and add operation, it may be appropriate when manipulating a pointer operand using such a data processing operation to check that the result of the multiply operation does not overflow, and the pointer control operation could be used to detect when such an overflow does occur, and then taken appropriate action.

[0071] Figure 4 is a flow diagram illustrating steps taken in one example implementation upon decoding a pointer control prefix instruction. At step 200, when it is determined that a pointer control prefix instruction has been decoded, the process proceeds to step 205 where a state indication bit is set to a first state. In one example implementation, this state indication bit may be provided within one of the process state registers 30.

[0072] At step 210, it is then determined whether the next instruction decoded for execution is the expected data processing instruction, i.e. is a data processing instruction of the form that the pointer control prefix instruction is intended to influence the execution of. For example, there may be a predetermined data processing instruction with which the pointer control prefix instruction is used, or at least a predetermined type of data processing instruction. In other implementations, rather than the data processing instruction being predetermined, the indication of the expected data processing instruction may be configurable by storing that information in a suitable configuration register, for example one of the system control registers 32, or indeed may be captured as information within the process state registers 30.

[0073] If it is determined at step 210 that the next instruction decoded is the expected data processing instruction, then the process proceeds to step 215 where the earlier-discussed pointer control operation is incorporated by the processing circuitry 4 when executing that data processing instruction. In addition, the state indication bit is then cleared in this example implementation, such that the decoding of the pointer control prefix instruction only affects the processing performed in response to one subsequent data processing instruction.

[0074] If at step 210 it is determined that the next instruction that has been decoded for execution is not the expected data processing instruction, then the process proceeds to step 220 where a defined action may be taken. For instance, the state indication information may be preserved in the first state until the given data processing instruction is executed. Alternatively, the state indication information may be cleared to a second state indicating that no pointer control operation is required (for example if it is considered appropriate not to incorporate a pointer control operation with execution of an instance of the expected data processing instruction if that expected data processing instruction is not encountered as the next instruction executed after the pointer control prefix instruction). As another alternative approach, it may be considered appropriate to generate an exception, given that the expected behaviour has not been observed (i.e. the next instruction was not the anticipated data processing instruction). As a yet further alternative approach, an indication of the unexpected behaviour could be stored in a storage element for subsequent reference, which would provide a less invasive approach than raising an exception, and may be considered sufficient in some implementations. In one example implementation the storage element could take the form of one of the status registers 34, such that a value can be set in that status register to indicate when a situation has arisen where a pointer control prefix instruction was not immediately followed by the expected data processing instruction.

[0075] In some example implementations, a single instance of a pointer control prefix instruction may be associated with multiple subsequent data processing instructions, and Figure 5 is a flow diagram illustrating steps that may be taken upon decoding such an instruction in one example implementation. When at step 250 it is determined that a pointer control prefix instruction that applies to multiple associated subsequent instructions has been decoded, then at step 255 state indication information is set to identify the number of instructions that are to have pointer control operations performed when those instructions are executed. This may be captured for example within a multibit field within one of the process state registers 30. If desired, additional information may also be stored for use when controlling the pointer control operations performed when each associated subsequent instruction is executed. Examples of additional information that may be captured are instruction indicating information to enable the processing circuitry to identify the data processing instructions for which the pointer control operation is to be performed, and / or control indicating information to enable the processing circuitry to identify a form of the pointer control operation to be performed. As another example of information that may be captured, such information may comprise action indicating information to identify the action to be taken in the event that performance of the pointer control operation results in a determination that the result operand is to be considered invalid. Such action indicating information could for example identify how the result operand should be modified in order to incorporate the earlier-mentioned errorindicating value in the event that the pointer check operation identifies that the result operand should be considered invalid were it to be used as a pointer.

[0076] This additional information could be captured in a variety of locations. For example, it could be captured within one or more system control registers 32, and the above information may be set within the system control register(s) by any suitable means, for example through execution of one or more earlier instructions. Alternatively, the above-mentioned information may be identified by the pointer control prefix instruction and stored in one or more of the process state registers 30 upon decoding the prefix instruction. In some instances, different information may be provided for different of the associated data processing instructions, hence capturing a finer granularity of control information, for example to capture the form of pointer control operation to be performed for each subsequent instruction, the action to be performed in the event that performance of the pointer control operation results in a determination that the result operand is to be considered invalid, etc.

[0077] In other example implementations, all or part of such additional information may not need to be captured, as it may be predetermined rather than configurable.

[0078] At step 260, as each associated instruction is encountered and executed, a pointer control operation is incorporated with the corresponding data processing operation, and the state indication information is adjusted to identify the remaining number of instructions for which a pointer control operation is required, until the point where all associated instructions have been handled. In implementations where state indication information is saved within the system, for example within one or more of the process state registers 30, for reference by the processing circuitry 4 when performing data processing operations in order to determine whether to incorporate a pointer control operation with those data processing operations, then it can be useful to make sure that that state indication information is preserved across exceptions. Hence, in one example implementation, as shown by the flow diagram of Figure 6, when an exception entry event occurs at step 300, causing a current software routine to be halted whilst an exception handling routine is executed, then the state indication information identifying the need for a pointer control operation is preserved at step 305, for example by storing that information in a saved processor state register. Then, in due course, when it is determined at step 310 that a return from the exception is occurring, then that state indication information can be restored at step 315, by retrieving that information from the saved processor state register.

[0079] In one example implementation, if desired, application of the pointer control operation may be made configurable. For example, as shown by the flow diagram of Figure 7, in one example implementation, when a pointer control prefix instructions is to be decoded at step 350, it is determined at step 355 whether an override value has been set in a predetermined configuration storage element, such as one of the system control registers 32. If not, then the process proceeds to step 360 where the pointer control prefix instruction is decoded in the manner discussed earlier, resulting in the generation of one or more control signals that cause a pointer control operation to be included when subsequently executing one or more associated data processing instructions. However, if the override value is set then at step 365 the pointer control prefix instruction is treated as a “no operation” (NoP) and accordingly no operation is performed in response to the instruction. In due course, the associated data processing instruction(s) will then execute as normal without any pointer control operation being incorporated.

[0080] Whilst in the example of Figure 7 an override value is used to determine when the pointer control prefix instruction should be treated as a no operation, it will be appreciated that in an alternative implementation the default may be for the pointer control prefix instruction to be treated as a no operation, and a value may have to be specifically set within the configuration storage to cause the pointer control prefix instruction to be decoded to generate control signals that cause a pointer control operation to be incorporated when executing one or more subsequent data processing instructions.

[0081] In one example implementation, the pointer control prefix instruction may be encoded in the instruction set architecture using an encoding that is currently treated as a “no operation” (NoP) instruction, to allow backwards compatibility with existing systems that do not support use of the pointer control prefix instruction. Hence, in a legacy system, the pointer control prefix instruction will merely be treated as a no operation, and hence its presence in software will not affect the correct operation of the legacy system. In addition, in systems that have been designed to execute software including the pointer control prefix instruction, the pointer control prefix instruction can be decoded in the manner discussed herein in order to alter the behaviour of one or more subsequent data processing instructions, in particular by incorporating a pointer control operation when performing the required data processing operations.

[0082] As discussed previously, in one example implementation it is desirable to preserve the value of the metadata portion of a pointer operand when that pointer operand is subjected to a data processing operation in order to manipulate the pointer value of the pointer operand so as to produce an updated pointer operand, or at least to identify when performance of the data processing operation has caused the value of the metadata portion to change. There are various scenarios where such an ability may be useful, one specific example being in systems that employ a tag-guarded memory access mechanism to seek to improve security of access to data. The application of the above described techniques within such a system will now be described in more detail.

[0083] Software to be executed by a data processing apparatus may typically be written in a high-level programing language and then compiled into code according to the instruction set architecture supported by the apparatus on which the software is to be executed. For example, the software may originally be written in a higher level language such as Java, C or C++, and then compiled into a natively supported instruction set architecture such as x86 or Arm®.

[0084] Some higher level programming languages, such as Java, are considered memorysafe languages because they include run time error detection checks for checking for certain errors relating to memory accesses. In contrast, memory-unsafe languages, such as C and C++, do not include such run time error checks. The enduring prevalence of use of memory- unsafe languages means that in compiled code according to a given instruction set architecture, there may be a large number of memory related errors which may be vulnerable to exploitation by an attacker or other malicious party. Such errors may include:

[0085] • Bounds violations, in which an array index supplied by the code is outside the legitimate bounds of the array;

[0086] • Use-after-free errors, in which an access to a memory location is made after that memory location has already be deallocated or freed;

[0087] • Use-after-return, in which a memory access to an address associated with a variable used within a function (such as a value on a stack) is made after already returning from the function; • Use-out-of-scope errors, in which variables are accessed outside of the scope in which they are declared; and

[0088] • Use-before-initialisation errors, in which a memory address associated with a variable is accessed before the variable has been initialised.

[0089] These are just some examples of memory-related errors which can result in unpredictable behaviour and potentially provide avenues for attackers to exploit. Hence, it may be desirable to provide architectural support, within the instruction set architecture supported by a given processing apparatus, for assisting with runtime detection of certain classes of memory errors.

[0090] One approach for protecting against certain memory usage errors of the type discussed above may be to provide guard tags which are stored in a memory system in association with blocks of one or more memory locations. When a tag-guarded memory access operation is requested based on a target address identifying a particular addressed location in the memory system, memory access circuitry may compare an address tag that is associated with the target address with a guard tag that is stored in the memory system in association with a block of one or more memory locations which includes the addressed location identified by the target address. The memory access circuitry may generate an indication of whether a match is detected between the guard tag and the address tag. This indication can be used to control whether the memory access is allowed to succeed or whether subsequent operations can succeed, or could merely be reported while allowing memory accesses to continue as normal.

[0091] This can be useful as, for example, a compiler compiling code based on a memory- unsafe language such as C or C++ can, when initialising regions of memory, set the guard tags of blocks of memory which the code is expected to access to particular values, and may associate the corresponding address tag values with the target addresses pointing to those blocks. If a memory usage error occurs, and for example the address pointer is used out of scope or extends out of the bounds of the valid range which was initialised, then it may be likely that the guard tag associated with the addressed location may not match the address tag associated with the target address, and then in this case the indication of whether a match is detected can be used to trigger some error handling response or error reporting mechanism. The particular response taken can depend on the particular needs of the software being executed or on the particular micro-architectural implementation of the architecture. Hence, even if the high level language does not have means for performing run time error checks in order to guard against memory access errors, the ISA used for the compiled code may include architectural features for performing such checks.

[0092] Note that, while the term “guard tag” is used above, the term “allocation tag” may be used instead. Figure 8 schematically illustrates a tag-guarded memory access mechanism in accordance with one example implementation. The physical address space used to refer to memory locations within the memory system may be logically partitioned into a number of blocks 400 each comprising a certain number of addressable locations. For conciseness, in the example of Figure 8, each block 400 comprises four memory locations, but other block sizes could be used as well. Each block 400 is associated with a corresponding guard tag 402. The guard tags associated with a certain number of blocks 400 can be gathered together and stored either within a different architecturally accessible memory location 404 within the physical address space, or within additional storage locations provided in main memory 18 which are not architecturally accessible (not mapped to the same physical address space). The use of separate non-architecturally accessible storage may in some cases be preferred to avoid using up space in the data caches 16, 17 for caching guard tag values, which could impact on the performance of the regular code and could make coherency management more complex. An additional tag cache 19 (as shown in Figure 1) could be provided in the micro architecture for caching tag values from the non-architecturally accessible storage, for faster access than if the tags had to be accessed from main memory 18. The particular mapping of which tag storage locations 404 correspond to each block 400 may be controlled by the load / store unit 15 and could be hardwired or could be programmable. While in Figure 8 each tag 402 is associated with a block of physical addresses, it would also be possible to provide guard tags 402 associated with virtual memory locations in a virtual memory address space, but this may require some additional address translations on each memory access. Hence by associating the guard tag 402 with physical memory locations this can improve performance. In general it is a choice for the particular micro architectural implementation exactly how the guard tags 402 are associated with the corresponding blocks 400 of the physical address space. In general, all that is required is that the guard tag 402 associated with a given block of memory can be accessed and compared.

[0093] Hence, when a tag-guarded memory access is required, an address tag 406 (which is associated with the target address 408 identifying the addressed location 410 to be accessed), is compared against the guard tag 402 which is associated with the block of memory locations 400 which includes the addressed location 410. For example, in Figure 8 the target address 408 points to a certain location B1 in memory, marked 410 in the address space of figure 8. Therefore the guard tag B which is associated with the block of locations B including location B1 is compared against the address tag 406 associated with a target address 408. As shown in the top of Figure 8, the address tag 406 may be determined as a function of selected bits of the target address itself. In particular, the address tag may be determined from bits within a portion of the target address which is unused for indicating the specific memory location which is to be selected as the addressed location 410. For example, in some architectures the top portion of bits of the target address may always have a certain fixed value such as a sign extension (all Os or all 1s) and so an address can be tagged with the address tag 406 by overwriting these unused bits with an arbitrary tag value. The particular address tag value can be selected by a programmer or compiler for example. The address tag and guard tag 402 can be a relatively small number of bits, e.g. 4 bits, and so need not occupy much space within the memory and within the target address. Providing 4 bits of tag space, i.e. 16 possible values of the tags, can often be enough to detect many common types of memory access errors.

[0094] Hence, when a tag-guarded memory access is performed, the load / store unit 15 compares the address tag 406 and the guard tag 402 associated with a block 400 including the addressed location 410, and determines whether they match. The load / store unit 15 generates a match indication indicating whether the address tag 406 and the guard tag 402 matched. For example, this match indication could be a fault signal 60 (as shown in Figure 1) which is generated if there is a mismatch between the address tag 406 and the guard tag 402, or an indication placed in a status register indicating whether there was a match, or an entry added to an error report to indicate the address for which the error was detected and / or the instruction address of the instruction which triggered the error.

[0095] Figure 9 shows a flow diagram for handling a tag guarded memory access. The instruction triggering the memory access may specify an address tag and a target address. As shown in Figure 8, in some cases the address tag may actually be derived from a subset of bits of the target address itself, although in other examples it could be specified in a separate register. At step 500, the instruction triggering the tag guarded memory accesses is encountered. In response, at step 520 the memory access circuitry 15 triggers a memory access to the addressed location 410 identified by the target address. Also, at step 540 the memory access circuitry 15 obtains the guard tag 402 which is stored in the memory system in association with the block of memory locations 400 that includes the addressed location 410 identified by the target address. At step 560 the memory access circuitry 15 compares the address tag 406 with the guard tag 402 obtained at step 540. At step 580 an indication of whether a match is detected between the guard tag and the address tag is generated by the memory access circuitry 15 (e.g. any of the types of match / mismatch reporting indication described above). The precise indication used to report any mismatch may vary from implementation to implementation.

[0096] In a system implementing memory tagging, tagged pointers may be manipulated as integers, which can lead to the tag value being modified. Even if an operation only targets the non-tag part of the pointer, the tag may still inadvertently be affected by overflow from the operation. This unintentional modification of the tag can have a mild beneficial effect in terms of, for example, highlighting errors in operations performed on address pointers, but it also reduces the security benefits of such a system by potentially making it possible for an attacker to manipulate the tag value. In many systems, this reduction in security outweighs the mild benefits that might be provided.

[0097] An example of an operation that might involve manipulating an address pointer is a pointer arithmetic operation, where the pointer is specified as an input operand for an arithmetic (e.g. add, subtract, multiply, divide, etc.) operation. Note that, while the term “pointer arithmetic” is used here, the processing circuitry is typically agnostic as to the meaning of the operands used for a given operation - i.e., a “pointer arithmetic” operation is, to the processing circuitry, just an arithmetic operation, and the address pointer(s) specified as input operands are, to the processing circuitry, just input operands.

[0098] Most arithmetic operations performed by the processing circuitry involve addition (for example, even a subtract, multiple or divide operation can be represented using one or more addition operations). The processing circuitry may comprise an arithmetic logic unit (ALU) for performing arithmetic operations, and the ALU may comprise ADD circuitry to perform addition operations. An example of an addition operation is shown in Figure 10.

[0099] Figure 10 illustrates the addition of two three-bit binary addends 620: 0b100 + 0b111 (note that the prefix “Ob.” is used here to indicate that the following value is a binary value - the value 0b100 is represented as “4” in decimal, and the value 0b111 is “7” in decimal). As shown in Figure 10, even though both of the addends are three-bit values, the addition generates a carry value 640 which has a non-zero value (a “1” in this case) in a more- significant bit position (i.e. the carry value is a 4-bit value 0b1000) - this is because when the bits in the third-least-significant position 660 are added together (0b1 + 0b1) the result is a two-bit value (0b10), and so the “1” carries over to the next-most-significant bit position. This means that the result value 680 is a 4-bit value (0b1011 , which is “11” in decimal). Hence, a carry value generated during an addition operation can overflow into a more-significant bit position.

[0100] Figure 11 illustrates how the generation of a carry value can lead to the modification of a tag in an address pointer. In particular, Figure 11 represents an addition operation to add a value “Y” to an address pointer “X”, to generate an output “Z”. For example, Y could be an offset value being added to a base address represented by address pointer X - however, it will be appreciated that this is just one example of why an arithmetic operation may be performed on an address pointer.

[0101] As shown in Figure 11 , the address pointer X and the other addend Y both have a value of “1” in position 700 corresponding to a most-significant bit of an address portion 720 of pointer X. This means that, when the addends X and Y are added together, a carry value is generated which overflows into a portion 740 of the result value Z that would be the tag portion 406 if Z were used as an address pointer. (Note that this is not the only way such a carry value can be generated - i.e. it is not essential for bit 700 to be “1” in both addends). Accordingly, even if the addend Y comprises no non-zero values in a portion 740 corresponding to the tag portion 406 of address pointer X, a carry value generated during the addition may still lead to the corresponding portion 740 in the output value Z differing from the tag portion 406 in the input address pointer Y. As discussed above, this could lead to a reduction in security.

[0102] Note that, whilst an arithmetic operation is one example of a pointer manipulation operation, other operations may also be applied to address pointers, and may also cause the tag portion to be modified. For example, a logical “OR” operation may be performed in respect of a value that might later be used as an address pointer, and such an operation may also modify the tag. For example, two operands may have tag portions that read:

[0103] 0b1010

[0104] 0b0001

[0105] If logical OR is performed on these two operands, the tag portion of the output value would read:

[0106] 0b1011

[0107] Hence, the tag portion of the output value is, in this case, different to the tag portions of both of the input operands.

[0108] To prevent the security risk that comes with allowing the tag portions of operands to be modified, then in accordance with the techniques described earlier a pointer control prefix instruction can be used to associate a pointer control operation with a subsequent data processing instruction, such that when that data processing instruction is executed, the data processing operation defined by that instruction is supplemented so as to include the pointer control operation. The pointer control operation can take a variety of forms, but can be arranged to seek to ensure that the output operand Z’ does not have the portion 740 updated in an unexpected manner. Considering the example of Figure 11 , this can be achieved by replicating the tag portion 406 of the address pointer X within the corresponding portion 740 of the result operand, for example by overwriting the corresponding bit 740 in the intermediate result operand Z so as to produce the modified result operand Z’, with portion 740 then representing a tag value matching that in the input operand X, but with the address portion 760 representing the modified address pointer produced as a result of the addition operation.

[0109] In an alternative implementation, the pointer control operation may cause a check to be performed when the result operand Z is produced to determine whether the portion 740 has a value that differs from the tag portion 406 in the input operand X. If so, then in one example implementation a given portion of the output operand can be set to an error-indicating value to produce the modified output operand Z’. For example, the processor circuitry may detect the overflow into the region 740 that corresponds to the tag portion, and in response to this detection may generate a modified result value Z’ that includes some error-indicating value. The error-indicating value may be chosen to be a value that causes the value Z’ to be treated as invalid if it is subsequently used as an address pointer.

[0110] Figure 12 is a flow diagram illustrating a tag preserving implementation of the pointer control operation, in accordance with one example implementation. At step 800, an arithmetic instruction is executed for which a pointer control operation has been indicated by a preceding pointer control prefix instruction. At step 805, the arithmetic operation is performed in order to generate a result operand, and a pointer check is then performed in respect of that result operand. As a result of the check, it is then determined at step 810 whether a portion in the result operand corresponding to the tag portion has the same value as in the tag portion of the input pointer operand. If so, the process can proceed directly to step 815, where the result operand is output. However, if there is a mismatch detected at step 810, then at step 820 a modified result operand is generated, which has its portion corresponding to the tag portion set to match the value of the tag portion of the input pointer operand.

[0111] Figure 13 is a flow diagram illustrating a tag preserving implementation of the pointer control operation, in accordance with an alternative example implementation. In accordance with this alternative implementation, there is no need for a check to be performed. Instead, when at step 830 an arithmetic instruction is executed for which a pointer control operation has been indicated by a preceding pointer control prefix instruction, then at step 835 the result operand is generated by performing the required data processing operation. Thereafter, at step 840, the value of the portion of the result operand corresponding to the tag portion is set to match the value of the tag portion in the input pointer operand. This can result in a more efficient implementation in certain situations, as it avoids the need for any check to be performed.

[0112] As mentioned earlier, as an alternative to seeking to preserve the tag value, in an alternative implementation a check of the result operand may be performed as per the approach described in Figure 12, but in the event of a mismatch it may be decided to modify the result operand to include an error-indicating value which will then flag that that result operand is invalid if a future attempt is made to use that result operand as an input pointer for a memory access operation.

[0113] Figure 14 illustrates examples of invalid pointers - the modified result value Z’ discussed earlier in Figure 11 may, for example, be set such that it is invalid in one of the ways illustrates in this figure. Figure 14 illustrates an example where an address pointer comprises 64 bits. In a valid address pointer 850 these bits may be interpreted as follows:

[0114] - the bottom (least-significant) 56 bits (bits 55:0) may be interpreted as address bits - these are the bits which identify a location in memory (either directly, or when combined with some other value such as a base address);

[0115] - bits 59:56 represent a 4-bit address tag; and - the top 4 bits (bits 63:60) may be spare bits and / or bits used to provide some other information.

[0116] The processing circuitry may modify a value in any of a number of different ways, to make it represent an invalid address pointer. For example, some implementations of the present technique could make use of some of the top bits, and set these to some specific value to indicate that the pointer is invalid - for example, Figure 14 shows an example of an invalid pointer 855 where the bits 61 :60 have been set to a value of 0b01. (It will be appreciated that a value of 0b01 for these bits is used as an example - the exact value used as the error indicating value may be implementation-dependent).

[0117] In some example implementations, the tag bits may be set to some specific value to indicate that the pointer is invalid. For example, certain tag values could be reserved for indicating errors, and hence the tag value may be set to one of those values. For example, Figure 14 shows an example of an invalid pointer 860 where the tag portion has been set to a value of 0b1110. (Again, this is just one example of a value that could be used as an error indicating value).

[0118] In some example implementations, if not all of the address bits are needed to define addressable memory, the address portion could be set to some non-canonical value (e.g. an address which is guaranteed to cause a fault if accessed). As a particular example, Figure 14 shows an invalid pointer 865 where the address bits have all been set to zero. Again, this is just one example of a value that could be used as an error indicating value - while it is fairly common to reserve this address value for providing some alternative information (e.g. indicating an error, as in this example), other implementations may use a different address value as an error indicating value.

[0119] Note that the particular values used in Figure 14 as the error generating values are just examples, and the specific values used may depend on the specific architecture used by the system. Moreover, note that some implementations may use some combination of these techniques to force the pointer to an invalid value.

[0120] Figure 15 is a flow diagram illustrating an example of a method which may be performed by the processing circuitry in response to executing at step 870 an arithmetic instruction for which a pointer check has been indicated by a preceding pointer control prefix instruction. The arithmetic instruction identifies an input operand, and the processing circuitry responds to the instruction by performing an operation at step 872, in respect of the input operand, to generate an output value. Whilst in this example the instruction is an arithmetic instruction, and hence an arithmetic operation is performed at step 872, it will be appreciated that the techniques described herein can be used in association with any instruction which has the potential to modify the tag portion of an address pointer. The processing circuitry also detects at step 874 whether the operation performed on the input operand involved an attempt to set the value of at least one bit in an identified portion of the output value to a value other than a value in a corresponding bit position in the input operand, where the identified portion is a portion of the output value which would be used as the tag portion if that output value was used as the address pointer for a memory access instruction. If it is determined that such an attempt was not (N) made, the output operand is returned at step 876 (e.g. it may be recorded in a register) without being modified. On the other hand, if it is determined that such an attempt was (Y) made, the processing circuitry sets at step 878 at least a given portion of the output value to an error-indicating value, before returning at step 880 the modified output value.

[0121] Figure 16 is a flow diagram illustrating an example of a method performed by access control circuitry in response to a memory access instruction being decoded at step 900. The access control circuitry is configured, when a memory access instruction is decoded, to determine at step 905 whether an address pointer identified by the memory access instruction is valid. If the pointer is invalid, a pointer error response is performed at step 910. For example, the error response could comprise raising an exception or recording a value to a status register. In some cases, after performing the error response (e.g. if the response is to record a value to a status register) at step 910, the method continues to step 915. On the other hand, the error response may be performed instead of performing steps 915, 920, 925 and 930 - for example, raising an exception may halt processing.

[0122] The method of Figure 16 also comprises determining at step 915 a memory address based on the address pointer identified by the memory access instruction. Note that, while this example only performs step 915 when the address pointer is determined at step 905 to be valid (Y), it is also possible in alternative implementations to perform step 915 before checking at step 905 whether the address pointer is valid.

[0123] The method also comprises a step 920 of comparing a tag value (address tag) determined based on a tag portion of the address pointer with an allocation tag (guard tag) associated with a memory location identified by the determined memory address, and determining whether the comparison indicates a given result. When (Y) the comparison indicates the given response, a tag error response is performed at step 925 (e.g. this could be the same as or different from the error response indicated above). On the other hand, when (N) it is determined that the comparison does not indicate the given result, the requested data access is performed at step 930 (subject to any other access requirements being satisfied).

[0124] Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer- readable code may additionally or alternatively enable the definition, modelling, simulation, verification and / or testing of an apparatus embodying the concepts described herein.

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

[0126] Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. The one or more netlists or other computer-readable representation of integrated circuit components may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly.

[0127] The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer-readable code defining instructions which are to be executed by the defined apparatus once fabricated.

[0128] Such computer-readable code can be disposed in any known transitory computer- readable medium (such as wired or wireless transmission of code over a network) or non- transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept.

[0129] Figure 17 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators.

[0130] Typically, a simulator implementation may run on a host processor 970, optionally running a host operating system 960, supporting the simulator program 950. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 IISENIX Conference, Pages 53 - 63.

[0131] To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 970), some simulated embodiments may make use of the host hardware, where suitable.

[0132] For example, the simulator code 950 may include instruction decoding program logic 952 to decode instructions in the target code - hence, the instruction decoding program logic may emulate the instruction decoder 6 described earlier. The simulator code 950 may also include register emulating program logic 954 to emulate the registers 14 described above. The simulator program also includes data processing program logic 956 to process instructions in the target code 940 (end hence emulate processing circuitry 4) as well as access control program logic 958 to emulate access control circuitry such as the MMU 20.

[0133] The simulator program 950 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 940 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 950. Thus, the program instructions of the target code 940, including the pointer control prefix instruction, data processing instruction and memory access instruction described above, may be executed from within the instruction execution environment using the simulator program 950, so that a host computer 970 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features.

[0134] Accordingly, the simulator code 950 is an example of a computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for executing target program code, the computer program comprising: instruction decoding program logic to decode instructions, wherein the instruction decoding program logic is responsive to a sequence of instructions to generate control signals; and data processing program logic responsive to the control signals to perform operations defined by the sequence of instructions; wherein: the instruction decoding program logic is responsive to a pointer control prefix instruction in the sequence of instructions to generate one or more control signals to cause the data processing program logic to incorporate a pointer control operation in association with a data processing operation defined by a given data processing instruction subsequent to the pointer control prefix instruction in the sequence, to control whether the data processing operation produces a result operand that is to be considered valid in a situation where a given input operand for the given data processing instruction is a pointer operand identifying a pointer used to determine an address to access memory.

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

[0136] In the present application, lists of features preceded with the phrase “at least one of” mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination. Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims.

Claims

CLAIMS1. An apparatus comprising: decoder circuitry to decode instructions, wherein the decoder circuitry is responsive to a sequence of instructions to generate control signals; and processing circuitry responsive to the control signals to perform operations defined by the sequence of instructions; wherein: the decoding circuitry is responsive to a pointer control prefix instruction in the sequence of instructions to generate one or more control signals to cause the processing circuitry to incorporate a pointer control operation in association with a data processing operation defined by a given data processing instruction subsequent to the pointer control prefix instruction in the sequence, to control whether the data processing operation produces a result operand that is to be considered valid in a situation where a given input operand for the given data processing instruction is a pointer operand identifying a pointer used to determine an address to access memory.

2. An apparatus as claimed in Claim 1 , wherein the pointer operand comprises a pointer portion to identify the pointer and a metadata portion to provide metadata associated with the pointer, and the pointer control operation is used to detect when a portion in the result operand corresponding to at least one of the pointer portion and the metadata portion takes a value which is to be considered invalid when the given input operand is the pointer operand.

3. An apparatus as claimed in Claim 2, wherein when the given input operand is the pointer operand, the result operand generated through performance of the data processing operation defined by the given data processing instruction is considered valid when the value of the portion in the result operand corresponding to the metadata portion matches a value of the metadata portion of the given input operand, and the pointer control operation is used to detect when there is a mismatch between the value of the portion in the result operand corresponding to the metadata portion and the value of the metadata portion of the given input operand.

4. An apparatus as claimed in Claim 2 or Claim 3, wherein when performance of the pointer control operation identifies that the result operand is to be considered invalid in a situation where the given input operand is a pointer operand, the processing circuitry is arranged to set at least a given portion of the result operand to an error-indicating value.

5. An apparatus as claimed in Claim 1 , wherein performance of the pointer control operation causes a portion of the result operand to be set to a value matching a value of a corresponding portion of the given input operand.

6. An apparatus as claimed in Claim 5, wherein the pointer operand comprises a pointer portion to identify the pointer and a metadata portion to provide metadata associated with the pointer, and the performance of the pointer control operation causes the processing circuitry to set the value of the portion of the result operand corresponding to the metadata portion to match the value of the metadata portion of the given input operand.

7. An apparatus as claimed in any preceding claim, wherein: the given data processing instruction is an arithmetic instruction, and performance of the data processing operation defined by the arithmetic instruction is arranged, when the given input operand is the pointer operand, to manipulate a value of the pointer identified by the pointer operand in order to produce, as the result operand, a modified pointer operand.

8. An apparatus as claimed in Claim 7, wherein the data processing operation defined by the arithmetic instruction is an arithmetic operation involving addition.

9. An apparatus as claimed in any preceding claim, further comprising: state storage to store state indication information; and the decoding circuitry is responsive to the pointer control prefix instruction to generate the one or more control signals to cause the state indication information to be set to a first state identifying that the pointer control operation is to be incorporated in association with the data processing operation defined by the given data processing instruction.

10. An apparatus as claimed in Claim 9, wherein the processing circuitry is arranged, responsive to the state indication information having the first state, to incorporate the pointer control operation in association with the data processing operation defined by the given data processing instruction, and to change the state indication information to a second state.

11. An apparatus as claimed in Claim 10, wherein: the given data processing instruction is an instruction of a given type and is expected to be a next instruction executed after the pointer control prefix instruction, and the processing circuitry is arranged to respond to the next instruction executed after the pointer control prefixinstruction being other than the given data processing instruction, to take one of the following actions: preserve the state indication information in the first state until the given data processing instruction is executed; clear the state indication information to the second state; generate an exception; store an indication of unexpected behaviour in a storage element.

12. An apparatus as claimed in any of claims 9 to 11 , wherein: the decoding circuitry is responsive to the pointer control prefix instruction in the sequence of instructions to generate one or more control signals to cause the processing circuitry to perform the pointer control operation for associated data processing operations defined by multiple given data processing instructions subsequent to the pointer control prefix instruction in the sequence; the first state indicates a number of given data processing instructions for which the pointer control operation is to be performed by the processing circuitry for the associated data processing operations, and the processing circuitry is arranged to update the state indication information each time the pointer control operation is performed so as to identify a remaining number of given data processing instructions for which the pointer control operation is to be performed.

13. An apparatus as claimed in any of claims 9 to 12, wherein the processing circuitry is arranged to cause the state indication information to be preserved when taking an exception and to be restored on a return from the exception.

14. An apparatus as claimed in any preceding claim, further comprising configuration storage to provide at least one of: instruction indicating information to enable the processing circuitry to identify the given data processing instruction for which the pointer control operation is to be performed; control indicating information to enable the processing circuitry to identify a form of the pointer control operation to be performed; action indicating information to identify the action to be taken in the event that performance of the control operation results in a determination that the result operand is to be considered invalid.

15. An apparatus as claimed in any preceding claim, wherein the given data processing instruction is a predetermined instruction subsequent to the pointer control prefix instruction in the sequence.

16. An apparatus as claimed in any preceding claim, further comprising configuration storage which when storing a predetermined value causes the decoder circuitry to be responsive to the pointer control prefix instruction to cause no operation to be performed as a result of the pointer control prefix instruction, rather than generating one or more control signals to cause the processing circuitry to incorporate the pointer control operation in association with the data processing operation defined by the given data processing instruction.

17. An apparatus as claimed in any preceding claim, wherein: the processing circuitry is responsive to a memory access instruction identifying a pointer operand to issue a memory access request comprising a request to access data stored at a memory location identified by a memory address determined based on a pointer portion of the pointer operand; and the apparatus further comprises access control circuitry responsive to the memory access request to compare a tag value determined based on a tag portion of the pointer operand with an allocation tag associated with the memory location identified by the memory address and, in response to the comparison indicating a given result, to perform a tag error response; the performance of the pointer control operation by the processing circuitry is configured to control a value of a portion of the result operand which would be used as the tag portion if the result operand was used as the pointer operand for the memory access instruction.

18. A method of controlling manipulation of pointers by an apparatus, comprising: decoding, using decoding circuitry, a sequence of instructions to generate control signals; performing, using processing circuitry, in response to the control signals, operations defined by the sequence of instructions; and causing the decoding circuitry to be responsive to a pointer control prefix instruction in the sequence of instructions to generate one or more control signals to cause the processing circuitry to incorporate a pointer control operation in association with a data processing operation defined by a given data processing instruction subsequent to the pointer control prefix instruction in the sequence, to control whether the data processing operation producesa result operand that is to be considered valid in a situation where a given input operand for the given data processing instruction is a pointer operand identifying a pointer used to determine an address to access memory.

19. A computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for executing target program code, the computer program comprising: instruction decoding program logic to decode instructions, wherein the instruction decoding program logic is responsive to a sequence of instructions to generate control signals; and data processing program logic responsive to the control signals to perform operations defined by the sequence of instructions; wherein: the instruction decoding program logic is responsive to a pointer control prefix instruction in the sequence of instructions to generate one or more control signals to cause the data processing program logic to incorporate a pointer control operation in association with a data processing operation defined by a given data processing instruction subsequent to the pointer control prefix instruction in the sequence, to control whether the data processing operation produces a result operand that is to be considered valid in a situation where a given input operand for the given data processing instruction is a pointer operand identifying a pointer used to determine an address to access memory.

20. A computer-readable medium to store computer-readable code for fabrication of the apparatus of any of claims 1 to 17.

Images