WO2025196399A1

WO2025196399A1 - Tag-locating-address translation operation

Info

Publication number: WO2025196399A1
Application number: PCT/GB2025/050308
Authority: WO
Inventors: Graeme Peter BARNES
Original assignee: ARM Ltd; Advanced Risc Machines Ltd
Current assignee: ARM Ltd
Priority date: 2024-03-20
Filing date: 2025-02-18
Publication date: 2025-09-25
Anticipated expiration: 2026-09-20
Also published as: GB2639630A; TW202538530A; GB202403967D0

Abstract

In response to a tag-checked memory access instruction specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in a memory system, it is determined, based on memory attribute information associated with the target data address, whether the target data address is in an untagged memory region for which a tag check would not be required. Based at least on whether the memory attribute information indicates that the target data address is in the untagged memory region, it is determined whether to architecturally perform a tag-locating-address translation operation for obtaining a tag-locating physical address locating the associated allocation tag within a physical address space, the tag-locating physical address being separate from a data- locating physical address locating the target data item within the physical address space.

Description

TAG-LOCATING-ADDRESS TRANSLATION OPERATION

The present technique relates to the field of data processing.

Some data processing architectures may provide support for tag checking operations based on an allocation tag stored in memory for a given data item and an address tag associated with the address pointer that is used to compute the address of that given data item. Such tag checks can help to detect memory safety errors (e.g. errors where, due to programming error and/or unexpected outcomes of program code, such as buffer overflow, an address pointer is used to cause access to a memory region that the address pointer was never intended to point to, risking corruption of data and increasing vulnerability to attack by a malicious party).

At least some examples of the present technique provide an apparatus comprising: tag checking circuitry to perform a tag check in response to a tag-checked memory access instruction specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in a memory system, the tag check comprising triggering an error handling response in response to detection of a tag mismatch between the associated allocation tag obtained from the memory system for the target data address and an address tag associated with the address operand; and memory management circuitry to control access to the target data address based on memory attribute information associated with the target data address, the memory attribute information indicative of whether the target data address is in an untagged memory region for which the tag check would not be required; in which: the memory management circuitry is configured to determine, based at least on whether the memory attribute information associated with the target data address of the tag-checked memory access instruction indicates that the target data address is in the untagged memory region, whether to architecturally perform a tag-locating-address translation operation for obtaining a taglocating physical address locating the associated allocation tag within a physical address space, the tag-locating physical address being separate from a data-locating physical address locating the target data item within the physical address space.

At least some examples of the present technique provide computer-readable code for fabrication of the apparatus described above. The computer-readable code may be stored on a storage medium. The storage medium may be a non-transitory storage medium.

At least some examples of the present technique provide a method comprising: in response to a tag-checked memory access instruction specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in a memory system, determining, based on memory attribute information associated with the target data address, whether the target data address is in an untagged memory region for which a tag check would not be required, the tag check comprising triggering an error handling response in response to detection of a tag mismatch between the associated allocation tag obtained from the memory system for the target data address and an address tag associated with the address operand; and determining, based at least on whether the memory attribute information associated with the target data address of the tag-checked memory access instruction indicates that the target data address is in the untagged memory region, whether to architecturally perform a tag-locating-address translation operation for obtaining a tag-locating physical address locating the associated allocation tag within a physical address space, the tag-locating physical address being separate from a data-locating physical address locating the target data item within the physical address space.

At least some examples provide a computer program for controlling a host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: tag checking program logic to perform a tag check in response to a tag-checked memory access instruction specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in a simulated memory system, the tag check comprising triggering an error handling response in response to detection of a tag mismatch between the associated allocation tag obtained from the simulated memory system for the target data address and an address tag associated with the address operand; and memory management program logic to control access to the target data address based on memory attribute information associated with the target data address, the memory attribute information indicative of whether the target data address is in an untagged memory region for which the tag check would not be required; in which: the memory management program logic is configured to determine, based at least on whether the memory attribute information associated with the target data address of the tag-checked memory access instruction indicates that the target data address is in the untagged memory region, whether to architecturally perform a tag-locating-address translation operation for obtaining a tag-locating simulated physical address locating the associated allocation tag within a simulated physical address space, the tag-locating physical address being different to a data-locating physical address locating the target data item within the simulated physical address space.

The computer program may be stored on a storage medium. The storage medium may be a non-transitory storage medium.

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:

Figure 1 illustrates an example of a data processing apparatus comprising tag checking circuitry;

Figure 2 illustrates two-stage address translation;

Figure 3 illustrates a translation table entry and use of indirection to specify memory attribute information;

Figure 4 illustrates a tag check;

Figure 5 illustrates an example of setting allocation tag values when allocating or deallocating regions of memory address space; Figures 6 and 7 illustrate examples of memory usage errors detected using the tag check;

Figure 8 illustrates steps performed for a tag checking operation;

Figure 9 illustrates physical tagging;

Figure 10 illustrates virtual tagging;

Figure 1 1 illustrates intermediate-address tagging;

Figure 12 illustrates steps for controlling whether a tag-locating-address translation is architecturally performed in response to a tag-checked memory access instruction;

Figure 13 illustrates steps for performing a tag-locating-address translation;

Figure 14 shows a first example of a tag-locating-address translation operation;

Figure 15 shows steps for performing the tag-locating-address translation operation according to the first example;

Figure 16 shows a second example of a tag-locating-address translation operation;

Figure 17 shows steps for performing the tag-locating-address translation operation according to the second example;

Figure 18 illustrates an example of control registers storing architectural state information for controlling address translation for allocation tag accesses;

Figure 19 illustrates steps for selecting whether to apply a data-address translation operation or add tag-address translation operation for generating a physical address identifying a memory system location storing a given allocation tag;

Figure 20 illustrates two examples of providing a tag table address region in one or more translatable address regions within the address space;

Figure 21 illustrates steps for generating a tag-locating address;

Figure 22 illustrates a tag-locating address determination operation for an address space comprising a single translatable address region;

Figure 23 illustrates a tag-locating address determination operation for an address space comprising two translatable address regions;

Figure 24 illustrates steps for tag-locating address translation in an example supporting first and second address translation modes;

Figures 25 to 28 illustrate different approaches to tag-locating address translation taken depending on whether the first or second address translation mode is used at a first stage and second stage of address translation;

Figure 29 illustrates a data-access-to-tag operation;

Figure 30 illustrates an example of performing a data-access-to-tag check;

Figure 31 illustrates another example of performing the data-access-to-tag check;

Figure 32 illustrates an example of data-address translation including a data-access-to- tag check; and

Figure 33 illustrates a simulation example. An apparatus has tag checking circuitry to perform a tag check in response to a tag- checked memory access instruction specifying an address operand for defining a target data address corresponding to a data item associated with an allocation tag stored in a memory system. The tag check comprises triggering an error handling response in response to detection of a tag mismatch between the allocation tag obtained from the memory system for the target data address and an address tag associated with the address operand. The error handling response could include, for example, rejecting the memory access (e.g. signalling a fault in response to the memory access instruction which fails the tag check), and/or recording information about the detected tag mismatch error (e.g. updating an error log to identify the target data address for which the tag mismatch was detected). It is not essential to prevent the memory access from proceeding when a tag mismatch is detected (e.g. in some cases the purpose of the tag check may be merely to generate a report for flagging possible memory usage errors to software developers, rather than necessarily requiring access to the underlying data in memory to be prevented). Nevertheless, by providing architectural support for assigning allocation tags to data items stored in the memory system and assigning address tags to address operands used to compute addresses of such data items and comparing the allocation tag and address tag when a tag-checked memory access instruction is executed, this can assist software-developers with developing more robust program code which is less likely to cause errors or be compromised by attackers.

Address translation circuitry performs address translation according to address mapping information associated with at least one stage of address translation including a given stage of address translation from a first address space to a second address space. In some examples, the address translation circuitry supports different tag translation modes for the given stage of address translation, for use when processing a tag-accessing instruction that specifies a given data address and requests that an operation is performed using a given allocation tag associated with a given data item corresponding to the given data address. The tag-accessing instruction could be a tag-checked memory access instruction for which operation performed using the given allocation tag is a tag check performed by the tag checking circuitry to compare the given allocation tag with an address tag associated with an address operand used to compute the given data address, and which also requests a read or write memory access to the given data item. Alternatively, the tag-accessing instruction could be a tag read/write instruction used to read or write values of allocation tags associated with a certain block of data items corresponding to the given data address (such a tag read/write instruction may not require the given data item itself to be accessed). Hence, the tag-accessing instruction can be any instruction that requires an operation to be performed using the allocation tag that is associated with the given data item at the given data address. It is not essential for the given data item itself to be accessed in response to the tag-accessing instruction. When performing the given stage of address translation in response to the tag-accessing instruction, the address translation circuitry may determine whether a first tag translation mode or a second tag translation mode is a selected tag translation mode to be used for the given stage of address translation in response to the tag-accessing instruction. In response to determining that the selected tag translation mode is the first tag translation mode, the address translation circuitry obtains a data-locating second address identifying a location of both the given data item and the given allocation tag within the second address space. In response to determining that the selected tag translation mode is the second tag translation mode, the address translation circuitry obtains a tag-locating second address identifying a location of the given allocation tag within the second address space separate from a location of the given data item in the second address space identified by the data-locating second address. In the case where the tag-locating second address is obtained according to the second tag translation mode, it is not essential for the data-locating second address itself to be obtained in response to the tag-accessing instruction, if the tag-accessing instruction does not need access to the given data item.

With this approach, the address translation circuitry supports greater flexibility in determining how to associate allocation tags with their corresponding data items. If the first tag translation mode is selected, then both the given data item and its associated allocation tag are mapped to the same address within the second address space (based on an item of address mapping information used in common for both accesses to the data item and accesses to its associated allocation tag). If the first tag translation mode is used for all stages of address translation, then the same physical address may be used to identify locations of both the given data item and the given allocation tag in the physical address space, and it may be left to the memory system to implement a technique for locating the allocation tag that is associated with a given data item identified by the physical address space. For example, the memory system could provide physical storage for storing an allocation tag alongside each data location - e.g. using spare bits which would otherwise be used for error correcting codes or other information, or alternatively the memory system could carve out part of its physical storage to be used for retaining the allocation tags associated with data items in another portion of its physical storage. The specific mechanism used to manage the association between data items and tags in the memory system may be implementation-dependent, and is separate from the address translation mechanism offered by the address translation circuitry. While this approach may simplify software development (as there is no need for software to control address translation table structures to provide for separate address mapping information for translating the addresses of the data item and associated allocation tag respectively), it may place greater burden on designers of the memory system hardware to provide ways of designating storage for allocation tags and associating the location of those allocation tags with the corresponding items.

On the other hand, if the second translation mode is selected for the given address translation mode, then the given allocation tag may be mapped to an address in the second address space which is separate from the address identifying the location of the corresponding data item. This allows the data item and its associated allocation tag to be mapped to different physical addresses, so that from the memory system’s point of view it does not need to manage any specific tag accessing mechanism (e.g. designation of physical storage permanently reserved for storing allocation tags), since the memory system can simply be sent two memory access requests when both the tag and the data need to be accessed - one for the tag-locating physical address (dependent on the tag-locating second address) and another for the data-locating physical address (dependent on the data-locating second address). Virtualizing the locations of tags by supporting tag-locating address translations for identifying the tag-locating second address separate from the data-locating address translations used to identify the data-locating second address can also be helpful for increasing efficiency of usage of available physical memory storage, as not every allocation tag that is mapped to a tag address in a given data address space would necessarily need to be allocated physical memory in a physical address space, and the virtualized approach enables the option of mapping the tag-locating addresses for the allocation tags associated with different data items to be assigned the same allocation tag value onto the same translated tag-locating address, to reduce the number of physical storage locations in memory needed to provide tag storage for a given number of data items.

Hence, by providing address translation circuitry which supports the ability to select between a first tag translation mode and a second tag translation mode, this can allow configuration of whether the task of identifying the location of the allocation tags associated with particular data items lies with software (in setting the relevant address translation mapping controls) or hardware of the memory system (if software has chosen to map the tag/data to the same physical address), allowing different tradeoff options balancing reduced complexity of maintaining tag address translation mappings (in the first tag translation mode) against more efficient use of available physical memory storage (in the second tag translation mode). Hence, a processor architecture which supports both first and second tag translation modes can better balance the needs of a wide range of workloads.

It is not essential that the given stage of address translation is performed based on the first or second tag translation mode every time the tag-accessing instruction is executed. The address translation circuitry may have at least one translation lookaside buffer (TLB) which can cache information derived from previous instances of performing the given stage of address translation for the given target address. If information identifying the tag-locating second address (or a physical address derived from the tag-locating second address, if the tag-locating second address itself would require further translation into the physical address) is already available in the translation lookaside buffer, then it would not be necessary to perform the given stage of address translation again. Also, as described below, in some examples, at least when the second tag translation mode would be used for the given stage of address translation and the tagaccessing instruction is a tag-checked memory access instruction that also requires access to the given data item, whether or not the tag translation is architecturally performed for obtaining the tag-locating second address could depend on attributes obtained in a data translation operation for obtaining the data-locating second address corresponding to the given data address.

In some examples, the address translation circuitry may support a two-stage translation regime in which address translation is performed based on a first stage of address translation from a virtual address space to an intermediate address space and a second stage of address translation from the intermediate address space to a physical address space. This can be helpful to support virtualisation where multiple guest operating systems (each responsible for setting address mappings for the first stage of address translation) may coexist on the same hardware platform, and so a hypervisor may control address mappings for the second stage of address translation to ensure that conflicting intermediate addresses in the intermediate address space obtained based on mappings set by different guest operating systems can be mapped to different physical addresses in the physical address space.

Where a two-stage translation regime is supported, the support for both the first and second tag translation modes can be provided either for the first stage (but not the second stage), or for the second stage (but not the first stage), or for both the first and second stages of address translation.

Hence, in some examples, the address translation circuitry may support use of the second tag translation mode when the given stage of address translation is the first stage of address translation. In this case, the first address space is the virtual address space and the second address space is the intermediate address space. The data-locating second address and taglocating second address may in this case be subject to further translation in the second stage of address translation, to obtain a corresponding data-locating physical address and tag-locating physical address in the physical address space. Hence, the mode control for selecting between the first and second tag translation modes influences whether the given data item and given allocation tag are mapped to separate addresses in the intermediate address space. Those separate intermediate addresses may depend on separate address mapping information defined in separate first-stage address translation table entries for the data item and its associated allocation tag respectively.

In some examples, the address translation circuitry may support use of the second tag translation mode when the given stage of address translation is the second stage of address translation, with the first address space being the intermediate address space and the second address space being the physical address space. In this case, the data-locating second address is a data-locating physical address and the tag-locating second address is a tag-locating physical address. Hence, the mode control for selecting between the first and second tag translation modes influences whether the given data item and given allocation tag are mapped to separate addresses in the physical address space, which are determined in address translation based on separate address mapping information defined in separate second-stage address translation entries for the data and allocation tag respectively. Those separate second-stage address translation entries may be selected based on information dependent on a data-locating first address which identifies a location of the given data item within the first (intermediate) address space, where the data-locating first address is obtained by translating the given (virtual) data address according to the first stage of address translation.

The address translation circuitry may select the selected tag translation mode based on tag translation control information which is configurable to control which tag translation mode is the selected tag translation mode for the given stage of address translation. Hence, while the hardware of the address translation circuitry supports both modes, a configuration setting may select which mode is to be used for a given instance of performing the given stage address translation for a given tag-accessing instruction.

In some examples, the tag translation control information could be a static configuration input fixed for a given processing system in which the address translation circuitry is implemented. For example, the same design of processor comprising the address translation circuitry may be usable with a wide variety of different memory storage hardware, and some memory storage units may not support tag-specific access mechanisms (so that it may be beneficial to constrain the address translation circuitry to use the second tag translation mode for at least one stage of address translation when the address translation circuitry is used in conjunction with that type of memory storage unit).

However, in some examples, the tag translation control information can include a software-configurable configuration input which can be set by software running on the data processing system. For example, the tag translation control information may comprise information specified in a control register accessible to at least some software (e.g. to software executing with a given level of privilege - less privileged software may not be able to set the information indicated in the control register). This enables greater dynamic control over whether a particular software workload will be executed with its tag accesses controlled according to the first or second tag translation mode.

The tag translation control information may comprise a first-stage tag translation mode indicator indicative of whether, at least for a first class of tag-accessing instruction, the first tag translation mode or the second tag translation mode should be used as the selected tag translation mode for a first stage of address translation for which the first address space is a virtual address space and the second address space is an intermediate address space. Hence, the first- stage tag translation mode indicator may be used to control which tag translation mode is used when the given stage of address translation is the first stage of address translation.

Given the support for the first and second tag translation modes, there can be different ways in which a given input address can be translated in the given stage of address translation: in the first tag translation mode, the address translation circuitry obtains the data-locating second address based on processing an input address according to a data-address translation operation, and in the second tag translation mode, the address translation circuitry obtains the tag-locating second address based on processing an input address according to a tag-address translation operation. The data-address translation operation and tag-address translation operation may process the input address in different ways (e.g. based on different translation table base addresses, or by applying different mappings between the input address and an address used to look up a translation table structure).

Hence, when the first-stage tag translation mode indicator indicates that the second tag translation mode should be the selected tag translation mode for the first stage address translation from a virtual address space to an intermediate address space, one approach can be that all accesses to stored allocation tags use the tag-address translation operation to identify the address in the second (intermediate) address space at which the required allocation tag is stored.

However, it can also be useful to provide a type of instruction which applies the data- address translation operation to an address used to identify one or more allocation tags of interest, even when the tag-accessing instructions would apply the tag-address translation operation in the second tag translation mode. Hence, in some examples, when performing the first stage of address translation for a bulk tag read/write instruction for requesting reading or writing of one or more allocation tags identified using a bulk tag target address specified by the bulk tag read/write instruction, the address translation circuitry may obtain a tag read/write target second address in the second address space based on applying the data-address translation operation to an input address depending on the bulk tag target address, even when the first-stage tag translation mode indicator indicates that the second tag translation mode should be used as the selected tag translation mode for the first stage of address translation in response to the tag -accessing instruction. Hence, the bulk tag read/write instruction specifies an address identifying the location of one or more allocation tags directly, rather than indirectly by specifying the address of the corresponding data item, and for the purposes of address translation behaves similar to a nontag-checked data access instruction which does not require any allocation tag to be accessed at all. Such a bulk tag read/write instruction which accesses allocation tags as if they were data items can be useful, for example, for hypervisors to allow the hypervisor to control the values of allocation tags used by a guest operating system.

The bulk tag read/write instruction may be prohibited from being executed in at least one privilege level in which the tag-accessing instruction would be allowed to be executed. This can reduce the likelihood of tampering with allocation tags by less privileged code, and reflects that a common use case for the bulk tag read/write instruction may be by hypervisors having privilege sufficient to allow execution of the bulk tag read/write instruction.

For some examples which support use of the second tag translation mode for the second stage of address translation (where the first address space is the intermediate address space and the second address space is the physical address space), the tag translation control information may also comprise a second-stage tag translation mode indicator indicative of whether, when the first-stage tag translation mode indicator indicates that the selected tag translation mode is the first tag translation mode for the first stage of address translation, the tag translation mode or the second tag translation mode should be used as the selected tag translation mode for the second stage of address translation. This allows a hypervisor to select that virtualized memory tagging (where different address translation mappings are applied to data and an associated allocation tag) is to be applied for the second-stage translation for a given guest operating system even if that guest operating system has not been designed to support virtualized tagging at the first stage of address translation. This can again help support more efficient utilization of physical memory storage, by avoiding the memory system having to carve out a permanent region of physical memory for storing tags.

When the first-stage tag translation mode indicator has a value indicating that the first tag translation mode is to be used for the first stage of address translation, the second-stage tag translation mode indicator influences which tag translation mode is used for the second stage of address translation. However, when the first-stage tag translation mode indicator indicates that the second tag translation mode is to be used for the first stage of address translation, it may be undesirable to also apply the second tag translation mode for the second stage of address translation, as this could risk unpredictable outcomes where both the data/tag-locating second addresses emerging from the first stage of address translation are separately treated as data addresses each to be mapped to separate data/tag addresses at the second stage of address translation. Hence, to reduce software overhead in managing such unpredictable address translation mappings, it can be helpful for the address translation circuitry to be configured so that, in response to determining that the first-stage tag translation mode indicator indicates that the selected tag translation mode is the second tag translation mode for the first stage of address translation, the address translation circuitry determines that the first tag translation mode should be used as the selected tag translation mode for the second stage of address translation (irrespective of the value set for the second-stage tag translation mode indicator).

There can be a number of different ways in which the tag-locating second address can be generated when the selected tag translation mode is the second tag translation mode.

In some examples, when performing the given stage of address translation in response to the tag-accessing instruction when the selected tag translation mode is the second tag translation mode for the given stage of address translation, the address translation circuitry may obtain, based on a data-locating first address identifying a location of the given data item in the first address space, a tag-locating first address identifying a location of the given allocation tag in the first address space, and then obtain the tag-locating second address by translating the taglocating first address according to address mapping information selected based on the taglocating first address from a given-stage translation table structure identified based on a given translation table base address. Hence, the tag-address translation operation mentioned earlier may comprise transforming the data-locating first address to generate a different tag-locating first address representing the location of the given allocation tag in the first address space, and then using the obtained tag-locating first address to select an entry of the given-stage translation table structure which provides an address mapping to the tag-locating second address. This approach can simplify software overheads in maintaining translation table structures because a single translation table structure maintained by software can be shared for both data-address translation operations and tag-address translation operations.

With this approach, when performing the given stage of address translation in response to the tag-accessing instruction when the selected tag translation mode is the first tag translation mode for the given stage of address translation, the address translation circuitry may obtain the data-locating second address by translating the data-locating first address according to address mapping information selected based on the data-locating first address from the given-stage translation table structure identified based on said given translation table base address. Hence, the same translation table base address can be used regardless of whether a tag-address translation operation is performed in the second tag translation mode or a data-address translation operation is performed in the first tag translation mode (or where a data-address translation operation is performed for the bulk tag read/write instruction mentioned earlier).

In the second tag translation mode, the address translation circuitry may obtain the taglocating first address based on: a tag table base address indicative a position of a tag table region designated within the first address space for storing allocation tags, and a tag table offset derived from the data-locating first address. Although other more complex transformations of the data- locating first address could be applied to generate the tag-locating first address, using part of the data-locating first address as an offset to be applied relative to a tag table base address can be simpler to implement in hardware.

In other examples, rather than transforming a data-locating first address to obtain a taglocating first address (so that data and tag address translations provide different first address inputs into the table lookups for the given stage of address translation), another approach could be to use the same data-locating first address as the input address used for translation table lookups for the given stage of address translation, but use that data-locating first address to use lookup different translation table structures defined by different base addresses, so that separate translation table entries for data and tag accesses may be identified from the respective translation table structures to map the same data-locating first address in the first address space to a data-locating second address and separate tag-locating second address in the second address space.

Hence, when performing the given stage of address translation in response to the tagaccessing instruction, the address translation circuitry may be configured so that, in response to determining that the selected tag translation mode is the first tag translation mode, the address translation circuitry obtains the data-locating second address by translating a data-locating first address identifying a location of the given data item in the first address space, based on address mapping information selected based on the data-locating first address from a data translation table structure identified based on a data translation table base address. In response to determining that the selected tag translation mode is the second tag translation mode, the address translation circuitry obtains the tag-locating second address by translating the data-locating first address based on address mapping information selected based on the data-locating first address from a tag translation table structure identified based on a tag translation table base address separate from the data translation table base address.

