Execution environment mismatch

Abstract

An apparatus is provided in which processing circuitry performs processing in one of a fixed number of at least two domains, one of which is subdivided into a variable number of execution environments. Memory translation circuitry determines a given encrypted environment identifier associated with one of the execution environments in response to a memory access request for a given memory address, and forwards the memory access request with the given encrypted environment identifier. The storage circuitry stores a plurality of entries, each entry associated with an associated encryption environment identifier and an associated memory address. The storage circuitry includes determination circuitry to determine, in at least one enabled mode of operation, whether the given encryption environment identifier is different from the associated encryption environment identifier associated with one of the entries associated with the given memory address.

Description

[0001] This technology involves data processing.

[0002] It is important to provide security in a system where several execution environments each obtain data from memory. Specifically, it is desirable to react to a situation where one execution environment issues a memory access request for data belonging to another execution environment.

[0003] In view of a first example configuration, a device is provided, comprising: a processing circuit configured to perform processing in one of a fixed number of at least two domains, one of which is further divided into a variable number of execution environments; a memory conversion circuit configured to determine a given encryption environment identifier associated with one of the execution environments in response to a memory access request to a given memory address, and to forward the memory access request together with the given encryption environment identifier; a storage circuit configured to store a plurality of entries, each entry being associated with an associated encryption environment identifier and an associated memory address, wherein the storage circuit comprises a determination circuit configured to determine, in at least one enabled operating mode, whether the given encryption environment identifier is different from the associated encryption environment identifier associated with one of the entries associated with the given memory address.

[0004] In view of the second example configuration, a method is provided, comprising: performing processing in one of a fixed number of at least two domains, one of the domains being further divided into a variable number of execution environments; determining a given encryption environment identifier associated with one of the execution environments in response to a memory access request to a given memory address; forwarding the memory access request together with the given encryption environment identifier; storing a plurality of entries, each entry being associated with an associated encryption environment identifier and an associated memory address; and determining in at least one enabled operating mode whether the given encryption environment identifier is different from the associated encryption environment identifier associated with one of the entries associated with the given memory address.

[0005] In view of the third example configuration, a computer program is provided for controlling a host data processing device to provide an instruction execution environment for execution of a target code; the computer program includes: a processing program logic configured to simulate processing of the target code in at least two domains of a fixed number, one of which is further divided into a variable number of execution environments; a memory protection program logic configured to respond to a memory access request for a given memory address by determining a given encryption environment identifier associated with one of the execution environments, and forwarding the memory access request together with the given encryption environment identifier; a storage data structure for storing a plurality of entries, each entry being associated with an associated encryption environment identifier and an associated memory address; and a determination program logic configured to determine in at least one enabled operating mode whether the given encryption environment identifier is different from the associated encryption environment identifier associated with one of the entries associated with the given memory address.

[0006] The present technology will be further described, by way of example only, with reference to embodiments thereof as shown in the accompanying drawings, in which:

[0007] Figure 1 presenting examples according to some embodiments;

[0008] Figure 2 An example showing a separate root domain for managing domain switching;

[0009] Figure 3 Another example of a processing system is schematically shown;

[0010] Figure 4 Shows how the system physical address space can be partitioned using granule protection tables;

[0011] Figure 5 Summarize the operation of the address translation circuit and the PAS filter;

[0012] Figure 6 Shows example page table entries;

[0013] Figure 7 An example showing a MECID consumer operating with a PAS TAG Eliminator to act as a memory protection circuit;

[0014] Figure 8 shows flow charts according to some of the above examples;

[0015] Fig. 9 shows a simulator implementation that can be used;

[0016] Fig.10Shows the location of encryption points and the extent to which clearing and neutralization operations extend within the system;

[0017] Fig.11 Show the relationship between cache tiers, PoE, and PoPA;

[0018] Fig.12 presents a flow chart illustrating the behavior of cache maintenance in more detail;

[0019] Fig.13A An example of a target for a cache maintenance operation is shown;

[0020] Fig. 13B Another example of a target for a cache maintenance operation is shown;

[0021] Fig.14 illustrates methods of data processing according to some examples;

[0022] Fig.15 shows a simulator implementation that can be used;

[0023] Fig.16 An example system according to some examples is shown;

[0024] Fig.17 An example of a MECID mismatch is shown;

[0025] Fig.18 A poison mode of operation is shown which causes the associated cache line to be corrupted in response to a mismatch;

[0026] Fig.19 presenting an example implementation in which an obfuscated mode of operation is demonstrated;

[0027] Fig. 20 An example of a clearing mode of operation is shown;

[0028] Fig.21 An example of an erase mode of operation is shown;

[0029] Fig. 22 An example of how mismatches are handled in different modes of operation is shown in the form of a flow chart;

[0030] Fig.23 illustrating the interaction between enabling mode and speculative execution in the form of a flow chart; and

[0031] Fig.24 A simulator implementation that can be used is shown.

[0032] Before discussing the embodiments with reference to the accompanying drawings, the following description of the embodiments and associated advantages is provided.

[0033] In some examples, a device is provided that includes: processing circuitry configured to perform processing in one of a fixed number of at least two domains, one of the domains being further divided into a variable number of execution environments; memory conversion circuitry configured to determine a given encryption environment identifier associated with one of the execution environments in response to a memory access request for a given memory address, and to forward the memory access request together with the given encryption environment identifier; and storage circuitry configured to store a plurality of entries, each entry being associated with an associated encryption environment identifier and an associated memory address, wherein the storage circuitry includes a determination circuit configured to determine, in at least one enabled operating mode, whether the given encryption environment identifier is different from the associated encryption environment identifier associated with one of the entries associated with the given memory address.

[0034] The at least two domains may be at least three domains. For example, these may include a secure domain, an insecure domain (which does not imply no security, but is only less secure than a secure domain), and a realm domain, which may be a domain subdivided into multiple execution environments. Access to resources between different domains may be controlled. For example, data belonging to a process executed in a secure domain may not be accessible to resources operating in an insecure domain. At the same time, resources in a secure domain may not be accessed by resources operating in a realm domain (and vice versa), but both the realm domain and the secure domain may access resources in an insecure domain. In these examples, each of the execution environments operating in the subdivided domains has an associated encryption environment identifier that identifies an area of ​​memory that can be used to store resources used by the execution environment in an encrypted manner. In this way, resources belonging to each execution environment can be isolated and protected from each other. Storage circuits (e.g., caches) can be used to store entries (e.g., cache lines). Each cache line can be associated by an execution environment identifier, that is, not necessarily a cache line is encrypted, but can alternatively be stored in an unencrypted manner and associated with the encryption environment identifier. Each of the entries (e.g., cache lines) also has an associated memory address (e.g., a location in a region of memory associated with the cache line). When a memory access request is issued on behalf of one of these execution environments, it will obtain an encryption environment identifier associated with that execution environment. The memory access request will then proceed through the memory hierarchy toward main memory. In some cases, the data associated with the memory access request will already be stored in a storage circuit (e.g., a cache). Under normal circumstances, for the data to be returned, the encryption environment identifier associated with the memory access request needs to match the encryption environment identifier associated with the entry of the storage circuit containing the data for which the memory access request was issued. In these examples, a determination circuit is provided to make the determination. The device may be able to switch between enabled operating modes, or the current mode may be fixed.

[0035] In some examples, the device includes a memory protection circuit configured to use a key input to perform encryption or decryption on the data in response to the data of the memory access request not being present in the memory circuit, wherein the key input is based on the given encryption environment identifier; the key input for each of the domains is fixed at the boot time of the device; and the key input for each of the execution environments is dynamic. The encryption environment identifier is used by the memory protection circuit to determine the key input (e.g., a key, a portion of a key, one or more tunable bits). The key input is used to implement encryption and decryption of the execution environment and the domain. It is therefore different for each domain and for each execution environment. The key input for the domain is fixed when the device starts. On the other hand, because the execution environment can be started, stopped and changed dynamically, the key input for the execution environment is dynamically determined.

[0036] In some examples, the storage circuit is configured to perform an error action in response to the given encryption environment identifier being different from the associated encryption environment identifier associated with the given memory address in at least one error operation mode. In these examples, the device responds to the mismatch when it occurs and the response to the mismatch is to perform an error action. In the event that no mismatch occurs, the memory access request continues as usual.

[0037] In some examples, the at least one enabled operating mode includes a destruction operating mode, in which in response to the associated memory address of the one of the entries being the given memory address when the given encryption environment identifier is different from the associated encryption environment identifier associated with the one of the entries, the storage circuit is configured to destroy the one of the entries. The entry is destroyed, thereby making the entry a destroyed entry. That is, some or all of the entries will generate errors if consumed by the processing circuit and when consumed by the processing circuit at a later period. By destroying the entry and postponing any errors that may be caused, it is possible to prevent reading data that may be private (in the case of a read request) or prevent the use of damaged data (in the case of a write request). However, if the data is absolutely no longer read, there is no need to cause an error. For example, in the case of pre-fetching or speculative execution, insufficient consumption may occur. In the case of a memory access request that is a memory read request, the data may be consumed almost immediately, resulting in an immediate error.

[0038] In some examples, the processing circuit is configured to generate an exception when one of the entries is received by the processing circuit. The corrupted entry is thus held unusable by the processing circuit.

[0039] In some examples, when the memory access request is a write memory access request, those portions of the one of the entries that are accessed by the (mismatched) write memory access request are modified and the remaining portions of the one of the entries are destroyed. A write request may modify only a portion of one of the entries (e.g., a cache line) of a storage circuit (e.g., a cache). In these cases, those portions of the entry that are sought to be modified by the memory access request are modified. At the same time, other portions of the entry that the access request did not seek to modify remain as they are, but are destroyed so that if accessed in the future, an exception will be caused by the processing circuit.

[0040] In some examples, the at least one enabled operating mode includes an obfuscated operating mode in which the storage circuit is configured to treat the entries of the storage circuit as different when the associated memory addresses of the entries match and the associated encryption environment identifiers of the entries mismatch. In these examples, in response to a mismatch, each entry effectively treats the encryption environment identifier as part of the address, rather than causing an error to occur. Two entries to the same address with different encryption environment identifiers are treated as two separate and different entries. Therefore, a mismatch "cannot" occur - a memory access request to a memory address using one encryption environment identifier seeks to access different items of data to entries associated with the same memory address and different encryption environment identifiers.

[0041] In some examples, the at least one enabled operating mode includes a clear operating mode in which, in response to the associated memory address of the one of the entries being the given memory address when the given encryption environment identifier is different from the associated encryption environment identifier associated with the one of the entries, the storage circuit is configured to clear and invalidate the one of the entries. In these examples, the mismatch is handled by writing the existing entry of the storage circuit back to a point in the memory hierarchy where encryption was performed using the encryption environment identifier (e.g., main memory). The entry in the storage circuit is then invalidated so that it cannot be accessed.

[0042] In some examples, in the flush mode of operation, in response to the associated memory address of the one of the entries being the given memory address when the given encryption environment identifier is different from the associated encryption environment identifier associated with the one of the entries, the storage circuit is further configured to treat the memory access request as a miss in the storage circuit. After the data has been written back (flushed) and then invalidated, the memory access request may be treated as a miss in the storage circuit. The request may therefore be reissued into the memory hierarchy, where the requested data is ultimately passed back to the storage circuit for storage.

[0043] In some examples, the processing circuit is configured to speculatively issue the memory access request as a speculative read request when in a speculative operating mode; and disable the speculative operating mode unless the memory circuit is in the enabled operating mode. For example, a speculative read request generated when speculating on the result of a branch instruction may occur using an incorrect encryption context identifier. For example, a speculative read request may be permitted for a normal memory (e.g., DRAM) address with a valid MMU mapping. However, if the MECID is "wrong" for the location, such access should not be permitted. A conventional hypervisor may have its own virtual address mapping for all DRAMs, independent of the mappings for the virtual machines supervised by the hypervisor. For domains with MECIDs, if any domain manager has a mapping to all DRAMs, the CPU will be able to speculate on these addresses regardless of whether the "correct" domain MECID value exists. As a result, the security system should prevent speculative read requests from occurring, or should implement one of the previously mentioned enabled modes that catch (or outright prevent) mismatches between encryption context identifiers.

[0044] In some examples, the at least one enabled operating mode includes an erase operating mode in which, in response to the associated memory address of the one of the entries being the given memory address when the given encryption environment identifier is different from the associated encryption environment identifier associated with the one of the entries, the storage circuit is configured to perform an erase of the one of the entries. Erasure of an entry differs from invalidation, where data is merely marked as invalid and inaccessible, in that data actually stored in the storage circuit is removed. There are several ways in which this can be accomplished.

[0045] In some examples, the storage circuit is configured to perform the erasure by zeroing or randomizing one of the entries. By zeroing the data, the data is replaced by a predefined sequence (generally a bit "0", but using a bit "1" may also be referred to as "zeroing"), where the predefined sequence has no apparent meaning. Another alternative is to scramble or randomize the data of the entry. In any case, the original meaning of the data is removed so that it can no longer be determined.

[0046] In some examples, when the memory access request is a write memory access request, the storage circuit is further configured to update the associated encryption identifier to correspond to the given encryption environment identifier. In addition to the actions previously described, the action of writing to the specific entry where the mismatch occurs may cause the encryption environment identifier associated with the entry to be overwritten by the encryption environment identifier associated with the memory access request.

[0047] In some examples, the determination circuit is configured to suppress, in at least one disabled operating mode, a determination of whether the given encryption environment identifier is different from the associated encryption environment identifier associated with one of the entries associated with the given memory address. The disabled operating mode thereby disables or suppresses mismatch detection from occurring. Thus, any mismatch that may occur is substantially ignored. This may therefore result in the plaintext of any entry of the storage circuit being leaked to other execution environments. In practice, there may be other protection mechanisms that prevent this from occurring. For example, the management system may prevent the issuance of memory access requests related to another execution environment.

[0048] In some examples, in at least some of the at least one enabled operating mode, in response to the associated memory address of the one of the entries being the given memory address when the given encryption environment identifier is different from the associated encryption environment identifier associated with the one of the entries, the storage circuit is configured to generate an asynchronous exception. In an asynchronous exception, the exception is inconsistent with the code that caused the exception. That is, the exception may be caused. However, it may not be handled until a (possibly non-deterministic) later time. However, this does allow debugging or detection of leaked data. There are several ways in which an asynchronous exception can be caused.

[0049] In some examples, the storage circuit is configured to generate the asynchronous exception and store details of the memory access request in one or more registers accessible to the processing circuit. Data related to the memory access request - such as the memory address to which the access is being made, the type of access (read or write), the execution environment to which the memory access request is generated, the execution environment in the storage circuit with which the memory address is associated, etc. can be stored in these registers. This can be used to enable debugging and / or detection of situations that lead to cryptographic environment mismatches.

[0050] The following examples may also be relevant.

[0051] According to one example arrangement, a device is provided that includes: processing circuitry configured to perform processing in one of a fixed number of at least two domains, one of the domains being subdivided into a variable number of execution environments; and memory protection circuitry configured to use a key input to perform encryption or decryption of data from a memory access request issued to a memory address within a current one of the domains, wherein the key input is different for each of the domains and for each of the execution environments; the key input for each of the domains is fixed at boot time of the device; and the key input for each of the execution environments is dynamic.

[0052] With respect to the at least two domains, at least one of the domains (there may be several) is subdivided so that several execution environments operate within the domain. A memory access request is a read or write request for data stored in a memory in a memory hierarchy. The data may be additionally cached within the memory hierarchy. However, the data is ultimately stored in a memory (e.g., DRAM). A key input is used to perform encryption or decryption of data in and out of the memory. The key input may be viewed as an input or parameter to an encryption or decryption algorithm that is kept secret to protect the confidentiality of the encrypted data. This includes the key itself, as well as portions of the key, tunable bits, and the like. The key input is different for each of a fixed number of domains. In addition, within at least one subdivided domain, the key input is different for each execution environment. As a result, data encrypted by one execution environment cannot be accessed within another execution environment within the subdivided domain unless both of the execution environments have the same key. This makes it feasible for data to remain confidential between execution environments. It should be noted that the form of the key input may be different between domains than between execution environments. For example, each domain may use a different key, while each execution environment may use the same key, but with different tunable bits. The key input for each of the domains is selected when the device is initially activated (e.g., during a boot sequence). In contrast, the key input for each of the execution environments is dynamic, such that it may change during operation of the device. In practice, the number of execution environments is variable, and key inputs may be established and deleted as needed due to the addition of new execution environments and the termination of old execution environments. The at least two domains include a subdivided domain and a root domain. In some cases, there are at least three domains including a secure domain or one of a less secure domain (described in more detail below).

[0053] In some examples, the device includes: a memory conversion circuit configured to convert the memory address from a virtual memory address to a physical memory address and provide an encryption environment identifier for generating the key input; and the memory access request and the encryption environment identifier are forwarded from the memory conversion circuit to the memory protection circuit. The memory conversion circuit may take the form of, for example, a memory management unit (MMU). In addition to providing a conversion from a virtual address to a physical address (which may be an intermediate physical address), an encryption environment identifier associated with the physical address is also provided. This encryption environment identifier is ultimately used to generate a key input for performing encryption (in the case of a write memory access) or decryption (in the case of a read memory access). After the encryption environment identifier has been determined, this is provided to the memory protection circuit together with the access request. The use of the encryption environment identifier means that the entire key input (such as the entire key) does not need to be provided. Alternatively, a smaller encryption environment identifier may be used instead, thereby reducing the system burden and cache line width expansion in the bus required to carry the identifier.

[0054] In some examples, the memory translation circuit is configured to store a plurality of page table entries and to indicate the encryption environment identifier in response to performing a lookup on the virtual memory address on the plurality of page table entries. Each page table entry thus contains an indication of an encryption environment identifier used to perform encryption of a particular page of memory. The indication may be the encryption environment identifier itself or it may be, for example, an indication of which of several encryption environment identifiers should be used for encryption and / or decryption of data stored on the page. The page table entry may also contain access permissions indicating which domains and / or execution environments may access the memory address.

[0055] In some examples, the memory conversion circuit includes a plurality of encryption environment identifier registers; and the memory conversion circuit is configured to indicate which of these environment identifier registers will be used to provide the encryption environment identifier. A different encryption environment identifier is stored in each of the plurality of encryption environment identifier registers. The indication stored in each page table entry then indicates which value in the register will be provided. As a result, the number of additional bits required in the page table entry is kept small - thereby reducing the amount of storage required. By providing a plurality of registers, it is possible to allow the execution environment to use two or more different encryption environment identifiers at the same time - each of the identifiers is used to access data at different locations. For example, the execution environment may use one encryption environment identifier to access its own private data, and may use a second encryption environment identifier to access data shared with a second execution environment. For example, the second execution environment may have a third encryption environment identifier to access its own private data, or the second encryption environment identifier may be the only encryption environment identifier used by the second execution environment. More complex sharing schemes are of course also possible.

[0056] In some examples, the encryption environment identifier is shared between subsets of the execution environments. By sharing the encryption environment identifier, multiple execution environments sharing the encryption environment identifier can each access the same area of ​​memory, and thereby share data between the execution environments that cannot be accessed by other execution environments that do not have the encryption environment identifier.

[0057] In some examples, the memory protection circuit is configured to obtain the key input for the one of the execution environments by performing a lookup using the encryption environment identifier provided by the memory access request. The memory protection circuit may thus contain a table or otherwise access a table using an encryption environment identifier and thereby obtain the key input corresponding to the encryption environment identifier.

[0058] In some examples, the result of the lookup is the key input in the form of a key. The lookup can thereby provide the key from the result of the lookup. In some examples, the lookup is performed specifically for the key input associated with the execution environment, rather than for the key input associated with the domains.

[0059] In some examples, the result of the lookup is the key input in the form of a contribution to perform the encryption or decryption. As previously described, the key input may be a (secret) contribution to performing the encryption or decryption (such as a trimmed value or portion of a key). In some examples, the lookup is performed specifically for key inputs associated with the execution environment, rather than for key inputs associated with the domains.

[0060] In some examples, the memory address to which the memory access request is issued is a physical memory address in one of a plurality of physical address spaces; and each of these physical address spaces is associated with one of the at least two domains. Depending on permissions provided in the underlying architecture, a domain may be able to access (perhaps in a restricted manner) data stored in a non-related domain.

[0061] In some examples, the memory address to which the memory access request is issued is a physical memory address in one of a plurality of physical address spaces; and each of the physical address spaces is associated with exactly one of the at least two domains.

[0062] In some examples, the at least two domains include a root domain for managing switching between the at least two domains; and the plurality of physical address spaces include a root physical address space associated with the root domain, which is separate from the physical address spaces associated with the plurality of other domains. By providing a dedicated root domain for controlling switching, this can help maintain security by limiting the extent to which code executed in one domain can trigger a switch to another domain. For example, the root domain can perform various security checks when requesting a domain switch. The root domain has its own physical address space assigned to it, rather than using one of the physical address spaces associated with one of the other domains. By providing a dedicated root physical address space isolated from the physical address spaces associated with the other domains, this can provide stronger security guarantees for data or code associated with the root domain, which can be considered to be the most critical to security in view of the fact that it will manage entries in other domains. Furthermore, providing a dedicated root physical address space that is distinguished from the physical address spaces of other domains can simplify system development, because it can simplify the allocation of physical addresses within the corresponding physical address space to specific units of the hardware memory storage device. For example, by identifying a separate root physical address space, it may be simpler for data or program code associated with the root domain to be preferentially stored in protected on-chip memory rather than in less secure off-chip memory, where the additional burden in determining the portion associated with the root domain is less than if the root domain's code or data were stored in a shared address space shared with another domain.

[0063] In some examples, the at least two domains include at least: a security domain associated with a secure physical address space, and a less secure domain associated with a less secure physical address space; the less secure physical address space is accessible from the less secure domain, the secure domain, and the root domain; and the secure physical address space is accessible from the secure domain and the root domain, and is inaccessible from the less secure domain. Thus, this allows code executed in the secure domain to have its code or data protected from access by code operating in the less secure domain, with stronger security guarantees than if page tables were used as a separate security control mechanism. For example, portions of code requiring stronger security may be executed in a secure domain managed by a trusted operating system that is different from a non-secure operating system operating in the less secure domain. An example of a system supporting such secure and less secure domains may be based on a system supporting a secure operating system that is managed by a trusted operating system that is different from a non-secure operating system operating in the less secure domain. Provided by Limited of Cambridge, UK Architectural features of the processing architecture operations of the processing system. In a specific implementation, the monitoring code for managing the switching between the secure and less secure domains uses the same secure physical address space used by the secure domain. In contrast, by providing a root domain as described above for managing the switching of other domains and assigning a dedicated root physical address space for use by the root domain, this helps improve security and simplifies system development.

[0064] In some examples, the multiple physical address spaces are all accessible from the root domain. Since the code executed in the root domain must be trusted by any party of the code operating in one of the other domains, when the root domain code will be responsible for switching to the specific domain in which the party's code is being executed, the root domain can be inherently trusted to access any of the physical address spaces. Making all physical address spaces accessible from the root domain allows execution such as converting a memory area into or out of a domain, copying code and data into a domain, for example, during startup, and providing services to the domain. In these sub-examples where multiple encryption environment identifier registers are provided, one of these registers can be used to store an encryption environment identifier associated with one of the software executed in the root domain in these domains that wishes to access. This allows the software in the root domain to encrypt / decrypt data in the domain domain. The root domain does not have a primary MECID for root PAS access. Alternatively, a default MECID value of 0 is used in the root domain. The root domain uses the Alternate MECID Register 96 to store the Alternate MECID for its access to the Realm PAS.

[0065] In some examples, one of the domains is a domain domain associated with a realm physical address space; and the realm physical address space is subdivided into the variable number of sub-region physical address spaces. Thus, each realm can be given its own physical address space within the total realm address space.

[0066] In some examples, the less secure physical address space is accessible from the realm domain; and the realm physical address space is accessible from the realm domain and the root domain, and is not accessible from the less secure domain. Thus, the realm domain can be considered more secure than the less secure domain, but similarly secure to the secure domain.

[0067] In some of these examples, the security domain is accessible from the domain domain. However, in other examples, the domain physical address space is inaccessible from the security domain; and the secure physical address space is inaccessible from the domain domain. Software vendors increasingly desire a secure computing environment that limits the need to trust other software vendors associated with other software executing on the same hardware platform. For example, there may be several uses in the domain, such as mobile payments and banking, enforcement of anti-cheat and piracy mechanisms in computer games, security enhancements to operating system platforms, secure virtual machines hosted in cloud systems, confidential computing, etc., where a party providing software code may be reluctant to trust a party providing an operating system or hypervisor (which may have been previously considered a trusted component). In a system that supports secure domains and less secure domains with corresponding physical address spaces, such as those based on the above With the increasing acceptance of secure components operating in a secure domain, the set of software that generally operates in a secure domain has grown to include several pieces of software that may be provided by a different number of software vendors, including parties such as an original equipment manufacturer (OEM) that assembles a processing device (such as a mobile phone) from components that include a silicon integrated circuit chip provided by a particular silicon vendor, an operating system vendor (OSV) that provides an operating system that runs on the device, and a cloud platform operator (or cloud host) that maintains a server farm that provides server space for hosting virtual machines on the cloud. Therefore, if these domains are implemented in a strict order of increasing privilege, there may be problems because an application vendor that provides application-level code that wishes to have a secure computing environment may not want to trust a party that may have traditionally provided software that executes a secure domain (such as an OSV, OEM, or cloud host), but likewise, these parties that provide code that operates in a secure domain are unlikely to want to trust an application vendor that provides code that operates in a higher privilege domain that is given access to data associated with a lower privilege domain. These examples recognize that a strict domain hierarchy of increasing privilege may be inappropriate, and therefore the realm domain may be considered orthogonal to the security domain, while the realm domain and security domain may each access less secure physical spaces, without the realm being able to access the other's physical space.