While the above examples describe implementations where the address translation circuitry selects whether to apply the first or second tag translation mode for obtaining the address in the second address space identifying the location of an allocation tag associated with a given data item, other examples could support the second tag translation mode (a virtualized tag translation mode) for obtaining addresses of allocation tags, but might not support the first tag translation mode. In this case, physical tagging (where the locations in memory of both the data item and its associated allocation tag are identified based on the same physical address) may not be supported.

Regardless of whether a physical tagging approach (e.g. using the first tag translation mode) is supported, in implementations supporting a virtualized tag translation mode (e.g. the second tag translation mode described above), processing of tag-checked memory access instructions may involve performing a tag-locating address translation operation to obtain the taglocating address, that may not otherwise be required for non-tag-checked memory access instructions. This may introduce a performance cost because performing the tag-locating- address translation operation risks more frequent address translation faults, which are harmful for processing performance, occurring if an entry providing the address translation mapping for the required tag address has not been configured by software or indicates failed access permissions (with the virtualized tag translation mode, the tag translation may use a different address translation entry from the entry used to obtain the corresponding data-locating address, and so even if the entry for obtaining the data-locating address has been correctly configured, this does not guarantee that the tag translation would not generate a translation fault). Hence, while introducing such a tag-locating-address translation operation in a virtualized tag translation mode can have benefits in reducing reliance on the memory system to manage the location of tags associated with corresponding data items (e.g. avoiding the need to carve out a portion of physical memory for tags), the virtualized tag translation mode could risk harming performance compared to an implementation that does not perform tag-locating address translation operations separate from the corresponding data-locating address translation operations.

In examples discussed below, memory management circuitry may control access to the target data address of a tag-checked memory access instruction based on memory attribute information associated with the target data address. The memory attribute information may indicate whether the target data address is in an untagged memory region for which the tag check would not be required. The memory management circuitry may determine, based at least on whether the memory attribute information associated with the target data address of the tag- checked memory access instruction indicates that the target data address is in the untagged memory region, whether to architecturally perform a tag-locating-address translation operation for obtaining a tag-locating physical address locating the associated allocation tag within a physical address space (the tag-locating physical address being separate from a data-locating physical address locating the target data item within the physical address space).

With this approach, software can signal (by setting the memory attribute information for a given set of addresses) whether tag checks are needed for accesses to those addresses, and for address regions where no tag check is needed, the tag-locating-address translation operation can be suppressed from being architecturally performed, to reduce the frequency with which address translation faults cause interruption of processing. This can help improve processing performance.

The memory management circuitry may suppress the tag-locating-address translation operation from being architecturally performed in response to detecting that the target data address is in the untagged memory region.

Some examples could also consider other factors when determining whether to suppress the tag-locating-address translation operation from being architecturally performed.

For example, the memory management circuitry may in some examples comprise the address translation circuitry mentioned above, so may also support the first and second address translation modes as mentioned earlier. In this case, the determination of whether to enable or disable architectural performance of the tag-locating-address translation operation may be relevant for the second address translation mode but not the first address translation mode.

Hence, in some examples, the memory management circuitry may suppress the taglocating-address translation operation from being architecturally performed in response to detecting that at least one tag translation mode indicator indicates that a virtualized tag translation mode is disabled, the virtualized tag translation mode comprising a mode in which the target data item is mapped to the data-locating physical address based on data-translating address mapping information corresponding to the target data address and the associated allocation tag is mapped to the tag-locating physical address based on tag-translating address mapping information corresponding to the target data address, the tag-translating address mapping information being separate from the data-translating address mapping information. For example, the virtualized tag translation mode could be the second address translation mode mentioned earlier (and could be applied either at the first stage or the second stage of address translation). The tag -translating address mapping information can be separate from the data-translating address mapping information for a number of reasons, depending on implementation (e.g. because the tagtranslation address mapping information and data-translating address mapping information are selected from translation table structures accessed using different translation table base addresses, or because the tag-translation address mapping information and data-translating address mapping information are selected from a same translation table structure based on different input addresses corresponding to the associated tag and data item respectively). Hence, even if the memory attribute information does not indicate the target data address is in an untagged memory region, the tag-locating-address translation operation can still be prevented from being architecturally performed, if virtualized tagging is currently disabled.

When the virtualized tag translation mode is disabled, the memory management circuitry may map both the target data item and the associated allocation tag to the data-locating physical address. This corresponds to the first address translation mode described above.

The memory attribute information may also support an encoding where the target data address is indicated as being in a tagged memory region. In this case, whether or not the taglocating-address translation is architecturally performed may depend on whether at least one further condition is satisfied (e.g. on instruction type information, and/or on the control indicator that controls whether the virtualized tag translation mode is enabled).

For example, the further condition being satisfied may be dependent on at least one tag translation mode indicator indicating that the virtualized tag translation mode is enabled. When the virtualized tag translation mode is indicated as disabled, the tag-locating-address translation may not be architecturally performed even if the memory attribute information indicates the target data address is in a tagged memory region.

When the tag-locating-address translation operation is to be architecturally suppressed, the memory management circuitry may prevent any fault being signalled based on the taglocating-address translation operation. Faults are costly for performance as they may cause interruption of the workload being executed to allow for execution of an exception handler. Hence, by preventing signalling of address translation faults for tag-locating address translation operations when an untagged memory region is accessed, this reduces likelihood of performance loss.

In some cases, when the tag-locating-address translation operation is to be architecturally suppressed, the memory management circuitry may suppress the tag-locating-address translation operation from actually being performed. Hence, the tag-locating-address translation operation may not be carried out at all. As well as reducing risk of spurious address translation faults, this also eliminates the bandwidth cost of performing the translation, which may free up address translation bandwidth for other translation operations.

However, in some implementations, even when the tag-locating-address translation operation is to be architecturally suppressed, the memory management circuitry could still allow the tag-locating-address translation operation to actually be performed, but prevent changes of architectural state caused by the tag-locating-address translation operation, so that the architectural result is the same as if the tag-locating-address translation operation was not performed. For example, the memory management circuitry can prevent signalling of a fault, updating of architecturally visible performance counters, and/or triggering of a read/write operation in memory based on the result of a tag-locating-address translation operation that is performed but which should architecturally be suppressed. Performing the tag-locating-address translation even if architecturally suppressed could be useful in some implementations as this may allow the tag-locating-address translation operation to start earlier (while awaiting the memory attribute information associated with the target data address) than if the tag-locating- address translation was deferred until the outcome of checking the memory attribute information was actually known. Also, in some cases, if performing the tag-locating-address translation causes translation table pointers to be cached in a translation lookaside buffer as a result of the tag-locating-address translation, this might help speed up later translations which require the same pointers (e.g. a given translation table pointer from a higher level of translation table in a multi-level translation table structure might be shared between some tagged memory regions and some untagged memory regions).

In some examples, a dedicated memory attribute type may be defined corresponding to the untagged memory region (or a number of variants of “untagged” memory attributes may be defined).

However, in other examples, the memory management circuitry may deduce whether the target data address is in the untagged memory region based on one or more memory attribute indicators of the memory attribute information for indicating one or more memory region attributes unrelated to performance of the tag check. Spare encoding space available in translation table entries for encoding attribute types may be extremely constrained, and so it may sometimes not be feasible to add new dedicated attribute types to an existing address translation architecture. Hence, in some cases, whether the region is tagged/untagged could be inferred from other attribute types already provided.

For example, a tagged memory region may be restricted to being a region indicated by memory attribute information as being a normal write-back cacheable memory region. A “normal” memory region may be a non-device memory region for which repeating or reordering accesses to the memory region is permitted (unlike “device” memory regions for which repeating or reordering accesses to the memory region is not permitted as this could cause side-effects). For example, device memory may typically be used for buffer structures used to control devices such as input/output (I/O) devices or hardware accelerators, so unlike reads/writes to memory storage used for random access memory data, performing the same read or write multiple times or reordering the sequence in which reads/writes are performed relative to the order in which the read/write requests are issued may cause inappropriate functioning of such devices. Memory tagging may typically be used for random access memory data, not device control structures, so an address in device memory may by default be considered to be untagged. Similarly, noncacheable memory regions (regions storing addresses which do not need to be allocated to the cache) are unlikely to store the general purpose random access memory data accessed by software prone to memory usage errors, so non-cacheable memory regions may also be assumed to be untagged. Therefore, in some examples, the memory management circuitry may determine that the target data address is in the untagged memory region in response to detecting that the target data address is in a region other than a normal write-back-cacheable memory region.

It will be appreciated that this is just one example and other examples may have a different way of encoding whether a memory region is tagged or untagged using memory attribute information associated with a target data address of a tag-checked memory access instruction.

The memory management circuitry may determine whether to architecturally perform the tag-locating-address translation operation based on the memory attribute information derived from at least one translation table entry accessed in a data-locating-address translation operation for translating the target data address to the data-locating physical address. The data-locating- address translation operation may be performed for the tag-checked memory access instruction for the purpose of identifying the physical address of the target data item, regardless of whether the tag-locating-address translation operation is architecturally performed or suppressed. Hence, by using the memory attribute information available from the data-locating-address translation operation to enable/disable whether the tag-locating-address translation operation is to be architecturally performed, this provides a simple-to-implement technique for preventing unnecessary faults that may arise from performing the tag-locating-address translation operation unnecessarily. One might think that enabling/disabling the tag-locating-address translation operation based on attribute information from the data-locating-address translation operation would be undesirable as performing the tag-locating-address translation operation sequential to the data-locating-address translation operation could risk unacceptably long latencies for the tag- checked memory access instruction, especially if both data and tag translations require a translation table walk. However, in practice, as the tag-locating-address translation operation is architecturally suppressed from being performed, but not necessarily actually prevented from being performed, it is possible to speculatively start performing the tag-locating-address translation operation before the memory attribute information is available, and prevent any faults or other architectural consequences being observed resulting from the speculatively performed tag-locating-address translation operation if it is found that the tag-locating address translation operation should have been suppressed. If it is later found that the tag -locating-address translation operation was to be architecturally disabled (suppressed), any remaining part of the tag-locating-address translation operation need not be completed.

In some examples, for a given stage of address translation, the memory management circuitry is capable of performing the tag-locating-address translation operation based on address mapping information from a tag-translating translation table entry different to a data-translating translation table entry providing address mapping information used for the given stage of address translation in a data-locating-address translation operation for translating the target data address to the data-locating physical address. As noted above, there can be different ways of causing the tag/data-locating address translation operations to use mappings from different translation table entries (e.g. accessing these entries using different translation table base addresses corresponding to separate tag/data translation table structures, or providing different tag/data input addresses to a common translation table structure shared between tags and data). The given stage of address translation could be either a first stage of address translation for translating from a virtual address space to an intermediate address space, or a second stage of address translation for translating from an intermediate address space to a physical address space.

In some examples, an apparatus comprises the tag checking circuitry mentioned above, tag-locating address determining circuitry to determine, based on a data-locating address identifying a location of a given data item within a first address space, a tag-locating address identifying a location of the allocation tag corresponding to the given data item within the first address space; and address translation circuitry to perform at least one stage of address translation from the first address space to a physical address space. The tag-locating address determining circuitry may determine the tag-locating address based on an offset relative to a tag table base address indicative of a position of a tag table address region designated within the first address space for storing allocation tags, the offset depending on an offset portion of the data- locating address.

Hence, within a first address space (which is to be translated into a physical address space using one or two stages of address translation), a data-locating address identifying a location of a given data item in the first address space is transformed to generate a corresponding taglocating address identifying a location of the associated allocation tag in the first address space. This transformation is between two addresses within the same address space (rather than a mapping from an address in a first address space to an address in a second address space).

Compared to alternatives (such as looking up the data-locating address in a tag-address translation table structure separate from the data-address translation table structure), this approach can simplify development of software for use with a system supporting virtualized tagging, as it means the same translation table structure can be shared for both data and tag translations. The tag-locating address determining circuitry can modify the data-locating address to identify the tag-locating address which can then be input for address translation using the same translation structure that is also used for data.

Also, generating the tag-locating address based on an offset relative to a tag table base address, with the offset depending on an offset portion of the data-locating address, can reduce the hardware cost of implementing the tag-locating address determining circuitry and reduce software development costs for the software which sets control information for controlling the taglocating address generation, compared to alternatives such as defining a data-to-tag address mapping table for providing more arbitrary mappings from the data-locating address of the first address space to the corresponding tag-locating address of the first address space. In some examples, the tag-locating address determining circuitry is configured to determine, based on one or more bits of the data-locating address less significant than the offset portion but contiguous with the offset portion, tag selection information indicative of which of a plurality of allocation tags stored at a same address of the tag table address region is the allocation tag corresponding to the data-locating address. This can be useful for implementations where each allocation tag comprises fewer bits than the number of bits of stored information that correspond to a single address in memory. For example, for byte-addressable memory where each unique address value corresponds to a respective byte (8 bits) of data in memory, the allocation tag may comprise fewer than 8 bits (e.g. 4 bits). In this case, it can be useful to pack multiple allocation tags into the memory location corresponding to a single address, so that allocation tags can be stored more compactly in the memory address space. Hence, if the minimum size of data returned by a memory read corresponds to the contents of a single addressable location (e.g. one byte), then an allocation tag read from memory may actually return multiple tags. To enable selection between the allocation tags returned from memory (and identify which tag actually relates to the data item of interest), the tag-locating address determining circuitry may determine tag selection information from the data-locating address, based on one or more bits less significant (but contiguous with) the portion used to derive the offset. For example, in an example where allocation tags are 4 bits wide and each address refers to 1 byte (8 bits) of memory, the next least significant bit after the portion used to derive the offset can be used to select between the two allocation tags present at a given byte of memory address space.

Other examples may use a different tag size. If the tag size is equal to the size of one addressable memory location then there is no need for the tag selection information to be derived by the tag-locating address determining circuitry, as a read to a given address in memory may return a single allocation tag.

In some examples, the tag table base address comprises an aligned address. An aligned address may be an address naturally aligned to an alignment boundary in memory. For example, the tag table base address could be explicitly or implicitly defined to be an address for which a number of least significant bits are all 0. By using an aligned tag table base address, this can reduce complexity of the tag-locating address determining circuitry. For example, this means an adder is not necessary to combine the base address with the offset, as the offset bits can simply by inserted into the positions that would correspond to 0 in the aligned base address. As adders are relatively slow compared to circuitry for multiplexing bits from different sources into the appropriate bit positions, eliminating the cost of an adder on each cycle of looking up address translation for a tag address can be helpful in improving performance and can make it easier for circuit designers to design circuitry that meets timing requirements. Also, use of an aligned base address means less stored information is needed to define the base address, as the lower bits of 0 do not need to be explicitly stored. For example, those 0 bits can be omitted from information stored in a register to define the base address. Alternatively if the register does define lower bits of the address, the lower bits of a register defining the base address could be ignored so that even if they are set to non-zero values, the base address is still an aligned address with a number of lower bits set to 0.

In some examples, the tag table base address could be fixed by design (e.g. constrained in an instruction set architecture to be at a particular location within the first address space).

However, to increase flexibility for software developers, it can be useful for the tag table base address to be variable based on tag table base address information. The tag table base address information may be configurable by software (e.g. in some cases, restricted to be modified by software with at least a given level of privilege). For example, the tag table base address information may be specified in a control register. In some examples, multiple pieces of tag table base address information may be specified, corresponding to different translation regimes, with the tag table base address to be used for generating the tag-locating address being selected by the tag-locating address determining circuitry based on an indication of which translation regime is a current translation regime.

The first address space may comprise at least one translatable address region, each translatable address region having a corresponding tag table address region designated within the first address space. A translatable address region may be a region of address space in which valid data address translations are allowed. Hence, in response to a data memory access request to access a data item at an address outside the translatable address region, the address translation circuitry may trigger a fault. Restricting valid address translations to one or more translatable address regions can be helpful as this leaves encoding space available in address values for encoding other information (e.g. the address tags for tag checks). Also, restricting the size of the translatable address region within the address space reduces overheads for software developers as they do not need to maintain translation table structures covering as large a region of address space.

In some examples, the tag table address region for a given translatable address region may be located within the given translatable address region. This can be simpler to implement for hardware/software designers as the introduction of the tag table address region may not require any change in which addresses of the first address space are translatable or non- translatable.

However, it is also possible for the tag table address region for a given translatable address region to be located outside the given translatable address region. For example, the tag table address region could be located in a neighbouring region to the translatable address region at which data corresponding to tags in the tag table address region are stored. If the tag table address region is located outside the corresponding translatable address region, then tag memory accesses to access an allocation tag in the tag table address region may be excluded from the requirement to access addresses only in the translatable region (unlike data accesses to access a data item), so a tag access to an address in the tag table address region may not trigger a fault. A data access to that tag table address region may trigger a fault. A tag access to an address in a part of the non-translatable address region other than the tag table address region may trigger a fault.

In some examples, for a given translatable address region having a region size which is variable based on region size information, a size of the corresponding tag table address region is variable to scale with a size of the given translatable address region. For example, translatable region size information may be set by software to define the size of the given translatable address region. As the granularity with which allocation tags are defined for data items in a given region of memory may be fixed (depending on the ratio of the allocation tag width to the size of the block of data sharing one allocation tag), it can be useful for the tag table storage region size to scale with the size of the corresponding translatable address region, so that the translatable region size information also implicitly defines the size of the given tag table address region (and hence the size of the offset portion used to form the tag-locating address and the bit positions at which that offset is applied to the tag table base address). Hence, this approach can avoid the need for separate configuration information (e.g. control register state) to be defined defining the size of the tag table size separate from the translatable address region size.

For example, a ratio between the size of the given translatable address region and the size of the corresponding tag table address region may be 2ⁿ, where 2ⁿ is a number of bytes of data that corresponds to the one or more allocation tags stored in one byte of the corresponding tag table address region.

In some examples, the first address space may support a single translatable address region.

However, other examples may (at least for some translation regimes or some operating states of processing circuitry) support the first address space comprising a plurality of translatable address regions having separate tag table base addresses identifying locations of respective tag table address regions for the plurality of translatable regions. Providing multiple translatable address regions can be useful for distinguishing address space used for different purposes (e.g. one translatable region for use by user/application-level software and another translatable region for use by kernel/operating system-level software). Hence, when determining the tag-locating address when multiple translatable address regions are in use, the tag-locating address determining circuitry may apply the offset relative to the tag table base address that corresponds to the translatable address region comprising the data-locating address. The tag table base addresses for the plurality of translatable address regions may be variable based on separate items of tag table base address information for the plurality of translatable address regions (e.g. the tag table base address information for each translatable address region may be stored in one or more control registers).

Similarly, the translatable address regions may have respective region sizes which are variable based on separate items of region size information for the plurality of translatable regions. Again, the size of a given tag table address region may scale with the size of the corresponding translatable region, so a tag table address region for one translatable address region may have a different size to a tag table address region for another translatable address region.

Some examples may support both single-translatable-region and multiple-translatable- region translation regimes, with control state stored in a control register defining the configuration of translatable address regions currently in use.

In some examples, the offset portion of the data-locating address excludes a least significant n bits of the data-locating address, where 2ⁿ is a number of bytes of data that corresponds to the one or more allocation tags stored in one byte of the corresponding tag table address region. Hence, the offset portion may correspond to the portion of the data-locating address that would select a unique allocation tag from the tag table address region (the bits of the address that would merely distinguish different addresses sharing the same allocation tag being ignored when determining the offset portion).

In some examples, for a data-locating address within a given translatable address region of size 2’ bytes, the tag-locating address determining circuitry may determine the tag-locating address as an address within the given translatable address region, where bits [t-1 :0] of the taglocating address comprise: bits [t-n-1 :0] of the tag-locating address specifying the offset portion obtained from bits [t-1 :n] of the data-locating address; and bits [t-1 :t-n] of the tag-locating address set based on tag table base address information indicative of the tag table base address corresponding to the given translatable address region; where 2ⁿ is a number of bytes of data that corresponds to the one or more allocation tags stored in one byte of the corresponding tag table address region. This approach can be relatively simple to implement in hardware circuit logic, and can provide sufficient flexibility for software to vary the location of the tag table address region within the first address space depending on which portions of the first address space are needed for other purposes.

The tag-locating address determining circuitry can be helpful for supporting a virtualized tag access mode in which, for an address translation performed by the address translation circuitry in response to a tag accessing instruction specifying a data address on which the data- locating address depends, when a virtualized tag access mode is enabled for a given stage of address translation for translating addresses from the first address space (e.g. virtual address space or intermediate address space) to a second address space (e.g. intermediate address space or physical address space): the address translation circuitry obtains a tag-locating physical address in the physical address space based on translation of the tag-locating address determined by the tag-locating address determining circuitry based on the data-locating address. Such a virtualized tag access mode can be helpful for reducing the requirement for the memory system to allocate physical memory for tags or provide a tag-specific access mechanism. In some examples, the virtualized tag access mode may be the only supported mode of accessing tags (e.g. corresponding to the second tag translation mode mentioned earlier). Other examples may also support a physical tag access mode (e.g. the first tag translation mode mentioned earlier).

In some examples, the address translation circuitry is configured to support the virtualized tag access mode for both: a first stage of address translation for which the first address space is a virtual address space and the second address space is an intermediate address space; and a second stage of address translation for which the first address space is the intermediate address space and the second address space is the physical address space. Other examples may support the virtualized tag access mode only for one of the first and second stages of address translation.

In examples which support the virtualized tag access mode for both the first and second stages of address translation, the tag-locating address determining circuitry may comprise shared hardware circuitry configured to be used for both: determining the tag-locating address in the virtual address space based on the data-locating address in the virtual address space, when the virtualized tag access mode is enabled for the first stage of address translation; and determining the tag-locating address in the intermediate address space based on the data-locating address in the intermediate address space, when the virtualized tag access mode is enabled for the second stage of address translation. Other than reading in different information defining the tag table base address, the mapping function for mapping a data-locating address to a tag-locating address may be the same regardless of whether that mapping function is applied to transform between corresponding data/tag virtual addresses in the virtual address space or to transform between corresponding data/tag intermediate addresses in the intermediate address space. Hence, it is possible to share the same hardware for both stages of address translation, to reduce the overall circuit area cost.

As described above, virtualized tagging (e.g. virtual or intermediate tagging as referred to herein), may be supported in some implementations. As a result, allocation tags may be stored in an address space (virtual or intermediate address space) along with data items and so the allocation tags may be accessible with a data memory access request. For example, an allocation tag stored at a given addressed location in an address space may be accessed with a data access operation specifying that given addressed location.

Accesses to allocation tags with data memory access requests may be inadvertent or intentional (and in some cases legitimate, as discussed further below). For example, an addressed location in memory storing an allocation tag may inadvertently be accessed by a data memory access operation as a result of programming error. On the other hand, an attacker may attempt to read the value of an allocation tag or write a value of an allocation tag as part of attempting to exploit the access provided to the allocation tags with a data memory access request. As described herein, allocation tags may be used as part of a tag check, and so their value may influence the outcome of the tag check, i.e. whether or not an error handling response is performed. Thus, it may be undesirable to allow inadvertent or intentional access to allocation tags with data memory access operations. For example, an attacker may attempt to exploit a tag check’s use of allocation tags to intentionally trigger or not trigger an error handling response based on the value of the allocation tag (e.g. as part of a denial of service attack if the modification of the allocation tag causes rejection of memory accesses so that there is disruption to the functioning of the victim software). Even if memory accesses of victim code are not disrupted by an attacker triggering a data access to the tag storage region , reading of tag values by an attacker may give side-channel information on usage of memory by a victim process. Thus, an attacker may attempt to read a current value of an allocation tag, or attempt to modify a value of an allocation tag, in order to influence the outcome of the tag check. Also, even if there is no malicious attempt in an inadvertent data access to the allocation tag, but this access merely results from a programming error, inadvertent updates to the allocation tag values caused by the error affecting one data access operation may cause spurious reporting of tag mismatch errors on another data access operation which itself was not subject to any programming error, which might cause software developers to unnecessarily spend development time in reviewing the wrong parts of the code allegedly causing the error when in fact the problem lies elsewhere.

It can therefore be advantageous to provide architectural support for identifying cases where a data access request specifies a target address corresponding to a memory address where an allocation tag is stored.

Thus, in some examples, an apparatus comprises the tag checking circuitry mentioned above, and data-access-to-tag checking circuity to perform a data-access-to-tag check. The data- access-to-tag check comprises: determining, based on memory address region defining information defining an allocation tag memory address region designated for storing allocation tags, whether a data memory access request specifies a target address corresponding to a memory address in the allocation tag memory address region; and denying read or write access to a data value stored at the memory address in the allocation tag memory address region in response to determining that the data memory access request specifies a target address corresponding to a memory address in the allocation tag memory address region.

Hence, read or write access to a data value may be denied based on the target address of a data memory access request corresponding to an address in a region of memory designated for storing allocation tags. This provides a mechanism within the architecture for controlling access to memory regions storing allocation tags, which may prevent inadvertent or unauthorized access to allocation tags.

As discussed above, the present approach may prevent exploits from a potentially malicious attacker by preventing a requester from being able to access allocation tags using a data memory access request directly specifying the address of an allocation tag. Compared to alternatives (such as not denying read or write permission based on a data memory access request specifying an address in a region of memory designated for storing allocation tags), this approach can provide increased security against an attacker looking to exploit an implementation’s response to a tag check.

Further, unnecessary or inadvertent access to allocation tags may be prevented. For example, a requester of the data memory access request may not have awareness of where allocation tags are stored in memory (virtual or physical) or the requester may inadvertently specify a target address corresponding to a memory address in an allocation tag memory address region designated for storing allocation tags. For example, as discussed herein, when operating in a virtualized tagging mode (such as either virtual tagging or intermediate tagging), it is possible that a memory access instruction could specify, as its target address intended for defining the location of a given data item, a virtual or intermediate physical address which actually corresponds to a virtual address or intermediate physical address in a region of memory designated as storing allocation tags. Accordingly, such unnecessary or inadvertent accesses to allocation tags may be prevented.

In some examples, denying read or write access may comprise one or more of triggering a fault, reading the data value as zero, and ignoring the write request to the data value. For example, if read access is to be denied, in some examples, the data value may be read as zero (in some cases the read operation may not be triggered and a zero value may be returned). In some cases, if write access is to be denied, the write access may be ignored. In some cases, for either denying read or write access, a fault may be triggered. For example, a fault indication may be generated.

In some examples, the allocation tag memory address region designated for storing allocation tags is designated in an address space other than a physical address space. For example, in some cases, the allocation tag memory address region designated for storing allocation tags is designated in a virtual or intermediate physical address space. Hence, the present access control approach may be applied in a non-physical (e.g. virtualized) memory tagging implementation, such as those discussed herein. Further, as discussed herein, in some examples, a virtualized tagging implementation (virtual or intermediate tagging) may be used and so the present access control approach may support virtualized tagging.

In some examples, the memory address region defining information comprises memory address region defining configuration information defining a variable location of the allocation tag memory address region in an address space. That is to say, in some examples, the location of the allocation tag memory address region in a given address space may not be fixed in the given address space. Accordingly, the allocation tag memory address region may be defined depending on a specific implementation, allowing a software-developer flexibility in how the region may be defined and used to store allocation tags. The allocation tag memory address region defining configuration information may comprise at least one of: information indicating a tag table base address; and information indicating a table size. Thus, rather than defining each individual address in the allocation tag memory address region, the configuration information may include information for determining a range of addresses which are included in the allocation tag memory address region. In some examples (e.g. the two-translatable region example discussed further below with respect to Figure 20), an address space may comprise more than one allocation tag memory address region and so the read/write access may be denied in the data-access-to-tag check if the target address of the data memory access request corresponds to any of the allocation tag memory address regions defined by the allocation tag memory address region defining configuration information.

In some examples, for the data-access-to-tag check, the data-access-to-tag checking circuitry is configured to: deny read or write access to a data value stored at the memory address in the allocation tag memory address region in response to: determining that the data memory access request specifies the target address corresponding to a memory address in the allocation tag memory address region; and determining that data-access-to-tag check enable information indicates that the data-access-to-tag check is enabled for the data memory access request.

Hence, whether read or write access is denied may be determined based also on data- access-to-tag check enable information indicating that the data-access-to-tag check is enabled for the data memory access request (as well as whether the data memory access request specifies a target address in the allocation tag memory address region). Read or write access may therefore be denied based on whether the data-access-to-tag check is currently enabled. This selective enabling of the data-access-to-tag check supports implementations where the data- access-to-tag check may be performed in some cases but not in other cases, for example for certain data memory access requests but not for other data memory access requests, or at certain times and not at other times. For example, there may be legitimate reasons for allowing a data access memory operation to have read or write access to an allocation tag, such as when executing a garbage collection operation. In this case, the data-access-to-tag check may be disabled based on the data-access-to-tag check enable information indicating that the data- access-to-tag check is disabled for the data memory access request. Thus, it may be advantageous to provide architectural support for providing configurable access to allocation tags with a data memory access request.

In some examples, the data-access-to-tag check enable information identifies whether the data-access-to-tag-check is enabled for data memory access requests that are read requests and, independent of whether the data-access-to-tag check is enabled for data memory access requests that are read requests, whether the data-access-to-tag check is enabled for data memory access requests that are write requests. Thus, separate control may be provided for read and write requests. Thus, in some cases, read access may be denied while write access may be permitted, and in other cases read access may be permitted and write access may be denied. Hence, read-only and write-only controls may be supported. The read-only control may provide protection against tampering from an attacker (i.e. modifying the value of the allocation tag), while still allowing software to inspect the value of the allocation tags. The write-only control may allow software to write to the allocation tags but may prevent the inspection of the allocation tag values.

In some examples, the data-access-to-tag checking circuitry is configured to: determine, for write data memory access requests, that the data-access-to-tag check is enabled independent of the data-access-to-tag check enable information. Thus, in some examples, the data-access- to-tag check may be performed for write data memory accesses irrespective of whether the data- access-to-tag check enable information indicates that the data-access-to-tag check is enabled. In some cases, it may be advantageous for the data-access-to-tag check to be performed for any data memory access request that is a write data memory access. For example, a write data memory access request may be executed by potential attacker looking to influence the outcome of a tag check as discussed herein.

In some examples, the data-access-to-tag check enable information identifies whether the data-access-to-tag check is enabled for privileged data memory access requests. Thus, in some examples, the data-access-to-tag check may be enabled or disabled for privileged data memory access requests. It may be more likely that garbage collection operations or other authorized data accesses to allocation tags may be performed by privileged code and so it may be advantageous to be able to disable the data-access-to-tag check for such privileged code.

In some examples, the data-access-to-tag checking circuitry is configured to: determine, for unprivileged data memory access requests, that the data-access-to-tag check is enabled independent of the data-access-to-tag check enable information. Thus, in some examples, the data-access-to-tag check may be performed for unprivileged data memory accesses irrespective of whether the data-access-to-tag check enable information indicates that the data-access-to-tag check is enabled. In some cases, it may be advantageous for the data-access-to-tag check to be performed for any data memory access request that is an unprivileged data memory access. For example, an unprivileged data memory access request may be executed by unprivileged code, which may not be trusted to access allocation tags.

In some examples, the data-access-to-tag check enable information identifies, independent of whether the data-access-to-tag check is enabled for privileged data memory access requests, whether the data-access-to-tag check is enabled for unprivileged data memory access requests.

Accordingly, separate read/write access control may be supported for privileged and unprivileged data memory access requests. In some implementations, the data-access-to-tag check may be enabled for unprivileged data memory access requests but disabled for privileged data memory access requests (i.e. code is executing at a privilege level greater than a predetermined privileged level). Thus, in this implementation, unprivileged data memory access requests attempting to read or write data stored in the allocation tag memory address region may be denied, whereas privileged data memory access requests may be permitted to read or write data stored in the allocation tag memory address region. Accordingly, read or write access to allocation tags stored in the allocation tag memory address region may be permitted or denied based on a privilege level of the code requesting the data memory access to the allocation tag.

In some examples, the data-access-to-tag check enable information is prohibited from being updated by instructions executed with insufficient privilege. Thus, in some examples, code executed with sufficient privilege may be able to update the data-access-to-tag check enable information to enable or disable the data-access-to-tag check, whereas code executed with insufficient privilege may not. A potential attacker may attempt to use code to update the data- access-to-tag check information and so preventing unprivileged code from being able to do so may increase security against potential attackers. Further, it may be advantageous for a hypervisor or security management process to be able to selectively enable the data-access-to- tag check.

In some examples, the data-access-to-tag check enable information comprises a field in a control register. As a result, a control register may be checked to efficiently determine whether the data-access-to-tag check is enabled for a given data memory access request. Further, in some examples, the data-access-to-tag check enable information may comprise a first field in a control register for enabling the data-access-to-tag check for read operations and a separate second field (either in the same control register or a different control register to the control register storing the first field) for enabling the data-access-to-tag check for write operations. Accordingly, separate control of the data-access-to-tag check may be provided for read and write operations.

In some examples, the data-access-to-tag check enable information may comprise a first field in a control register for enabling the data-access-to-tag check for privileged data memory access operations and a separate second field (either in the same control register or a different control register to the control register storing the first field) for enabling the data-access-to-tag check for unprivileged data memory access operations. Accordingly, separate control of the data- access-to-tag check may be provided for privileged and unprivileged data memory access operations.

In some examples, the data-access-to-tag check enable information comprises range information defining at least one range of address space for which the data-access-to-tag check is enabled. In some examples, the data-access-to-tag check enable information may be checked to determine whether the target address of the data memory access request is included in the range of address space defined by the range information. As a result, a plurality of addresses may be efficiently indicated as having the data-access-to-tag check enabled for data memory access requests to target addresses within that plurality of addresses.

In some examples, the data-access-to-tag check enable information may comprise separate range information for read and write operations. Thus, in some examples, the data- access-to-tag check information comprises range information for defining at least one range of address space for which the data-access-to-tag check is enabled for read operations, and range information for defining at least one range of address space for which the data-access-to-tag check is enabled for write operations. In some examples, the data-access-to-tag check enable information may comprise separate range information for privileged and unprivileged data memory access requests. Thus, in some example, the data-access-to-tag check enable information comprises range information for defining at least one range of address space for which the data-access-to-tag check is enabled for privileged data memory access requests, and range information for defining at least one range of address space for which the data-access-to- tag check is enabled for unprivileged data memory access requests. In some examples, the data- access-to-tag check enable information comprises one or more of the range information for read data access operations, the range information for write data access operations, the range information for privileged data memory access requests, and the range information for unprivileged data memory access requests.

In some examples, the data-access-to-tag check enable information is specified in a translation table entry corresponding to the target address of the data memory access request. This may provide an efficient indication of whether the data-access-to-tag check is enabled. In some examples, as access to the translation table entry is already required in order to perform translation of the target address, using the translation table entry information corresponding to the target address of the data memory access request may provide a particularly efficient mechanism for determining whether the data-access-to-tag check is enabled.

In some examples, for the data-access-to-tag check, the data-access-to-tag checking circuitry is configured to: deny read or write access to a data value stored at the memory address in the allocation tag memory address region in response to: determining that the data memory access request specifies the target address corresponding to a memory address in the allocation tag memory address region; and the memory access request being triggered by an instruction other than at least one class of data accessing instruction permitted to access allocation tags in the allocation tag memory address region.

Thus, in some examples, read or write access may be denied also based on the class of instruction that triggered the data memory access request not being a class of data accessing instruction permitted to access allocation tags in the allocation tag memory address region. In some examples, a class of data accessing instructions may be designated as being permitted to access allocation tags, whereas instructions of classes other than the permitted class may be denied access to allocation tags. Accordingly, the type of data memory access may be used to selectively deny or permit read or write access to allocation tags.

In some examples, for the data-access-to-tag check, the data-access-to-tag checking circuitry is configured to: deny read or write access to a data value stored at the memory address in the allocation tag memory address region in response to: determining that the data memory access request specifies the target address corresponding to a memory address in the allocation tag memory address region; and determining that the data memory access request is an unprivileged memory access request. Hence, read or write access may be denied based also on the data memory access request being an unprivileged memory access. As discussed above, it may be advantageous to prevent unprivileged memory accesses from accessing allocation tags as attackers may use unprivileged memory accesses in an attempt to read or modify allocation tags to influence the outcome of a tag check.

In some examples, tag-locating address determining circuitry is provided to, when operating in a virtualized tagging mode, determine, based on a data-locating address identifying a location of a given data item within a first address space other than a physical address space, a tag-locating address identifying a location of the allocation tag corresponding to the given data item within the first address space; in which the data-access-to-tag checking circuitry is configured to deny read or write access to a data value stored at the memory address in the allocation tag memory address region in response to: determining that the data memory access request specifies the target address corresponding to a memory address in the allocation tag memory address region; and determining that the tag-locating address determining circuitry is operating in the virtualized tagging mode.

Hence, the present approach may support a data-access-to-tag check in a virtualized tagging mode in which addresses are designated for storing tags in a first address space that is to be translated to a physical address space via one or more stages of address translation, and may deny read or write access based also on determining that the tag-locating address determining circuitry is operating in the virtualized tagging mode. Accordingly, the present approach may support virtualized tagging (i.e. virtual tagging or intermediate tagging, discussed herein).

The techniques discussed above may be implemented within a data processing apparatus which has hardware circuitry provided for implementing the tag checking circuitry, address translation (memory management) circuitry, tag-locating address determining circuitry and/or data-access-to-tag checking circuitry discussed above. However, the same technique can also be implemented within a computer program which executes on a host data processing apparatus to provide an instruction execution environment for execution of target code. Such a computer program may control the host data processing apparatus to simulate the architectural environment which would be provided on a hardware apparatus which actually supports target code according to a certain instruction set architecture, even if the host data processing apparatus itself does not support that architecture. The computer program may have tag checking program logic, address translation (memory management) program logic, tag-locating address determining program logic, and/or data-access-to-tag checking program logic which emulate functions of the corresponding circuitry discussed above, including support for virtualized tagging modes, architectural suppression of tag-address translation operations, tag-locating address determination and/or data-access-to-tag checks discussed above. For an embodiment where the functioning of a corresponding hardware implementation is simulated in software, references made to the “physical address space” in descriptions of the corresponding hardware embodiments can be understood as referring in the simulation to a simulated physical address space, since when the functioning of a target instruction execution environment is simulated, the physical address space of that environment does not actually refer to locations in hardware memory storage of the host, but can be further mapped onto a virtual address space used by the host data processing apparatus.

Such a simulation program can be useful, for example, when legacy code written for one instruction set architecture is being executed on a host processor which supports a different instruction set architecture. Also, the simulation can allow software development for a newer version of the instruction set architecture to start before processing hardware supporting that new architecture version is ready, as the execution of the software on the simulated execution environment can enable testing of the software in parallel with ongoing development of the hardware devices supporting the new architecture. The simulation program may be stored on a storage medium, which may be an non-transitory storage medium.

Specific examples are set out below with reference to the drawings.

Figure 1 illustrates an example of a data processing apparatus 2, which for example can be a processor, e.g. central processing unit (CPU). The apparatus 2 includes instruction fetch/decode circuitry 4 for fetching program instructions from an instruction cache or memory for execution by execution circuitry 16, and for decoding the instructions to generate control signals for controlling the execution circuitry 16 to perform the operations represented by the instructions. The execution circuitry includes a number of execution units 20, 22, 28 for executing various classes of instruction, with reference to register state stored in registers 14. For example, the execution circuitry 16 may include an arithmetic/logic unit (ALU) 20 for executing arithmetic operations and logical operations (e.g. Boolean operations), a branch unit 22 for executing branch instructions which trigger an non-sequential jump in program flow, and a load/store unit 28 for executing load/store operations to load data from a memory system to the registers 14 or store data from the registers 14 to the memory system. The memory system may comprise one or more levels of cache, and random access memory storage.

A memory management unit (MMU) 6, which is an example of address translation circuitry, is provided to support the load/store unit 28 in performing memory access operations (load/store operations) and support the instruction fetch circuitry 4 in fetching instructions from the memory system. While Figure 1 shows a single MMU 6 used for both instruction fetches and load/store operations triggered by executed instructions, it will be appreciated that in some examples two distinct MMU units may be provided, one for handling memory management functions for instruction fetches and the other for handling memory measurement functions for the load/store operations executed by load/store unit 28. The MMU 6 controls access to the memory system, based on address mapping information and memory attribute information specified using translation table structures stored in the memory system. The address mapping information is used to translate between virtual addresses in a virtual address space (used to identify the executable instructions to be fetched and/or target data to be accessed by load/store operations) and physical addresses in a physical address space (used by the underlying memory system to identify the storage locations of the required instructions and/or data). The memory attribute information can specify permissions or memory region attributes which are used to control whether a given memory access request is allowed to access the information at the corresponding memory address and/or to control how the memory access operation to that address is processed within the CPU 2 or in the memory system itself. The translation table structures are set by software executing on the apparatus 2. The software may write the translation table entries of the translation table structures to the memory system, and set a base address stored in a base register of the MMU 6 to indicate the location at which the translation table structure can be accessed. Updates to the base address register may be restricted to software executing with a given level of privilege or higher (e.g. application-level software may not be allowed to update the base address register, but operating- system-level or hypervisor-level software may be allowed to update the base address register).

The MMU 6 includes one or more translation lookaside buffers (TLBs) 8 for caching information derived from the translation table structures stored in the memory system, so that future memory accesses which can reuse translation table information already obtained from the memory system for a previous access can be processed faster than if the same information has to be obtained from memory again. If, for a given memory access, the required information is not available in the TLBs 8, table walk circuitry 12 can perform a translation table walk operation to issue one or more memory access requests to the memory system for locating the required translation table information. In some examples, such a translation table walk operation may involve a sequence of dependent memory accesses to traverse multiple levels of translation table where a higher level of table of the translation table structure includes a pointer referencing an entry in a lower level of table.