[0068] In some examples, the less secure physical address space is accessible from all of the at least two domains. This is useful because it facilitates data or program code to be shared between software executed in different domains. If a particular item of data or code is to be accessible in different domains, it can be allocated to the less secure physical address space so that it can be accessed from any of these domains.

[0069] The following examples may also be relevant.

[0070] According to one example arrangement, a device is provided, comprising: processing circuitry configured to perform processing in one of a fixed number of at least two domains, wherein one of the domains is subdivided into a variable number of execution environments, one of the execution environments being a managed execution environment configured to manage the execution environments; and memory protection circuitry that defines an encryption point after at least one unencrypted storage circuit of a memory hierarchy and before at least one encrypted storage circuit of the memory hierarchy, wherein the at least one encrypted storage circuit is configured to use a key input to perform encryption or decryption on data of a memory access request issued from within a current one of the domains, wherein the key input is different for each of the domains and for each of the execution environments; and the managed execution environment is configured to inhibit issuing maintenance operations to the at least one encrypted storage circuit of the memory hierarchy.

[0071] Processing may occur within a digital (two or more, such as three or more) domain or world. One of these domains / worlds is further divided into several (e.g., multiple) execution environments, and one of these execution environments is a management execution environment responsible for the management of each of the execution environments. The management execution environment handles, for example, cache maintenance operations. A memory protection circuit is provided to protect the memory. For example, it may handle the isolation of the memory used by each of these domains. The memory protection circuit defines encryption points within the memory hierarchy. The memory hierarchy system (storage circuit) before the encryption point stores unencrypted data, while the memory hierarchy system (storage circuit) after the encryption point stores encrypted data. The encryption used for these encrypted storage circuits is different for each of the domains and for the execution environment. That is, unless explicitly requested, software executed in one domain or execution environment cannot decrypt data belonging to software in another domain or execution environment. This is achieved by using key inputs (e.g., keys, portions of keys, or tunable bits) that are different for each domain and / or execution environment during the encryption process. At least some of the cache maintenance operations issued by the management execution environment are about unencrypted storage circuits, not about encrypted storage circuits. This is because, because data belonging to one domain or execution environment is generally not accessible to another domain or execution environment (except in certain specifically defined circumstances), there may be no need to clear that data to prevent it from inadvertently becoming accessible to another domain or execution environment. The number of cache maintenance operations may therefore be limited, thereby reducing performance impact.

[0072] In some examples, the management execution environment is configured to issue the maintenance operation to the at least one unencrypted storage circuit of the memory hierarchy in response to a change in memory assignment made to one of the execution environments. Because the unencrypted storage circuits of the memory hierarchy store data in an unencrypted format, it is important for maintenance operations to specifically identify these storage circuits. After the encryption point, because the data is generally inaccessible to other execution environments (or domains / worlds), performing certain maintenance operations becomes less critical. For example, a change in memory assignment may occur due to the termination of an execution environment or due to the start of a new execution environment.

[0073] In some examples, the maintenance operation is an invalidation operation. The invalidation operation marks the data in the cache as unavailable (e.g., deleted) so that it must be obtained from somewhere else in the memory hierarchy, such as a memory. By invalidating at most the encryption point, the data is no longer accessible without performing a decryption process. Therefore, if the key input associated with the data is also erased or lost, the data is no longer accessible. It is important to ensure that any previous execution environment that uses this memory space and whose data is stored in an unencrypted storage circuit in an unencrypted manner has its data invalidated so that it cannot be accessed by the new execution environment. This is achieved by using a cache maintenance operation that marks the unencrypted storage circuit. Because the data associated with the old execution environment is encrypted, the same maintenance operation that marks the encrypted storage circuit is not required. Because the new execution environment does not have access to the old key of the old execution environment, the data cannot be decrypted.

[0074] In some examples, the maintenance operation is a clear and invalidate operation. The clear and invalidate operation causes the dirty (modified) data to be written further up the memory hierarchy—for example, to a memory backed by DRAM. At the same time, entries in the cache of the memory hierarchy are invalidated so that future accesses to the data are accomplished by obtaining the data from memory.

[0075] In some examples, the maintenance operation is configured to invalidate entries in at least one unencrypted storage circuit associated with the one of the execution environments. The invalidation maintenance operation is thus directed toward the entries in the unencrypted storage circuit (wherein data is stored in an unencrypted manner) associated with or belonging to a specific one of the execution environments. Data belonging to other execution environments remain valid unless / until marked by other invalidation operations. Marking of entries belonging to a specific execution environment can be achieved by issuing cache maintenance operations to specific physical addresses (or address ranges) belonging to the specific execution environment. The management execution environment of the management execution environment can determine these physical addresses belonging to these execution environments. By indexing the cache using the physical address, each cache can quickly determine whether the relevant address exists in the cache. Its alternative is to specify the execution environment whose entry is to be invalidated for the cache maintenance operation. This will require searching the cache (which will be time-consuming) or indexing the cache depending on the execution environment.

[0076] In some examples, the change in assignment is the assignment of memory to the one of the execution environments. In some examples, the change in assignment may be the deallocation or cancellation of memory of the one of the execution environments.

[0077] In some examples, the maintenance operation is configured to invalidate entries in the at least one encrypted storage circuit associated with the expired ones of the execution environments. When the memory is to be reassigned (or deallocated), the invalidation may be performed if / when the execution environment ends. By performing the invalidation at the end of the previous execution environment, sensitive data is not saved in an unencrypted manner, which improves the security of the system.

[0078] In some examples, each of these execution environments is associated with an encryption environment identifier used to generate the key input; and the maintenance operation is configured to invalidate entries in the memory hierarchy associated with the encryption environment identifier. An expired execution environment can therefore be identified within the memory hierarchy based on an encryption environment identifier specifically for the expired execution environment. Of course, in some cases, an encryption environment identifier may be used by multiple execution environments to allow data to be shared between these multiple execution environments. In these cases, the encryption environment identifier may be used in an invalidation operation when all execution environments expire or when a specific one or a specific subset of the execution environments expire. As explained above, an alternative way to achieve invalidation is to issue an invalidation request to the management execution environment (which knows the physical addresses assigned to each execution environment) for the physical addresses associated with the execution environments whose entries are to be invalidated. This avoids any need to index the cache according to the execution environment (identifier) ​​or to diligently search the cache for the relevant entries.

[0079] In some examples, the memory address to which the memory access request is issued is a physical memory address in one of a plurality of physical address spaces; and each of these physical address spaces is associated with one of the at least two domains. Each of the domains may therefore have its own physical address space.

[0080] In some examples, the memory protection circuitry defines a physical obfuscation point located after at least one unobfuscated storage circuit of the memory hierarchy and before at least one obfuscated storage circuit of the memory hierarchy; the at least one unobfuscated storage circuit treats physical addresses from different physical address spaces corresponding to the same memory system resource as if the physical addresses corresponded to different memory system resources. In addition to the physical obfuscation point (PoPA), there is also an encryption point (PoE). Obfuscation is suppressed before the physical obfuscation point. This means that (in components before the PoPA) two memory accesses sent to the same physical address in different physical address spaces are treated as requests for different memory addresses. This can result in the obfuscation of the same data belonging to two entries being stored twice in the cache.

[0081] In some examples, the physical obfuscation point is at or after the encryption point. Thus, the memory hierarchy has zero or more components with encryption and no physical obfuscation.

[0082] In some examples, the physical obfuscation point is at the encryption point. The encryption point and the physical obfuscation point thus exist at the same point in the memory hierarchy.

[0083] In some examples, in response to the memory transition request requesting a transfer of memory from a source physical address space to a destination physical address space, the maintenance operation is configured to invalidate at least some entries in the at least one obfuscated storage circuit. In the case where memory (e.g., at least one page) is to be transferred between address spaces, the maintenance operation may extend up to the physical obfuscation point—but not beyond the physical obfuscation point. This may therefore extend beyond the encryption point.

[0084] In some examples, the at least some of the entries are assigned to one of the at least two domains associated with the source physical address space.Invalidation may thus be limited to entries moved from the source physical address space.

[0085] Certain embodiments will now be described with reference to the figures.

[0086] Figure 1 An example of a data processing system 2 having at least one requestor device 4 and at least one completer device 6 is schematically shown. An interconnect 8 provides communication between the requestor device 4 and the completer device 6. The requestor device is capable of issuing memory access requests requesting memory access to a specific addressable memory system location. The completer device 6 is a device that has the responsibility of servicing memory access requests therefor. Although not shown, the completer device 6 is a device that has the responsibility of servicing memory access requests therefor. Figure 1 , but some devices may be able to act as both a requester device and a completer device. Requester device 4 may, for example, include a processing element such as a central processing unit (CPU) or a graphics processing unit (GPU) or other master device (such as a bus master, a network interface controller, a display controller, etc.). Completer devices may include a memory controller responsible for controlling access to corresponding memory storage units, a peripheral controller that controls access to peripheral devices, etc. Figure 1 An example configuration of one of the requester devices 4 is shown in more detail, but it will be understood that the other requester devices 4 may have similar configurations. Alternatively, the other requester devices may have the same configurations as shown in FIG. Figure 1 The requester device on the left has 4 different configurations.

[0087] The requester device 4 has a processing circuit 10 that performs data processing in response to instructions with reference to data stored in registers 12. The registers 12 may include general registers for storing operands and results of processed instructions, and control registers for storing control data for configuring how the processing is performed by the processing circuit. For example, the control data may include a current domain indication 14 for selecting which operating domain is the current domain, and a current exception level indication 15 indicating which exception level is the current exception level in which the processing circuit 10 is operating.

[0088] The processing circuit 10 may be capable of issuing a memory access request specifying a virtual address (VA) identifying an addressable address to be accessed and a domain identifier (domain ID or "security state") identifying a current domain. Address translation circuitry 16 (e.g., a memory management unit (MMU)) converts the virtual address into a physical address (PA) through one or more stages of address translation based on page table data defined in a page table structure stored in the memory system. The translation lookaside buffer (TLB) 18 acts as a lookup cache for caching some page table information for faster access than if the page table information had to be fetched from memory each time a memory translation is required. In this example, in addition to generating a physical address, the address translation circuit 16 selects one of several physical address spaces associated with the physical address, outputs a physical address space (PAS) identifier identifying the selected physical address space, and also provides a MECID whose purpose is described in more detail below.

[0089] The PAS filter 20 acts as a requester-side filtering circuit for checking, based on the translated physical address and the PAS identifier, whether the physical address is allowed to be accessed within the specified physical address space identified by the PAS identifier. This lookup is based on granule protection information stored in a granule protection table structure stored within the memory system. The granule protection information may be cached in the granule protection information cache 22, similar to caching page table data in the TLB 18. Although in Figure 1 In the example of FIG. 1 , the granule protection information cache 22 is shown as a separate structure from the TLB 18, but in other examples, these types of lookup caches may be combined into a single lookup cache structure so that a single lookup of an entry of the combined structure provides both the page table information and the granule protection information. The granule protection information defines information that restricts the physical address space from which a given physical address may be accessed, and based on this lookup, the PAS filter 20 determines whether to allow a memory access request to proceed to issue to one or more caches 24 and / or the interconnect 8. If the specified PAS of the memory access request is not allowed to access the specified physical address, the PAS filter 20 blocks the transaction and may signal a fault.

[0090] Although Figure 1An example of a system with multiple requester devices 4 is shown, but for Figure 1 The features shown on the left side of the one requestor device may also be included in a system with only one requestor device (such as a single core processor).

[0091] Although Figure 1 An example is shown in which the selection of a PAS for a given request is performed by address translation circuit 16, but in other examples, information for determining which PAS to select may be output by address translation circuit 16 along with the PA to PAS filter 20, and PAS filter 20 may select a PAS and check whether the PA is allowed to access within the selected PAS.

[0092] The provision of the PAS filter 20 helps support systems that can operate in several operating domains, each associated with its own isolated physical address space, where, for at least a portion of the memory system (e.g., for some cache or coherency enforcement mechanisms such as snoop filters), the separate physical address spaces are treated as if they refer to completely separate sets of addresses identifying separate memory system locations, even though addresses within these address spaces actually refer to the same physical location in the memory system. This can be useful for security purposes.

[0093] Figure 2 Examples are shown of different operating states and domains in which processing circuitry 10 may operate, and examples of the types of software that may execute in different exception levels and domains (it will be understood, of course, that the specific software installed on the system is selected by the administrator managing the system, and is therefore not an essential feature of the hardware architecture).

[0094] The processing circuit 10 may operate at a number of different exception levels 80 (in this example, four exception levels labeled EL0, EL1, EL2, and EL3), where in this example, EL3 refers to the exception level with the greatest privilege level, and EL0 refers to the exception level with the least privilege. It will be appreciated that other architectures may choose the opposite numbering, so that the exception level with the highest number may be considered to have the lowest privilege. In this example, the least privileged exception level EL0 is for application-level code, the next-highest privileged exception level EL1 is for operating system-level code, the next-highest privileged exception level EL2 is for hypervisor-level code for managing switching between a number of virtualized operating systems, and the highest privileged exception level EL3 is for monitoring code for managing switching between respective domains and allocation of physical addresses to physical address spaces, as described later.

[0095] When an exception occurs while processing software in a particular exception level, for some types of exceptions, the exception is caused to take a higher (more privileged) exception level, where the particular exception level that the exception will take is selected based on the attributes of the particular exception that occurred. However, in some cases, it may be possible to cause other types of exceptions to take the same exception level as the exception level associated with the code being processed when the exception is taken. When an exception is taken, information characterizing the state of the processor when the exception is taken can be saved, including, for example, the current exception level when the exception is taken, and thus once the exception handler has processed to handle the exception, processing can then return to the previous processing, and the saved information can be used to identify the exception level to which processing should return.

[0096] In addition to the different exception levels, the processing circuitry also supports several operating domains including a root domain 82, a secure (S) domain 84, a less secure domain 86, and a domain domain 88. For ease of reference, the less secure domain will be described below as a "non-secure" (NS) domain, but it will be understood that this is not intended to imply any particular security (or lack of security) level. Alternatively, "non-secure" only indicates that the non-secure domain is intended for code that is less secure than code operating in the secure domain. When the processing circuitry 10 is at the highest exception level EL3, the root domain 82 is selected. When the processing circuitry is in one of the other exception levels EL0 to EL2, the current domain is selected based on the current domain indicator 14 indicating which of the other domains 84, 86, 88 is in use. For each of the other domains 84, 86, 88, the processing circuitry may be in any of the exception levels EL0, EL1, or EL2.

[0097] At boot time, several boot code segments (e.g., BL1, BL2, OEM Boot) may be executed, for example, within a higher privilege exception level EL3 or EL2. For example, the boot code BL1, BL2 may be associated with a root domain, and the OEM boot code may operate in a secure domain. However, once the system is booted, at run time, the processing circuit 10 may be considered to operate in one of the domains 82, 84, 86, and 88 at a time. Each of the domains 82 to 88 is associated with its own associated physical address space (PAS) that enables data to be isolated from different domains within at least a portion of the memory system. This will be described in more detail below.

[0098] The non-secure domain 86 may be used for regular application-level processing, as well as operating system and hypervisor activities for managing such applications. Thus, within the non-secure domain 86, there may be application code 30 operating at EL0, operating system (OS) code 32 operating at EL1, and hypervisor code 34 operating at EL2.

[0099] The secure domain 84 enables certain SoC security, media, or system services to be isolated into a physical address space separate from the physical address space used for non-secure processing. The secure and non-secure domains are not equal in the sense that non-secure domain code cannot access resources associated with the secure domain 84, while the secure domain can access both secure and non-secure resources. An example of a system that supports such partitioning of the secure domain 84 and the non-secure domain 86 is based on Provided by Limited The secure domain may run a trusted application 36 at EL0, a trusted operating system 38 at EL1, and optionally a secure partition manager 40 at EL2, which, if secure partitioning is supported, may use stage 2 page tables to support isolation between different trusted operating systems 38 executing in the secure domain 84 in a manner similar to the way in which the hypervisor 34 may manage isolation between virtual machines or guest operating systems 32 executing in the non-secure domain 86.

[0100] Extending a system to support a security domain 84 has become common in recent years because it enables a single hardware processor to support isolated secure processing, avoiding the need for processing to be executed on a separate hardware processor. However, as the use of security domains has become increasingly common, many actual systems with such security domains now support a relatively complex mix of services provided by a wide range of different software vendors within the security domain. For example, the code operating in the security domain 84 may include different pieces of software provided by, among other things: a silicon vendor that manufactures integrated circuits, an original equipment manufacturer (OEM) that assembles the integrated circuits provided by the silicon vendor into an electronic device (such as a mobile phone), an operating system vendor (OSV) that provides an operating system 32 for the device; and / or a cloud platform vendor that manages a cloud server that supports services for several different clients through the cloud.

[0101] However, suppliers who provide user-level code (which may be typically expected to execute as applications 30 within a non-secure domain 86) increasingly desire to have a secure computing environment that can be trusted not to leak information to other parties operating the code on the same physical platform. Such secure computing environments can be dynamically allocated at run time, and authentication and provability are desirable, so that users can verify whether sufficient security guarantees are provided on the physical platform before trusting the device to process potentially sensitive code or data. Users of such software may not want to trust suppliers who provide rich operating systems 32 or hypervisors 34 that may typically operate in non-secure domains 86 (or even if these suppliers themselves are trustworthy, users may want to protect themselves from the operating system 32 or hypervisor 34 being compromised by attackers). Furthermore, although the secure domain 84 can be used for such user-provided applications that require secure processing, in practice, this causes problems for both users who provide code that requires a secure computing environment and suppliers of existing code that operates within the secure domain 84. For vendors of existing code operating within the secure domain 84, adding arbitrary user-supplied code within the secure domain increases the attack surface for potential attacks on their code, which may be undesirable, and therefore allowing users to add code into the secure domain 84 may be strongly discouraged. On the other hand, users who provide code that requires a secure computing environment may be reluctant to trust all vendors of different code segments operating in the secure domain 84 with access to their data or code, and if code operating in a particular domain requires authentication or certification as a prerequisite for the user-supplied code to perform its processing, it may be difficult to audit and authenticate all of the different code segments provided by different software vendors that operate in the secure domain 84, which may limit the opportunities for third parties to provide more secure services.

[0102] Therefore, if Figure 2 As shown, an additional domain 88 called a realm domain is provided, which can be used by such user-introduced code to provide a secure computing environment orthogonal to any secure computing environment associated with components operating in the secure domain 24. In the realm domain, the executed software may include several realms (or execution environments), wherein each realm may be isolated from other realms by a realm management module (RMM) 46 operating at the exception level EL2. The RMM 46 may control the isolation between the respective realms 42, 44 executing the realm domain 88, for example, by defining access permissions and address mappings in a page table structure in a manner similar to the hypervisor 34 in which it manages isolation between different components operating in the non-secure domain 86. In this example, the realms include an application-level realm 42 executing at EL0, and a packaged application / operating system realm 44 executing across the exception levels EL0 and EL1. It will be understood that it is not necessary to support EL0 and EL0 / EL1 types of realms, and multiple realms of the same type may be established by the RMM 46.

[0103] The domain domain 88 has its own physical address space assigned to it similar to the security domain 84, but the domain domain is orthogonal to the security domain 84 in the sense that while the domain domain 88 and the security domain 84 can each access the non-secure PAS associated with the non-secure domain 86, the domain domain 88 and the security domain 84 cannot access each other's physical address space. This means that the code executed in the domain domain 88 and the security domain 84 has no dependencies on each other. The code in the domain domain only needs to trust the hardware, RMM 46, and the code switching between the management domains operating in the root domain 82, which means that certification and authentication become more feasible. Proof enables a given software to request verification that the code installed on the device matches certain expected properties. This can be implemented by checking whether the hash of the program code installed on the device matches the expected value signed by a trusted party using a cryptographic protocol. The RMM 46 and the monitoring code 29 can be proved, for example, by checking whether the hash of this software matches the expected value signed by a trusted party (such as a silicon vendor that manufactures an integrated circuit including the processing system 2, or an architecture vendor that designs a processor architecture that supports domain-based memory access control). This may allow the user-provided code 42, 44 to verify that the integrity of the domain-based architecture can be trusted before performing any secure or sensitive functions.

[0104] Thus, it can be seen that code associated with the realms 42, 44 (which would have previously executed in the non-secure domain 86, as shown by the dashed lines showing gaps in the non-secure domain where these processes would have previously executed) can now be moved into the realm domain where they can have stronger security guarantees due to their data and code being inaccessible to other code operating in the non-secure domain 86. However, due to the realm domain 88 being orthogonal to the secure domain 84 and therefore not being able to see each other's physical address spaces, this means that vendors of code in the realm domain do not need to trust vendors of code in the secure domain, and vice versa. Code in the realm domain can simply trust the trusted firmware that provides the monitoring code 29 and RMM 46 for the root domain 82, which can be provided by the silicon vendor or vendor of the instruction set architecture supported by the processor that may already be inherently necessarily trusted when the code is executed on these vendors, enabling users to have a secure computing environment without requiring further trust relationships with other operating system vendors, OEMs, or cloud hosts.

[0105] This can be useful for a range of applications and use cases, including, for example, mobile e-wallet and payment applications, game anti-cheat and piracy mechanisms, security enhancements for operating system platforms, secure virtual machine hosting, confidential computing, networking, or gateway processing for IoT devices. It will be appreciated that users may find domain support useful for many other applications.

[0106] To support the security assurances provided to the domain, the processing system may support attestation reporting capabilities where firmware images and configurations are measured at boot time or at run time, for example, monitoring code images and configurations or RMM code images and configurations, and at run time, domain content and configurations are measured so that the domain owner can trace the attestation reports back to known specific implementations and certifications to make a trust decision whether to operate on the system.

[0107] like Figure 2 As shown, a separate root domain 82 for managing domain switching is provided, and the root domain has its own isolated root physical address space. The establishment of the root domain and the isolation of its resources from the security domain allow for a more robust implementation, even for systems with only non-security domains 86 and security domains 84, but no domain domains 88, but can also be used to support implementations that do support domain domains 88. The root domain 82 can be implemented using monitoring software 29 provided (or certified) by a silicon vendor or architecture designer, and can be used to provide secure boot functionality, trusted boot measurement, system-on-chip configuration, debug control, and management of firmware updates for firmware components provided by other parties (such as OEMs). The root domain code can be developed, certified, and deployed by a silicon vendor or architecture designer without having to rely on the final device. In contrast, the security domain 84 can be managed by the OEM for the implementation of certain platform and security services. Management of the non-secure domain 86 may be controlled by the operating system 32 to provide operating system services, while the domain domain 88, while being isolated from the existing secure software environment in the secure domain 84, allows the development of new forms of trusted execution environments that may be dedicated to user or third-party applications.

[0108] Figure 3 Another example of a processing system 2 for supporting these techniques is schematically shown. Figure 1 The same elements are shown using the same reference numerals. Figure 3The address translation circuitry 16 is shown in more detail and includes a stage 1 memory management unit 50 and a stage 2 memory management unit 52. The stage 1 MMU 50 may be responsible for translating a virtual address into a physical address (when the translation is triggered by EL2 or EL3 code) or an intermediate physical address (when the translation is triggered by EL0 or EL1 code in an operating state that requires further stage 2 translation by the stage 2 MMU 52). The stage 2 MMU may translate the intermediate physical address into a physical address. The stage 1 MMU may be based on page tables controlled by the operating system for translations originating from EL0 or EL1, page tables controlled by the hypervisor for translations from EL2, or page tables controlled by the monitoring code 29 for translations from EL3. On the other hand, the stage 2 MMU 52 may be based on a page table structure defined by the hypervisor 34, the RMM 46, or the secure partition manager 14 depending on which domain is being used. Separating translation into two stages in this manner allows operating systems to manage address translation for themselves and applications under the assumption that they are the only operating systems running on the system, while RMM 46, hypervisor 34, or SPM 40 can manage isolation between different operating systems running in the same domain.

[0109] like Figure 3 As shown, the address translation process using the address translation circuit 16 can return security attributes 54 that, in conjunction with the current exception level 15 and the current domain 14 (or security state), allow access to a segment of a particular physical address space (identified by a PAS identifier or "PAS TAG") in response to a given memory access request. The physical address and PAS identifier can be looked up in a granular protection table 56 that provides granular protection information as described earlier, or this can come from the address translation circuit. In this example, the PAS filter 20 is shown as a granular memory protection unit (GMPU) that verifies whether access to the requested physical address via the selected PAS is allowed, and if so, allows the transaction to pass to any cache 24 or interconnect 8 that is part of the system mesh architecture of the memory system.

[0110] The GMPU 20 allows memory to be assigned to separate address spaces and efficient sharing schemes while providing strong hardware-based isolation guarantees and providing spatial and temporal flexibility in the method of assigning physical memory to these address spaces. As described earlier, the execution units in the system are logically partitioned into virtual execution states (domains or "worlds"), with one execution state (root world) at the highest exception level (EL3) called the "root world" that manages the assignment of physical memory to these worlds.

[0111] Virtualizes a single system physical address space into multiple "logical" or "architectural" physical address spaces (PAS), where each such PAS is an orthogonal address space with independent coherence properties. System physical addresses are mapped to a single "logical" physical address space by extending it with PAS tags.

[0112] A given world is allowed to access a subset of the logical physical address space. This is performed by a hardware filter 20 which may be attached to the output of the memory management unit 16.