As shown in Figure 2, in some examples the MMU 6 may support a two-stage address translation regime, in which translation between virtual address space 40 and a physical address space 52 includes first and second stages of address translation. The target address of a given memory access operation is specified by the instruction fetch circuitry 4 or execution circuitry 16 as a target virtual address 42 in a virtual address space 40. In a first stage of address translation, the target virtual address 42 is mapped to a target intermediate address 48 in an intermediate address space 46, based on address mapping information defined in a stage-1 translation table structure 44 (which may comprise multiple levels of table as mentioned above). In a second stage of address translation, the target intermediate address 48 is mapped to a target physical address 54 in the physical address space 52, based on address mapping information defined in a stage- two translation table structure 50 (which also may comprise multiple levels of table). The stage- one translation table structure 44 may be controlled by an operating system and the stage-two translation table structure 50 may be controlled by a hypervisor (that is, the base address registers used to provide the base addresses of the stage 1 and stage 2 translation tables 44, 50 may have updated restricted to being made by instructions executing at operating-system-level privilege or higher (for the stage 1 translation table base address) or by instructions executing at hypervisorlevel privilege or higher (for the stage 2 translation table base address).

Two-stage address translation is helpful for supporting virtualisation where a number of distinct guest operating systems (each managing corresponding sets of stage 1 translation tables 44 for the applications managed by the operating system) coexist on the same hardware platform. Each guest operating system may act as if it is the only operating system present, and the intermediate addresses generated in the stage 1 translation may, from the point of view of the operating system, appear to be physical addresses referencing memory system locations. However, as different guest operating systems may have specified the same intermediate addresses for different items of data used by the respective operating systems or the applications managed by the operating systems, the hypervisor can set the stage 2 translation tables 50 used for each guest operating system to ensure that the same intermediate address value specified for different guest operating systems can be mapped to distinct physical addresses in the physical address space 52 depending on which guest operating system is active. The hypervisor may update a stage-2 base address register which identifies the location of the stage 2 translation tables 50 on a context switch between guest operating systems (similarly the operating system may update a stage-1 base address register which identifies the location of the stage 1 translation tables 44 on a context switch between applications, to manage switching between a number of distinct translation table structures).

The translation table entry which provides the stage- 1 or stage-2 address mapping used to generate the intermediate address in stage 1 or the physical address 54 in stage 2 is referred to as a page descriptor (distinguishing from table descriptors at higher levels of the table which, instead of providing an address mapping, provide a pointer to a subsequent level of the table structure). As shown in Figure 3, in addition to the translated address mapping (e.g. an indication of an intermediate address mapping for stage-1 translation or a physical address mapping for stage-2 translation), the page descriptor 60 may also specify memory attribute information indicating properties of a region of address space corresponding to this page descriptor 60 and/or permissions indicating information for defining rules for controlling whether or not various classes of memory access operation are allowed to access the region of address space corresponding to the page descriptor 60. As shown in Figure 3, while some memory attribute information may be specified directly in the page descriptor 60, it is also possible for the page descriptor 60 to specify a reference to an indirection table 62 (e.g. stored in registers 14 of the processor 2) which provides memory attribute information. This can be helpful where the encoding space for attribute information is restricted within the page descriptor 60 itself. An indirection table entry identifier directly encoded in the page descriptor 60 can indicate which entry of the indirection table 62 specifies the attribute information for the associated region (page) of address space. A given entry of the indirection table 62 may have greater capacity to store additional attribute information than would be capable of being stored in the page descriptor 60 itself. The use of indirection can also be helpful as it means that if the same update to memory attribute information needs to be made for multiple distinct pages of address space, this update can be carried out more efficiently by simply updating a single indirection table entry referenced by many page descriptors, rather than individually updating each page descriptor. Hence, it will be appreciated that, when referring to memory attribute information below, that information could be specified either directly or indirectly in the translation table entry 60 used to identify the memory attribute information (indirect specification referring to the case when the translation table entry 60 contains an index value which identifies an entry of the indirection table 62 that provides the required memory attribute information).

As well as supporting a two-stage address translation regime as shown in Figure 2, the MMU 6 may also support other translation regimes involving a single stage of address translation (direct from a virtual address to physical address, using a set of (possibly multi-level) translation tables similar to the stage 1 and stage 2 translation tables 44, 50 shown in Figure 2. Where multiple translation regimes are supported, which particular translation regime is in use at a given time may depend, for example, on a current operating state of the processor. For example, a current operating mode, exception/privilege level and/or other control information stored in registers 14 may be used to determine the translation regime currently in use.

Referring again to Figure 1 , the apparatus 2 includes tag checking circuitry 34 for supporting tag checking operations being performed for memory access operations carried out by the load/store unit 28. Such tag checking operations can be useful for detecting memory safety errors. As discussed later on, the apparatus 2 may also have tag-locating address determination circuitry 10 and data-access-to-tag checking circuitry 32. While Figure 1 shows an example where the tag checking circuitry 34 and data-access-to-tag checking circuitry 32 are separate from the load/store unit 28 and MMU 6, other examples could provide these elements as part of the load/store unit 28 or MMU 6. Similarly, while the tag-locating address determining circuitry 10 is shown within the MMU 6 in the example of Figure 1 , the tag-locating address determining circuitry 10 could also be provided separate from the MMU 6.

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®. Some higher level programming languages, such as Java, are considered memory-safe 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:

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

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

• 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

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

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 safety errors.

One approach for protecting against certain memory usage errors of the type discussed above may be to provide allocation tags which are stored in a memory system in association with blocks of one or more memory locations. When a tag-checking memory access operation is requested based on a target address computed from a given address operand (e.g. a register operand stored in one of the registers 14) memory access circuitry may compare an address tag that is associated with the given address operand with an allocation tag that is associated with the data item stored at a location in the memory system identified based on the target address. The memory access circuitry may generate an indication of whether a match is detected between the allocation 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 (e.g. in an error log or by setting an indication in a register) while allowing memory accesses to continue as normal. The allocation tag can also be referred to as a “guard tag”, “memory colouring tag” or “memory safety check tag”.

Such tag checking can be useful as, for example, software based on a memory-unsafe language such as C or C++ can, when initialising regions of memory, set the allocation tags associated with blocks of data items which the code is expected to access to particular values, and may associate the corresponding address tag values with the address pointer operands used to generate target addresses for accessing those blocks. Different allocation tag values may be assigned to neighbouring memory regions which are intended for different purposes, so that if an address pointer intended for accessing for one of those regions is accidentally set to a value that causes it to cause access to another region, the error can be detected based on the tag mismatch. Hence, 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 allocation tag associated with the accessed data item may not match the address tag associated with the address operand used to access the data item, and then in this case the indication of whether a match is detected can be used to trigger an 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.

Figure 4 schematically illustrates a concept of a tag checking operation performed by the tag checking circuitry 34 in response to a tag-checking memory access. An address space used to refer to memory locations within the memory system may be logically partitioned into a number of blocks 70 each assigned a corresponding allocation tag 72. For example, the block of address space corresponding to one tag 72 could be 16 bytes, for instance. As described further below, there can be a number of ways in which the association between the block 70 of data items and its corresponding tag 72 can be managed, either based on virtualized tagging schemes where the address translation functionality of the MMU 6 is used to identify separate physical addresses for a data item in a given block 70 and its corresponding allocation tag 72, or based on a physical tagging scheme where both the data item 70 and its corresponding allocation tag 72 are identified using the same physical address, and it is the responsibility of the memory system to manage storage for allocation tags 72 and provide a mechanism for retrieving the data item and/or tag associated with a given physical address. Hence, there is flexibility to implement the association between the data items 70 and the corresponding allocation tags 72 in a variety of ways, but in general data items in each block 70 of memory address space are capable of being associated with a corresponding allocation tag value 52. The particular numeric value assigned to a given allocation tag for a given block 50 of address space is arbitrary (e.g. selected by software) and can be controlled based on execution of tag setting instructions supported in the instruction set architecture (ISA) supported by the processor 2. Similarly, instructions for setting an address tag for a given address pointer operand may be supported in the ISA.

Hence, when a tag-checked memory access is required, an address tag 80 (which is associated with the address operand 82 used to derive the target address of the data item to be accessed) is compared against the allocation tag 72 which is associated with the block of data items 70 including the data item 84 corresponding to the target address. For example, in Figure 4 the target address points to the data item B1 , marked 84 in Figure 4. Therefore the allocation tag B which is associated with the block of data items B including data item B1 is obtained from the memory system and compared against the address tag 60 associated with the target address 62. As shown at the top of Figure 4, the address tag 80 may be determined as a function of selected bits of the address operand used to compute the target address. In particular, the address tag 80 is derived from a portion of the address operand 82 which is unused for indicating address bits used to compute the target address of the required data item 84. For example, in some ISAs the top portion of bits of an address value may always have a certain fixed value such as a sign extension (all 0s or all 1 s) and so an address operand can be tagged with the address tag 80 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 80 and allocation tag 72 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.

Hence, when a tag-checking memory access is performed, the tag checking circuitry 34 compares the address tag 80 obtained from the address operand and the allocation tag 72 obtained from the memory system, and determines whether they match. The tag checking circuitry 34 generates a match indication indicating whether the address tag 80 and the allocation tag 72 matched. For example, this match indication could be a fault signal which is generated if there is a mismatch between the address tag 80 and the allocation tag 72, or an indication placed in a status register indicating whether there was a tag 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. The particular form of the generated indication of whether a match is detected between the allocation tag and the address tag may vary from implementation to implementation.

In some cases, the tag checking operation may comprise controlling whether a memory access to the data item associated with the target address is allowed depending on whether the match is detected between the allocation tag and the address tag.

However, in other examples the tag-checking memory access may comprise performing a memory access to the data item associated with the target address irrespective of whether a match is detected between the allocation tag 72 and the address tag 80. For example, in some cases accessing the allocation tag may sometimes require a separate read request to be sent to memory, separate from the request for the corresponding data item. Therefore, it may delay processing of the actual memory access if the memory access to the data item is delayed until the allocation tag and the address tag have been compared, so it may be desired to perform the memory access to the data item before the allocation tag is available, and then check the allocation tag later once available.

In one example, the indication of whether a match is detected may be a signal representing a fault condition, which is generated when a mismatch is detected between the allocation tag and the address tag. For example, the memory access circuitry may signal a similar memory fault to faults generated if access permissions are violated or unmapped addresses are accessed, or a different kind of fault condition could be indicated. The fault signal could trigger the processing circuitry to execute an exception handling routine for responding to the detected fault, and can prevent the memory access being successful (or if the tag mismatch is not detected until sometime after the memory access has been initiated, blocks program code from progressing beyond the point when the tag mismatch is detected).

Alternatively, a status indication may be recorded within a control register accessible to the processing circuitry of the apparatus, to indicate whether a match or mismatch was detected in the comparison of the allocation tag and the address tag. The status information could then be read by subsequent instructions to check whether the memory access was valid.

Another option for reporting whether the address tag and allocation tag matched or mismatched can be to record information in an error log associated with the executed piece of code, which tracks any allocation tag errors detected throughout the piece of code. For example, in response to a mismatching allocation tag and address tag, the target address which triggered the mismatch, or the instruction address of the instruction which triggered the mismatching memory access, could be recorded in the error log, which may be stored in memory for example. In this case, rather than performing any specific action to impede the operation of the code, the errors could simply be recorded in the error log. The error log could then be made available to a software provider of the code to assist the provider with reviewing the code for errors and identifying areas of development for eliminating errors in subsequent versions of the software.

Hence, it will be appreciated that there are a range of ways in which the tag match/mismatch indication could be generated by the memory access circuitry (and hence a range of possible error handling responses that could be taken).

In some examples, each addressable data item could have its own allocation tag (e.g. each block 70 shown in Figure 4 could comprise a single byte of memory).

However, in practice the overhead of setting individual allocation tags for each addressable data item (e.g. each byte of memory address space) may be too high, and it can be more efficient to associate each allocation tag with a block of multiple bytes of address space. In this case a block 70 comprising several adjacent bytes in memory (each byte individually addressable by different addresses corresponding to the data items within the block 70) may share the same allocation tag, which can be enough for detecting common forms of memory- related error. The address tag can be associated with the target address in different ways. In some cases the address tag could be specified separately from the target address, e.g. using a separate register specified by a tag-checking memory access instruction which triggers the tag-checking memory access operation. However, in other examples (as shown in Figure 4) the address tag may be determined as a function of one or more selected bits of the target address. That is, the address tag may comprise information derived from a portion of the target address itself. Often, while an instruction set architecture may support addresses with a certain number of address bits (e.g. 64 bits), a given hardware device may not in practice need so much memory capacity that it would use all the possible addresses which can be represented using that number of address bits. For example, with current trends in device usage there is not yet any need to provide 2⁶⁴ individual addressable locations. Therefore, often some bits of the memory addresses may effectively be unused and may either always have the same value, or be set as a sign extension of the most significant “real” address bit (so that the unused portion is set to all Os or all 1 s). This unused portion can therefore be reused to represent the address tag or a value for deriving the address tag, to avoid needing to access a separate register in order to obtain the address tag, and also to make it easier to track the correspondence between the addresses and the corresponding address tags as the address tag may by definition be transported along with the address whenever the address is manipulated or moves between registers.

In examples which use a portion of the target address to determine the address tag, note that this address tag is different to a tag portion of the target address which may be used by caches to derive a cache tag used to determine whether the information associated with the target address is stored within the cache. Many caching schemes may store a tag portion of the address of a cached piece of data alongside that data within the cache, so that on searching the cache for a given address, part of the address can be compared with the cache tags stored alongside the cached data in order to determine whether the cached data actually corresponds to the required address. However, in this case the tag portion of the address which is compared with the tag stored in the cache would be derived from part of the portion of the address which actually identifies the particular data item requested to be accessed, i.e. changing the cache tag portion of an address would by definition result in the address pointing to a different addressed location within the memory system and causing the read/write operation to operate on a different data item. In contrast, with the address tag 80 used for the tag-checking memory operation, the memory access circuitry may select the location storing the required data item independent of the address tag 80. That is, even if the address tag 80 within the address operand has different values, the location in memory referenced by the target address may still be the same. The selection of the location to access in memory for the required data item depends only on other portions of the target address other than the address tag 80. This gives the freedom for compilers to set the address tags associated with particular addresses to any value to match the corresponding allocation tag values which have been allocated to the relevant blocks of data in the memory system.

In some implementations, the instruction decoder could support separate non-tagchecking and tag-checking variants of memory access instructions. In this case, the tag-checking memory access operation could be triggered in response to the tag-checking variant of the memory access instruction. In contrast non-tag-checking memory access instructions could simply trigger an access to the addressed location identified by the target address specified by that instruction, without needing to obtain an allocation tag or perform any comparison between the address tag and the allocation tag.

However, in other implementations all memory accesses may be considered to be tagchecking memory accesses. Hence, in some cases any memory access instruction may be considered to trigger the memory access circuitry to perform a tag-checking memory access operation as discussed above.

However, even if all memory access instructions are interpreted as tag-checking memory access instructions, there may still be other ways in which the instruction set architecture may support selectively disabling the allocation tag comparison for certain operations. For example, a control parameter within a control register of the processing apparatus could selectively disable tag comparisons.

Also, as explained below, memory attribute information encoded directly or indirectly in a translation table entry associated with the target address could specify whether the accessed memory region is a tagged memory region requiring a tag check to be performed, or an untagged memory region which does not require a tag check to be performed. Hence, even for the same instruction encoding, whether or not the tag check is performed may depend on the memory attribute information set for the target address in a translation table entry accessed by the MMU 6.

Another option is for a certain value of the address tag or allocation tag to be interpreted as a “match all” value so that the “match all” tag value is considered to match against any possible value of the opposite tag, again effectively disabling the effects of the tag comparison so that no error is reported regardless of whether the address tag matches the allocation tag. Hence, in some cases the comparison in the tag check may be detecting whether there is a mismatch between the allocation tag 72 and address tag 80, but not all cases where the values of the allocation/address tags 72, 80 differ need to be detected as mismatches which trigger an error handling response, since if one or both of the allocation tag 72 and address tag 80 is a “match all” tag then no error handling response needs to be triggered.

Figures 5, 6 and 7 illustrate some examples use cases showing how support for such tag checks can help catch memory safety usage errors such as use-out-of-scope or use-after-free errors. Figure 5 illustrates steps performed by the software (e.g. an operating system) responsible for allocating regions of memory for particular purposes, to set the allocation tag values associated with the allocated region of memory. As shown in the left part of Figure 5, initially there is a free region of memory which is not currently allocated for any particular purpose, which is initially assigned allocation tag values of 4 (in this example, each 16 byte granule of data has a separate allocation tag value). After a memory allocation operation in which a portion of the free region of memory is allocated to storing particular data, the memory allocating software executes tag setting instructions to set the allocation tag values associated with the newly allocated data region to a different value 6, differentiated from the allocation tag values of 4 for the surrounding regions of memory. When the memory allocating software later deallocate the same region, it updates the allocation tag values for the deallocated region to a different value (tag = 7) from the value (tag = 6) prior to the deallocation. The particular allocation tag values shown in Figure 5 are arbitrarily selected (e.g. the new allocation tag value of 7 for the deallocated memory region is arbitrary and could have been replaced with 2 or 3 or any other value different from 4 or 6, the values set for the allocation tags in neighbouring regions and for the allocation tag of the deallocated region prior to deallocation). However, in general the allocating software will aim to ensure that allocation tag values associated with a given region of memory are updated when either allocating or deallocating that memory, so that there is a change in allocation tag value when transitioning between a free region and an allocated region or when transitioning between allocated regions allocated for different purposes.

Figure 6 illustrates how an out of bounds use of a pointer can be detected using the tag check, having set the allocation tag values for the memory regions according to the middle portion of Figure 5 (prior to the deallocation of the memory region allocated with allocation tag value of 6). A given address pointer “ptr” loaded from memory is used as an address operand to generate a target address of a memory. The software developer or compiler that generates the software being executed intends this pointer to be used to reference the data region 86 assigned the allocation tag value 6, and so at the point of allocation the pointer “ptr” has similarly been assigned the address tag value of 6. Hence, for correct usage of the pointer ‘ptr’ within bounds, the address computed based on the pointer falls within data region 86, the allocation tag 72 obtained from the memory system has a value of 6 and the address tag 80 obtained from the address operand (pointer) used to compute the target memory address also has a value of 6, so a tag match indication is generated and there is no need to trigger any error response.

However, sometimes the same pointer “ptr” may be used out of bounds to generate a target address in a different memory address region 88 from the region 86 intended to be accessed using the pointer. For example, data region 86 could have been allocated as a buffer data structure to which items of data can be pushed for processing by another software process. The buffer data structure may have been allocated to have a certain maximum size corresponding to the extent of the allocated data region 86, and for robust memory safe software, it would be best for the software developer or compiler to ensure the software includes one or more instructions to check for buffer overflows before pushing further data onto the buffer. However, some software developers may forget to include such safety checks in the software code, so if the code executes too many instances of a function for pushing data onto the buffer, the address pointer used to track the next point of the buffer at which data should be inserted may extend out of bounds, beyond the region 86 allocated for the buffer. This can risk corruption of other data in a region of memory beyond the region 86 allocated for the buffer (in this example the region beyond the buffer is a free region so the error may not necessarily cause incorrect functioning, but it could also have been allocated for other data which may be corrupted by the out of bounds use of the pointer “ptr”). This causes a risk as (while the buffer overflow in itself may not always be a problem), it might be exploited by an attacker aiming to disrupt operation of the victim software or cause branching to harmful gadget code which gives the attacker access to information they could otherwise have accessed. However, by supporting memory tagging, such an out of bounds use of pointer “ptr” can be detected using the tag check because the address tag value of 6 will not match the allocation tag value of 4 for the region 92 of address space accessed using the pointer. Hence, an indication of a tag mismatch can be generated and used to prevent the memory access proceeding and/or generation of an error report that can be returned to the software developer to help them patch up vulnerabilities or potential errors in their code.

Similarly, Figure 7 shows how even if the pointer is used within the address bounds expected, there may be temporal errors based on the timing at which the pointer is used to control memory accesses to a given region of address space. A given address pointer “ptr” may have been established for use in a limited period when data is stored in a given memory region 86, but after that memory region has been deallocated, the pointer may still exist in memory and may accidentally be used to compute the target address of another memory access, which can risk compromising data now stored in the same memory region which should not be made accessible using the pointer “ptr”. Since the allocation tag value is updated from 6 to 9 on deallocating a given data region 6, use of pointers generated prior to the deallocation (which would be associated with an address tag of 6) can be detected based on the mismatch between the address tag of 6 and the allocation tag of 9, and again used to trigger error reporting.

It will be appreciated that Figure 6 and 7 show just some of the kinds of memory usage errors that can be detected using such tag checks, but in general the support for assigning address tags to address pointers and allocation tags stored in the memory associated with corresponding data items can help catch memory safety bugs, which can help software developers develop more robust and secure program code.

Figure 8 illustrates steps performed by the tag checking circuitry 34 for a tag checking operation. At step 800, in response to a tag-checked memory access instruction, the tag checking circuitry 34 obtains an address tag 80 from an address operand 82 used to compute the target address of the data item to be accessed in response to the tag-checked memory access instruction. Also, the tag checking circuitry 34 obtains an allocation tag 72 from the memory system associated with the data item identified by the target address of the memory access instruction. At step 802, the tag checking circuitry 34 compares the address tag 80 and the allocation tag 72, and at step 804 detects whether a tag mismatch is detected. In general, a tag mismatch may be detected when the address operand is not equal to the allocation tag. However, in some examples, a “match all” value may be supported so if one of the address operand or the allocation tag has the “match all” value then a tag match may be detected regardless of the value of the other tag. If a tag match is detected (e.g. because the address tag 80 and allocation tag 72 are equal, or because one of the tags has a match all value), then at step 806 no tag mismatch error needs to be signalled. If a tag mismatch is detected then at step 808 an error handling response is triggered. The error handling response could include signalling of a fault and/or updating error log information.

To support the tag check described above, a mechanism is provided to support storing, within the memory system, an allocation tag 72 to be associated with a given data item stored in the memory system. There can be a variety of different ways in which that association can be managed, either using the address translation functionality provided by the MMU 6, or using hardware in the memory system to identify the location storing the allocation tag corresponding to a given data item.

Figure 9 shows an example using physical tagging to associate the allocation tag with its corresponding data item. In this example, when locating an allocation tag associated with a given data item, the allocation tag is identified based on the same physical address that is used to identify the corresponding data item. Hence, the address translation performed by the MMU 6 does not need to perform any special translation function for generating the address of an allocation tag 72. Instead, the address translation from virtual address to physical address that would be carried out to obtain the physical address of the data item is sufficient for any operation that requires the associated allocation tag 72 (e.g. that operation could be a tag check associated with a tag-checked memory access to the data item, or could be a standalone tag setting instruction or tag reading instruction which writes or reads the allocation tag 72 without necessarily also accessing the corresponding data item). With this approach, the memory system supports a mechanism to identify, based on the physical address of the data item / tag pair, the locations storing the data item and the associated allocation tag, so that on a tag access the required allocation tag can be read/written in the memory system.

A variety of mechanisms could be used by the memory system to designate the tag storage. As shown in Figure 9, one option is to implement separate physical memory units for storing data and tags respectively, with the same physical address obtained in the address translation being sent to the data physical memory for data accesses and the tag physical memory for tag accesses and used to identify the location of the corresponding data item or allocation tag. Another option can be that the allocation tag values are stored alongside corresponding data items in a common memory storage unit. For example, some memory storage units may include spare capacity for error correction codes associated with stored data items. Error correction functionality may not always be in use, so the error correction code storage could be reused for storing allocation tag values. Another option can be that, within a given data physical memory unit for storing data items, a portion of that physical storage is carved out and reserved for storing the allocation tags associated with the data items stored in that memory unit. The carved out region could be fixed or variable. If a variable region is designated, some stored state information (e.g. a base address or a table structure separate from the base address and translation table structures used by the MMU 6) may be maintained in the memory to identify which region of the data storage provides the tag associated with a particular data item. With a carve-out approach, as the tag storage is part of the internal address space of the physical memory system that can be addressed based on a physical address, it is also possible that the physical storage locations storing the tags could be mapped to virtual addresses using mapping information in the translation tables 44, 50. However, unlike the virtualized tagging approaches discussed below, in this case, the virtual addresses mapped to tag storage would be translated to physical addresses just like any other data address, with no tag-specific address translation functionality being supported by the MMU 6 separate from data-address translations. If physical tagging is used, the particular mechanisms used by the memory system to maintain the association between data items and tags may be implementation-specific and may be invisible to software executing on the apparatus 2.

Figures 10 and 11 illustrate examples using virtualized tagging to associate the allocation tag 72 with its corresponding data item. In these examples, the address translation functionality offered by the MMU 6 is used to translate a data-locating virtual address (VA) identifying a given data item into separate physical addresses PA1 , PA2 identifying the data item and its associated allocation tag respectively. By supporting a virtualized tag translation mode where the allocation tag 72 is assigned a different physical address from its corresponding data item (based on separate address translation mappings at at least one of the stage 1 and stage 2 address translations), this makes implementation of the physical memory much simpler because the memory system does not need to implement any special mechanism for managing tag storage. From the point of view of the memory system, allocation tags appear to be data items and so for tag-checked memory accesses where both a given data item and its associated tag value are to be accessed, two separate memory access requests can be issued to the memory system: one specifying the data-locating physical address PA1 identifying the location storing the data item and one specifying the tag-locating physical address PA2 identifying the location storing the allocation tag. The MMU (address translation circuitry) may support mechanisms enabling software to define the translation table structures so as to control the translation of the data- locating VA into the separate data-locating and tag-locating physical addresses PA1 , PA2.

In the example of Figure 10, virtual tagging is used, so that the stage of address translation at which the target address of the data item is mapped to separate addresses for data item and tag respectively is the stage 1 address translation. In this example, two separate stage 1 address translation mappings are used to obtain respective data-locating and tag-locating intermediate addresses IPA1 , IPA2 corresponding to the specified data item virtual address VA. Each of those intermediate addresses IPA1 , IPA2 can then be translated further in stage 2 to corresponding physical addresses PA1 , PA2 used to access the corresponding data and allocation tag stored in the memory system. As shown by the dashed line in Figure 10, one way of controlling use of separate stage 1 translation mappings for data and tag translations respectively can be that, for tag translations, a modification is applied to the data-locating VA to generate a modified VA identifying the location of the allocation tag within the virtual address space, and then that modified VA is used as the input for looking up translation table structures, so that a separate entry of the stage 1 translation tables 44 is used for tag address translations compared to the entry used from the same stage 1 translation tables 44 for data address translations. Other examples may not apply that address modification, but instead select different sets of translation tables 44 (based on different base registers) depending on whether the stage 1 address translation is being performed for a data item access or a tag access.

On the other hand, in the example of Figure 11 , intermediate tagging is used, so that the stage of address translation at which the address identifying the data item is mapped to separate addresses for data item and tag respectively is the stage 2 address translation. In this example, the stage 1 address translation translates the VA of the data item into a corresponding intermediate address IPA1 (with a same stage 1 address translation mapping shared by both data item and tag), but the stage 2 translation then selects separate stage-2 address translation mappings to generate the data-locating physical address PA1 and tag-locating physical address PA2 respectively. Again, as shown by the dashed line in Figure 1 1 , for tag address translations some examples may apply an address modification operation to determine, based on the data- locating intermediate address IPA1 , a tag-locating intermediate address IPA2 within the intermediate address space so that a separate entry of the stage 2 translation tables 50 is used for tag address translations compared to the entry used from the same stage 1 translation tables 44 for data address translations. Other examples may not apply that address modification, but instead select different sets of stage 2 translation tables 50 (based on different base registers) depending on whether the stage 2 address translation is being performed for a data item access or a tag access.

As shown in Figure 10 (for conciseness this is not also shown in Figure 11 , but can also apply to intermediate tagging), for examples where the number of bits in one allocation tag is smaller than the number of bits in one addressable memory location (e.g. one byte), two or more allocation tags may be stored at the same tag-locating physical address PA2, and so part of the data-locating address VA or IPA1 may be used to select between the tags stored at the same tag-locating physical address PA2. Hence, in general, a virtualized tag translation mode may be supported in which, for a given stage of address translation which maps addresses from a first address space to a second address space, a data-locating first address in the first address space is translated to separate data-locating and tag-locating second addresses in the second address space. The data-locating first address depends on the data virtual address used to identify the data item in the virtual address space and the physical addresses of the data item and associated allocation tag respectively depend on the separate data-locating and tag-locating second addresses. For an example with virtual tagging as shown in Figure 10, the given stage of address translation is the stage 1 translation, the first address space is the virtual address space 40, the second address space is the intermediate address space 46, the data-locating first address is the data-locating virtual address, and the data-locating and tag-locating second addresses are intermediate addresses which are further translated into corresponding physical addresses in a second stage of address translation. For an example with intermediate tagging as shown in Figure 11 , the first address space is the intermediate address space 46, the second address space is the physical address space 52, the data-locating first address is the intermediate address IPA1 generated in the stage 1 translation corresponding to the data-locating virtual address, and the separate data- locating and tag-locating second addresses generated in the stage 2 translation for data item and tag respectively are physical addresses PA1 , PA2 used to identify the corresponding storage locations of the data and allocation tag in memory.

Some examples may support at least one virtualised tag translation mode, e.g. based on the virtual tagging mode shown in Figure 10 and/or the intermediate tagging mode shown in Figure 1 1 . Some examples may support both virtual tagging and intermediate tagging, so that it is selectable, e.g. based on control state set by software, which mode is applied. An advantage of supporting at least one virtualised tag translation mode is that this removes the need for the physical memory to implement mechanisms for managing storage of allocation tags 72. This makes memory system implementations simpler.

Even if the memory system does support mechanisms for managing storage of allocation tags 72, using the address translation functionality to identify the tag storage locations for certain data items can help support more efficient utilisation of available physical memory storage capacity. Software setting the address translation tables may have greater awareness of whether tag checks are likely to be required for particular blocks of data items, and so can avoid setting translation table entries mapping allocation tags to physical memory for the tags corresponding to regions of data item addresses that are unlikely to require tag accesses. Hence, unlike the physical memory system, which may conservatively need to assume that any data item may require physical storage for a corresponding tag or which may have been statically defined to reserve a certain chunk of its physical storage for storing allocation tags, the software managing the address translation mappings has more visibility of which allocation tags are going to be needed and which are unlikely to be accessed. Therefore, that software can identify which allocation tags should be allocated physical storage based on corresponding valid translation table entries, and which allocation tags may merely be nominally associated with corresponding data items but not allocated physical memory at a given time (e.g. using paging mechanisms to page in/out of external storage so that allocation tags can be allocated physical memory only as/when they are actually required, to make more efficient use of the limited memory capacity of the physical memory system). Also, the software can select the address mappings so that, in a given stage of address translation from a first address space to a second address space, the translation entries accessed for tag address translations for two or more distinct blocks of data items can map the corresponding tag-locating addresses onto the same second address in the second address space, in cases where the two or more blocks of data items are to share the same allocation tag value. This means that less physical memory needs to be allocated for tag storage, as multiple blocks of data items can share the same tag storing location in physical memory, compared to an approach where tag/data share the same physical address and the memory system cannot benefit from any software provided hint on whether the tags for distinct blocks of physical data addresses are to have the same allocation tag value, so would allocate separate physical storage in memory for each distinct “granule” of data items (where the “granule” is the block of data items sharing a single allocation tag).

It is possible to provide a MMU 6 which supports only the virtualized tag translation mode (e.g. one or both of the virtual/intermediate tagging modes shown in Figures 10 and 1 1 ), but does not support physical tagging as shown in Figure 9. However, other examples may also support the option of using physical tagging as shown in Figure 9. It can be useful to support flexibility to vary which approach is used, as for implementations where the memory system does support mechanisms to locate the allocation tag associated with a given data item based on the same physical address used to identify both the data item and tag, this can simplify software implementation by reducing the overhead in managing separate translation table mappings for data and tags respectively. Hence, for a given stage of address translation from a first address space to a second address space, the MMU 6 can select between a first tag translation mode and a second tag translation mode. In the first tag translation mode, any translations performed for tag accesses simply reuse the same translation as the corresponding data item accesses. In the second tag translation mode, translations performed for tag accesses involve a separate tagaddress translation operation, separate from the data-address translation operation, with the tagaddress translation operation and data-address translation operation using different translation table entries to provide the address mappings for the given stage of address translation. For the example of Figure 10, stage 1 translations use the second tag translation mode and stage 2 translations use the first tag translation mode. For the example of Figure 11 , stage 1 translations use the first tag translation mode and stage 2 translations use the second tag translation mode. For the example of Figure 9, both stage 1 and stage 2 translation use the first tag translation mode. The first tag translation mode can be considered to translate a given input address according to a data-locating-address translation operation, and the second tag translation mode can be considered to translate a given input address according to a tag-locating-address translation operation. The selection between the first and second tag translation modes can be based on control information set by software, e.g. a configuration value in a control register.

When a virtualized tag translation mode is supported, the tag-locating address translation operation used to obtain the physical address PA2 of the allocation tag requires a separate translation table entry compared to the data-locating address translation operation used to obtain the physical address PA1 of the corresponding data item. With the virtual tagging approach Figure 10, both stages 1 and 2 may use tag-translating translation table entries established for translating the modified VA to IPA2 and for translating IPA2 to PA2, which are separate from the entries for translating VA to IPA1 and IPA1 to PA1 . With the intermediate tagging approach shown in Figure 1 1 , stage 2 may use a separate translation table entry to translate IPA2 to PA2 for a tag access, separate from the entry used to translate IPA1 to PA1 for the data access. Hence, performing the tag-locating address translation may risk additional faults which would not arise for a non-tag-checking data access, since if the operating system or hypervisor has not yet configured an appropriate translation table entry for the tag-locating address translation, or the translation table entry accessed in the tag-locating address translation specifies permissions which are not satisfied by the memory access operation, a memory fault may occur, causing interruption to processing. To reduce the performance cost, it may be desirable not to incur the increased risk of faults associated with performing the tag-locating address translation if an access is carried out to a region of memory for which tag checks are not required.

To address this, the translation tables may define, in the attributes/permissions information encoded directly or indirectly within a translation table entry 60 used for the region of address space providing a given data item, attribute information indicating whether that region is a tagged region (for which accesses to the region should be treated as tag-checked memory accesses for which the tag check is required) or an untagged region (for which the tag check is not required). In some examples, a dedicated attribute type could indicate whether the region is tagged or untagged. However, it is also possible to infer tagged/untagged status from one or more other attribute types. For example, the attribute information could indicate whether the region is Normal memory type or Device memory type (Device memory type being subject to additional restrictions preventing memory access operations to the Device memory region being, for example, repeated more than once, interrupted after being partially actioned and restarted later and/or reordered compared to the order in which the memory access operations are requested, with Normal memory type not being subject to any of these restrictions). Also, the attribute information could indicate cacheability attribute information which indicates whether data from the corresponding region of address space should be cached in a cache once accessed from main memory. For example, the cacheability attribute information could indicate whether the region is a writeback cacheable region (for which caches are permitted to hold dirty data which has been updated but has not yet been written back to the backing store in memory), write- through cacheable region (for which any updates to cached data are immediately propagated through to the backing store in memory) or non-cacheable region (for which data should not be cached in any cache). In some examples, the tagged status of a region of address space may be determined when the attribute information for the region indicates that the region is a Normal memory region which is writeback cacheable. Any region having attribute information indicating that the region is not a Normal writeback cacheable region may be considered to be untagged.

Hence, based on the attribute information associated with the page of address space comprising the accessed data item, the MMU 6 can determine whether it is needed to architecturally perform the tag-locating-address translation for obtaining the tag-locating physical address of the associated allocation tag. If the memory access instruction is targeting an untagged region of memory, the tag-locating-address translation is not architecturally performed. For example, either the tag-locating-address translation is not performed at all, or it is performed but any architectural effects of the translation are suppressed - the architectural state of the system remaining the same as if the translation was never performed. For example, if the translation is architecturally (but not necessarily actually) suppressed, faults may not be triggered based on the translation, architecturally-visible performance counters (if provided) may not be updated based on the translation, and no memory access may be triggered based on an address obtained by the tag-locating-address translation.

Figure 12 is a flow diagram illustrating how the tag-locating-address translation can be enabled/disabled based on memory region attribute information associated with the address of the data item to be accessed.

At step 1200, a tag-checked memory access instruction specifying a target data address is detected. The tag-checked memory access instruction may be any instruction which requests read or write access to a target data item identified by the target data address and which, at least when the memory attribute information specified for the data item identified by the target data address specifies that the target data address corresponds to a tagged memory region, causes the tag checking circuitry 34 to perform a tag check between an address tag associated with the address operands used to complete the target data address and an allocation tag stored in the memory system associated with the target data item. In some examples, a dedicated class of tag- checked class of memory access instruction may be provided, separate from a non-tag-checked class of memory access instructions, so that the steps of Figure 12 may be performed for the tag- checked class of instructions but not for non-tag-checked memory access instructions. In other examples, the instruction encoding may not distinguish whether the memory access instruction is tag-checked or non-tag-checked, and all data-item-accessing memory access instructions may in principle be able to act as tag-checked memory access instructions, but whether the tag check is actually performed may depend on the memory attribute information as described below. Also, in some cases, whether a given memory access instruction is a tag-checked memory access instruction may depend on a mode indicator or other tag check enable/disable control value which may be used to control whether or not tag checks are enabled or disabled.

At step 1200, in response to the tag-checked memory access instruction, the MMU 6 obtains memory region attribute information specified by a translation table entry associated with the target data address. Such attribute information could be obtained by the table walk circuitry 12 performing a table walk operation to trigger memory access operations for traversing the stage 1 and/or stage 2 translation table structures 44, 50 (following any trail of pointers between multiple levels of table in the translation table structures 44, 50) and locating the page descriptor 60 corresponding to the target data address. Alternatively, if the attribute information corresponding to the target data address is already cached in a TLB 8, then the memory region attributes specified by the translation table entry associated with the target data address can be obtained from the TLB 8 instead of performing the table walk operation.

At step 1202, the MMU 6 determines which memory region type is specified by the memory region attributes associated with the target data address. If the target data address is in an untagged memory region (e.g. any region other than a Normal Writeback Cacheable region), then at step 1204, the MMU 6 determines that the tag-locating-address translation does not need to be architecturally performed. Hence, either the tag-locating-address translation operation is not performed at all, or if it is speculatively performed then no memory fault is triggered based on the tag-locating address translation even if the tag-locating-address translation would have caused a fault to be detected if architecturally performed (e.g. fault detection may arise if there is no valid address translation entry defined for the mapping “modified VA -> IPA2” or “IPA2 -> PA2” shown in Figures 10 and 1 1 for the virtualized translation modes). Hence, by suppressing faults for tag-locating-address translations when the access is to an untagged memory region, this reduces the overhead on software developers as, when virtualized translation modes are in operation, it is not necessary for transition table entries mapping the addresses of allocation tags to be configured for the allocation tags corresponding to each data item address. The software only needs to configure allocation tag mapping translation table entries for those data addresses for which tag checks are actually required. For accesses to untagged memory regions, at step 1206 the MMU 6 or the tag checking circuitry 34 determines that no tag check is required.

If the target data address is determined to be in a tagged memory region (e.g. a Normal writeback cacheable region), then at step 1208, the MMU 6 determines whether virtualized tagging (e.g. one of the virtual and intermediate tagging approaches shown in Figures 10 and 1 1 ) is currently enabled. As discussed further below with respect to Figures 18 and 19, the determination of whether a virtualised tagging mode is active can be made using tag translation control information VTE, IPMTE stored in control registers.

If virtualised tagging is enabled and the access is to a tagged memory region, then at step 1210 the MMU 6 architecturally performs the tag-locating-address translation operation to obtain the translated tag-locating physical address PA2 which identifies the location of the allocation tag corresponding to the data item identified by the target data address specified by the tag-checked memory access instruction. Steps for performing the tag-locating-address translation are described in more detail in the examples of Figures 14 to 17 and 24 below. If any fault condition is detected when performing the tag-locating-address translation operation, then a memory fault is signalled, which may cause an interruption to the current processing and cause the processor 2 to switch to executing instructions from an exception handler, which may investigate the fault and determine how to proceed (e.g. trigger the operating system or hypervisor responsible for the stage of address translation at which the fault was detected to configure a translation table entry for the required address mapping if no such mapping has previously been provided).

Assuming no memory fault is detected in the tag-locating-address translation operation, then at step 1212, the load/store unit 28 issues a memory access request to the memory system specifying the tag-locating physical address PA2 obtained by the MMU 6 in the tag-locating- address translation operation. The tag-accessing memory access request specifying PA2 requests access to an allocation tag, separate from a data-accessing memory access request specifying physical address PA1 which is issued to the memory system to request access to the corresponding data item. At step 1214, when the memory system returns a word of data corresponding to the tag-locating physical address PA2, the load/store unit 28 or the tag checking circuitry 34 selects between the allocation tags contained in the returned data word (e.g. between two allocation tags, in the example shown in Figure 10), based on tag selection information determined from the target data-locating address identifying the required target data item. For example, the tag selection information can be the nibble selection information explained with reference to Figures 22 and 23 below. At step 1216, the tag checking circuitry 34 performs the tag check operation of Figure 8 using the allocation tag selected at step 1214 and the address tag 80 associated with the address operand of the memory access instruction (e.g. the address tag 80 may be extracted from upper bits of the address operand as shown in Figure 4).

On the other hand, if the memory access is to a data item in a tagged region of memory, but virtualized tagging is currently disabled, then at step 1218 the tag-locating-address translation is not architecturally performed, since in this case the tag translation is based on a physical tagging regime as shown in Figure 9, and so the allocation tag 72 associated with the target data item can be located based on the same physical address PA1 as the physical address of the data item itself. Both the allocation tag and the data item are associated with the same data-locating physical address PA1 . At step 1220, if not issued already for the data access, a memory access request is issued to the memory system specifying the data-locating physical address, to request access to the allocation tag (and the data item) associated with that address. When the allocation tag is returned from the memory system, at step 1222 a tag check (as in Figure 8) is performed using the obtained allocation tag and the address tag associated with the address operation of the memory access instruction. Figure 13 illustrates steps for performing the tag-locating address translation operation for a tag accessing instruction for accessing one or more allocation tags corresponding to a specified data address. The tag accessing instruction could be a tag-checked memory access instruction which also triggers an access to the corresponding data item (as in the example of Figure 12) or could be a tag read/write instruction which requests read/write access to the allocation tag(s) for a certain block of data items corresponding to the specified data address without also accessing the corresponding data item. In this example, a given stage of address translation for translating from a first address space to a second address space, referred to below as the stage-n translation, includes selection between a first tag translation mode and a second tag translation mode. When a one-stage address translation regime is in use, the stage-n translation can be the single stage of address translation used in that regime (with the first address space being the virtual address space 40 and the second address space being the physical address space 52, a single stage of translation tables mapping addresses directly from the virtual address space 40 to the physical address space 52). When a two-stage address translation regime is in use, the stage-n translation could be either the stage 1 translation (where the first address space is the virtual address space 40 and the second address space is the intermediate address space 46 with address mappings for the translation determined based on the stage 1 translation tables 44) or the stage 2 translation (where the first address space is the intermediate address space 46 and the second address space is the physical address space 52 with address mappings for the translation determined based on the stage 2 translation tables 50).

At step 1300, the MMU 6 determines that a tag-locating address translation is to be performed for obtaining the tag-locating physical address corresponding to a data address specified using address operand of the tag-accessing instruction. The data address may be specified as a virtual address in the virtual address space 40.

At step 1302, a data-locating first address in a first address space 40, 46 is determined depending on the data address specified by the tag-accessing instruction. If the stage-n translation is a translation in a single-stage translation regime or is the stage 1 translation of a two-stage translation regime, then the data-locating first address can simply be the data address specified by the instruction. If the stage-n translation is the stage 2 translation of the two-stage translation regime, then the data-locating first address can be the intermediate address (e.g. IPA1 in Figure 1 1 ) obtained by translating the data address VA in the stagel translation.

At step 1304, the MMU 6 determines which tag translation mode is a selected tag translation mode to be used for the stage-n address translation from the first address space to the second address space. For example, the determination of the selected tag translation mode may be based on tag translation control information stored in control registers 14, which is set by software operating with at least a given level of privilege (e.g. operating system level privilege if the stage-n translation is a single-stage of translation or the stage 1 translation in a two-stage regime), or hypervisor level privilege if the stage-n translation is the stage 2 translation). If the MMU 6 determines that a first tag translation mode is selected (a translation mode in which virtualised tagging is disabled for the stage-n translation), then at step 1306 the MMU 6 obtains a data-locating second address, which identifies the location within the second address space of both the data item corresponding to the data address and its associated allocation tag. For example, the data-locating first address obtained at step 1302 may be used to lookup the TLB 8 and/or the translation tables 44, 50 to obtain address mapping information for translating the data-locating first address into the data-locating second address. In this case, both the data translation and the tag translation would be controlled based on the same translation table entry providing the address mapping from the data-locating first address (e.g. VA or IPA1 ) to the data- locating second address (e.g. IPA1 or PA1 ). At step 1308, the MMU 6 determines the tag-locating physical address depending on the data-locating second address.

If the MMU 6 determines that a second tag translation mode is selected (a translation mode in which virtualised tagging is enabled for the stage-n translation), then at step 1310, the MMU 6 obtains a tag-locating second address (e.g. IPA2 or PA2) identifying the location of the allocation tag in the second address space separate from the location of the data item identified by the data-locating second address (e.g. IPA1 or PA1 ). A separate translation table entry identifies the mapping to the tag-locating second address, compared to the entry used to obtain the address mapping for the data-locating second address. Two examples of how such separate translation table entries can be located are explained below with respect to Figures 14 to 17. At step 1312, the MMU 6 determines the tag-locating physical address depending on the tag-locating second address determined at step 1310.

At both steps 1308 and 1312, if the stage-n translation is a translation in a single-stage translation regime or is the stage 2 translation of a two-stage translation regime, then the taglocating physical address can simply be equal to the data-locating second address determined at step 1306 or 1310, as the data-locating second address is already a physical address in the physical address space. If the stage-n translation is the stage 1 translation of the two-stage translation regime, then the data-locating second address (also serving as tag-locating second address) can be further translated into the tag-locating physical address, e.g. based on a further stage-2 translation. In the case where the first tag translation mode is selected for a stage 1 translation in a two-stage address translation regime, then at step 1308 the stage-2 translation performed for obtaining the tag-locating physical address may use either the first or second tag translation mode, depending on any mode selection configuration value specified for the stage-2 translation. In the case where the second tag translation mode is used for the stage 1 translation of a two-stage translation, then at step 1312 the stage-2 translation may be performed based on the first tag translation mode (to prevent uncertain results caused by using the second tag translation mode for both stage-1 and stage-2 translations).

It will be appreciated that the steps shown in Figure 13 may not be needed every time a tag-accessing instruction is executed. While any required stages of translation for the current translation regime may be fully performed the first time a given region of address space not having relevant information cached in the TLB 8 is accessed, for subsequent accesses to the same region of address space, information cached in the TLB 8 from a previous access may be used to avoid the need to perform the full translation process again. For example, some TLBs 8 may simply cache information defining the association between a given data address in the virtual address space with the corresponding tag-locating physical address (which has previously been determined according to the process defined in Figure 13), to avoid needing to consider which tag translation mode is the selected tag translation mode each time. Hence, while the MMU 6 may have a configuration which supports the operations shown in Figure 13 being performed for a tag-accessing instruction, it does not always need to use that configuration for each tagaccessing instruction. For example, the control information used to select which tag translation mode is the selected tag translation mode may be checked on page table walks, but may not be needed when an address for a tag access hits in the TLB 8.

Hence, if the second tag translation mode is selected for a given stage of address translation, different translation table entries may be used to identify the second addresses in the translated second address space which correspond to the data item and tag respectively. Figures 14 to 17 show two example techniques for identifying the distinct translation table entries used to obtain the mappings for the data-locating second address and tag-locating second address.

As shown in Figure 14, one option is to provide distinct translation table base address registers for storing base addresses used to access the translation tables for data-locating address translations and tag-locating address translations respectively. This means that the same input address can be used to select corresponding entries from two distinct translation table structures, one for data accesses and one for tag accesses, so that the same input address in a first address space can be mapped to two distinct addresses in a second address space. The software responsible for controlling the given stage of address translation can be responsible for storing to memory the translation table entries required for each distinct translation table structure and setting the translation table base address registers to point to the respective translation table structures. From the hardware point of view in the MMU 6, the translation process can be the same for both data and tag accesses, except that there is a selection between a first translation table base address register and a second translation table base address register depending on whether the current translation is for a data access or an allocation tag access.

Hence, as shown in Figure 14 for a stage-n translation from a first address space 90 (virtual or intermediate address space) to a second address space 92 (intermediate or physical address space), a given data-locating first address 94 in the first address space 90 is, for a data- locating-address translation operation, used to select a corresponding translation entry 98 from a stage-n data translation table structure 96 used for data accesses. The stage-n data translation table structure 96 is identified based on a first translation table base address TTBR data stored in a first translation table base address register. Based on the access to the selected data- address-mapping translation table entry 98, a corresponding data-locating second address 104 in the second address space 92 is determined. While Figure 14 for conciseness shows the selected translation table entry 98 directly specifying the mapping to the data-locating second address 104, it will be appreciated that often the stage-n data translation table structure 96 may be a multi-level table and so the entry 98 selected based on the data-locating first address 94 may actually specify a table pointer identifying a further translation table, and the data-locating second address 104 may be obtained from an entry of a translation table obtained after one or more steps of traversing such table pointers.

On the other hand, for a tag-locating-address translation operation, the data-locating-first address 94 would be used to select a corresponding entry 102 from a stage-n tag translation table structure 100 separate from the stage-n data translation table structure 96. The stage-n tag translation table structure 100 is identified based on a second translation table base address TTBR tag separate from the first translation table base address TTBR data. The second translation table base address is stored in a second translation table base address register separate from the first translation table base address register. Based on the access to the selected tag-address-mapping translation table entry 102 from the stage-n tag translation table structure, a corresponding tag-locating second address 106 in the second address space 92 is determined (again, while a single level of table 100 is shown in Figure 14 for the tag translation, it will be appreciated that some examples may traverse two or more levels of translation table before obtaining the mapping to the tag-locating second address 106).

Hence, in the example of Figure 14 there is no need to apply any special “data-to-tag” address manipulation or transformation to the data-locating first address prior to performing TLB or translation table lookups. The same data-locating first address is used as the input to the TLB or translation table lookup process, but is used to select from distinct translation table structures accessed by different base addresses for data and tag accesses respectively.

Figure 15 illustrates steps for performing a tag translation for tag-accessing instruction, based on the example of Figure 14. Steps 1500 to 1504 are the same as steps 1300 to 1304 of Figure 13.

If the first tag translation mode is the selected translation mode for the stage-n translation, then at step 1506, the MMU 6 obtains a stage-n translation table entry 98 corresponding to the data-locating first address 94 from a data translation table structure 96 identified based on a data translation table base address TTBR data. At step 1508, the MMU 6 translates the data-locating first address 94 of the first address space 90 to the data-locating second address 104 of the second address space 92, using address mapping information from the stage-n translation table entry obtained at step 1506. Step 1510 for obtaining the tag-locating physical address is the same as step 1308 of Figure 13.

If the second tag translation mode is the selected translation mode for the stage-n translation, then at step 1512, the MMU 6 obtains a stage-n translation table entry 102 corresponding to the data-locating first address 94 from a tag translation table structure 100 identified based on a tag translation table base address TTBR tag. At step 1514, the MMU 6 translates the data-locating first address 94 of the first address space 90 to the tag-locating second address 106 of the second address space 92, using address mapping information from the stage-n translation table entry obtained at step 1512. Step 1516 for obtaining the tag-locating physical address is the same as step 1312 of Figure 13.

Figure 16 illustrates a second example for locating different translation table entries for the same stage of address translation applied for data-access and tag-access translations respectively. In this example, the same translation table structure 1 12 (accessed via a base address TTBR shared between data and tag accesses) is used to provide address mappings for both data-locating address translations and tag-locating address translations. For data-locating address translations for a given (stage-n) stage of address translation from the first address space 90 to the second address space 92, the data-locating first address 1 10 in the first address space 90 is used to look up the stage-n translation table structure 112, to obtain a data-mapping translation table entry 1 16 which is used to identify the data-locating second address 120 in the second address space 92. Again, while not shown in Figure 16 for conciseness, it is possible that the information in the accessed data-mapping translation table entry 116 selected based on the data-locating first address 110 is a table pointer used to traverse one or more further levels of table before locating the mapping information specifying the data-locating second address 120.

On the other hand, for tag-locating-address translations, before looking up the common translation table structure 1 12 shared with data-locating address translations, the tag-locating address determination circuitry 10 applies a transformation function to the data-locating first address 110, to obtain a tag-locating first address 108. Note that this transformation is a transformation within the same (first) address space 90 (unlike the stages of address translation which translate from one address space to another). Examples of the transformation function are described later with respect to Figures 22 and 23. The transformed tag-locating first address 108 is used to lookup TLBs 8 or used as input to a page table walk process for traversing the stage-n translation table structure 1 12, so that the translated tag-locating second address 118 depends on a tag-mapping entry 114 of the stage-n translation table structure which can be different from the data-mapping entry 1 16 used for the data-locating address translation. Note that, while Figure 16 shows the different tag-mapping entry 1 14 and data-mapping entry 116 being separate in the first level of translation table looked up based on the tag-locating first address 108 and data- locating first address 110 respectively, in cases where the stage-n translation table structure 112 is implemented as a multi-level structure where each level of table is looked up based on a different portion of bits from the input address 108, 1 10, it might be that on some occasions the same entry of the first-level translation table may be used for both tag and data translations, and it may be the entries at a subsequent level of translation table that are selected differently for tag and data translations to eventually provide different translated second addresses 1 18, 120 for the allocation tag and data item respectively.

Figure 17 illustrates steps for performing a tag translation for a tag-accessing instruction, based on the example of Figure 16. Steps 1700 to 1704 are the same as steps 1300 to 1304 of Figure 13.

If the first tag translation mode is the selected translation mode for the stage-n translation, then at step 1706, the MMU 6 translates the data-locating first address 110 of the first address space 90 to a data-locating second address 120 of the second address space 92, using address mapping information from a stage-n translation table entry 1 16 selected from the stage-n translation table structure 1 12 based on the data-locating first address 1 10. Step 1708 for obtaining the tag-locating physical address depending on the data-locating second address is the same as step 1308 of Figure 13.

If the second tag translation mode is the selected translation mode for the stage-n translation, then at step 1710, the tag-locating address determination circuitry 10 obtains a taglocating first address 108 of the first address space 90 that corresponds to the data-locating first address 110 of the first address space 90. For example, the transformation from data-locating first address 1 10 to tag-locating first address 108 could be based on applying an offset selected based on the data-locating first address 110 to a tag storage region base address defining a location of a tag storage address region within the first address space 90. At step 1712, the MMU 6 translates the tag-locating first address 108 of the first address space 90 to a data-locating second address 1 18 of the second address space 92, using address mapping information from a stage-n translation table entry 114 selected from the stage-n translation table structure 1 12 based on the tag-locating first address 108. Step 1714 for obtaining the tag-locating physical address depending on the tag-locating second address is the same as step 1312 of Figure 13.

Figure 18 illustrates an example of a subset of control register state stored in registers 14, which is relevant to controlling tag-address-locating translation operations performed by the MMU 6 and data-access-to-tag checks performed by the data-access-to-tag checking circuitry 32. The registers 14 includes a set of control registers, separate from general purpose registers which are used to provide general purpose operands for instructions, which define architectural state which has specifically defined meaning in an instruction set architecture. For example, the control register state may be used to control an operating mode/state of the processor 2. The control register state may influence how instructions are processed by the processor 2.

For example, the execution circuitry 16 may support processing instructions in multiple exception levels associated with different levels of privilege. For example, the supported exception levels may include exception levels EL0 to EL3, where EL0 is the least privileged and EL3 is the most privileged, with exception level EL0 being for application-level program code, exception level EL1 being for operating-system-level program code, exception level EL2 being for hypervisor-level program code, and exception level EL3 being for secure supervisory code which carries out certain security management operations. It will be appreciated this is just one example of a possible privilege scheme, and other examples may have a different approach to designating different levels of privilege available in different operating states, but the subsequent examples are described with reference to this particular scheme.

In the register names shown in Figure 18, a register name with a suffix _ELy (where y =

1 , 2 or 3) denotes that the least privileged exception level allowed to update the architectural state in that register is exception level ELy, so attempts to write to the register from a less privileged exception level than ELy would cause a fault to be signalled (e.g. registers with suffix _EL2 can be written to from EL2 or EL3 but not from EL1 ). The registers shown with a suffix _ELx are banked registers for which multiple versions of the register can be provided corresponding to different exception levels (e.g. one version _EL2 is associated with the hypervisor-level exception level EL2 and another version _EL1 is associated with the operating-system level exception level).

Hence, in this example, the following set of control registers are provided, specifying the following items of control state information:

SCTLR2 ELx (a system control register, banked to provide separate versions of the register for

EL1 , EL2 and EL3 respectively - which register is used at a given time depends on whether the current exception level is EL1 , EL2 or EL3), which specifies:

• VTE: example of a first-stage tag-translation mode indicator, used for specifying whether virtual tagging (the use of the second tag translation mode for a stage 1 address translation) should be enabled or disabled. For example, VTE can be encoded as follows: o 0: virtual tagging is disabled; o 1 : virtual tagging is enabled.

(this encoding can be helpful for backwards compatibility with legacy code which may assume that a reserved bit of register SCTLR2 that has been reused to provide the VTE indicator would have a value of 0).

• nDGA: data-access-to-tag check enable indication, used for specifying whether a data- access-to-tag check (described further below) is enabled. For example, nDGA can be encoded as follows: o 0: data-access-to-tag check is enabled o 1 : data-access-to-tag check is disabled

(implementing nDGA with a negative encoding, with the check being disabled when the value of nDGA is 1 ) can be helpful for backwards compatibility with legacy code which may assume that a reserved bit of register SCTLR2 that has been reused to provide the nDGA indicator would have a value of 0, so it can be safer to consider the data-access- to-tag check enabled unless software aware of the data-access-to-tag check has explicitly chosen to disable it by setting nDGA to 1 ).