[0113] The world defines the security attributes of accesses (PAS tags) using fields in the translation table descriptors of the page tables used for address translation. The hardware filter 20 has access to a table (granule protection table 56, or GPT) that defines, for each page in the system physical address space, granule protection information (GPI) indicating the PASTAG associated therewith and (optionally) other granule protection attributes.

[0114] The hardware filter 20 checks the world ID and security attributes of the granule's GPI and decides whether access can be granted, thus forming a granule memory protection unit (GMPU).

[0115] For example, GPT 56 may reside in on-chip SRAM or in off-chip DRAM. If stored off-chip, GPT 56 may be integrity protected by an on-chip memory protection engine that may use encryption, integrity, and freshness mechanisms to maintain the security of GPT 56.

[0116] Locating the GMPU 20 on the requester side of the system (eg, on the MMU output) rather than on the integrator side allows access rights to be assigned at a page granularity while permitting the interconnect 8 to continue hashing / striping pages across multiple DRAM ports.

[0117] Transactions remain PAS tagged as they propagate throughout the system mesh 24, 8 until they reach a location defined as a physical obfuscation point 60. This allows the filter to be located at the requester as compared to completer filtering. The PAS TAG can be used as a deep security mechanism for address isolation as transactions are propagated throughout the system: for example, flash memory can add the PAS TAG to the address tags in the cache, preventing accesses to the same PA generated with the wrong PAS TAG from hitting in the cache, and thus improving side-channel resistance. The PAS TAG can also be used as a context selector for a protection engine attached to the memory controller 68 that encrypts data before writing it to external DRAM.

[0118] The Point of Physical Obfuscation (PoPA) is the location in the system where the PAS TAG is stripped and the address is changed from a logical physical address back to a system physical address. The PoPA can be located below the cache on the completer side of the system that generates access to the physical DRAM (using the cryptographic context resolved by the PAS TAG). Alternatively, it can be located above the cache to simplify the system implementation at the cost of reduced security.

[0119] At any point in time, the world may request to transition a page from one PAS to another. A request is generated to the monitoring code 29 at EL3 to check the current state of the GPI. EL3 may only allow a specific set of transitions to occur (e.g., from a non-secure PAS to a secure PAS, but not from a domain PAS to a secure PAS). To provide clean transitions, a new instruction may be supported by the system - "Data Purge and Invalidate to Physical Obfuscation Points" that the EL3 may submit before transitioning a page to a new PAS - this ensures that any residual state associated with the previous PAS is cleared from any caches upstream of the PoPA 60 (closer to the requester side than that PoPA).

[0120] Another property that can be achieved by attaching the GMPU 20 to the master side is efficient sharing of memory between worlds. It may be desirable to grant shared access to a physical granule to a subset of N worlds while preventing other worlds from accessing it. This can be achieved by adding "restricted sharing" semantics to the granule protection information while forcing it to use a specific PAS TAG. As an example, the GPI, while tagged with the PAS TAG of the secure PAS 84, may indicate that a physical granule can only be accessed by the "domain world" 88 and the "secure world" 84.

[0121] An example of the above property is making rapid changes in the visibility property of a particular physical granule. Consider the case where each world is assigned a private PAS that is only accessible to that world. For a particular granule, a world can request to make them visible to the non-secure world at any point in time by changing their GPI from "exclusive" to "restricted sharing with non-secure world" without changing the PAS association. In this way, the visibility of the granule can be increased without the need for expensive cache maintenance or data copy operations.

[0122] exist Figure 3In the example of , a MECID consumer 64 is also shown. This forms a memory protection circuit 62 together with the PAS TAG eliminator 60. The MECID consumer 64 consumes the MECIDs provided by the memory converter 16, each of which is associated with a different domain or execution environment. The MECID consumer 64 provides a key input for encrypting data passing through the encryption point (PoE) based on the MECID. This encryption can be separated from the encryption based on PAS execution. It is therefore feasible for each domain (each of which can be associated with a different MECID) to separately encrypt its own data in a way that the data cannot be accessed by other domains. Therefore, even if there is an error, misconfiguration, or attack on the RMM 46 that allows one domain to access the physical address space of another domain, data belonging to other domains is meaningless to that domain.

[0123] It should be noted that in this example, the PoE and MECID consumer 64 are shown combined with the PAS TAG remover 60. In principle, the PoE can be anywhere between the supplier of the MECID (e.g., the address translation circuit 16) and the PoPA 60, and the two elements 60, 64 can be executed sequentially rather than together. The elements of the memory hierarchy that appear between the requester device and the PoE will store data in an unencrypted manner and using the corresponding MECID. In contrast, other elements of the memory hierarchy (after the PoE) will store data in an encrypted manner without using the corresponding MECID.

[0124] Figure 4 5 shows how a granule protection table 56 may be used to divide a system physical address space 64 into blocks allocated for access within a particular architectural physical address space 61. A granule protection table (GPT) 56 defines which portions of a system physical address space 65 are allowed to be accessed from each architectural physical address space 61. For example, a GPT 56 may include several entries for each granule corresponding to a physical address of a particular size (e.g., a 4K page) and may define an assigned PAS for the granule, which may be selectable from non-secure, secure, domain, and root domains. By design, if a particular granule or group of granules is assigned to a PAS associated with one of the domains, it may only be accessed within the PAS associated with that domain and not within the PAS of other domains. However, it should be noted that while a granule assigned to a secure PAS (for example) cannot be accessed from within the root PAS, the root domain 82 is able to access that granule of physical addresses by specifying in its page table PAS selection information that ensures that virtual addresses associated with pages mapped to that region of physically addressed memory are translated to physical addresses in the secure PAS rather than in the root PAS. Thus, data sharing across domains (where permitted by the accessibility / inaccessibility rules defined in the earlier described tables) can be controlled at the point of selecting a PAS for a given memory access request.

[0125] However, in some implementations, in addition to allowing granules of physical addresses to access within the assigned PAS defined by the GPT, the GPT may use other GPT attributes to mark certain areas of the address space as shared with another address space (e.g., an address space associated with a domain of lower or orthogonal privilege that would normally not be allowed to select the assigned PAS for access requests to that domain). This may facilitate temporary sharing of data without requiring a change to the assigned PAS for a given granule. For example, in Figure 4 In the example, region 70 of the domain PAS is defined in the GPT as being assigned to the domain domain, and will generally be inaccessible from the non-secure domain 86 since the non-secure domain 86 cannot select the domain PAS for its access requests. Since the non-secure domain 26 cannot access the domain PAS, the data in region 70 is generally not visible to non-secure code. However, if the domain temporarily wishes to share some of its data in its assigned memory area with the non-secure domain, it may request the monitoring code 29 operating in the root domain 82 to update the GPT 56 to indicate that region 70 will be shared with the non-secure domain 86, and this may make region 70 also visible to the non-secure code. Figure 4 The non-secure PAS shown on the left can be accessed by the domain domain 70 without changing which domain is the assigned domain for region 70. If the domain domain has designated a region of its address space as shared with the non-secure domain, then although a memory access request designated for that region issued from the non-secure domain may initially specify the non-secure PAS, the PAS filter 20 may remap the PAS identifier of the request to instead specify the domain PAS so that downstream memory system components treat the request as if it had always been issued from the domain domain. Since the operation of assigning different domains to a particular memory region involves a greater degree of cache / TLB invalidation and / or data zeroing in memory or copying of data between memory regions that may be more performance intensive than would otherwise be necessary if the sharing was intended to be only temporary, this sharing may improve performance.

[0126] Portions of a domain PAS are assigned to each currently in use domain within the system. Access to these sub-areas 90, 92 within a domain PAS may be restricted / controlled by the RMM 46 as previously discussed. However, in addition, the contents of each sub-area 90, 92 may be encrypted differently depending on the domains associated with these sub-areas in the domain PAS. For example, a first sub-area 90 is associated with a first domain R0 and the data within that sub-area is therefore encrypted differently than the contents of a second sub-area 92 associated with a second domain R1. In addition, each PAS is encrypted. Figure 4In the example of , each PAS is encrypted with a different key, and the sub-areas are then further encrypted with different individual keys. In other embodiments, the realm domains themselves may not have a master key, and the individual realms themselves may be encrypted instead. Each realm / execution environment has its own encrypted area of ​​the PAS that other execution environments (realms) cannot access. In addition, due to encryption, the realms cannot access the secure realm or the root realm.

[0127] It should be noted that the PAS is provided along with the physical address in a memory access request. Thus, the memory treats two requests for the same physical address (with different PAS) as requests for different physical addresses, even though the same physical address is actually being accessed. This "obfuscation" is important because it provides a more secure separation of the PAS. Therefore, cache timing attacks that make inferences about privileged data based on whether the privileged data is present in the cache become infeasible if not impossible. Data stored in a cache for one PAS is not accessible to another PAS.

[0128] Figure 5 Summarizing the operation of the address translation circuit 16 and the PAS filter. The PAS filtering 20 can be viewed as an additional 3-stage check performed after the stage 1 (and optionally stage 2) address translation performed by the address translation circuit. It should also be noted that the EL3 translation is based on providing two bits of address-based select information (in Figure 5 In the example of , the page table entry marked NS, NSE), and the single bit of selection information "NS" is used to select the PAS in other states. Figure 5 The security state as input to the granule protection check in refers to the domain ID identifying the current domain of the processing element 4. The MECID is provided by the stage 2 MMU in the case of EL0 and EL1, whereas the MECID is provided by the stage 1 MMU in the case of software executing at EL2 and EL3.

[0129] In practice, the translation table need not store the MECID directly, and in fact doing so would significantly increase the size of the page table entry. Figure 6As shown, each entry 98 of the page table in the address translation circuit 16 contains attributes 100, which may indicate access permissions, memory type, access, and dirty status, etc. A PAS indicator field 102 is used to indicate which PAS is used for the entry. In the case of the EL3 stage 1 translation table, the NS and NSE bits are used to define the PAS (i.e., whether the root domain, secure domain, domain domain, or non-secure domain is being referenced). In the EL2 stage 1 table and in the EL1 and EL0 stage 2 tables, it is the NS bit that is used alone in the domain (and sometimes secure) state. This allows access to either target, i.e., NS=0 refers to the domain (or secure) PAS and NS=1 refers to the non-secure PAS. Additionally, an AMEC flag 104 is provided. This indicates which MECID storage register will be used to provide the MECID value. In this case, the AMEC field is 1 bit (0 or 1) and therefore indicates whether the value stored in the first register 94 should be used or whether the value stored in the second register 96 should be used. With subsequent increases in the size of the AMEC field, other numbers of registers may of course be provided. Finally, each entry 98 of the page table contains the (physical) page number 106 to which the entry 98 relates. Once the MECID has been established, it is provided as part of an outgoing memory request, where it is ultimately consumed by the MECID consumer 64 to perform encryption / decryption.

[0130] By storing the MECID itself in registers 94, 96, and by storing only a pointer in an entry 98 of the page table, it is possible to keep the pages smaller. By providing a set of registers 94, 96, it is possible to use multiple MECIDs simultaneously - for example, if a particular domain has its own MECID, but also has access to an area of ​​physical space shared with another domain, then both the domain's own MECID and the MECID for the shared space can be stored simultaneously. Similarly, the hypervisor 34 can use an alternate MECID register 96 to load the domain's MECID to access the physical address space belonging to that particular domain. By providing multiple MECID registers 94, 96, it is also possible to keep the MECID size independent of the format of the page table. It is also possible to use large MECIDs (e.g., values ​​that span multiple registers). In some examples, multiple registers may be used to store different MECIDs for different virtual to physical conversion areas. For example, for the example shown in Figure 5 For each of the different exception levels in the field, a different MECID register may be used.

[0131] It will be appreciated that the RMM 46 and / or hypervisor 34 is responsible for loading the correct MECID value into the registers 94, 96 during a context switch operation. That is, the MECID used by the new in-use realm will be loaded into these registers 94, 96.

[0132] Figure 7 An example is shown of a MECID consumer at PoE 64 operating with a PAS TAG remover at PoPA 60. Here, an incoming memory access request is received with the MECID and PAS. The incoming memory access request therefore misses or is discarded from other caches 24 of the memory hierarchy.

[0133] In the case where the memory access reaches the MECID consumer 64, the corresponding first key input is found using PAS, and the corresponding second key input is found using MECID. In the case of providing multiple MECID tables (e.g., for each PAS), PAS is also used to select which MECID table to use to obtain the second key input. The key input may be a key for performing the first and second stage encryption. Alternatively, the key input may be a key that is mathematically combined together (e.g., hashing the bits together or appending) to form a further key. In some examples, each of the two inputs is a part of the key (wherein the default value is used or provided for the world outside the domain world). The key input may also be or alternatively be a fine-tunable bit. Other possibilities or combinations of these possibilities will also be understood by the technician. In any case, the key input is passed to the encryption / decryption unit 108. This uses the key input and the data itself to perform encryption (in response to a memory write request) or decryption (in response to a memory read request). In the case of a memory write request, the encrypted data is then written in the memory, and in the case of a memory read request, the decrypted data is provided back to the requestor device 4.