TCR2 ELx (a translation control register which is banked to provide separate versions associated with exception levels EL1 , EL2 and EL3 selected between depending on the current exception level), which specifies a number of items of tag table base address information VTB, VTBO, VTB1 , VGB for defining a base address of a tag region of address space, which is used for the transformation from data-locating first address 1 10 to tag-locating first address 108 as shown in Figure 16. The item VGB is provided only in the version of TCR2 EL2 associated with EL2 and is not provided for EL1 or EL3. Which item of tag table base address information is used for a given translation operation depends on which translation regime is in use and which stage of address translation is the given stage of address translation for which the second tag translation mode has been enabled:

• for stage 2 translations, if intermediate tagging (use of the second tag translation mode for stage 2 translations) has been enabled, the tag table base address is determined from VGB in register TCR2 EL2;

• for stage 1 translations in a translation regime which supports a single translatable address region (see Figure 20 below for more description of translatable address regions), if virtual tagging (use of the second tag translation mode for stage 1 translations) has been enabled, the tag table base address is determined from VTB in register TCR2_ELx, where ELx is the current exception level; and

• for stage 1 translations in a translation regime which supports two translatable address regions (again, see Figure 20 discussed below), if virtual tagging has been enabled, the tag table base address is determined from VTBO or VTB1 in register TCR2_ELx, where ELx is the current exception level, with VTBO being used if the most significant bit of the data-locating first address is 0 (i.e. the address is in translatable region 0) and VTB1 being used if the most significant bit of the data-locating first address is 1 (i.e. the address is in translatable region 1 ).

Regardless of which item of tag table base address information VTB, VTBO, VTB1 , VGB is used, the tag table base address can be encoded such that the tag table base address information specifies only a number of upper bits of an aligned base address (so that less significant bits which are all implicitly set to 0 for an aligned base address can be omitted from the stored register state).

HCR2 EL2 (or alternatively, VTCR EL2) a register used for storing hypervisor control information (or information set by a hypervisor for controlling virtualization of address translations). HCR2 EL2 or VTCR_EL2 specifies a second-stage tag translation control indicator IPMTE which indicates whether intermediate tagging (the use of the second tag translation mode for stage-2 translations) is enabled or disabled. IPMTE has the following encoding: o 0: intermediate tagging is disabled; o 1 : intermediate tagging is enabled.

(again, this encoding can be helpful for backwards compatibility as legacy code may assume the reserved bit reused to provide the IPMTE control may have a value of 0). TCR1 ELx (a translation control register banked to provide separate versions for EL1 EL2, EL3 respectively) - another register providing translation control information associated with exception level ELx. TCR1_ELx specifies information defining the size of each translatable address region:

• TOSZ: defines size of single translatable address region in a single-region translation regime or the size of translatable address region 0 in a two-region translation regime;

• T 1 SZ: defines size of the second translatable address region 1 in a two-region translatable region.

For example, TOSZ and T1 SZ may specify a value x such that the size of the corresponding translatable address region is 2^{(64 - x)} bytes.

TTBRs a number of translation table base address registers (TTBRs) for providing the base address of translation table structures. For data accesses, the TTBRs may specify multiple translation table base address registers, including for example:

- TTBR0_ELx (separate versions for EL1 , EL2, EL3 respectively): base address of translation table to be used for data accesses in a single-region translation regime or for data accesses in translatable region 0 of a double-region translation regime;

- TTBRI ELx (separate versions for EL1 and EL2 respectively): base address of translation table to be used for data accesses in translatable region 1 of a double-region translation regime.

For example, TTBR data in Figure 14 and TTBR in Figure 16 may be the address specified in the relevant one of TTBR0_ELx and TTBRI ELx selected based on (i) the current exception level, and (ii) whether a single- or double-translatable region translation regime is in operation (other control state not shown in Figure 18 may specify which translation regime is the current regime). For tag translations, if the approach shown in Figure 16 is used, then tag translations use the same translation table base address as the translation table base address used for data translations. However, if the approach shown in Figure 14 is used, then as shown by the dashed lines in Figure 18 the TTBRs may also include a number of further TTBRs to provide additional base addresses TTBR tag for the tag-translation table structures 100 corresponding to the data- translation table structures 96 referenced by the corresponding TTBRs used for data accesses. Hence, each TTBR may in this case have two versions: one for data accesses and one for tags.

It will be appreciated that the specific control registers provided and the particular layout of control state within those registers may vary considerably from one ISA to another. Hence, the particular allocation of items of control state to particular registers, or the features specifying whether given groups of control state are in a single register or spread across separate registers, is not particularly important and can be implemented in other ways. Similarly, it is not essential to provide banked versions of the same register associated with different exception levels and other examples could provide a single version of each item of architectural state (with software switching the value of the state when switching between one exception level and another). However, banked items of state for different exception level can be useful to reduce software overhead on taking exceptions and returning from exceptions.

Nevertheless, for controlling operations related to virtualized tagging support, in general it can be useful to provide:

- tag translation control information (e.g. the first-stage tag-translation mode indicator VTE and second-stage tag-translation mode indicator IPMTE) used to control whether to use the first or second tag translation mode for performing tag-locating-address translations at a given stage of address translation;

- data-access-to-tag check enable information (e.g. nDGA), which controls whether a data- access-to-tag check is enabled or disabled;

- information for defining the position and size of an allocation tag storage region in a first address space 90, which is useful for examples where the tag translation involves an address transformation applied to the data-locating first address 110 to generate the taglocating first address 108 as shown in Figure 16, and for determining in a data-access-to- tag check whether a data access has specified in an address in the tag storage region of the first address space; and/or

- in examples where tag translations use a further set of translation tables separate from the translation table used for data translations as shown in Figure 14, one or more additional base addresses for those translation table structures to be used for tag translations.

This information could be provided in a different format to that shown in Figure 18, but for the sake of example, subsequent description references the particular indicators shown in Figure 18.

Figure 19 illustrates operations for controlling, when a translation operation is to be performed in a two-stage address translation regime for obtaining the address of allocation tag(s) to be accessed by a tag accessing instruction, whether to perform a tag-address translation operation (corresponding to the second tag translation mode mentioned earlier) or a data-address translation operation (corresponding to the first tag translation mode) for obtaining the tag-locating second address in a given stage of address translation. Figure 19 shows this determination for both the stage-1 and stage-2 address translations.

At step 1900 the MMU 6 determines which class of instruction is executed to cause the tag-locating-address translation to be performed. For example, the tag accessing instruction being executed could be either:

- a tag-checked memory access instruction, which specifies a target data address identifying a given data item, and is requesting that a read/write memory access is made to the given data item itself and also that (if the target data address corresponds to a tagged memory region as discussed with reference to Figure 12) a tag check is performed using the corresponding allocation tag stored in the memory system and the address tag associated with the address operand of the instruction; - a (non-bulk) tag read/write instruction, which specifies a target data address identifying a block of one or more data items of a certain size (either just a single tag granule or data items corresponding to multiple tag granules), but does not require access to the data items themselves, but is instead requesting a read/write operation to be performed on the location(s) at which the allocation tag(s) corresponding to those data items are stored. Such an instruction can be used to set the tag values when allocating or deallocating regions of memory as shown in Figure 5. The non-bulk tag read/write instruction indirectly specifies the address of the tag(s) required to be read or written, by specifying the corresponding data item address. In the example of Figure 16, say, the non-bulk tag read/write instruction may specify as its target data address a virtual address corresponding to the data-locating first address 110 in the first address space 90, but may cause a memory access to be performed to the physical address corresponding to the tag-locating second address 1 18, rather than the physical address corresponding to the data-locating second address 120.

- a bulk tag read/write instruction, which is a special kind of tag read/write instruction which, rather than specifying the location of the tag indirectly by specifying the address of the corresponding data item, directly specifies the address of the tag itself. For example, with reference to Figure 16, say, the bulk tag read/write instruction may specify, as its target address, a virtual address corresponding to tag-locating first address 108 (e.g. if the stage of address translation shown in Figure 16 is stage-1 , the address operand of the bulk tag read/write instruction specifies tag-locating first address 108 as a virtual address, or if the stage shown in Figure 16 is stage-2, then the tag-locating first address 108 is the result of the stage-1 translation of the virtual address specified by the instruction). The translation of the tag-locating first address 108 as if it were a data address then causes a read/write access to be made to the physical address corresponding to the tag-locating second address 118 translated based on the tag mapping entry 114 in the stage-n translation. It can be useful to provide such bulk tag read/write instructions, which specify addresses of tags directly rather than indirectly via the data address, to simplify hypervisor management of a guest operating system’s stage- 1 translation tables.

If the current instruction for which a tag-locating-address translation is required is an instruction specifying the location of the tag by specifying a data address (e.g. is either a tag- checked memory access instruction, or a non-bulk-tag read/write instruction), then at step 1902 of Figure 19 the MMU 6 determines whether the first-stage tag translation mode indicator VTE corresponding to the current translation regime indicates that virtual tagging is enabled for the stage-1 address translation (e.g. VTE can be read from the relevant version of register SCTLR2_ELx associated with the current exception level ELx, if multiple banked versions of VTE for different exception levels are supported). If virtual tagging is enabled for stage-1 translations for the current translation regime, then at step 1904, the MMU 6 applies the tag-address translation operation (e.g. according to the second tag translation mode shown in Figures 13, 15 or 17) for stage-1 translation of the data address specified by the tag-accessing instruction. At step 1906, the stage-2 translation is then performed according to a data-address translation operation (e.g. according to the first tag translation mode shown in Figures 13, 15 or 17). The combination of steps 1904, 1906 means that the overall two-stage address translation is performed as in the virtual tagging approach shown in Figure 10, with the stage-1 translation being the one that maps a virtual data address to separate data and tag addresses in the intermediate address space, which can then each further be translated to separate physical addresses in the stage-2 translation.

If either the first-stage tag translation mode indicator is determined to indicate that virtual tagging is disabled for the stage-1 translation (N at step 1902), or the instruction being executed to cause the tag access is a bulk tag read/write instruction specifying a tag address (rather than a data address), at step 1908 the data-address translation operation (i.e. the first tag translation mode shown in Figures 13, 15 or 17) is applied for the stage-1 address translation, so virtual tagging is disabled for stage 1 . At step 1910, the MMU 6 determines whether the second-stage tag translation mode indicator IPMTE stored in control register HCR2 EL2 or VTCR EL2 corresponding to the current translation regime indicates that intermediate tagging is enabled. If so, then at step 1912, the MMU 6 applies the tag-address translation operation (second tag translation mode shown in Figures 13, 15 or 17) when performing the stage 2 translation from intermediate address space to physical address space, and so intermediate tagging is applied as shown in Figure 1 1 , where the stage 1 translation translates the data and tag accesses in common from the virtual address space to the intermediate address space, but a given intermediate address IPA1 identifying the location of the data in the intermediate address space is mapped to a tag-locating physical PA2 identifying the location of the allocation tag separate from the physical address PA1 identifying the corresponding data item.

On the other hand, if the second-stage tag translation mode indicator checked at step 1910 identifies that intermediate tagging is disabled at stage 2, then at step 1906 the data-address translation operation (first tag translation mode) is also applied to stage 2, and so in this case the combination of steps 1908 and 1906 will be that both stages 1 and 2 use the data-address translation operation (first tag translation mode), and so a physical tagging approach such as the one shown in Figure 9 will be used, with both data and its associated allocation tag identified using the same physical address, and it being left to the memory system to locate the storage location of the tag based on the data-locating physical address.

As noted above with respect to Figure 16, some implementations of the tag-locating- address translation operation (second tag translation mode) may include a step where the taglocating address determination circuitry 10 determines, based on the data-locating first address 110 identifying the location of a given data item in the first address space 90, a tag-locating first address 108 which identifies the location of a corresponding allocation tag in the first address space 90, before then applying a given stage of address translation to translate the tag-locating first address 108 into a tag-locating second address 118 in a second address space 92. Any mapping function may be used to derive the tag-locating first address 108 from the data-locating first address 1 10. For example, a data-to-tag address mapping table may be maintained in memory by software, to specify mappings between data-locating first addresses 1 10 and corresponding tag-locating first addresses 108. For example, a further base register may be provided in the control registers of the ISA, to store a base address used to access the data-to- tag address mapping table. This approach may offer greater flexibility in the locations within the first address space 90 designated for storing tags, but may increase overheads for software in setting the data-to-tag address mappings and for hardware, incurring additional latency in accessing the data-to-tag address mapping table. Another approach could be that each data- locating first address may have a one-to-one fixed mapping with a corresponding tag-locating first address (with a fixed mapping function constraining that mapping, such as that each tag-locating first address is at a certain offset from the corresponding data-locating first address). However, without the ability for software to vary the mapping between the data-locating first address 1 10 and the tag-locating first address 108, this might unacceptably constrain the locations at which data items can be placed within the first address space 90, causing greater burden in adjusting the regions of address space used by data for other purposes.

Figures 20 to 23 illustrate an approach for performing a tag-locating address determination operation, which balances flexibility for software to vary the addresses allocated in the first address space 90 for storing allocation tags with a simpler and more performance-efficient operation to perform in hardware.

As shown in Figure 20, a given translation regime may restrict valid data addresses to being located in one of a limited number of translatable address regions. Figure 20 shows an example with a single translatable address region (left hand side of Figure 20) and an example with two translatable address regions (right hand side of Figure 20). Attempts to access data using an address in an untranslatable address region (outside any of the translatable address regions) may cause a memory fault to be signalled. This approach can be useful because, while address operands in a 64-bit instruction set architecture may theoretically be able to address 2⁶⁴ distinct bytes of address space, in practice current usage requirements do not require that much addressable memory capacity, and so in practice a smaller number of bits may be sufficient to support the number of addressable locations required. For example, the size of the translatable region might be restricted to 2⁴⁸ , 2⁵³, or 2⁵⁶ bytes of address space, to pick some arbitrary examples. By leaving some untranslatable regions which do not support any valid address being specified in that region, this has several advantages. Firstly, this means there is no need for the software setting the address translation mappings to provide any valid address mappings corresponding to the untranslatable regions, which reduces the burden of maintaining the translation table structures. Also, having some unused bits at the top of a larger (e.g. 64-bit) address operand leaves some space for encoding other information in address operands, such as the address tag 80 shown in Figure 4.

As shown in the left hand example of Figure 20, for a translation regime using a single translatable region 200 for the first address space 90, that region may cover 2’ bytes of address space, extending from address 0 to address 2’ - 1 , where t is the translatable region size determined from the region size indicating value T0SZ from register TCR1_ELx as described above (again, there could be more than one version of the T0SZ parameter corresponding to different exception levels, with the particular region size for the current translation regime depending on the current exception level).

To accommodate tag-locating addresses for locating allocation tags within the first address space, a tag table address region 202 is defined within the translatable address region 200. The size of the tag table address region 202 scales with the size of the translatable region 200, depending on the size of the allocation tag in comparison to the size of the corresponding block of data which is associated with that allocation tag. In general, if 2ⁿ bytes of data items share the one or more allocation tags stored in a single byte of address space, then the tag table address region is 1/2ⁿ times the size of the translatable region 200. For example, if an allocation tag is assigned to each 16 byte block of data and two 4-bit allocation tags fit in one byte of address space, then 32 bytes of data share 1 byte’s worth of allocation tags, so n = 5. This means that the size of the tag table address region 202 would be 1/32^th of the size of the translation region 200. To support an efficient tag address determination operation, it can be simplest for the tag table base address identifying the start of the tag table address region to be a naturally aligned address boundary, aligned to a boundary at intervals of the size of the tag table address region (i.e. at intervals of 2^{(t n)}, where 2’ is the size of the translatable address region and 2ⁿ is the ratio between the tag table address region size and the translatable address region size). This means that there are a maximum of 2ⁿ different aligned locations at which the tag table address region 202 could be located within the translatable region 200, so the location of the tag table address region 202 can be expressed by an n-bit tag table base address value VTB, VGB as shown in Figure 18. In the example of Figure 22, n = 5. By using an aligned tag table base address, the operations for combining the base address with an offset do not require an addition, but can be carried out simply by concatenating the base address with the offset, which is much faster for hardware to carry out than an addition and consumes less power.