[0134] Therefore, the MECID itself is not a key (or key input) which may actually be much larger than the MECID. This eliminates the need to transmit a larger key across the system mesh architecture 24, 8. However, in examples where the PoE is closer to the generator of the MECID (e.g., the address translation circuit 16), it may be more practical to transmit the key input itself.

[0135] When a realm is established, new entries are added to the MECID consumer 64. Similarly, when a realm is deleted or terminated, these entries in the storage of the MECID consumer 64 are deleted and the data belonging to that process is no longer readable. In contrast, the key input provided to each PAS is static and is determined at device startup.

[0136] In examples where PoE and POPA are separate, a first stage encryption (eg, for a specific domain) and a second stage encryption (for PAS) may be performed.

[0137] The above description has focused on the use of MECID and encryption / decryption related to the domain. However, the same technology can also be applied in other worlds or domains, such as the secure world / domain.

[0138] Figure 8 A flowchart 110 is shown according to some of the above examples, wherein a key is obtained using two inputs (as opposed to the input being used directly in the encryption / decryption phase). In step 112, a memory access request is received. In step 114, a first key input for a particular domain is obtained (e.g., based on PAS). This key input is fixed at boot time. In step 116, a second key input is obtained based on the current execution environment. This key input is dynamic in the sense that the key input exists as long as the associated execution environment for this key input exists. In step 118, a key is obtained using the key input. Next, in step 120, it is determined whether the memory access request is a write request. If not, the data obtained from the memory is decrypted using the key in step 122. Otherwise, in step 124, the data is encrypted using the key and stored in the memory. As explained above, the explicit step 118 of obtaining the key may be omitted and the key input is used directly in the decryption 122 and / or encryption 124 steps.

[0139] Fig. 9 The simulator that can be used is shown to be implemented. Although the embodiment described earlier implements the present invention with the device and method for operating the specific processing hardware of the technology concerned, it is also possible to provide an instruction execution environment according to the embodiment described herein, which is implemented by using a computer program. Such computer programs are often called simulators because they provide a software-based implementation of the hardware architecture. The types of simulator computer programs include emulators, virtual machines, models, and binary converters (including dynamic binary converters). In general, the simulator is implemented and can be run on a host processor 430 that optionally runs a host operating system 420 and supports the simulator program 410. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulators that are implemented at reasonable speeds, but this method may be justified in some cases, such as when it is necessary to execute another processor native program code because of compatibility or reuse reasons. For example, the simulator can be implemented to provide an instruction execution environment with additional functionality that is not supported by the host processor hardware, or to provide an instruction execution environment that is generally associated with different hardware architectures. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0140] Where an embodiment has been previously described with reference to a particular hardware architecture or feature, in an analog embodiment, equivalent functionality may be provided by a suitable software architecture or feature. For example, a particular circuit may be implemented as computer program logic in an analog embodiment. Similarly, memory hardware (such as registers or caches) may be implemented as software data structures in an analog embodiment. Where one or more of the hardware elements mentioned in the previously described embodiments are present in an arrangement on host hardware (e.g., host processor 430), some analog embodiments may utilize host hardware (where appropriate).

[0141] The simulator program 410 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to the target code 400 (which may include applications, operating systems, and hypervisors) that is the same as the program interface of the hardware architecture modeled by the simulator program 410. Thus, the program instructions of the target code 400 may be executed within the instruction execution environment using the simulator program 410, so that a host computer 430 that does not actually have the hardware features of the apparatus 2 discussed above may emulate these features. For example, since the target code may be tested by running within a simulator executed on a host device that does not support the architecture, this may be useful to allow the target code 400 developed for a new version of the processor architecture to be tested before hardware devices that actually support the architecture are available.

[0142] The simulator code includes handler logic 412 that emulates the behavior of the processing circuit 10, for example, including instruction decoding program logic that decodes instructions of the target code 400 and maps the instructions to corresponding instruction sequences in the native instruction set supported by the host hardware 430 to perform functions equivalent to the decoded instructions. The handler logic 412 also emulates the processing of the code at different exception levels and domains as described above. Register emulation logic 413 maintains data structures in the host address space of the host processor that emulate the architectural register states defined according to the target instruction set architecture associated with the target code 400. Thus, instead of Figure 1 In the example of storing such architectural state in hardware registers 12, which are instead stored in the memory of the host processor 430, where register emulation logic 413 maps register references of instructions of the target code 400 to corresponding addresses for obtaining emulated architectural state data from the host memory. This architectural state may include the current domain indication 14 and the current exception level indication 15 described earlier, as well as the MECID register 94 and the ALT MECID register 96 described earlier.

[0143] The emulation code includes memory protector logic 416 and address translator logic 414 that emulate the functionality of the MECID consumer 64 and address translation circuitry 16, respectively. Thus, the address translator logic 414 translates virtual addresses specified by the target code 400 into emulated physical addresses in one of the PASs (which from the target code's point of view refer to physical addresses in memory), but actually maps these emulated physical addresses onto the (virtual) address space of the host processor via the address space mapper logic 415. The memory protector logic 416 "consumes" the MECID provided as part of the memory access request, and provides one or more key inputs used to encrypt / decrypt data from memory.

[0144] Fig.10 The location of encryption points and the extent to which clearing and invalidation operations extend within the system are shown. As previously described, address translation circuitry 16 in the form of one or more stages 50, 52 of the MMU is used to translate virtual addresses (VA) into physical addresses (PA) and (where access is generated by an execution environment) MECIDs. MECIDs are examples of encryption environment identifiers for data that encrypts data passing through the PoE for a particular execution environment. The granular memory protection unit 20 is used to provide a PAS TAG associated with the physical address space to be accessed (although this can also be provided directly from the address translation circuitry 16). A combination of the PAS TAG PA and (where appropriate) the MECID is used to access data held in a particular physical address space (identified by the PAS TAG) at a particular physical location (identified by the PA) associated (if applicable) with a particular execution environment (using the MECID). After the PoE, any MECIDs are consumed and used to perform encryption / decryption on the storage circuitry beyond the PoE.

[0145] like Fig.10 As shown, the PoE can be located anywhere within the cache hierarchy 24. As it moves closer to the processor, more cache stores encrypted data. As the PoE moves closer to the memory, less cache stores encrypted data and instead stores unencrypted data together with the MECID. For example, in Fig.10 In the example of , the cache hierarchy 24 is composed of a first-level cache 130, a second-level cache 132, and a third-level cache 134. If the PoE is located between the first-level cache 130 and the second-level cache 132, the data will be stored unencrypted in the first-level cache 130 and encrypted in the second-level cache 132, the third-level cache 134, and the main memory. In contrast, if the PoE is located between the second-level cache 132 and the third-level cache 134, the data will be stored encrypted in the third-level cache 134 and the main memory, but will be stored unencrypted in the first-level cache 130 and the second-level cache 132.

[0146] In the case where PoE is different from PoPA, encryption related to MECID occurs through PoE, while further encryption can occur at PoPA (to a different PAS). It should be noted that in some embodiments, encryption of data within the PAS that has been encrypted at PoE does not occur.

[0147] During the operation of the cache, maintenance operations may need to be performed. This includes clearing and invalidation operations (which are specific types of invalidation operations), which can be performed due to changes in memory assignment (such as removal from the execution environment or assignment to a new execution environment). At least some of these cache maintenance operations are only performed to the PoE at most and do not exceed it. For example, when the execution environment expires, the data belonging to the execution environment must continue to be protected. After the PoE, the data is encrypted and therefore protected, the key used for encryption is deleted, and the data is no longer accessible. However, before the PoE in the cache level 24, the data is stored in an unencrypted manner and should therefore be removed from the cache to prevent different execution environments with the same MECID from accessing the data (the MECID identifier space may be small and therefore reused). To achieve this, cache maintenance operations are performed to the PoE at most, resulting in data invalidation (and therefore making it no longer accessible). In some embodiments, the actual operation is a clearing and invalidation operation, even if the clearing of the data (writing it back to the memory) has no effect on the expired execution environment.

[0148] Fig.11 The relationship between the cache hierarchy 24, the PoE 64, and the PoPA 60 is shown. As previously described, the PoE 64 may be located anywhere within the cache hierarchy 24. For example, the PoE 64 may appear after all caches in the cache hierarchy 24, before main memory, or it may be located before the cache hierarchy 24. The PoPA 60 is located on or after the PoE 64. For example, the PoE 64 and the PoPA 60 may be located at the same point somewhere in the cache hierarchy 24. In some examples, the PoE 64 and the PoPA 60 may be located at alternating ends of the cache hierarchy—that is, the PoE 64 may appear before the cache hierarchy 24 and the PoPA 60 may appear at the end of the cache hierarchy 24. Thus, there may be three different "zones" within the memory hierarchy: a first set of storage circuits where data is unencrypted and obfuscated (up to PoE 64), a second set of storage circuits where data is encrypted and obfuscated (between PoE 64 and PoPA 60), and a third set of storage circuits where data is encrypted and unobfuscated (after PoPA 60).

[0149] As previously explained, cache maintenance operations related to changes in memory assignments are issued to those caches in the cache hierarchy that precede, but do not pass through, the PoE 64. Other cache maintenance operations, such as the movement of data or memory pages from one domain to another, may pass through the PoE 64 and up to the PoPA 60, and still other cache maintenance operations may permeate the entire memory hierarchy.

[0150] Fig.12 A flow chart 140 is shown that illustrates the behavior of cache maintenance in more detail from the perspective of a particular cache. At step 142, a cache maintenance operation (CMO) is received by the cache. The cache maintenance operation contains an indication of the target and the location of the PoE 64. The target may be, for example, a physical address associated with a transferred specific area of ​​memory (e.g., belonging to an execution environment that is known to have expired), or may identify the MECID itself, depending on the architecture of the cache. At step 144, the cache determines whether it is before the PoE 64 in the hierarchy. If not, there is nothing further to be done and the process ends (or returns to the beginning). Otherwise, at step 146, the target is cleared and invalidated. Then, at step 148, a new CMO is issued to the cache at the next cache level. The new CMO contains the same target and the same indication of the PoE 64. In this way, only the cache lines identified by the CMO are invalidated. However, this only occurs up to the PoE 64. Past this point, this type of CMO is ignored and not forwarded. Data belonging to the target cache lines is encrypted after passing PoE64, so invalidation of these cache lines is not strictly necessary.

[0151] Other cache maintenance operations may also be applied and handled in the usual manner, i.e., they may still propagate after PoE 64 (if appropriate).

[0152] Thus, different cache maintenance instructions may be issued for each move of memory between execution environments, and for moves of memory between domains. Still further instructions may be provided for other cache maintenance operations.

[0153] Fig.13AThe target of the cache maintenance operation is shown. In this example, the maintenance operation is caused by assigning memory to an execution environment. This may occur, for example, due to the expiration and / or establishment of a specific execution environment. The domain management module (RMM) causes the cache maintenance operation to be performed on addresses 0x2132 and 0xC121. However, the hypervisor 32 or operating system may similarly be responsible for the execution of such operations. In any case, the cache maintenance operation is sent to the first-level cache 130. These operations cause the corresponding entries in the cache to be invalidated. The cache maintenance operation is then sent through the memory hierarchy, up to but not beyond the PoE 64. In this case, this includes the first-level cache 130 and the second-level cache 132. However, the third-level cache 134 is not affected, that is, the cache maintenance operation is not forwarded. In each case, the entry marked with address 0xC121 or 0x2132 (due to the relevant cache being before the PoE 64, which is not encrypted) is invalidated (or cleared and invalidated). Invalidation does not occur past PoE 64 (due to these CMOs) as these entries are encrypted and inaccessible.

[0154] Fig. 13B The target of the cache maintenance operation is shown. In this example, the maintenance operation is caused by the expiration of the execution environment (0xF1). For example, the expiration of the execution environment is managed by the domain management module (RMM) 46, although similar cache maintenance operations can be issued by the hypervisor 34 instead. In any case, an instruction is issued to indicate that the memory associated with this execution environment should be invalidated. The MECID for the corresponding execution environment is found. Again, this can be performed by the RMM or the hypervisor 34, but can also be determined by another component. Then, an invalidation instruction is sent out with reference to the specific MECID associated with the expired execution environment (in this case, 0xF14E). As previously explained, this invalidation instruction is sent through the memory hierarchy, up to but not exceeding the PoE 64. In this case, this includes the first-level cache 130 and the second-level cache 132. In each case, the entry marked with MECID 0xF14E (due to the relevant cache being before the PoE, which is not encrypted) is invalidated (or cleared and invalidated).

[0155] It should be noted that the lookup performed between the execution environment and the MECID allows MECIDs that are not associated with any single execution environment, thereby allowing data sharing. In these cases, the entry belonging to this MECID may be invalidated when a specific one of the associated execution environments (if, for example, one of the execution environments acts as the "master environment" of the MECID) terminates, or may be invalidated when all associated execution environments terminate. A further reason for separating the execution environment identifier and the MECID is to limit the reuse of the MECID and allow more MECIDs to exist simultaneously than the MECID currently in use. For example, the execution environments can be made dormant (not in use), but their data can be kept within the system. In this example, for example, there may be only 256 execution environments that can run simultaneously (because the execution environment identifier is 8 bits). However, the MECID identifier is larger (16 bits), and therefore, the execution environment can be swapped in and out.

[0156] Due to the above, the cache hierarchy is less affected by cache maintenance operations. This is because certain cache maintenance operations (e.g., those that invalidate expired execution environments) do not need to occur after the PoE has passed. Therefore, the system impact of invalidation requests can be reduced. Since after the PoE has passed, the data is encrypted and therefore, even if another execution environment accesses these memory items, these memory items will not be understandable, which will not compromise security. The cache maintenance operations that invalidate these data entries are therefore not used for useful purposes.

[0157] Fig.14 A data processing method 140 according to some examples is shown. At step 142, processing is performed in one of a plurality of (e.g., two or more, such as three or more) domains. One of these domains is further divided into a number of execution environments (e.g., domains). Processing accesses memory within a memory hierarchy. At step 144, encryption points are defined within the memory hierarchy. This divides the memory hierarchy into an encrypted component (where the data is stored in encrypted form) and an unencrypted component (where it is not). Next, at step 146, at least some maintenance operations to be issued (such as those associated with an expired execution environment) are suppressed at or beyond the issuance of the PoE 64. These cache maintenance operations are not issued to storage circuits where data is stored in encrypted form.

[0158] Fig.15The simulator that can be used is shown to be implemented. Although the embodiment described earlier implements the present invention with the device and method for operating the specific processing hardware of the technology concerned, it is also possible to provide an instruction execution environment according to the embodiment described herein, which is implemented by using a computer program. Such computer programs are often called simulators because they provide a software-based implementation of the hardware architecture. The types of simulator computer programs include emulators, virtual machines, models, and binary converters (including dynamic binary converters). In general, the simulator is implemented and can be run on a host processor 430 that optionally runs a host operating system 420 and supports the simulator program 410. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulators that are implemented at reasonable speeds, but this method may be justified in some cases, such as when it is necessary to execute another processor native program code because of compatibility or reuse reasons. For example, the simulator can be implemented to provide an instruction execution environment with additional functionality that is not supported by the host processor hardware, or to provide an instruction execution environment that is generally associated with different hardware architectures. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0159] Where an embodiment has been previously described with reference to a particular hardware architecture or feature, in an analog embodiment, equivalent functionality may be provided by a suitable software architecture or feature. For example, a particular circuit may be implemented as computer program logic in an analog embodiment. Similarly, memory hardware (such as registers or caches) may be implemented as software data structures in an analog embodiment. Where one or more of the hardware elements mentioned in the previously described embodiments are present in an arrangement on host hardware (e.g., host processor 430), some analog embodiments may utilize host hardware (where appropriate).

[0160] The simulator program 410 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to the target code 400 (which may include applications, operating systems, and hypervisors) that is the same as the program interface of the hardware architecture modeled by the simulator program 410. Thus, the program instructions of the target code 400 may be executed within the instruction execution environment using the simulator program 410, so that a host computer 430 that does not actually have the hardware features of the apparatus 2 discussed above may emulate these features. For example, since the target code may be tested by running within a simulator executed on a host device that does not support the architecture, this may be useful to allow the target code 400 developed for a new version of the processor architecture to be tested before hardware devices that actually support the architecture are available.

[0161] The simulator code includes handler logic 412 that emulates the behavior of the processing circuit 10, for example, including instruction decoding program logic that decodes instructions of the target code 400 and maps the instructions to corresponding instruction sequences in the native instruction set supported by the host hardware 430 to perform functions equivalent to the decoded instructions. The handler logic 412 also emulates the processing of the code at different exception levels and domains as described above. Register emulation logic 413 maintains data structures in the host address space of the host processor that emulate the architectural register states defined according to the target instruction set architecture associated with the target code 400. Thus, instead of Figure 1 In the example of storing such architectural state in hardware registers 12, it is instead stored in the memory of the host processor 430, where register emulation logic 413 maps register references of instructions of the target code 400 to corresponding addresses for obtaining simulated architectural state data from the host memory. This architectural state may include the current domain indication 14 and the current exception level indication 15 described earlier, as well as the MECID register 94 and the ALT MECID register 96 described earlier. Similarly, the storage circuit emulation program logic 148 maintains a data structure in the host address space of the host processor that emulates the memory hierarchy. Thus, instead of (for example) Fig.10 The data in the example is stored in the L1 cache 130, the L2 cache 132, the L3 cache 134, and the memory 150, which is instead stored in the memory of the host processor 430, where the storage circuit emulation program logic 148 maps the memory addresses of the instructions of the target code 400 to corresponding addresses for obtaining the simulated memory addresses from the main memory.

[0162] The emulation code includes memory protection program logic 416 and address translation program logic 414 that emulate the functionality of the MECID consumer 64 and the address translation circuit 16, respectively. Thus, the address translation program logic 414 converts the virtual address specified by the target code 400 into an emulated physical address in one of the PASs (which refers to a physical address in memory from the point of view of the target code), but actually maps these emulated physical addresses to the virtual storage structures 130, 132, 134, 150 emulated by the storage circuit emulation program logic 148 via the address space mapping program logic 415. As previously described, the memory protection program logic 416 "consumes" the MECID provided as part of the memory access request and provides one or more key inputs used to encrypt / decrypt data from the memory. The storage circuit emulation logic 148 may also emulate the functionality of the cache maintenance operations, encryption points 64, and physical obfuscation points 60 as previously described.

[0163] Fig.16 An example system according to some examples is shown. In these examples, a memory access request for a virtual address is issued by an execution environment (realm) running in a subdivided world / domain (i.e., a domain domain) on a processing circuit 10. The memory access request is received by a memory conversion circuit (e.g., an address conversion circuit) 16. Here, the virtual address (VA) is converted into a physical address (PA). Additionally, the PAS is determined and the MECID is determined as previously described. The memory access request is then sent to the memory hierarchy to locate the requested data. In this example, it is received by the storage circuit in the form of a first-level cache 130. In this example, because the first-level cache appears before the PoE 64, the contents of the first-level cache 130 are unencrypted. Each unencrypted cache line entry therefore stores data associated with the address, PAS, and MECID of the cache line.

[0164] A "hit" occurs on the cache if / when the physical memory address (PA) corresponds to one of the cache lines stored in the cache. In this case, the requested data is returned, and the memory access request therefore does not need to proceed to the main memory 150. In contrast, a "miss" occurs when no cache line corresponds to the requested physical memory address (no cache line stores the requested data). In this case, the memory access request is forwarded further up the memory hierarchy toward the main memory 150. When the requested data is located (which may be in the main memory), the data may be stored in the lower level cache 130 so that it may be accessed more quickly in the future.

[0165] As previously mentioned, each cache line in cache 130 stores data associated with the physical address of the cache line, the data of the cache line, the identity of the physical address space (PAS) with which the data is associated, and a MECID, which is an example of a cryptographic environment identifier and can be associated with a subset of execution environments (often a specific execution environment). This is the execution environment (or environments) that "owns" the data. In response to a hit, determination circuitry 180 determines whether there is a match between the MECID of the hit entry of storage circuitry 130 and the MECID provided in the memory access request.

[0166] Fig.17 An example of a MECID mismatch is shown. This may occur for several reasons. For example, a table in the memory translation circuit 16 may contain multiple entries for the same PA (each belonging to a different MECID). It may also be inadequate to perform cache maintenance operations when the MECID is reassigned. The MECID width may be too large for the system, resulting in duplication of components of the MECID that are actually used. In some cases, mismatches may occur due to inadequate translation lookaside buffer (TLB) maintenance and barriers when updating the MECID register.

[0167] In any case, this example illustrates a memory read request issued from a memory conversion circuit. The request is for physical address 0xB1432602. This is composed of a cache line address of 0xB14326 and an offset into the cache line of 02, which is the specific portion of the cache line that the memory read request is seeking to read. The request also points to a PAS of 01 (which in this example refers to a domain PAS) and a MECID of 0xF143, which is an MECID associated with the execution environment or domain to which the memory read request was issued. This is received by the storage circuit 130, which determines whether a hit exists on the accessed memory address. In this case, since the storage circuit 130 contains an entry with a cache line address of 0xB14326, a hit exists. PAS (01) also matches. However, in this case, although there is a hit, the determination circuit is able to determine (by comparison) that the MECID mismatches. Specifically, the MECID sent with the request is 0xF143, whereas the MECID stored for the cache line is 0xF273. Thus, the request was issued by an execution environment that should not have access to the line. Thus, an erroneous action may be caused.

[0168] Since a MECID may be associated with several execution environments (in case data is to be shared between these execution environments), please remember that a MECID does not necessarily identify a specific execution environment.

[0169] There are several error actions that can be taken and several configurations that can be employed to prevent a mismatch from occurring.

[0170] Fig.18 A corruption mode of operation is shown in which a corruption of a cache line is caused in response to a mismatch. Here, a memory write request is issued that specifies a particular portion of a cache line. However, a mismatch with the MECID occurs. In this example, the specified portion of the cache line is overwritten / modified by the write request. These portions are now expected to be correct and therefore not corrupted. However, other portions of the cache line are recorded as being corrupted. If these corrupted portions of the cache line are read by the processing circuitry in the future (e.g., due to a later memory read request for these portions of the cache line), a corruption notification is provided back to the processing circuitry. This in turn results in a synchronization error being caused by the processing circuitry.

[0171] By not creating an error immediately, it is possible to completely avoid any such errors. For example, if no future memory read requests are issued for other parts of the cache line, the corruption notification will never be delivered back to the processor and an error will never be caused. Therefore, although the mismatch should not occur, it has no effect.

[0172] In other embodiments, the entirety of a cache line may be corrupted as a result of a write to any portion of the cache line, since the overwritten data can be said to have caused the original data to be corrupted. In other examples, a memory read request will cause part or all of the cache line to be corrupted and immediately returned to the processing circuitry, which will (almost immediately) cause a synchronization error to be caused. In some examples, all or part of the data returned from the cache as part of the read request is corrupted, but the cache line itself remains unmodified.

[0173] Also in this example, in addition to destroying the mismatching cache line, the MECID of the cache line is updated to the MECID provided in the memory access request.

[0174] Fig.19 An example implementation is shown in which the obfuscated operation mode is shown. Here, a memory read request hit or miss is determined based on PA, PAS, and MECID. That is, an "effective address" is formed using all three components. In this example, the first read request is about address 0xB1432620, and a MECID of 0x2170 is used. Obviously, since the PA matches, the address should hit on entry 182 in cache 130. However, because the MECID, PAS, and PA are considered to be the total effective "address" and because all three do not match (the MECID of entry 182 is 0xF273 compared to the MECID of 0x2170 requested), a miss exists. This can be determined by determination circuit 180, which seeks a match on each of PA, PAS, and MECID.

[0175] In contrast, a second memory read request made to the exact same PA and PAS with a different MECID of 0xF273 will hit since the PA, PAS, and MECID all match.

[0176] If the PA, PAS and MECID are the same in both the cache line and the memory access request, then a memory access request due to a physical address may only hit the cache line, thus preventing a mismatch from occurring.

[0177] There are several actions that can be taken in response to a miss. In some examples, a mismatch in the MECID alone can be used to inhibit any further progress of the request. In other examples, the miss will be forwarded up the memory hierarchy. When the request reaches the PoE, the incorrect MECID will be used to select the key input, which may therefore result in incorrect decryption of the requested data (in the case of a read request) or incorrect encoding of the provided data (in the case of a write request). However, in both cases, the goal of maintaining the secrecy of the data is maintained.

[0178] Fig. 20 An example of a flush mode of operation is shown. Here, when a mismatch is detected, the mismatching cache line in cache 130 is flushed (written back further up the memory hierarchy, such as past the encryption point, such as back to memory). The mismatching line is then invalidated and the requested line is then fetched from memory.

[0179] Thus, in this example, the memory access read at address 0xB1432620 with MECID 0xF273 mismatches on cache line address 0xb14326 with MECID 0x2170. The cache line is therefore written back to memory (cleared) and invalidated (the "V" flag changes from 0 to 1). Next, the subject of the request (address 0xB1432620) is extracted from memory with MECID 0x2170. In practice, this memory access request may still fail if the MECID is not correct in the memory hierarchy. Specifically, after the encryption point, if the MECID is incorrect, the wrong key input will be selected for decryption and garbage will be returned by the memory access request. In any case, the extracted data is then stored in cache 130 using the MECID of the new access request.

[0180] Fig.21 An example of an erase mode of operation is shown. In this mode of operation, when a mismatch is detected, the data of the mismatched line in cache 130 is zeroed, scrambled, or randomized so that it is no longer intelligible. The line is thus made unusable. It should be noted that this is different from the operation of invalidating a cache line (e.g., by setting the validity flag "V" to 0).