As shown in the right-hand example of Figure 20, for a translation regime using two translatable address regions 206, 204, there is a lower translatable region (region 0) 206 of size 2^t0, where tO is the region size for translatable region 0 as defined using the region size indicating value T0SZ from register TCR1_ELx selected based on the current exception level ELx. Translatable region 0 (206) extends from address 0 to address 2^t0 - 1 and, in an address with 64 bits [63:0], bits [63:t0] are constrained to be all 0 for valid addresses in translatable region 206. There is also an upper translatable region (region 1 ) 204 of size 2^t1, where t1 is the region size for translatable region 1 as defined using the region size indicating value T1 SZ from register TCR1_ELx selected based on the current exception level ELx. Translatable region 1 (204) extends from address 2⁶⁴ - 2^t1 to address 2⁶⁴-1 and, in an address with 64 bits [63:0], bits [63:t1 ] are constrained to be all 1 for valid addresses in translatable region 206. This leaves a large untranslatable address region extending from address 2^t0to address 2⁶⁴ - 2^t1 - 1 free as encoding space used for other purposes, including support for defining address tags 80 with values other than all 0s or all 1 s in the upper bits [63:t0] or [63:t1] not used to distinguish valid addresses in one of the translatable address regions 206, 204. The translatable region sizes to, t1 can be different to each other - e.g. the upper translatable region 204 could be smaller or larger than the lower translatable region 206. Support for two translatable regions can be useful to help isolate data in a kernel region of address space used by operating systems (which may use the upper translatable region 204) from data in a user region of address space used by application code (which may use the lower translatable region 206), since this makes it less likely that an address pointer computed by user code accidentally points to a location in the kernel region of address space 204.

When two translatable address regions 204, 206 are supported, then each of those regions may have its own corresponding tag table address region 208, 210 designated for storing the allocation tags for corresponding data items in that translatable address region 204, 206. As in the approach with a single translatable region, the ratio between the size of a given translatable regions 204, 206 and the size of the corresponding tag table address region 208, 210 may be fixed, depending on the size of the allocation tag and the number of bytes of data that share one allocation tag, and so the size of the tag table address region 208, 210 scales with the size of the corresponding translatable address region 204, 206 defined by T0SZ or T1 SZ. The location of the tag table address region 208, 210 in a given translatable address region 204, 206 depends on a corresponding item of tag table base address information VTB1 (for translatable region 1 204) or VTB0 (for translatable region 0 206) stored in register TCR2_ELx for the current exception level ELx. The tag table base addresses VTB0, VTB1 are defined independently for the two translatable regions 204, 206, so the relative position within the translatable region of the tag table address region can be different for the two translatable regions 204, 206.

Figure 21 illustrates an example of the tag-locating address determining circuitry 10 performing a tag-locating address determination operation for a tag-accessing instruction requiring the tag-locating address translation operation to be performed. The tag-locating address determination operation acts on a given data-locating first address 1 10 which is either equal to, or depends on a virtual address specified by the tag-accessing instruction (e.g. having been obtained in an earlier stage of address translation applied to that virtual address).

At step 2100, the tag access is determined to be required, based on execution of the tagaccessing instruction. In response, at step 2102, the MMU 6 determines whether a virtualized tag translation mode (e.g. the second tag translation mode described above) is currently enabled (e.g. based on the control state VTE or IPMTE associated with the current stage of address translation for the current translation regime). If a virtualized tag translation mode is currently disabled for the current stage of address translation, there is no need to map a data-locating- address to a tag-locating address within the first address space, and so at step 2110 the address of the tag within the second address space 92 is performed based on translating the data-locating first address 1 10. If virtualized tag translation is enabled for the current stage of address translation, then at step 2104 the MMU 6 determines whether the data-locating first address 110 is a valid address within the range of any translatable address region 200, 204, 206 supported in the current translation regime. If not, then a fault is signalled at step 2106, to prevent uncertain results caused by triggering a tag access corresponding to an untranslatable address. If the data- locating first address 1 10 is in a translatable address region 200, 204, 206, then at step 2108 the tag-locating first address 108 is determined by applying an offset, determined based on a predetermined portion of the data-locating first address, to the tag table base address represented by tag table base address information VTB, VTB0, VTB1 , VGB. The tag table base address is determined based on VTB for a single-translatable-region stage-1 translation, based on VGB for a stage-2 translation, based on VTB0 for a two-translatable-region stage 1 translation where the data-locating address is in translatable region 0 (206), and based on VTB1 for a two-translatable- region stage 1 translation where the data-locating address is in translatable region 1 (204). Also, at step 2108 the tag-locating address determining circuitry 10 identifies, based on one or more bits of the data-locating first address 110 which are less significant than (but contiguous with) the portion used to derive the offset, nibble selection information which can be used to select between two or more allocation tags within the same byte of address space.

Figure 22 illustrates the tag-locating address determining operation at step 2108 for a single-region translation regime, either for a stage 1 or stage 2 translation. Here, 2’ is the configurable translation region size defined by T0SZ and this example assumes that the tag table base address “table base” is defined by a 5 bit field VTB (for stage 1) or VGB (for stage 2) in system register, and so this example assumes the ratio between the translatable region size and tag table region size is 32 (2⁵). For ease of explanation, Figure 22 is shown applied to a virtual address as the data-locating first address 1 10, but the same operation can be performed for stage 2 translations where the data-locating first address 1 10 would be an intermediate address and, other than taking a different tag table base address value VGB instead of VTB (and in some examples a different size parameter defining the size 2’ of the translatable address region for Figure 22), the tag-locating address determining operation can be the same as for stage 1 .

As shown in Figure 22, for a single translatable region of size 2’, the data-locating first address 110 can be considered to comprise meaningful address bits [t-1 :0] equal to a given address value, and upper bits [55:t] which are constrained to be 0 for valid addresses (this example assumes there are no meaningful bits of the address above bit [55], since bits [56] onwards may be reserved for other purposes such as storing the address tag 80). As shown in the portion of Figure 22 marked 110’, the same address 110 can be interpreted, for the purposes of generating the tag-locating first address 108, as containing a tag index value at bits [t-1 :5] which denotes the offset relative to the tag table base address (the offset being the indication of which particular address within the tag table address region 202 should be the tag-locating first address 108 for this particular access). The offset corresponds to the part of the address which identifies which of a number of distinct tag granules the address 110 falls into, where a tag granule is a block of address space for which all addresses in the block share the same allocation tag 72 stored in the memory system.

Hence, when generating a corresponding tag-locating first address 108, bits [t-6:0] are set based on the tag index value from bits [t-1 :5] of the data-locating first address 1 10. Effectively, an arithmetic right shift (in this example, by 5 bits) is performed, although in practice no shifting logic is required as the tag-locating first address 108 can be formed simply by concatenating bit values in the appropriate bit positions. Bits [t-1 :t-5] of the tag-locating first address 108 are set equal to the corresponding bits of the 5-bit table base address identifying value VTB (for stage 1 ) or VGB (for stage 2). Hence, by defining the base address as an address naturally aligned to a 2’ address boundary, this eliminates any need to add an offset (“tag index”) to the base address when computing the tag-locating first address 108. Upper bits [55:t] remain all 0 in the tag-locating first address 108, so that the tag table is fully within the translatable address region 200.

The nibble selection information 220 is generated equal to bit [4] of the data-locating first address 1 10. This reflects that, in this particular example, as shown in Figure 10, with 4-bit tags and 8-bit addressable locations, each byte-addressable location stores two tags, requiring only a single bit of state to select which of the two allocation tags returned from a given byte memory is the tag associated with the data item identified by the data-locating first address 1 10. However, other examples could have a different number of allocation tags per byte of the tag address storage region, and so if there are more than two allocation tags per byte then more than one nibble selection bit could be used, which would be the next least significant one or more bits after the least significant bit used for the tag index (offset).

Figure 23 shows a similar operation for a stage-1 translation performed in a translation regime with two translatable address regions 204, 206. The principle is the same as in Figure 22, with the tag-locating first address 108 being determined as an offset relative to a base address, with the offset being determined from bits [t-1 : 5] of the data-locating first address 110. However, in Figure 23 the translatable region size t and tag table base address (“table base[s]”) differs depending on whether the data-locating first address 110 is in the upper translatable address region 204 or lower translatable address region 206. If the data-locating first address 1 10 has a most significant bit [55] equal to s=0, then the address 1 10 is in the lower translatable address region 206, the translatable region size t = tO is determined from control state T0SZ and the tag table base address (the value to specify in bits [t0-1 :t0-5] of the tag-locating first address 108) is determined from VTB0. If the data-locating first address 1 10 has a most significant bit [55] equal to s=1 , then the address 110 is in the upper translatable address region 204, the translatable region size t = t1 is determined from control state T 1 SZ and the tag table base address (value to specify in bits [t1 -1 :t1-5] of the tag-locating first address 108) is determined from VTB1. Other than considering different region sizes and tag table base addresses depending on whether the upper bit [55] is 0 or 1 , the tag-locating first address 108 and nibble selection information 220 are determined in a similar way to Figure 22.

While the examples of Figures 22 and 23 are based on a fixed ratio of 1/32 between the size of the tag table address region 202, 208, 210 and the size of the corresponding translatable address region 200, 204, 206, and hence a fixed 5-bit size of the tag table base address value injected at bits [t-1 :t-5] of the tag-locating first address 108, other examples might support variable allocation tag size or variable size of the granule of data items which share one allocation tag, in which case the bit positions marking the boundary of the table base address and tag table index shown in Figures 22 and 23 could vary.

In examples which support the tag-locating address determination for both stage 1 and stage 2 translations, the same hardware can be shared between both stages of address translation, since other than taking a different value for the translatable region size t and the table base address “table base”, the mapping functions are the same regardless of which stage of address translation the tag-locating address determination are applied. Hence, the tag-locating address determining circuitry 10 can be shared between a number of different translation regimes.

Figure 24 is a flow diagram setting out a particular example of steps for implementing tag address translations with support for variable tag translation modes (enabling/disabling of virtualized tagging at first and second stages of address translation). It will be appreciated that Figure 24 is a specific implementation of some of the features described more generically above, and so there are also other ways of implementing similar functionality.

At step 2400, a tag-accessing instruction is executed. The tag-accessing instruction may be any instruction which could (at least for some settings of control state information and/or memory attribute information in translation table addresses) trigger an operation to be performed using one or more allocation tags stored in memory. The tag-accessing instruction specifies a target address.

At step 2402, the MMU 6 determines whether stage-1 address translation is currently enabled. There may be some address translation regimes where it is possible to disable stage- 1 translations and perform translation using stage 2 only, to translate an intermediate address specified using an operand of the tag-accessing instruction to a physical address (as noted below, there can also be regimes where stage-2 translations are disabled, so that either only stage-1 is used, or for certain most secure code operating in the hypervisor exception level or a more privileged exception level the code may be allowed to specify physical addresses directly without any stage of address translation). For example, control state (restricted to being updatable by software having a hypervisor-level privilege or higher) may be used to indicate whether stage-1 translations and/or stage-2 translations are currently enabled.

If stage-1 address translation is determined to be enabled, then at step 2404 the MMU 6 determines whether virtual tagging (denoted as VMTE for conciseness) is enabled for stage-1 translations (e.g. this may be determined based on the first-stage tag translation control indicator VTE described above). Also, the MMU 6 determines whether the current tag-accessing instruction is a bulk tag read/write instruction. If virtual tagging is currently disabled or the current tag-accessing instruction is a bulk tag read/write instruction, then there is no need to apply any special tag-address translation operation distinct from the data-address translation operation for stage-1 translations. Instead, at step 2406 the data-address translation operation is applied for stage- 1 to translate the virtual address (data-locating first address VA) specified as the target address of the tag-accessing instruction to a corresponding data-locating intermediate address in the intermediate address space 46. This data-address translation operation is the same as what would be carried out for locating the intermediate address of the data item corresponding to the required allocation tag(s).

As well as obtaining the data-locating intermediate address, the stage-1 address translation also identifies memory attribute information defined directly or indirectly using a page descriptor 60 from the stage-1 address translation tables, which provides an indication of whether the memory region associated with the data-locating first address is in a tagged or untagged region of memory as described earlier. The tagged/untagged status can be inferred from other memory permission information such as whether the address is in a normal writeback cacheable region of memory. In some examples, a further option may be supported for memory regions, to regard the region as a “canonical tagged” region, which is a region for which, although there are no explicitly stored allocation tags for data items in that region of address space, in a two- translatable-region translation regime, tag checks can be performed assuming that the allocation tag 72 has all bits set to 0 for accesses to an address in a lower translatable region 206 and that the allocation tag has all bits set to 1 for accesses to an address in an upper translatable region 204. Such a canonical tag can be useful to match with the expected values of upper address bits in addresses set “canonically” for the lower/upper translatable regions 206, 204 respectively. In some examples, the canonical tag option could be a separate attribute type, distinct from tagged and untagged regions of memory. However, in other examples, the attribute information itself might merely distinguish tagged regions from untagged regions, with a control value stored in a control register indicating whether, in a current mode of operation, untagged memory regions should be regarded as truly “untagged” (with no tag value at all), or “canonical tagged” (with implied allocation tags having all bits set corresponding to the most significant bit of the target address). If stage-1 translation is currently disabled at step 2402, then no memory attribute information is available from stage-1 , and so the tag access may be processed by default as if the stage-1 memory attribute information specifies a tagged memory region. If the stage-1 translation was disabled at step 2402, then steps 2404 and 2406 can be omitted and the method proceeds straight to step 2408.

In the case where either stage-1 translation is disabled or stage-1 translation is performed at step 2406 for a bulk tag read/write instruction or for another tag accessing instruction where virtual tagging was disabled, at step 2408 the MMU 6 determines whether stage 2 translation is enabled.

If stage-2 translation is enabled, then at step 2430 the MMU 6 determines whether the memory region type determined from stage-1 is a tagged region (either based on stage-1 memory attribute information, or based on the default determination of “tagged” region type if stage-1 translation is disabled) and whether intermediate tagging is enabled for stage-2 translations (e.g. this may be determined based on the second-stage tag translation control indicator IPMTE described above).

If the access memory region is not a tagged region or intermediate tagging is disabled, then at step 2412 the MMU 6 performs the stage-2 address translation of a target intermediate address (either the target address of the tag accessing instruction itself, if stage 1 translation is disabled, or the address obtained by the stage 1 translation at step 2406) to a corresponding physical address, based on a corresponding entry of stage-2 address translation tables 50. In this case, as neither stage 1 nor stage 2 have used the virtualized tagging approach (VMTE or IPMTE enabled), the physical tagging approach shown in Figure 9 is being used.

If stage-2 translation is disabled for the current translation regime, steps 2430 and 2412 are omitted.

At steps 2414, 2416, different outcomes are possible depending on the memory region type being accessed. If the accessed memory region type is a canonical address region (no at step 214, yes at step 2416), then at step 2418 a canonical tag value is returned by the MMU 6 (based on implicitly setting the allocation tag bits to all 0s if the access is to an address in the lower translatable address region 206 and all 1s if the access is to an address in the upper translatable address region 204), without requiring any explicit request to be sent to the memory system to obtain the canonical allocation tag values. On the other hand, if the region is untagged (no at both steps 2414, 2416), the tag access may effectively be not performed, as at step 2420 any read request to the allocation tag returns a default value of 0 (read as zero - RAZ) and any write request to the allocation tag is ignored (write ignore - Wl), without generating any fault. However, if the access is to an address identified as being a tagged region (e.g. based on the memory attributes associated with the data-locating first address), then at step 2422 a request is sent to the memory system specifying the data-locating physical address obtained from the stage- 1 and/or stage-2 translations (or based on the physical address specified by the tag accessing instruction itself if both stage-1 and stage-2 were disabled), and requesting return of the allocation tag corresponding to that address. Assuming that no error occurs with that tag access request, then at step 2424 a “physical tag” is returned by the memory system, located based on an implementation-specific mechanism implemented by the memory system according to the physical tagging approach as explained with reference to Figure 9 above. If an error occurs with the tag access request specifying the data-locating physical address (e.g. the memory system cannot locate an allocation tag corresponding to this physical address) then at step 2426 a fault is signalled.

If, at step 2430, it was determined that the target address of the tag accessing instruction corresponds to a tagged memory region and that intermediate tagging is enabled using the IPMTE control described earlier, then at step 2432 the tag-locating address determining operation described with reference to Figures 16-17 and 20 to 23 is applied to transform the data-locating intermediate address obtained in the stage-1 translation 2406 (or specified directly by the tag accessing instruction if stage-1 translation was disabled) into a corresponding tag-locating intermediate address, and that tag-locating intermediate address is then translated to a taglocating physical address by performing a stage-2 address translation at step 2434.

At step 2436, an additional check is performed using stage-2 memory attribute information defined directly or indirectly using the relevant stage-2 translation table entry used to provide the address mapping in the stage-2 translation performed at step 2434. As the tag-locating intermediate address has been modified relative to the corresponding data-locating intermediate address, the tag-locating intermediate address might be associated with a different stage-2 memory attributes compared to a corresponding data-locating intermediate address, so an additional check of whether the tag-locating intermediate address corresponds to a “normal” address region is performed, to avoid possible side-effects by requesting an allocation tag access to a Device type memory region. Hence, if the stage-2 attributes for the tag-locating intermediate address specify that this address is in a normal region of memory, then at step 2438 a memory request specifying the tag-locating physical address is sent to the memory system to request read/write access to the corresponding allocation tag(s), which are implemented as virtualized tags as there is no need for the physical memory system to have any awareness that allocation tags are supported (based on intermediate tagging as shown in Figure 1 1 ). If the stage-2 memory attributes indicate that the tag-locating intermediate address corresponds to a Device-type memory region then at step 2440 no tag-accessing memory system request is sent to the memory system, to avoid side-effects being caused for Device memory regions, and at step 2440 the tag access operation returns an allocation tag value of 0 (read as zero, RAZ) if the tag access is a read operation and is ignored (write ignore, Wl) if the tag accesses a write operation.

Returning to step 2404, if it was determined that virtual tagging (VMTE) is enabled for the stage-1 translation, then at step 2440 the tag-locating address determination operation is applied to the data-locating virtual address specified as the target address of the tag accessing instruction, to obtain a corresponding tag-locating virtual address which is translated in a stage-1 translation at step 2442, and if stage-2 translations are enabled (yes at step 2444) the tag-locating intermediate address generated by the stage-1 translation is further translated into a tag-locating physical address by a stage-2 translation performed at step 2446. If stage-2 translations are disabled (no at step 2444) then step 2446 is omitted and the result of the stage- 1 translation is already a tag-locating physical address. Either way, at step 2448 there is a similar check of any stage-2 memory region attributes obtained in the stage-2 translation to the check described at step 2436, and if the stage-2 attributes indicate that the tag-locating intermediate address is in a device memory region (no at step 2448) then the tag read/write request is treated as RAZ/WI, while if the tag-locating intermediate address is in a Normal memory region (yes at step 2448) then a memory system request is issued to the memory system specifying the tag -locating physical address obtained at step 2442 or 2446 to request a read/write operation to be performed on the allocation tags associated with the physical address (if stage-2 translations are disabled at step 2444 then step 2450 is similarly performed as if the stage-2 permissions had indicated a normal address region). Hence, if step 2450 is performed then the allocation tags are implemented as virtualized tags based on virtual tagging as shown in Figure 10, having separate addresses allocated in the virtual address space for the allocation tags separate from the virtual addresses of the corresponding data items.

As shown in the annotations regarding read permission checks shown in Figure 24, for cases where the tag accessing instruction is a tag-checked memory access instruction, whether any read permission check is required for tag read operations can vary depending on whether virtualized tagging is enabled for either stage-1 or stage-2 translations. If a physical tagging approach is taken (and so virtualized tagging is determined to be disabled at both steps 2404 and 2430), then there is no need for any specific read permissions check for a tag read, because it may be assumed that any violation of read permissions would be detected when a corresponding access is made to the data item which shares the same physical address as the corresponding allocation tags. If the intermediate tagging approach is taken (yes at step 2430), then no specific additional read permissions check is performed at stage 1 translations for a tag access, because that translation is in common with the corresponding stage 1 translation performed for a corresponding data item access, but for the stage 2 translation at step 2434 a further read permissions check is performed to check whether the stage-2 memory permissions indicated directly or indirectly by the stage-2 translation table entry corresponding to the tag-locating intermediate address obtained at step 2432 indicate that there is permission to read the tags at the corresponding intermediate address (as this stage-2 translation table entry may be different to the stage-2 translation table entry corresponding to the data-locating intermediate address, it is possible that there could be permission to read the data item but not the corresponding tag). Similarly, if the virtual tagging approach is taken (yes at step 2404), then for a tag read for a tag- checked memory access instruction, a read permissions check is performed at step 2442, based on stage-1 read permission information obtained directly or indirectly from the stage-1 translation table entry corresponding to the tag-locating virtual address (modified VA of Figure 10), and a stage-2 read permissions check is performed at step 2446, based on stage-2 attributes specified directly or indirectly by the stage-2 translation table entry corresponding to the tag-locating intermediate address (IPA2 in Figure 10). If any of the additional read permissions checks for tag reads performed at steps 2434, 2442, 2446 indicates that there is no read permission to the tags, a fault is signalled.

On the other hand, for tag read/write instructions (where there would be no corresponding data item access), each of the address translation steps 2406, 2412, 2434, 2442, 2446 may include a corresponding check of read/write permissions from the corresponding translation table entry used for the translation, to check whether there is permission to read or write the tags, and a fault may be signalled if the read/write permissions are violated by the tag access request.

Figures 25 to 28 provide a summary of different options supported for data and tag translations.

Figure 25 shows an example where physical tagging is used, so that both data accesses and tag accesses use the same translation mappings at both stage 1 and stage 2 of the two- stage address translation, to obtain a physical address locating both the data item and its corresponding allocation tag within the physical address space 52. This approach is selected if the first-stage tag translation control information VTE indicates virtual tagging is disabled and the second-stage tag translation control information IPMTE indicates intermediate tagging is also disabled.

Figure 26 shows an example where the first-stage tag translation control information VTE indicates virtual tagging is disabled and the second-stage tag translation control information IPMTE indicates intermediate tagging is enabled. This corresponds to the intermediate tagging approach shown in Figure 1 1. In this case, for tag or data accesses based on instructions specifying a given data virtual address VA, the stage-1 translation is the same for both tag and data accesses and translates the data virtual address VA to the same data-locating intermediate address I PA for both tag and data accesses, but for data accesses the stage 2 translation maps the data-locating intermediate address to a data-locating physical address while for tag accesses the tag-locating address determining circuitry 10 transforms the data-locating intermediate address into a tag-locating intermediate address before the MMU 6 performs stage-2 translation of the tag-locating intermediate address to a tag-locating physical address separate from the data- locating physical address.

Figure 27 shows an example in which the first-stage tag transition control information VTE indicates that virtual tagging is enabled, and the second-stage tag translation control information IPMTE indicates intermediate tagging is disabled. In this case, for data accesses or tag accesses triggered by bulk tag read/write instructions (btag), the stage 1 and stage 2 translations are performed in the same way as in Figure 25 to translate the data address or the target address of the btag instruction into a physical address. Note that for btag instruction, it is expected that the instruction would specify a different virtual address to the virtual addresses used for data accesses (since the virtual address of the btag instruction would be within the tag table address region 202, 208, 210 rather than the rest of a translatable address region 200, 204, 206 as for data accesses), but from the point of view of address translation by the MMU 6 the translation for btag instructions is processed using the same translation process as for data accesses (albeit expected to be applied to a different input address). On the other hand, for non-bulk tag read/write instructions and for tag reads performed for tag checks for tag-checked memory access instructions, prior to stage 1 address translation the tag-locating address determining circuitry 10 transforms the data-locating virtual address specified by the instruction into a tag-locating virtual address, before stage- 1 and stage-2 address translation are performed to translate the taglocating virtual address IPA2 to a tag-locating physical address PA2 (nbtag PA).