[0181] In this example, therefore, the mismatch is caused by a memory request to address 0x94130001, which hits on the cache line at address 0x941300. However, the mismatch occurs because the request has a MECID of 0x2142 and the cache line has a MECID of 0x7D04. The cache line with an address of 0x941300 (in this case) is therefore zeroed by setting all bits of the data to 0. The cache line can then be returned. Thus, the unencrypted data is rendered inaccessible. It should be noted that in this example, the cache line is not invalidated (although this mode of operation may additionally set the cache line to invalid).

[0182] Fig. 22 An example of the overall process is shown in the form of a flowchart 190. At step 192, a memory access request is received by the storage circuit 130. At step 194, it is determined whether a hit exists. If not, then at step 196, the request is forwarded further into the memory hierarchy, for example, toward the main memory 150. The process then returns to step 192. Otherwise, at step 198, it is determined (e.g., by determining circuit 180) whether a mismatch occurs between the MECID of the memory access request and the hit entry in the storage circuit 130. If not, then at step 200, the memory access request is completed (e.g., by reading or writing the relevant entry in the storage circuit 130), and the request then proceeds to step 192. Otherwise, at step 202, it is determined in which mode the system is operating. If the system is in a destruction operation mode at step 202, the entry in the storage circuit 130 is destroyed as previously described. The process then proceeds to step 210. If the system is in the clear mode of operation, then at step 204, the entries in the storage circuit 130 are cleared and invalidated, and the process then proceeds to step 210. If the system is in the erase mode of operation, then at step 206, the entries in the storage circuit 130 are zeroed or scrambled. The process then proceeds to step 210. These are all examples of erroneous modes of operation in which mismatches result in errors. In contrast, the scramble mode of operation ( Fig.19 The error mode and the confusion mode together form the enabled mode of operation. The other mode of operation of the determination circuit 180 is, at step 208, the disabled mode of operation, which simply ignores the mismatch and completes the request. The process then continues to step 210.

[0183] After some enabled operating modes, the process proceeds to step 210 to determine whether the synchronous mode is also enabled. If so, then at step 212, an asynchronous exception is also generated (e.g., by writing to register 12 associated with processing circuit 10 in relation to a mismatch). In either case, the process then returns to step 192.

[0184] In each of the error operation modes, the MECID of the mismatching entry may also be updated to the MECID of the incoming memory access request.

[0185] The device may be able to switch between enabling each or a subset of the operating modes and disabling operation at runtime. Each of the enabled operating modes is dependent and the system may include any combination of these modes. A disabled mode may also exist, or may not exist.

[0186] Fig.23 The interaction between the enabled modes and speculative execution is shown in the form of a flow chart 214. In speculative execution, instructions are executed before it is known whether they should be executed (e.g., to put on hold the results of branch instructions). Speculative reads may occur using the wrong MECID (as previously explained), and therefore it may be desirable to have one of the enabled modes in use for speculative execution to occur. In step 216, a determination is made as to whether the determination circuit 180 is in an enabled operating mode. If so, then in step 218, a speculative operating mode that permits speculative reads and writes to occur is enabled. If not, the speculative operating mode is disabled. This prevents speculative read operations from occurring (and in some embodiments, may also prevent speculative write operations). Regardless, the process then returns to step 216.

[0187] As an alternative to this process, rather than continuing to “poll” the current operating mode of determination circuitry 180 , the speculative operating mode may be enabled / disabled each time the operating mode of determination circuitry 180 changes.

[0188] Fig.24The simulator that can be used is shown to be implemented. Although the embodiment described earlier implements the present invention with the device and method for operating the specific processing hardware of the technology concerned, it is also possible to provide an instruction execution environment according to the embodiment described herein, which is implemented by using a computer program. Such computer programs are often called simulators because they provide a software-based implementation of the hardware architecture. The types of simulator computer programs include emulators, virtual machines, models, and binary converters (including dynamic binary converters). In general, the simulator is implemented and can be run on a host processor 430 that optionally runs a host operating system 420 and supports the simulator program 410. In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulators that are implemented at reasonable speeds, but this method may be justified in some cases, such as when it is necessary to execute another processor native program code because of compatibility or reuse reasons. For example, the simulator can be implemented to provide an instruction execution environment with additional functionality that is not supported by the host processor hardware, or to provide an instruction execution environment that is generally associated with different hardware architectures. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

[0189] Where an embodiment has been previously described with reference to a particular hardware architecture or feature, in an analog embodiment, equivalent functionality may be provided by a suitable software architecture or feature. For example, a particular circuit may be implemented as computer program logic in an analog embodiment. Similarly, memory hardware (such as registers or caches) may be implemented as software data structures in an analog embodiment. Where one or more of the hardware elements mentioned in the previously described embodiments are present in an arrangement on host hardware (e.g., host processor 430), some analog embodiments may utilize host hardware (where appropriate).

[0190] The simulator program 410 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a program interface (an instruction execution environment) to the target code 400 (which may include applications, operating systems, and hypervisors) that is the same as the program interface of the hardware architecture modeled by the simulator program 410. Thus, the program instructions of the target code 400 may be executed within the instruction execution environment using the simulator program 410, so that a host computer 430 that does not actually have the hardware features of the apparatus 2 discussed above may emulate these features. For example, since the target code may be tested by running within a simulator executed on a host device that does not support the architecture, this may be useful to allow the target code 400 developed for a new version of the processor architecture to be tested before hardware devices that actually support the architecture are available.

[0191] The simulator code includes handler logic 412 that emulates the behavior of the processing circuit 10, for example, including instruction decoding program logic that decodes instructions of the target code 400 and maps the instructions to corresponding instruction sequences in the native instruction set supported by the host hardware 430 to perform functions equivalent to the decoded instructions. The handler logic 412 also emulates the processing of the code at different exception levels and domains as described above. Register emulation logic 413 maintains data structures in the host address space of the host processor that emulate the architectural register states defined according to the target instruction set architecture associated with the target code 400. Thus, instead of Figure 1 In the example of storing such architectural state in hardware registers 12, it is instead stored in the memory of the host processor 430, where register emulation logic 413 maps register references of instructions of the target code 400 to corresponding addresses for obtaining simulated architectural state data from the host memory. This architectural state may include the current domain indication 14 and the current exception level indication 15 described earlier, as well as the MECID register 94 described earlier. Similarly, the storage circuit emulation program logic 148 maintains a data structure in the host address space of the host processor that emulates the memory hierarchy. Thus, instead of (for example) Fig.10 The data in the example is stored in the L1 cache 130, the L2 cache 132, the L3 cache 134, and the memory 150, which is instead stored in the memory of the host processor 430, where the storage circuit emulation program logic 148 maps the memory addresses of the instructions of the target code 400 to corresponding addresses for obtaining the simulated memory addresses from the main memory.

[0192] The emulation code includes address translation program logic 414 that emulates the functionality of the address translation circuit or memory translation circuit 16, respectively. Thus, the address translation program logic 414 converts virtual addresses specified by the target code 400 into emulated physical addresses in one of the PASs (which from the point of view of the target code refers to physical addresses in memory), but actually maps these emulated physical addresses onto virtual storage structures 130, 132, 134, 150 emulated by the storage circuit emulation program logic 148 via the address space mapping program logic 415. The determination program logic 151 is capable of determining whether the MECID supplied as part of the emulated memory access request for the memory address matches the MECID associated with the entry for the memory address in the emulated memory hierarchy 148, and thus performs the functionality of the determination circuit 180 described previously. The storage circuit emulation logic 148 may emulate the encryption point 64 and the physical obfuscation point 60 as previously described. The determination program logic 151 may determine whether a difference is detected between the encryption environment identifiers as previously discussed.

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

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

Claims

1. A device comprising: processing circuitry configured to perform processing in one of a fixed number of at least two domains, one of the domains being subdivided into a variable number of execution environments; a memory translation circuit configured to determine, in response to a memory access request to a given memory address, a given encryption environment identifier associated with one of the execution environments, and to forward the memory access request together with the given encryption environment identifier; A storage circuit configured to store a plurality of entries, each entry being associated with an associated encryption environment identifier and an associated memory address, wherein The storage circuitry includes a determination circuit configured to determine, in at least one enabled operating mode, whether the given encryption environment identifier is different from the associated encryption environment identifier associated with one of the entries associated with the given memory address.

2. The device according to claim 1, comprising: a memory protection circuit configured to use a key input to perform encryption or decryption on the data in response to the data of the memory access request not being present in the memory circuit, wherein The key input is based on the given encryption environment identifier; The key input for each of the domains is fixed at boot time of the device; and The key input for each of the execution environments is dynamic.

3. A device according to any preceding claim, wherein The storage circuit is configured to perform an error action in response to the given encryption environment identifier being different than the associated encryption environment identifier associated with the given memory address in at least one error operating mode.

4. A device according to any preceding claim, wherein The at least one enabled operating mode includes a destruction operating mode, in which the storage circuit is configured to destroy the one of the entries in response to the associated memory address of the one of the entries being the given memory address when the given encryption environment identifier is different from the associated encryption environment identifier associated with the one of the entries.

5. The device according to claim 4, wherein The processing circuitry is configured to generate an exception when the one of the entries is received by the processing circuitry.

6. The device according to any one of claims 4 to 5, wherein When the memory access request is a write memory access request, those portions of the one of the entries accessed by the write memory access request are modified and the remaining portions of the one of the entries are destroyed.

7. A device according to any preceding claim, wherein The at least one enabled operating mode includes an obfuscated operating mode in which the storage circuitry is configured to treat the entries of the storage circuitry as different when the associated memory addresses of the entries match and the associated encryption environment identifiers of the entries mismatch.

8. A device according to any preceding claim, wherein The at least one enabled operating mode includes a clear operating mode, in which the storage circuit is configured to clear and invalidate the one of the entries in response to the associated memory address of the one of the entries being the given memory address when the given encryption environment identifier is different from the associated encryption environment identifier associated with the one of the entries.

9. The device according to claim 8, wherein In the clear operation mode, in response to the associated memory address of the one of the entries being the given memory address when the given encryption environment identifier is different from the associated encryption environment identifier associated with the one of the entries, the storage circuit is further configured to treat the memory access request as a miss in the storage circuit.

10. An apparatus according to any preceding claim, wherein The processing circuitry is configured to, while in a speculative mode of operation, speculatively issue the memory access request as a speculative read request; and The speculative mode of operation is disabled unless the storage circuit is in the enabled mode of operation.

11. An apparatus according to any preceding claim, wherein The at least one enabled operating mode includes an erase operating mode, in which the storage circuit is configured to perform an erase of the one of the entries in response to the associated memory address of the one of the entries being the given memory address when the given encryption environment identifier is different from the associated encryption environment identifier associated with the one of the entries.

12. The device according to claim 11, wherein The storage circuit is configured to perform the erasing by zeroing or randomizing the one of the entries.

13. An apparatus according to any preceding claim, wherein When the memory access request is a write memory access request, the storage circuit is further configured to update the associated encryption identifier to correspond to the given encryption environment identifier.

14. An apparatus according to any preceding claim, wherein The determination circuitry is configured to suppress, in at least one disabled operating mode, a determination of whether the given encryption environment identifier is different than the associated encryption environment identifier associated with one of the entries associated with the given memory address.

15. An apparatus according to any preceding claim, wherein In at least some of the at least one enabled operating mode, in response to the associated memory address of the one of the entries being the given memory address when the given encryption environment identifier is different from the associated encryption environment identifier associated with the one of the entries, the storage circuit is configured to generate an asynchronous exception.

16. The device according to claim 15, wherein The storage circuitry is configured to generate the asynchronous exception and to store details of the memory access request in one or more registers accessible to the processing circuitry.

17. A method comprising: executing processing in one of a fixed number of at least two domains, one of the domains being subdivided into a variable number of execution environments; determining, in response to a memory access request to a given memory address, a given encryption environment identifier associated with one of the execution environments; forwarding the memory access request together with the given encryption environment identifier; storing a plurality of entries, each entry being associated with an associated encryption environment identifier and an associated memory address; as well as A determination is made in at least one enabled operating mode whether the given encryption environment identifier is different than the associated encryption environment identifier associated with one of the entries associated with the given memory address.

18. A computer program for controlling a host data processing apparatus to provide an instruction execution environment for the execution of object code; the computer program comprising: processing program logic configured to emulate processing of the object code in a fixed number of at least two domains, one of the domains being subdivided into a variable number of execution environments; memory protector logic configured to respond to a memory access request for a given memory address by determining a given encryption environment identifier associated with one of the execution environments, and forwarding the memory access request along with the given encryption environment identifier; a storage data structure for storing a plurality of entries, each entry being associated with an associated encryption environment identifier and an associated memory address; and Determining program logic configured to determine, in at least one enabled operating mode, whether the given encryption environment identifier is different than the associated encryption environment identifier associated with one of the entries associated with the given memory address.

Images