Figure 28 shows an example in which the first-stage tag transition control information VTE indicates that virtual tagging is enabled, and the second-stage tag translation control information IPMTE indicates intermediate tagging is enabled. In this case, translations for data accesses and non-bulk tag accesses are the same as in Figure 27 (since even if IPMTE indicates intermediate tagging is enabled, the second stage of address translation still uses the first address translation mode if the second address translation mode has been enabled for the first stage of address translation - see steps 1902 to 1906 of Figure 19). However, for btag instructions, which by default are treated as if virtual tagging is disabled for stage 1 translations, then if IPMTE indicates intermediate tagging is enabled, the translations for btag instructions are performed as shown in Figure 26, not Figure 27. Hence, Figure 28 corresponds to the functionality from Figure 27 for data accesses and non-bulk tag accesses, and the functionality of Figure 26 for btag accesses.

As shown in Figures 26 to 28, when virtualized tagging is enabled at either stage 1 or stage 2, it is possible that a memory access instruction (other than the bulk or non-bulk tag read/write instructions) could specify, as its target address intended for defining the location of a given data item to be accessed by the memory access instruction, a virtual address which actually corresponds to a virtual address or intermediate address in the tag table address region 202, 208, 210 designated for storing allocation tags. This is denoted as “data2” in Figures 26 to 28 and corresponds to a data-access-to-tag operation.

This data-access-to-tag operation will be explained in further detail with reference to figure 29. As shown, a region of address space is designated as an allocation tag memory address region 240 (which may correspond to tag table address region 202, 208, 210). The address space may be a virtual address space or an intermediate virtual address space (i.e. depending on the stage of translation, stage-1 or stage-2). Tag Z 242 is stored within the allocation tag memory address region 240. Also stored within the address space but external to the allocation tag memory address region 240 is data Z 244 (i.e. a data item). Tag Z 242 corresponds to the allocation tag associated with data Z, and used in a tag check performed if required when a data access to data Z 242 is requested.

A tag-checked load or store operation (LDR/STR) may be requested, and using techniques described above, a target data address based on the address operand of the LDR/STR may be determined. A target tag address may also be derived from the target data address of the LDR/STR. As shown in figure 29, the target data address corresponds to the location in the address space storing data Z 244, and the target tag address corresponds to the location in the address space storing tag Z 242. Using tag Z 242, and an address tag derived from an address operand of the tag-checked load or store operation, a tag-check may be performed for the load or store operation. An example of a tag check operation is described with reference to figure 4.

Alternatively, rather than a tag-checked load or store operation, a tag access instruction may be requested (LDG(M)/STG(M, where LDG and STG denote the non-bulk tag read and write instructions respectively, and LDGM and STGM denote the bulk tag read and write instructions respectively)). In this case, there would be no data access to data Z 244. Instead, the target tag address would be derived from the target data address of the tag access instruction, and tag Z 242 may be accessed using this target tag address.

However, separately, a load or store operation LDR/STR may specify an address operand which corresponds to a data address in a tag region. As shown, the load or store operation may specify an address operand that corresponds to the data address in the allocation tag memory address region 240 where the tag Z 242 is stored. The address operand of this load or store operation could have been intended to define a location of a given data item in the address space to be accessed by the load or store instruction. That is to say, the load or store operation may be a memory access operation intending to access a data item located in the address space rather than an allocation tag. However, as a result of storing allocation tags in a separate region of a virtual/intermediate physical address space (i.e. the allocation tag memory address region 240), it is possible that the load or store operation may inadvertently (or intentionally if being used by an attacker as part of a potential exploit), instead specify a virtual address or intermediate address in the allocation tag memory address region 240. This is a so-called data-access-to-tag operation.

By providing architectural support to deny read or write access to a data value (i.e. tag Z 242) stored at a memory address in the allocation tag memory address region 240 in response to determining that a data memory access (i.e. the data-access-to-tag operation) request specifies a target address corresponding to a memory address in the allocation tag memory address region, inadvertent or intentional access to allocation tags using data memory access requests (i.e. load or stores) may be prevented.

Referring again to figure 1 , apparatus 2 includes data-access-to-tag checking circuitry 32 for performing a data-access-to-tag check, such as that shown in figures 30 and 31. The data- access-to-tag check will be explained in further detail with reference to figure 30.

At step 3000, a data memory access request that specifies a target address is executed. The data memory access request may be a load or store request, for example (e.g. a load/store request triggered by a general purpose load/store instruction LDR/STR, having a different encoding (e.g. different opcode) from the special tag read/write instructions LDG, STG, LDGM, STGM described earlier). As explained in reference to the figure 29, the data memory access request may be a data-access-to-tag memory access operation, i.e. the data memory access request may be a load or store operation that specifies an address operand corresponding to an address in a region of memory designated as storing allocation tags.

At step 3002, it is determined whether the data memory access request specifies a target address corresponding to a memory address in an allocation tag memory address region designated for storing allocation tags. This determination is based on memory address region defining information that defines an allocation tag memory address region designated for storing allocation tags. As shown in figure 29, the allocation tag memory address region may be in an address space other than a physical address space, such as a virtual address space or an intermediate physical address space.

The memory address region defining information may include memory address region defining configuration information defining a variable location of the allocation tag memory address region in an address space. In some examples, the memory address region defining configuration information includes at least one of: information indicating a tag table base address; and information indicating a table size. In some examples, the tag table base address is indicative of a position of a tag table region designated within the address space for storing allocation tags, and may correspond to the tag table region discussed above. For example, the memory address region defining information can be the tag table base address information VTB, VTBO, VTB1 or VGB described earlier with respect to Figure 18.

At step 3004, if it is determined that the data memory access request specifies a target address corresponding to a memory address in an allocation tag memory address region designated for storing allocation tags, read or write access to a data value stored at the memory address in the allocation tag memory address region is denied.

Denying read or write access may include triggering a fault, for example generating a fault signal indicating that read or write access has been denied. Denying read access may include reading the data value stored at the memory address as zeroes. In some examples, the data value is not read but rather zeroes are returned when a read access is requested. Denying write access may include ignoring the write access request, i.e. not performing the requested write access.

At step 3006, if it is determined that the data memory access request does not specify a target address corresponding to a memory address in an allocation tag memory address region designated for storing allocation tags, read or write access to a data value stored at the memory address in the allocation tag memory address region is permitted. In some examples, permitting the read or write access may include performing the read or write access to the data value. In other examples, permitting read or write access includes not denying read or write access by the data-access-to-tag checking circuitry. However, in these examples, the read or write access may not be performed for one or more other reasons. That is to say, in some examples, just because the read or write access has not been denied by the data-access-to-tag checking circuitry does not necessarily mean that the read or write access is actually performed (e.g. the read/write access may fail other kinds of permissions checks applied by the MMU 6).

Another example data-access-to-tag check will now be described with reference to figure 31. At step 3100 a data memory access request specifies a target address. Step 3100 may correspond to step 3000 of figure 30. At step 3102, it is determined whether the data memory access request specifies a target address corresponding to a memory address in an allocation tag memory address region designated for storing allocation tags. Step 3102 may correspond to step 3002 of figure 30.

At step 3104, it is determined whether the data-access-to-tag check enable information indicates that the data-access-to-tag check is enabled for the data memory access request. The data-access-to-tag check enable information may identify whether the check is enabled for privileged data memory access requests.

In some examples, the data-access-to-tag check enable information identifies, independent of whether the check is enabled for privileged data memory access requests, whether the data-access-to-tag check is enabled for unprivileged data memory access requests.

The data-access-to-tag check enable information may, in some examples, identify whether the check is enabled for read memory access requests, and independently, whether the check is enabled for write memory access requests.

The data-access-to-tag check enable information may be prohibited from being updated by instructions executed with insufficient privilege. For example, unprivileged code may not be able to update the data-access-to-tag check enable information, whereas privileged code may be able to do so.

The data-access-to-tag check enable information may comprise a field in a control register. For example, referring to figure 18, a system control register, such as SCTLR2_ELx, may specify a data-access-to-tag check enable indication, nDGA, to specify whether a data- access-to-tag check is enabled. Separate read and write controls may be supported for specifying whether a data-access-to-tag check is enabled for read operations and separately for write operations. For example, a system control register, such as SCTLR2_ELx, may specify a read data-access-to-tag check enable indication, nDGAR, and a write data-access-to-tag check enable indication, nDGAW. Hence, in some examples, the read data-access-to-tag check enable indication and the write data-access-to-tag check enable indication may be stored in the same control register. In other examples, the read data-access-to-tag check enable indication may be stored in a different control register to the control register storing the write data-access-to-tag check enable indication.

In some examples, separate privileged and unprivileged data memory access controls may be supported for specifying whether a data-access-to-tag check is enabled for privileged data memory accesses and separately for unprivileged data memory accesses. For example, different registers, e.g. different banked versions of the system control register (such as SCTLR2_ELx discussed above), may specify different privileged/unprivileged versions of the data-access-to-tag check enable indication, nDGA. In some examples, the privileged data memory access data-access-to-tag check enable indication and the unprivileged data memory access data-access-to-tag check enable indication may be stored in the same control register.

Thus, in some implementations, to determine whether the data-access-to-tag check enable information indicates that the data-access-to-tag check is enabled for the data memory access request, a system control register may be checked to determine whether a data-access- to-tag check enable indication (such as nDGA, nDGAR, nDGAW) specifies whether a data- access-to-tag check is enabled for the data memory access request.

In some examples, the data-access-to-tag check enable information comprises range information defining at least one range of address space for which the data-access-to-tag check is enabled. Thus, in some examples, to determine whether the data-access-to-tag check enable information indicates that the data-access-to-tag check is enabled for the data memory access request, the address specified by the data memory access request may be compared to the at least one range of address space to determine whether the address specified by the data memory access request is an address in the at least one range of address space for which the data- access-to-tag check is enabled. It will be appreciated that the at least one range of address space may define at least one range of addresses in a virtual or intermediate physical address space, as well as a physical address space. In some examples, the data-access-to-tag check enable information may comprise separate range information for read and write operations. In some examples, the data-access-to-tag check enable information may comprise separate range information for privileged and unprivileged data memory access requests. Thus, in some examples, the data-access-to-tag check information comprises one or more of: range information for defining at least one range of address space for which the data-access-to-tag check is enabled for read operations; range information for defining at least one range of address space for which the data-access-to-tag check is enabled for write operations; range information for defining at least one range of address space for which the data-access-to-tag check is enabled for privileged data memory access requests; and range information for defining at least one range of address space for which the data-access-to-tag check is enabled for unprivileged data memory access requests.

The data-access-to-tag check enable information could also be specified in a translation table entry corresponding to the target address of the data memory access request. For example, a translation table entry which provides stage-1 or stage-2 address mapping used to generate an intermediate address in stage 1 or a physical address in stage 2 (referred to herein as a page descriptor), may also specify the data-access-to-tag check enable information.

At step 3106, it is determined whether tag-locating address determining circuitry is operating in a virtualised tagging mode. As discussed herein, tag-locating address determining circuitry may be provided to, when operating in a virtualised tagging mode, determine, based on a data-locating address identifying a location of a given data item within a first address space other than a physical address space, a tag-locating address identifying a location of the allocation tag corresponding to the given data item within the first address space.

When the tag-locating address determining circuitry is operating in a virtualised tagging mode, as discussed in reference to figure 29, a load or store operation may inadvertently specify an address operand corresponding to a data address in a region designated for storing allocation tags. Thus, enabling the data-access-to-tag check when operating in a virtualised tagging mode may help to prevent inadvertent data accesses to allocation tags.

At step 3108, it is determined whether the data memory access request was triggered by an instruction other than at least one class of data access instruction permitted to access allocation tags in the allocation tag memory address region. In some examples, a certain class of data access instructions may be permitted to access allocation tags in the allocation tag memory address region. For example, a bulk-tag or non-bulk tag read or write instruction (described above), or a tag-setting instruction (described in relation to figure 29) may be classes of data access instructions permitted to access allocation tags in the allocation tag memory address region.

At step 3110, it is determined whether the memory access request is an unprivileged data memory access request. For example, it may be determined whether the code executing the memory access request is operating at a privilege level less than a predetermined minimum privilege level.

At step 3112, read or write access to a data value stored at the memory address in the allocation tag memory address region may be denied. The step may correspond to step 3004 of figure 30. Step 3112 may be performed in response to determining that step 3102 combined with any one or more of steps 3104, 3106, 3108, and 31 10 are satisfied (i.e. determined in the affirmative). It will be appreciated that any of steps 3104, 3106, 3108 may be omitted, or the order may be changed without changing the functionality. For example, while shown in figure 31 as each step leading to the next step, all of steps 3102 to 3110 may be performed simultaneously and the result used to determine whether to deny read or write access in step 31 12.

In some examples, step 31 12 may be performed independent of the determination of step 3104. For example, for an unprivileged data memory access, read or write access may be denied at step 31 12 independent of whether it is determined at step 3104 that the data-access-to-tag check enable information indicates that the data-access-to-tag check is enabled for the data memory access request.

At step 3114, read or write access to a data value stored at the memory address in the allocation tag memory address region is permitted. This step may correspond to step 3006 of figure 30. In some examples if any one of steps 3102 to 31 10 (or the steps actually being used in a given implementation) produces a ‘No’ result, step 3114 may be performed. Figure 32 illustrates an example of data-address translation including a data-access-to- tag check. At step 3200, a data access instruction is executed.

At step 3202, it is determined whether stage-1 address translation is currently enabled. As discussed herein, in some implementations, stage-1 or stage-2 address translation may be enabled, or both stage-1 and stage-2 translation may be enabled.

If stage-1 address translation is determined to be enabled, then at step 3204 it is determined whether virtual tagging (denoted as VMTE) is enabled. If stage-1 address translation is disabled, the method may proceed directly to step 3214.

If virtual tagging is determined to be enabled, then at step 3206, it is determined whether the data-access-to-tag check is enabled (denoted as ‘tag access check enabled?’). This may be determined based on determining that data-access-to-tag check enable information indicates that the data-access-to-tag check is enabled for the data access, as discussed with reference to figures 30 and 31 .

If the data-access-to-tag check is determined to be enabled, then at step 3208, it is determined whether the data access corresponds to an access to the memory region designated for storing allocation tags. For example, it may be determined whether the data access specifies a target address corresponding to a memory address in the allocation tag memory address region.

If it is determined that the data access corresponds to an access to the memory region designated for storing allocation tags, then at step 3210, a data access fault is marked. This may comprise triggering a fault indication.

If virtual tagging was disabled at step 3204, the data-access-to-tag check was disabled at step 3206 and/or the data access does not specify a target address corresponding to memory address in the allocation tag memory address region, then the method proceeds to step 3212. If the data access fault is marked at step 3210, the process proceeds to step 3212.

At step 3212, a data-address translation operation is applied for stage-1 translation to translate the virtual address specified as the target address of the data access operation to a corresponding data intermediate address in an intermediate address space. Step 3212 may correspond to step 2406 of figure 24.

At step 3214, it is determined whether stage-2 translation is enabled. If stage 2 translation is enabled, then at step 3216, stage-2 address translation is performed to translate the data intermediate address (either the target address of the data access if stage- 1 translation is disabled, or the address obtained by the stage 1 translation at step 2406). The method then proceeds to step 3218. If stage-2 address translation is disabled at step 3214 then the method may proceed directly to step 3218.

At step 3218, the data access operation may be performed using the result of the stage- 2 address translation (if stage-2 address translation is enabled) or the result of the stage-1 address translation (if stage-2 address translation is disabled). 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.

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.

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 GDSIL 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.

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. 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.

Figure 33 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 3306, optionally running a host operating system 3304, supporting the simulator program 3302. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and/or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in “Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, Pages 53 - 63.

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 3306), some simulated embodiments may make use of the host hardware, where suitable.

The simulator program 3302 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 3300 (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 3302. Thus, the program instructions of the target code 3300 described above, may be executed from within the instruction execution environment using the simulator program 3302, so that a host computer 3306 which does not actually have the hardware features of the apparatus 2 discussed above can emulate these features.

Hence, the simulator program 3302 may have instruction decoding program logic 3314 which simulates decoding and processing of instructions in an equivalent manner to the functionality offered by the instruction decode circuitry 4 and execution circuitry 16 described above. The instruction decoding program logic 3314 decodes instructions of the target code 3300 and maps these to corresponding sets of instructions in the native instruction set of the host apparatus 3306. Memory management (address translation) program logic 3308, tag checking program logic 3312 and data-access-to-tag checking program logic 3318 simulate the functionality of the MMU 6, tag checking circuitry 34 and data-access-to-tag checking circuitry 32 described earlier, including address translation, tag checks and support for virtual/intermediate tagging. Host memory mapping program logic 3310 maps register accesses and memory access operations requested by the target code to accesses to corresponding data structures maintained on the host hardware of the host apparatus 3306, such as by accessing data in registers or memory of the host apparatus 3306. When the memory management program logic 3308 implements address translation based on translation tables defined by the target software, these translation tables translate addresses into a simulated physical address space, which the target software 3300 understands to correspond to physical locations in a memory system, but the host memory mapping program logic 31 10 further maps the simulated physical addresses, obtained by the memory management program logic 3308 based on translation tables defined for the target code 3300, to host virtual addresses used to access host memory in the host processing apparatus 3306. These host virtual addresses may themselves be translated into host physical addresses using the standard address translation mechanisms supported by the host (the translation of host virtual addresses to host physical addresses being outside the scope of what is controlled by the simulator program 3302).

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.

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

1 . An apparatus comprising: tag checking circuitry to perform a tag check in response to a tag-checked memory access instruction specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in a memory system, the tag check comprising triggering an error handling response in response to detection of a tag mismatch between the associated allocation tag obtained from the memory system for the target data address and an address tag associated with the address operand; and memory management circuitry to control access to the target data address based on memory attribute information associated with the target data address, the memory attribute information indicative of whether the target data address is in an untagged memory region for which the tag check would not be required; in which: the memory management circuitry is configured to determine, based at least on whether the memory attribute information associated with the target data address of the tag-checked memory access instruction indicates that the target data address is in the untagged memory region, whether to architecturally perform a tag-locating-address translation operation for obtaining a tag-locating physical address locating the associated allocation tag within a physical address space, the tag-locating physical address being separate from a data-locating physical address locating the target data item within the physical address space.

2. The apparatus according to claim 1 , in which the memory management circuitry is configured to suppress the tag-locating-address translation operation from being architecturally performed in response to detecting that the target data address is in the untagged memory region.

3. The apparatus according to any of claims 1 and 2, in which the memory management circuitry is configured to suppress the tag-locating-address translation operation from being architecturally performed in response to detecting that at least one tag translation mode indicator indicates that a virtualized tag translation mode is disabled, the virtualized tag translation mode comprising a mode in which the target data item is mapped to the data-locating physical address based on data-translating address mapping information corresponding to the target data address and the associated allocation tag is mapped to the tag-locating physical address based on tagtranslating address mapping information corresponding to the target data address, the tagtranslating address mapping information being separate from the data-translating address mapping information.

4. The apparatus according to claim 3, in which when the virtualized tag translation mode is disabled, the memory management circuitry is configured to map both the target data item and the associated allocation tag to the data-locating physical address.

5. The apparatus according to any preceding claim, in which, in response to detecting that the memory attribute information indicates that the target data address is in a tagged memory region, the memory management circuitry is configured to determine, based on whether at least one further condition is satisfied, whether to architecturally perform the tag-locating-address translation operation for translating the tag-locating first address.

6. The apparatus according to claim 5, in which the further condition being satisfied is dependent on at least one tag translation mode indicator indicating that a virtualized tag translation mode is enabled, the virtualized tag translation mode comprising a mode in which the target data item is mapped to the data-locating physical address based on data-translating address mapping information corresponding to the target data address and the associated allocation tag is mapped to the tag-locating physical address based on tag-translating address mapping information corresponding to the target data address, the tag-translating address mapping information being separate from the data-translating address mapping information.

7. The apparatus according to any preceding claim, in which, when the tag-locating-address translation operation is to be architecturally suppressed, the memory management circuitry is configured to prevent any fault being signalled based on the tag-locating-address translation operation.

8. The apparatus according to any preceding claim, in which, when the tag-locating-address translation operation is to be architecturally suppressed, the memory management circuitry is configured to suppress the tag-locating-address translation operation from actually being performed.

9. The apparatus according to any of claims 1 to 7, in which, when the tag-locating-address translation operation is to be architecturally suppressed, the memory management circuitry is configured to allow the tag-locating-address translation operation to be performed, but prevent changes of architectural state caused by the tag-locating-address translation operation.

10. The apparatus according to any preceding claim, in which the memory management circuitry is configured to deduce whether the target data address is in the untagged memory region based on one or more memory attribute indicators of the memory attribute information for indicating one or more memory region attributes unrelated to performance of the tag check.

11. The apparatus according to any preceding claim, in which the memory management circuitry is configured to determine that the target data address is in the untagged memory region in response to detecting that the target data address is in a region other than a normal write-back- cacheable memory region.

12. The apparatus according to any preceding claim, in which the memory management circuitry is configured to determine whether to architecturally perform the tag-locating-address translation operation based on the memory attribute information derived from at least one translation table entry accessed in a data-locating-address translation operation for translating the target data address to the data-locating physical address.

13. The apparatus according to any preceding claim, in which, for a given stage of address translation, the memory management circuitry is capable of performing the tag-locating-address translation operation based on address mapping information from a tag-translating translation table entry different to a data-translating translation table entry providing address mapping information used for the given stage of address translation in a data-locating-address translation operation for translating the target data address to the data-locating physical address.

14. The apparatus according to claim 13, in which the given stage of address translation comprises a first stage of address translation for translating from a virtual address space to an intermediate address space.

15. The apparatus according to any of claims 13 and 14, in which the given stage of address translation comprises a second stage of address translation for translating from an intermediate address space to a physical address space.

16. Computer-readable code for fabrication of the apparatus of any preceding claim.

17. A method comprising: in response to a tag-checked memory access instruction specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in a memory system, determining, based on memory attribute information associated with the target data address, whether the target data address is in an untagged memory region for which a tag check would not be required, the tag check comprising triggering an error handling response in response to detection of a tag mismatch between the associated allocation tag obtained from the memory system for the target data address and an address tag associated with the address operand; and determining, based at least on whether the memory attribute information associated with the target data address of the tag-checked memory access instruction indicates that the target data address is in the untagged memory region, whether to architecturally perform a tag-locating- address translation operation for obtaining a tag-locating physical address locating the associated allocation tag within a physical address space, the tag-locating physical address being separate from a data-locating physical address locating the target data item within the physical address space.

18. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for execution of target program code, the computer program comprising: tag checking program logic to perform a tag check in response to a tag-checked memory access instruction specifying an address operand for defining a target data address corresponding to a target data item having an associated allocation tag stored in a simulated memory system, the tag check comprising triggering an error handling response in response to detection of a tag mismatch between the associated allocation tag obtained from the simulated memory system for the target data address and an address tag associated with the address operand; and memory management program logic to control access to the target data address based on memory attribute information associated with the target data address, the memory attribute information indicative of whether the target data address is in an untagged memory region for which the tag check would not be required; in which: the memory management program logic is configured to determine, based at least on whether the memory attribute information associated with the target data address of the tag- checked memory access instruction indicates that the target data address is in the untagged memory region, whether to architecturally perform a tag-locating-address translation operation for obtaining a tag-locating simulated physical address locating the associated allocation tag within a simulated physical address space, the tag-locating physical address being different to a data- locating physical address locating the target data item within the simulated physical address space.

19. A storage medium storing the computer program of claim 18.