Data processing device and method

Abstract

The memory access circuit (26) controls access to the memory based on ownership information, the ownership information defining, for a given memory region, an owner domain specified from two or more domains, each domain corresponding to at least a portion of a software process executed on the processing circuit (8). The owner domain has the right to prevent other domains from accessing data stored in the given memory region. When the security configuration parameters of a given domain specify that the given domain is associated with a trusted intermediate domain identified by the security configuration parameters, the trusted intermediate domain may be allowed to perform at least one domain management function for the given domain, such as providing keys and / or saving / restoring security configuration parameters. This may enable use cases where multiple instances of the same domain with shared parameters need to be established on the same system or on different systems at different times.

Description

Technical Field

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

[0002] Known to provide for strengthening the memory access control technology of specific memory area in memory address space.Generally, these techniques can be based on privilege level, so that the process of executing with higher privilege level can exclude the process of lower privilege level from accessing memory area. Summary of the invention

[0003] At least some examples provide a device comprising: a processing circuit for performing data processing in response to one or more software processes; and a memory access circuit for controlling access to multiple memory areas based on ownership information, the ownership information defining, for a given memory area, an owner domain specified from multiple domains, each domain corresponding to at least a portion of at least one of these software processes, the owner domain having the authority to prevent other domains from accessing data stored in the given memory area; and a domain management unit for controlling the operation of a given domain based on security configuration parameters associated with the given domain; wherein: when the security configuration parameters of the given domain specify that the given domain is associated with a trusted intermediate domain identified by the security configuration parameters, the domain management unit is configured to allow the trusted intermediate domain to perform at least one domain management function of the given domain.

[0004] At least some examples provide a data processing method, comprising: performing data processing in response to one or more software processes; implementing ownership permissions for multiple memory areas based on ownership information, the ownership information defining an owner domain specified from multiple domains for a given memory area, each domain corresponding to at least a portion of at least one of these software processes, the owner domain having the right to prevent other domains from accessing data stored in the given memory area; and controlling the operation of the given domain based on security configuration parameters associated with the given domain; wherein: when the security configuration parameters of the given domain specify that the given domain is associated with a trusted intermediate domain identified by the security configuration parameters, the trusted intermediate domain is allowed to perform at least one domain management function of the given domain.

[0005] At least some examples provide a computer program for controlling a host data processing device to provide an instruction execution environment, including: memory access program logic for controlling access to multiple memory areas of a simulated memory address space based on ownership information, the ownership information defining an owner domain specified from multiple domains for a given memory area, each domain corresponding to at least a portion of at least one software process among multiple software processes executed in the instruction execution environment, the owner domain having the right to prevent other domains from accessing data stored in the given memory area; and domain management program logic for controlling the operation of a given domain based on security configuration parameters associated with the given domain; wherein: when the security configuration parameters of the given domain specify that the given domain is associated with a trusted intermediate domain identified by the security configuration parameters, the domain management program logic is configured to allow the trusted intermediate domain to perform at least one domain management function of the given domain.

[0006] A storage medium can store a computer program. The storage medium can be a non-transitory storage medium. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0008] Figure 1 A data processing system is schematically shown, the data processing system comprising a plurality of processing components utilizing memory areas stored in a first memory and a second memory;

[0009] Figure 2 schematically illustrating the relationship between a plurality of processes executed, the privilege levels associated with the processes, and the realms associated with the processes for controlling which process owns a given memory region and therefore has exclusive rights to control access to the given memory region;

[0010] Figure 3 schematically shows memory areas managed by a domain management unit and a memory management unit;

[0011] Figure 4 A more detailed example of processing components and domain management control data stored in memory is shown;

[0012] Figure 5 shows an example of a domain hierarchy in which a parent domain may define domain descriptors that describe properties of various child domains;

[0013] Figure 6 and Figure 7 Two different instances of the domain hierarchy are shown;

[0014] Figure 8 An example of a domain descriptor tree maintained by an upper domain to record domain descriptors of its child domains is shown;

[0015] Fig. 9 An example of the content of a domain descriptor is shown;

[0016] Fig.10 A table showing the life cycle states of different domains;

[0017] Fig.11 A state machine diagram to indicate the changes in the life cycle states of a domain;

[0018] Fig.12 a table showing the contents of an entry in the ownership table for a given memory region;

[0019] Fig.13 Table to show visibility attributes that may be set for a given memory region to control which realms other than the owner are allowed to access the region;

[0020] Fig.14 shows examples of different life cycle states for memory regions, including states corresponding to RMU-private memory regions that are reserved for exclusive access by domain management units;

[0021] Fig.15 A state machine for illustrating transitions of life cycle states for a given memory region;

[0022] Fig.16 shows how ownership of a given memory region can be passed between an ancestor realm and its descendant realms;

[0023] Fig.17A schematically illustrates memory access control provided based on page tables that define memory control attributes that depend on privilege levels and domain management unit levels that provide orthogonal levels of control over memory access based on permissions set by an owner domain;

[0024] Fig. 17B An example of a translation lookaside buffer is shown;

[0025] Fig.18 A flowchart showing a method for controlling access to a memory based on a page table and an RMU table;

[0026] Fig.19shows the use of child realms that correspond to specific address ranges within a process associated with an ancestor realm of the child realm;

[0027] Fig. 20 An example of a parameter signature is shown;

[0028] Fig.21 A method for limiting realm startup when a parameter signature does not match an expected signature is shown;

[0029] Fig. 22 and Fig.23 Two examples of use cases are shown in which it may be used to initiate another realm with the same keys or security parameters as used by another realm;

[0030] Fig.24 shows an example in which a realm may be associated with a trusted intermediate realm;

[0031] Fig.25 An exemplary method of controlling a domain management function for a target domain using an intermediate domain is shown;

[0032] Fig.26 A method for generating proofs for a target domain is shown; and

[0033] Fig. 27 An example of a simulator that can be used is shown. DETAILED DESCRIPTION

[0034] In a privilege-based memory access control scheme, a more privileged process may set access permissions that define memory regions that a less privileged process may access. However, this may generally mean that any region accessible to a less privileged process may also be accessible to a more privileged region. Thus, all applications executing under a given operating system or virtual machine may need to trust software associated with that operating system or virtual machine, and all operating systems or virtual machines executing under a given hypervisor may need to trust that hypervisor.

[0035] In some use cases, this trust in more privileged processes may not be desirable. For example, in a data center, multiple virtual machines may be provided by multiple different parties, each executing under the control of a hypervisor provided by a cloud platform provider that manages the data center. For example, the provider of a given virtual machine (or an application executing under a given virtual machine) may not want its data exposed to the hypervisor or other virtual machines. For example, a banking provider may provide virtual machines for executing banking applications and may not want sensitive financial information to be accessible to the hypervisor or other virtual machines sharing the same physical platform.

[0036] The device may have processing circuitry for supporting the processing of one or more software processes (such as applications, operating systems / virtual machines, hypervisors, etc.). Memory access circuitry may be provided to control access to multiple memory regions of a memory address space based on ownership information, which defines, for a given memory region, an owner domain specified from a plurality of domains. Each domain corresponds to at least a portion of at least one of the software processes. The owner domain of a given memory region has the right to prevent other domains from accessing data stored in the given memory region. Thus, in contrast to a privilege-based model in which access permissions only define which processes are allowed to access (read or write) a given memory region, for a domain-based approach, the owner domain has the ability to control which other domains access the memory region it owns. Thus, there is a distributed control of memory access, in which different portions of the address space may be assigned different domain owners that have control over access to that portion of the address space, rather than a typical privilege-based model in which a single process defines top-down rules for access to the address space by less privileged processes. The method enables a given domain to protect its data from being accessed by other processes, including processes operating at the same privilege level or at a higher privilege level.

[0037] In some examples, this realm-based approach can be applied in parallel with a privilege-based approach so that there are multiple overlapping sets of access rights for a given memory region: privilege-based permissions set by a higher privileged process, and access permissions set by the owner realm for the memory region. If the memory access satisfies both sets of permissions, then the memory access may be allowed.

[0038] Based on the security configuration parameters associated with a given domain, a domain management unit may be provided with control operations for a given domain. For example, the security configuration parameters may define information such as the domain type (which may manage the properties that a domain has or what operations a domain can perform), the protected address range associated with the given domain (which may mark the boundaries of memory areas that may be securely accessed by the given domain), and other information regarding whether operations such as debugging using a memory access circuit, or outputting data from a memory protector to an external memory outside the boundaries protected by the memory access circuit will be permitted. In addition, the security configuration parameters may, for example, include key material for deriving at least one key that is used to protect data associated with a given domain. It will be appreciated that a variety of different security configuration parameters may be defined for a domain.

[0039] In the technology discussed below, security configuration parameters for a given domain may specify that the given domain is associated with a trusted intermediate domain identified by the security configuration parameters. A domain management unit may allow a trusted intermediate domain to perform at least one domain management function for a given domain. Providing this trusted intermediate domain can be used to implement multiple use cases, where various instances of the same domain need to be established, for example, at different points in time and / or on different physical platforms, where each instance of the same domain needs to access some shared configuration parameters so that the domain can operate predictably, regardless of the specific instance of the domain being established. It may be difficult to establish such shared configuration parameters in a repeatable manner by the given domain itself or by the hardware platform while still maintaining security and trust. Providing a trusted intermediate domain that defines certain domain management functions that are allowed to be performed for a given domain can implement the following use cases, such as secure migration of a domain from one platform to another, or providing shared keys to multiple instances of the same domain executed on the same system or different physical systems for load balancing or redundancy purposes. Since the trusted intermediate realm itself is a realm with its own proprietary protection provided by the memory access circuitry, this means that the security of the trusted intermediate realm itself can be verified and validated to provide trust that the realm managed by the trusted intermediate realm is secure.

[0040] The domain management function may include updating at least a portion of the security configuration parameters of a given domain. In some cases, the ability to update the security configuration parameters may be limited to certain stages of the domain life cycle, such as prior to the launch of a given domain. A domain may not be allowed to be processed by the processing circuitry until the domain has been launched.

[0041] This makes it easier to migrate realms between platforms, or save or restore previous versions of a realm, or start multiple instances of the same realm with shared security configuration, by providing a trusted intermediate realm that can manage updates to certain security configuration parameters.

[0042] In one example, each realm other than the root realm can be associated with a corresponding ancestor realm that created the realm. The realm management unit can support security configuration parameters to define a trusted intermediate realm as a realm other than an ancestor realm of a given realm. That is, while a trusted intermediate realm can be defined as an ancestor realm (if desired), the architecture also allows a trusted intermediate realm to be defined as a realm other than an ancestor realm.

[0043] Thus, while an ancestor domain may initially establish a domain, sometimes the ancestor domain itself may not be trusted to be aware of certain security configuration parameters for a given domain, such as key material used to derive keys used to protect data to be used by that domain. By enabling domains other than the ancestor domain to establish certain security configuration parameters for a target domain managed by an intermediate domain, this may allow for greater security in situations where multiple domains need to have the same security configuration. For example, a trusted intermediate domain may be a domain that operates based on software provided by a banking provider, healthcare provider, or other party, which is meant to be a managed domain with access to certain sensitive information, while the ancestor domain may be a management program executed on a cloud platform that may not be trusted by the banking / healthcare provider, etc.

[0044] During the establishment of a given domain, based on at least one command issued by the parent domain, the domain management unit can set whether the given domain is associated with a trusted intermediate domain. Therefore, both the parent domain and the trusted intermediate domain may have the ability to set certain security configuration parameters at certain stages of the life cycle of the given domain. As described below, the parameter signature scheme can be used to verify whether the security configuration parameters have been correctly set for the given domain before the given domain is started. This can be used to check whether the parent domain correctly configured the trusted intermediate domain during the establishment of the domain, so that a party that needs to ensure that the domain has certain security configuration settings as defined by the trusted intermediate domain can verify whether the correct trusted intermediate domain is involved. This prevents a malicious parent domain from incorrectly setting the identification of the trusted intermediate domain for a given domain.

[0045] The domain management unit may support an attestation function, wherein in response to an attestation command identifying a target domain, the domain management unit may provide an attestation that attests to the properties of the target domain. For example, the attestation may include information derived from configuration parameters of the target domain and / or the contents of a memory area owned by the target domain. The attestation may be signed with some key that attests to its authenticity.

[0046] For a domain for which security configuration parameters specify that a target domain is associated with a trusted intermediate domain, the attestation may include information indicating the fact that the target domain is associated with a trusted intermediate domain. In addition, the attestation may include intermediate domain attestation information, which is either information that directly attests to the properties of the trusted intermediate domain, or information that enables receipt of the attestation to request further attestation of the trusted intermediate domain associated with the target domain. For example, the intermediate domain attestation information may be merely an identifier of the trusted intermediate domain, and a subsequent attestation command may subsequently be issued that identifies the trusted intermediate domain as the target domain in order to generate further attestation for the trusted intermediate domain. Therefore, typically, when attesting a given domain, the domain management unit may also provide information that enables the verifying entity to also attest to the associated trusted intermediate domain so that it can establish trust in the fact that the domain is correctly configured by the trusted intermediate domain.

[0047] The domain management unit may prevent a given domain from being processed by the processing circuitry until the given domain has been started. Before the given domain has been started, a trusted intermediate domain associated with the given domain may be allowed to trigger the generation of an attestation for the given domain. This may be used by the trusted intermediate domain to verify that security configuration parameters for the given domain have been correctly configured before providing keys or other configuration information to the domain. This may improve security. Conversely, if an attestation command is issued by a domain other than the trusted intermediate domain associated with the target domain, the attestation command may be rejected if the target domain is not in a valid state.

[0048] In one example, the domain management functionality provided by the trusted intermediate domain may be to provide at least one provided secret for a given domain. The provided secret may include at least one key for protecting data (including data values ​​and / or program code) associated with the given domain; and / or key material for deriving the key. Therefore, by defining a trusted intermediate domain that can be trusted to provide provided secrets (which can be used to protect the contents of a memory area owned by another domain), this can enable multiple instances of the same domain to be established in a secure manner and in a timely manner on the same or different physical platforms or under different instances. The domain management unit may prohibit any domain other than the trusted intermediate domain from providing the provided secret for a given domain.

[0049] The provision of at least one provided secret to a given domain may be limited to before the given domain has been launched. After the given domain has been launched, the trusted intermediate domain may be prohibited from providing these provided secrets to the given domain. This can be used to improve security because certain checks can be performed on the launch of the given domain, and this ensures that the provided secret can be verified before the domain is launched to enable it to be processed. The management of the provision of at least one provided secret can be based on key management policy information, which can be provided by the trusted intermediate domain. For example, the key management policy can specify how many other domains can have a given secret obtained by the trusted intermediate domain, the time period within which a given version of the secret can be provided to the domain managed by the trusted intermediate domain, or other conditions, etc., which are verified by the trusted intermediate domain as being satisfied for the managed domain before the secret can be provided to the managed domain. The policy itself can be proven by using the proof mechanism discussed above to prove the properties of the trusted intermediate domain.

[0050] At least one of the provided secrets may not be a unique type of key used by a given domain. There may also be other types of secrets, such as "instance-unique" secrets derived from characteristics of a specific hardware instance of hardware. These secrets may remain the same if a given domain is executed on a specific platform and subsequently restarted on the same platform; but if the domain is restarted on a different platform, these secrets may be different. Instance-unique secrets may be securely derived without a trusted intermediate domain, and these secrets may be derived, for example, using the hardware devices of the physical platform when operating within a given domain. Another type of secret may be "domain-unique" root secrets, which may be generated, for example, using a pseudo-random number generator accessed by the software of the given domain itself, and these root secrets may be different each time the domain is restarted, even if restarted in the same system.

[0051] However, in situations where a realm needs to be migrated to a different physical platform, or if multiple instances of the same realm need to be created, where the different instances of the same realm need access to a shared secret so that they can all securely access the same data, a root secret unique to those instances or unique to the realm may not be applicable. Providing a trusted intermediate realm to manage the provisioning of at least one provisioning secret as described above helps resolve this issue.

[0052] In another example, the domain management unit may allow a trusted intermediate domain to record a security configuration record indicating at least a subset of the security configuration parameters associated with a given domain. Typically, domains other than a given domain itself may not be allowed to access its security configuration parameters. In some implementations, only the domain management unit may be allowed to read the security configuration parameters of a given domain (even though the given domain itself may not be allowed to read them). However, by defining specific trusted intermediate domains in the security configuration parameters of a given domain, and allowing the trusted intermediate domain to record indications of certain security configuration parameters, this may enable migration and preservation / restore of domains.

[0053] For example, the domain management unit may allow a trusted intermediate domain to update at least a subset of security configuration parameters associated with a given domain based on security configuration records previously recorded by the trusted intermediate domain. Thus, if a domain needs to be migrated from one physical platform to another, a trusted intermediate domain may be established to operate on both the source platform and the target platform, and then the trusted intermediate domain may record the security configuration record associated with the given domain on the source platform, encrypt the security configuration record using its own key, and send the encrypted data to the corresponding instance of the trusted intermediate domain on the target platform, which may then decrypt and restore these security configuration parameters from the security configuration record. This enables secrets or configuration information associated with a given domain to survive the migration process while maintaining security. Another exemplary use may be for a domain to be terminated, where processing resources need to be made available for all other purposes, and then for the same domain to be re-established later, while still having access to shared secrets. In addition, similar methods may support related use cases, such as backing up and then restoring a complete domain, or taking a snapshot or checkpoint of a domain that allows the domain to be rolled back to a previously known state later. Thus, the use of a trusted intermediate realm enables a number of operations that might otherwise be unsafe.

[0054] Managing record security configuration records and / or recovering security configuration parameters from security configuration records can be based on policy information provided by the trusted intermediary realm. Likewise, the policy itself can be proven by proving the trusted intermediary.

[0055] The security configuration parameters for a given domain may include at least one of the following: a domain type; a protected address range associated with the given domain; an indication of whether debugging is enabled within the given domain; an indication of whether data is allowed to be output from a first memory to a second memory access-controlled by a memory access circuit; and key material for deriving at least one key to protect data associated with the given domain. In addition, the security configuration parameters may also include identification of a trusted intermediate domain as discussed above.

[0056] The domain management unit can be implemented in different ways. In one example, the domain management unit can be a dedicated hardware unit that implements the security protection provided by the domain scheme. In other examples, the domain management unit can include software executed on a processing circuit that is different from the software associated with each domain.

[0057] The above example describes a device having the memory access circuit and domain management unit discussed above. However, in another example, a corresponding computer program may be provided for controlling a host data processing device to provide an instruction execution environment for executing instructions. The computer program may include memory access program logic and domain management program logic, both of which correspond functionally to the memory access circuit and domain management unit discussed above. For example, the computer program may be an emulator program that can be presented to software executed on an emulator, and an execution environment similar thereto will be provided by an actual hardware device, even though there may not be any actual hardware that provides the architectural features desired by the software within the host computer executing the emulator computer program. Specifically, the functionality of the desired hardware architecture (including the implementation of ownership rights and domain management based on commands issued by a trusted intermediate domain of a domain) can be simulated by providing program logic (such as a set of instructions or data structures) that enables a general host computer to execute code for execution on a device having the above-mentioned domain protection in a manner compatible with the following results, which will be implemented on a device actually having the above-mentioned memory access circuit and domain management unit. The emulator computer program for controlling the host data processing device may be stored on a storage medium, which may be a non-transitory storage medium.

[0058] Figure 1 A data processing system 2 is schematically shown, comprising a system-on-chip integrated circuit 4 connected to a separate non-volatile memory 6, such as an off-chip flash memory used as a mass storage device. The system-on-chip integrated circuit 4 includes a plurality of processing components in the form of (in this exemplary embodiment) two general purpose processors (CPUs) 8, 10, and a graphics processing unit (GPU) 12. It will be appreciated that in practice many different forms of processing components may be provided, for example, additional general purpose processors, graphics processing units, direct memory access (DMA) units, co-processors, and other processing components for accessing memory areas within a memory address space and performing data processing operations on data stored in these memory areas.

[0059] The general purpose processors 8, 10 and the graphics processing unit 12 are coupled to an interconnect circuit 14 through which they conduct memory transactions with an on-chip memory 16 and an external memory 6 (via an external memory interface 18). Figure 1 In the embodiment, the memory 16 is on-chip, but in other embodiments, the memory 16 may be implemented as an off-chip memory instead. The on-chip memory 16 stores data corresponding to multiple memory regions within the overall memory address space. These memory regions correspond to memory pages and are subject to management operations that control which memory regions (pages) exist in the on-chip memory 16 at a given time, which processes can access the data stored in these memory regions and other parameters related to these memory regions. More specifically, in this exemplary embodiment, each of the processing components 8, 10, 12 includes a domain management unit 20, 22, 24 and a general memory management unit 26, 28, 30. The general memory management unit 26, 28, 30 is used to control aspects of the operation of the memory region, such as address mapping (such as mapping between virtual addresses and intermediate physical addresses, or physical addresses), privilege level constraints on processes that can access a given memory region, storage characteristics of data within a given memory region (such as cacheability, device memory status, etc.), and other characteristics of the memory region.

[0060] The domain management units 20, 22, 24 manage data for implementing ownership rights to a plurality of memory regions, whereby a given memory region has a given owning process (or owner "domain") specified from a plurality of processes (a process or domain is, for example, one of a monitor program, a manager program, a guest operating system program, an application program, etc., or a specific sub-portion of such a program). A given owning process (owner domain) for a given memory region has exclusive rights to control access to given owned data stored in the given memory region. Specifically, the owner process has rights to prevent access to the memory region owned by the owner process by processes executing at a higher privilege level than the owner process.

[0061] Therefore, multiple memory areas are divided between multiple owner domains. Each domain corresponds to at least a portion of at least one software process and is assigned ownership of multiple memory areas. The owning process / domain has the right to control access to data stored in the memory area of ​​their domain, including the right to prevent more privileged processes from accessing the owned area of ​​the domain. The management and control of which memory areas are memory-mapped to each domain are performed by processes other than the owner domain itself. Using this arrangement, processes such as a manager can control which memory areas (pages of memory) are included in the domain owned by the corresponding guest virtual machines (guest operating systems), which are managed by the manager, but the manager itself may not actually have the right to access the data stored in the memory area that the manager has allocated to a given domain. Thus, for example, the guest operating system can keep the data stored in the domain of the guest operating system (i.e., the data stored in the memory area owned by the guest operating system) private to its management manager.

[0062] The division of the memory address space into domains and the control of ownership of these domains are managed by a domain management unit 20, 22, 24 associated with each of the processing components 8, 10, 12, and are control processes that are orthogonal to the more traditional forms of control provided by the general memory management unit 26, 28, 30. The domain management unit 20, 22, 24 thus provides memory access circuitry to enforce ownership rights to memory regions of the memory address space. In some cases, the memory access circuitry that enforces domain ownership rights may also include portions of the MMU 26, 28, 30 (e.g., a TLB in the MMU 26, 28, 30 may include some control data for controlling access based on domain control provided by the RMU 20, 22, 24 to avoid the need to access two separate structures). In this exemplary embodiment, each of the processing components 8, 10, 12 includes its own domain management unit 20, 22, 24; this is advantageous for performance purposes. However, more generally, the memory access circuitry that implements ownership rights may include a single instance of a domain management unit, a combination of all of the domain management units 20, 22, 24 that are present, or a subset of those domain management units 20, 22, 24 that are present. Thus, the memory access circuitry for implementing ownership rights may be dispersed across the system-on-chip integrated circuit 4 associated with different processing components 8, 10, 12, or collected together in one location or in some other configuration.

[0063] The processing components including general purpose processors 8, 10 are shown to include corresponding decoding and execution circuits 32, 34, which decode and execute program instructions. These program instructions include commands (domain management commands or RMU commands) for controlling the management of memory areas in different ownership domains of memory address space. As an example, the executed program instructions may include program instructions designated as domain management unit commands, and when these program instructions are encountered in the program instruction stream, these program instructions are directed to the associated domain management units 20, 22, 24, so that these program instructions can be executed (take action) by the associated domain management units 20, 22, 24. Examples of domain management unit commands include commands for initializing new domains or invalidating existing domains, for allocating memory areas to specific domains, for removing memory areas from specific domains, and for outputting data contained in memory areas from the first memory 16 to the second memory 6 when the output data is encrypted and other processes are performed so that the output data is protected in the second memory 6. Further domain management unit commands are provided to import data from the second memory 6 back into the first memory 16 with associated decryption and validation operations performed on the input data.

[0064] In the context of such export and import of data from memory areas, it will be appreciated that a first memory such as the on-chip memory 16 is closely managed by a domain management unit 20, 22, 24 within the system-on-chip integrated circuit 4, and that these domain management units 20, 22, 24 are therefore able to enforce ownership rights and restrict access to data within a given memory area to the process that owns the memory area, or to those processes to which the owning process has granted access. However, when the data within the memory area is exported, for example to an external non-volatile memory 6 as a second memory, the control of access provided by the domain management unit 20, 22, 24 is no longer effective and therefore the data needs to be protected in some other way. This is achieved by encrypting the data within the memory area before the data is exported, and then decrypting it with a private key when the data is imported back into the on-chip memory 16.

[0065] The output process may be accompanied by the generation of metadata that specifies the characteristics of the output data. This metadata may be stored separately in a metadata memory area of ​​the first memory (the on-chip memory 16), wherein the metadata remains private to the domain management units 20, 22, 24 (i.e., accessible only to such domain management units 20, 22, 24 and not accessible to any of the existing processes), so that when data is input back into the on-chip memory 16, the metadata may be read for the input data and the characteristics of the data represented in the metadata and the characteristics of the input data may be checked to ensure the integrity of the input data (e.g., checksum, data size, signature, etc.). It may be the case that the private data of the domain management units 20, 22, 24 (including the above metadata representing the output area / page) needs to be output from the on-chip memory 16 to the off-chip non-volatile memory 6 (for example to make room within the on-chip memory 16), and in this case, the RMU-private metadata itself may be encrypted for protection of the RMU-private metadata and new metadata representing the output metadata may be maintained within the on-chip memory 16 (this maintained metadata being significantly smaller in size than the output metadata) so that the encrypted and output metadata can be checked and confirmed when it is input back into the on-chip memory 16 for use.

[0066] This metadata describing the characteristics of the memory area and the data stored in the memory area can be arranged as part of a hierarchical structure, such as a metadata memory area tree with a branching pattern. The form of this metadata memory area tree can be determined under software control because different areas of the memory address space are registered as metadata areas owned by the domain management unit 20, 22, 24. It will be understood that although the software controlling the registration of such memory areas can allocate, deallocate and control the relationship between memory areas used to store metadata, this software itself does not own the data contained in these memory areas in the sense of being able to control which processes can access this data. In the case of a memory area that is private to the domain management unit 20, 22, 24 (i.e., the memory management circuit), such access rights can be limited only to the domain management unit 20, 22, 24 itself and this RMU-private data will not be shared with any other process.

[0067] When given data stored in a given memory area is output, the memory area under consideration is then invalidated, making the content inaccessible. To reuse this page, the page is made "valid" by using a Clean command, which overwrites the memory area with other data that is unrelated to the previous content, so that when the given memory area is released for use by another process, this previous content is not made accessible to another process. For example, the content of a given memory area can be written to all zero values, or to a fixed value, or to a random value, thereby overwriting the original content of the memory area. In other instances, the overwriting of the content of the output memory area can be triggered by the output command itself rather than a subsequent Clean command. In short, before making the given memory area accessible to processes other than the given owning process, the outputted given owned data can be overwritten by values ​​unrelated to the given owned data. When a given memory region owned by a given process is to be exported, as part of the export process, the domain management unit 20, 22, 24 executing the domain command to perform the export takes ownership of the memory region in question from the given process (even if the region is RMU-private), locks access to the memory region relative to all other processes (and other domain management units), performs the export operation (including encryption, metadata generation, and overwriting), and then unlocks access to the memory region and releases ownership of the memory region. Thus, the memory region in the process being exported, being imported can remain private to the domain management unit in question while the command is being executed.

[0068] Figure 2 The relationship between multiple processes (programs / threads), multiple exception levels (privileged levels), secure and non-secure processor domains, and multiple domains representing ownership of a given memory region is schematically shown. As shown, the hierarchy of privileged levels extends from exception level EL0 to exception level EL3 (where exception level EL3 has the highest privilege level). The operating state of the system can be divided between a secure operating state and a non-secure operating state, as represented by secure domains and non-secure domains in, for example, a processor using the TrustZone® architecture, which is provided by ARM® Limited (Cambridge, UK).

[0069] like Figure 2As shown, the memory access circuit (domain management units 20, 22, 24 and associated control software (e.g., millicode running a domain management unit)) manages multiple domains within the execution environment. A given memory area (memory page) is owned by a specific domain. A domain may have child domains within the domain, and grandchild domains within these child domains (e.g., see domain A (parent), domain B (child), and domain C (grandchild)). The memory areas to which ownership is given to domain A can then have ownership of these memory areas transferred from domain A to domain B under the control of the process owned by domain A. Thus, the parent domain is able to give ownership of the area to its own child domain of the parent domain. These child domains can then transfer ownership of the memory areas they receive from their parent domains to be subsequently owned by their own child domains (e.g., domain C) of these child domains, which are grandchild domains of the original domain (i.e., domain A). Processes within a given domain may be executed at the same privilege level or at different privilege levels. The domain to which a procedure belongs is therefore an orthogonal parameter relative to the privilege level of the procedure, but in many practical situations domains and privilege levels may correspond, since convenient mechanisms for moving between domains may involve the use of exceptions that themselves move the system between different privilege levels (exception levels).

[0070] Figure 3 A domain management unit 20 and a general memory management unit 26 are schematically shown, which respectively perform different management operations on multiple memory pages (memory areas) stored in the on-chip memory 16. As shown, the domain management unit 24 uses multiple domain descriptors 42, each of which specifies the properties of the domain. The domain management unit 24 can also maintain a domain zone group table (or ownership table), which includes entries indexed by physical addresses, each entry including information for the corresponding memory area, including an indication of which domain the memory area belongs to, that is, which domain has exclusive authority to control access to control data in the memory area, even if the domain does not control whether the domain itself actually owns the memory area. The domain descriptors and domain zone group table entries can be stored in the memory 16, but can also be cached in the RMU itself. Thus, if Figure 3As shown, different memory regions have different ownership domains as indicated by the domain designations RA, RB, RC, RD, and RE. Some of the memory regions are also owned by the domain management unit 20 (private to the domain management unit) and are marked as RMU-private. Such RMU-private regions can be used to store metadata describing the characteristics of other memory regions, temporarily store memory regions being exported or imported, or for other purposes of the domain management unit 20 itself. RMU-private regions may still be owned by the corresponding owner domain, but may be inaccessible to general read / write access issued by the owner domain (alternatively an RMU command issued to the RMU 20 may be required to trigger the RMU 20 to make any changes to the RMU-private regions).

[0071] The addressing of the memory region may be by virtual address, intermediate physical address, or physical address, depending on the particular system under consideration. The domain management unit 20, and the general memory management unit 26, may therefore store translation data that enables received addresses (whether these received addresses are virtual memory addresses or intermediate memory addresses) to be translated into addresses that more directly represent the memory region within the on-chip memory 16 under consideration, such as physical addresses. This address translation data may be managed and dispersed within the on-chip system integrated circuit 4 using translation lookaside buffers and other distributed control mechanisms.

[0072] Figure 4 Shows Figure 1 A more detailed example of one of the processing components 8, 10, 12 and the control data stored in the memory 16 for controlling memory access. For ease of explanation, Figure 4 CPU 0 is shown as processing component 8, but it will be appreciated that the processing component may also be CPU 1 10 of GPU 12 or any other processing component within data processing device 2. Figure 4As shown in , the processing component 8 includes a processing circuit 32 (which may include the decoding and execution logic described above), a memory management unit 26 that may include one or more translation lookaside buffers 100 for caching entries of the translation table (if a shared MMU-RMU TLB structure is used, the one or more translation lookaside buffers may also be supplemented with field-based control data from the RMU 20), and a table traversal unit 102 for controlling the allocation of data to the TLB 100 and triggering a traversal access to the memory to locate the required data used to control whether a given memory access is allowed to be executed. The processing component 8 may also include a cryptographic unit 104, which may perform cryptographic operations for encrypting or decrypting data used, for example, in the paging (output / input) operations discussed above. The processing component 8 also includes a plurality of caches 110, which may cache data or instructions read from the memory 16. If the access to the memory triggered by the processing circuit 32 or by the table traversal unit 102 misses in the cache, the data may be located from the main memory 16.

[0073] The processing component 8 also includes a domain management unit 20 as discussed above. In some embodiments, the domain management unit (RMU) 20 may be provided as a hardware circuit. However, some of the RMU operations discussed below may be relatively complex to be implemented simply in hardware, for example if these RMU operations require multiple accesses to different memory areas. Therefore, in some instances, the RMU 20 may be implemented using program code that may be stored in the data processing device 2 and may be executed using a general processing circuit 32. Unlike general software that can be written to the memory 16 and can be rewritable, the RMU software (millicode) may be installed on the data processing device in a relatively permanent manner so that the RMU software is not removable and may be considered as part of the platform provided by the processing system. For example, the RMU program code may be stored in a read-only memory (ROM). Therefore, the RMU may include a hardware unit, or may include a processing circuit 32 that executes the domain management software, which is triggered to execute by RMU commands, which are included in the general software executed by the processing circuit 32. In some examples, RMU 20 may be implemented using a combination of hardware and software, e.g., some simpler functions may be implemented using hardware circuits for faster processing, but more complex functions may be implemented using millicode. Thus, it will be appreciated that subsequent references to the RMU may refer to hardware or software or a combination of both.

[0074] like Figure 4As shown in , the memory 16 may store multiple pieces of control information used by the MMU 26 and the RMU 20 to control access to the memory. This includes translation tables (also called page tables) 120, which define memory access attributes for controlling which processes are allowed to access a given memory region, and address mapping information for translating virtual addresses to physical addresses. The translation tables 120 may be based on the information described above with respect to Figure 2 The exception level in question is defined such that a process executing at a more privileged exception level can set permissions that govern whether a process executing at a less privileged exception level is allowed to access a corresponding memory region.

[0075] In addition, multiple domain management tables or domain control information 122 are provided for controlling memory access in an orthogonal manner relative to the MMU page table 120 to allow less privileged processes to control whether to access more privileged processes (domain control is orthogonal to MMU control in the sense that (for a memory access request to be serviced) it may be necessary to pass two types of access control checks). Using the domain management table, the owner process (domain) of a given memory region has the right to exclude processes executing at more privileged exception levels from accessing the memory region. The domain management data includes a domain descriptor 124, which describes the properties of a given domain. Each domain corresponds to at least a portion of at least one software process executed by the processing circuit 32. Some domains may correspond to two or more processes, while other domains may correspond to only a sub-portion of a given software process. A domain can also be viewed as being mapped to a given area of ​​a memory address space (wherein when the processing circuit 32 is executing program instructions located in a corresponding area of ​​the memory address space, the processing circuit is executing within the given domain). Therefore, a domain can be viewed as a collection of software processes or a portion of a software process, or as an area of ​​a memory address space. These two views are equivalent. For ease of explanation, the subsequent description refers to a domain as at least a portion of at least one software process, but the corresponding view of a domain as a collection of memory areas is equally valid (in which case "entry" and "exit" to / from a domain may correspond to arriving at / leaving the portion of program execution corresponding to the memory address of the domain).

[0076] The domain management data 122 also includes a domain execution context area 126, which can be used to save and restore the architectural state associated with a given domain when the domain is exited or entered. The domain management data also includes a domain zone group table (or ownership table) 128, which defines which domain is the owner domain of the memory region for each region of the memory address space. The owner domain of a given memory region has the right to exclude other domains (including more privileged processes) from accessing data stored in the memory region. The use of the domain management data is discussed in more detail below. In general, the domain management unit 20 and the MMU 26 can be viewed as a memory access circuit that implements ownership permissions defined by the owner domain for the memory region owned by the domain. This can be particularly useful, for example, for a cloud platform, in which multiple virtual machines 36 provided by different parties can be executed under the control of a manager 38 provided by a cloud server operator. The party providing one of the virtual machines may not want its data and code to be accessible to the manager. By introducing the concept of a domain where a domain executing at a less privileged exception level can exclude a more privileged exception level from accessing data or instructions of that domain, this enables the provision of a blind manager that can increase the confidence of code developers to install their software on a cloud service where the physical hardware can be shared with code provided by other parties.

[0077] like Figure 5 As shown in , the domains are managed by the RMU 20 according to a domain hierarchy in which each domain except the root domain 130 is a child domain having a corresponding parent domain that initializes the child domain by executing an initialization command. The root domain 130 may be, for example, a domain associated with a monitor code or system firmware executing at the most privileged exception level EL3. For ease of explanation, Figure 5 The example of and the initial example discussed later show the situation that each child domain executes at a lower privilege level than its parent domain. However, as will be discussed below, it is also possible to establish a child domain that executes at the same exception level as its parent.

[0078] Generally speaking, for the domain management portion of the memory access control provided by the MMU 26, the child domain has default access to any memory area owned by its parent domain. Similarly, it is assumed that any descendant of a given domain can access the memory area owned by the given domain. However, because the domain management control is orthogonal to the control provided by the conversion table 120 based on the exception level, the process executed at a higher privilege level can still exclude less privileged codes from accessing the data of the process by setting the parameters of the conversion table 120 accordingly. Therefore, generally speaking, a given child domain has the right to exclude the parent domain of the given child domain from accessing the data stored in the given memory area owned by the given child domain. Whether the child domain actually excludes the parent domain from accessing the given memory area can be set based on the control attributes set in the ownership table 128 (the default situation may be that the parent domain does not have access to the area owned by the child domain, but the child domain can choose to grant access to the parent domain by setting the visibility attribute accordingly). When there are multiple sibling domains (different child domains that share the same parent domain), then a given child domain may exclude a sibling domain from accessing data stored in a given memory area owned by the given child domain. In addition, the visibility attributes set in the ownership table 128 may control the extent to which a sibling domain may access the data of each other generation domain. Alternatively, access to sibling domains may be controlled based on the parent visibility attribute, so that if a child domain makes a page visible to its parent domain, the same page also becomes visible to the sibling domains of the child domain and further descendants of the sibling domain. In some cases, the ownership table 128 may have a global visibility attribute that may allow a given owner process to enable any process executed under any domain to access data in the memory area owned by the given owner process.

[0079] like Figure 5 As shown in , each domain 140 is associated with one or more domain execution context (REC) memory areas 126, which can be used to store the architectural state of the domain, such as register values, when exiting from a given domain. The number of RECs 126 provided for a given domain may depend on how many threads of execution are operating under the given domain. For example, a domain may be established using a single main REC area 126 when initially initialized, but the domain may subsequently configure other memory areas owned by the domain to be used as further RECs when necessary. REC memory areas are owned by the corresponding domain whose execution state is stored in the REC.

[0080] Each domain is associated with a domain descriptor 124, which is stored in a memory area owned by an ancestor domain of the domain whose properties are described in the domain descriptor 124. In order to be flexible in the number of child domains that can be defined at a given domain generation, a tree structure called a domain descriptor tree (RDT) is used to manage domain descriptors, which will be discussed in more detail later. The domain descriptor 124 can be used to define the properties of the domain, which can be checked by the RMU 20 when entering or exiting the domain to ensure safety. The domain descriptor can also track the progress of the domain through various life cycle states, so that the execution of certain RMU commands for the domain can be limited to specific life cycle states to ensure that the domain is created and invalidated in a safe manner.

[0081] Figure 6 and Figure 7 shows two different examples of possible domain hierarchies. Figure 6 In the example, Figure 2 Each defines its own domain in the process shown in . Thus, the root domain 130 corresponds to the monitor software or firmware operating at the exception level EL3. The root domain defines two child domains 142, one corresponding to the secure operating system operating at the secure EL1 and the other corresponding to the manager at EL2. The manager defines a grandchild domain 144 corresponding to different guest operating systems at EL1, and each of these guest operating systems defines a further great-grandchild domain 146 corresponding to an application executed at the least privileged exception level EL0. Similarly, the secure operating system in domain 142 may define a grandchild domain 148 corresponding to different secure applications. The parent domain in the hierarchy may transfer ownership of the memory page it currently owns to the new child domain (by using a Granule.add command as discussed below), or may invalidate one of the pages of the parent domain, map the page to the virtual address space of the child, and allow the child domain to claim ownership of the page by executing a page ownership (claim) command. A page ownership command may be rejected if the specified page of the memory address space is not already owned by the ancestor domain issuing the command.

[0082] like Figure 7 As shown in , it is not necessary for processes of each privilege level to have separate domains, and therefore in Figure 7 Some of the privilege level boundaries shown in the dashed lines in FIG. 1 may not correspond to domain boundaries. Figure 7, an application 150 and its operating system execute in the same domain as the manager domain 142 operating at exception level EL2, and thus a single domain spans the EL2 manager code, the operating system operating at EL1, and the application at EL0. On the other hand, a different application 152 under the same manager may define its own separate domain. In this case, the domain boundary is between EL1 and EL0 and there is no EL2-EL1 domain boundary (both the manager and the operating system may execute in the same domain). For another operating system, a separate EL1 domain 154 may be defined, which may also have some applications executing in the same domain as the operating system, and other applications having their own dedicated domain. Similarly, on the security side, Figure 7 The secure OS and applications in EL3 execute entirely within the EL3 root realm, and therefore there are no realm boundaries when operating on the secure side. Therefore, the exact configuration of realms can be determined at run time on a given system, depending on the needs of the processes being executed. Software can determine at run time that it only requires a small and fixed number of child realms (this may be the case for low-level firmware), or that it requires many realms or a varying number of realms (this may be used, for example, for a hypervisor on a cloud platform that may manage an unknown number of guest virtual machines).

[0083] The domain descriptors 124 for a given ancestor domain are managed according to a domain descriptor tree (which is an instance of a domain management tree that defines domain management data for a plurality of child domains of the ancestor domain). The tree has a variable number of levels. Figure 8 An example of a domain descriptor tree 160 managed by a particular parent domain is shown. The tree 160 includes a plurality of domain descriptor tree blocks (RDTGs) 162, each of which includes a plurality of domain descriptor tree entries (RDTEs) 164. Each RDTE 164 provides a pointer to a domain descriptor 166 for a given child domain of the parent domain, or to a further RDTG 162 for the next level of the domain descriptor tree. The RDTG 162 for the first level of the tree can be identified by a domain descriptor tree pointer 168, which can be stored as part of the data associated with the parent domain (e.g., the domain descriptor of the parent domain). Therefore, when the parent domain issues an RMU command associated with a given child domain, the parent domain can trigger the RMU to traverse the domain descriptor tree in order to locate the domain descriptor 166 of the required child domain (if the domain descriptor has not yet been cached in the RMU 20). Each RDTG 162 can have a variable number of entries 164.

[0084] like Figure 8As shown in the table in , a given RDTE 164 that provides a pointer to an RDTG 162 at a subsequent level of the tree may include an order value indicating the maximum number of entries in the pointed-to RDTG. For example, the order value may indicate a power of 2 corresponding to the total number of entries in the pointed-to RDTG. Other information that may be included in the RDTE 164 may include a status value indicating the state of the RDTE (e.g., whether the RDTE is free for allocation of domain descriptor tree data, and whether the RDTE provides a pointer to a further RDTG 162 or to a child domain descriptor 166). In addition to the pointer, the RDTE may also include a reference count that tracks the number of non-free RDTEs in the pointer to the RDTG, which RDTEs can be used to determine whether further RDTEs can be allocated to the RDTG 162. RMU commands triggered by the previous domain can control the RMU 20 to establish further RDTGs of the tree and / or edit the contents of the RDTEs within an existing RDTG.

[0085] It should be noted that Figure 8 The tree shown in shows the child realms of a particular ancestor realm. Each other ancestor realm may have a separate realm descriptor tree that tracks its own child realms for that ancestor realm. The datagrams associated with the tree (including RDTG 162 and child realm descriptors 166) are stored within pages owned by the ancestor realm, and other realms may therefore be excluded from accessing this data. Thus, only the ancestor realm may have visibility of those specific child realms that the ancestor realm is configured with, so that a process executing at a higher privilege level may not have visibility of what realms have been created below any child realms that the process itself has directly created.

[0086] like Figure 8 As shown in , each of the child domains of a given ancestor domain may have a corresponding domain identifier (RID) 168 that is used by the ancestor domain to identify the particular child domain. A RID is a local domain identifier because the RID is specific to a particular ancestor domain. Child domains of different ancestor domains may have the same local RID. Although it is possible to use a local RID with an arbitrary value selected by the ancestor domain for a given child domain, Figure 8 In the method shown in , the local RID for a given child realm has a variable number of variable length bit portions and each of the variable length portions is used by the RMU 20 to index into a given level of the realm descriptor tree 160. For example, Fig.13The domain descriptor of the child domain with local RID = 7 in is accessed by the domain descriptor pointer in entry 7 of the following first level RDTG 162. The domain descriptor of the child domain with local RID = 3.3 is accessed by entry 3 in the following first level of the tree and entry 3 in the following second level of the tree. Similarly, the domain descriptor of the child domain with local RID = 1.2 is accessed by entry 1 in the following first level and entry 2 in the following second level. It should be noted that although for the sake of brevity, Figure 8 The local RIDs are shown using decimal values ​​7, 3.3 etc., but they will be implemented as a sequential concatenation of binary digits in the processing device 2.

[0087] The RID for a given domain may include a sequential connection of indices to be used to access the domain management data for a given domain at the corresponding level of the domain descriptor tree. Although it is not necessary for the indices to be sequentially connected in the same order sequence in which they are used to step through the tree, this may be preferred because it makes the management of tree access simpler. It does not matter whether the sequential connection is from low to high or from high to low. The sequential connection of the indexes may be followed by a predetermined termination mode that allows the RMU 20 to determine when there are no further levels of the tree to be stepped through.

[0088] Some embodiments can apply this RID construction technology to a global domain descriptor tree, which can store domain descriptors for all domains in the system in a similar tree structure (where each of the RIDs is a globally unique value). However, software development can be made simpler by defining a given previous generation child domain in a tree and then using a separate tree for each other previous generation domain to track the child domain of the previous generation domain. Therefore, the domain descriptor tree can be a local domain descriptor tree related to a given previous generation domain for storing domain management data of the child domain initialized by a given previous generation domain. The domain identifier can therefore be a local domain identifier, which identifies the specific child domain used by a given previous generation domain. The child domain initialized by different previous generation domains can be allowed to have the same value of the local domain identifier. In this way, the previous generation domain can select which RIDs are used for the child domain of the previous generation domain without knowing what other domains have been established by other previous generation domains, wherein the RID used for the child domain is constructed according to the mode in which the previous generation domain configures its domain descriptor tree.

[0089] Local domain identifiers can be used by domain entry instructions or RMU commands issued by a software process. However, the hardware architecture can use the absolute identification of a given descendant domain to distinguish between domains created by different ancestors. Figure 8In addition to the local realm identifiers shown in , a given realm may also have a global realm identifier (or "internal" realm identifier) ​​that is unique to the given realm. At least one hardware structure may use a global realm identifier (GRID) rather than a local realm identifier (LRID) to identify a given realm. For example, realm block table 128 and / or TLB 100 may use a global realm identifier to identify a realm.

[0090] In some examples, an arbitrary binary value may be assigned as the GRID for a given domain, which may be completely independent of the LRID used by the parent domain to reference the child domain. Different microarchitecture implementations of the same domain architecture may use different methods to assign GRIDs.

[0091] However, in one example, the GRID for a given domain may be constructed based on the LRID of the domain's predecessor. This may be useful because it may enable a simpler determination of whether a given domain is a descendant of another domain or a predecessor of another domain, which may be used for access control by MMU 26 and RMU 20.

[0092] It is not necessary for all local RIDs to be constructed using a sequential connection of the tree index method. In some cases, it may be useful for specific values ​​of local RIDs to be reserved for reference to certain preset domains. RMU commands that specify the current domain or the domain of the parent of the current domain may be relatively common. Therefore, a predetermined RID value may be reserved for reference to the domain of the parent of the current domain. For example, an LRID with all bits set to 1 (indicating a value of 1) may be reserved for reference to the domain of the parent of the current domain. Similarly, a predetermined domain identifier value may be reserved for reference to the current domain itself. For example, an LRID value of 0 may be used to reference the current domain.

[0093] The RMU may support certain query commands that may be triggered by a given domain in order to query the constraints that must be satisfied when the given domain establishes its domain descriptor tree. For example, in response to the query command, the RMU 20 (or processing circuit 32) may return a constraint value indicating at least one of the maximum number of levels of the domain descriptor tree 160 defined by the given domain, the maximum number of entries allowed at a given level of the tree structure for the given domain, and / or the maximum number of child domains that can be initialized by the given domain. For example, the system may include registers that may indicate properties such as the number of bits available in the LRID or GRID for a particular hardware implementation. The RMU or processing circuit may, in response to the query command, check the number of bits available for the domain identifier (or the appropriate response may be hardwired for a specific processor implementation), and may also check the information on how many bits of the specified identifier have been used up by the previous domain in the global domain identifier, so as to determine how many bits are available to be used to define further children for the current domain. The previous domain may use the response to the query command to determine how to construct the RDT of the previous domain.

[0094] Fig. 9 An example of the contents of a domain descriptor 166 for a given domain is shown. The domain descriptor may define security configuration parameters for the domain. It will be appreciated that this is only an example and other implementations may not include all of the listed information, or it may include additional information. In this example, the domain descriptor includes the following items:

[0095] • The global RID of the realm. Thus, by traversing the realm descriptor tree based on the local RIDs, the corresponding global RID can be identified and this can be used to index hardware structures such as the TLB by the given realm, or to check ownership tables or other information based on the GRID definition.

[0096] • The lifecycle state of a given realm, which may be used by the RMU 20 to determine whether to accept a given command triggered by the given realm.

[0097] • The type of a given domain. For example, the domain type may indicate whether the domain is a full domain or a child domain as discussed later.

[0098] • A bounded exception level (BEL) value that identifies the bounded exception level for the corresponding domain. BEL indicates the maximum privilege level at which the domain is allowed to execute. For example, Figure 7In the example, realm 142 may have a BEL at EL2, realm 152 may have a BEL at EL0, and realm 154 may have a BEL at EL1. By providing an explicit parameter identifying the BEL in the realm descriptor, this provides flexibility for realms spanning multiple exception levels, because the BEL can be used when an exception occurs to determine whether the exception can be taken within the current realm or whether a realm exit to a parent realm is required to handle the exception.

[0099] • A resource count indicating the total number of memory regions (Realm Protection Zone Groups or RPGs) owned by a realm and its descendants. This is used to ensure that all memory pages owned by a realm and its descendants are invalidated (and eventually erased) before these memory regions can be allocated to different realms. For example, the resource count can be used to keep track of how many regions still need to be scrubbed.

[0100] • The start and end addresses of protected addresses for the realm. For example, a protected address range may define a range of memory address space within which pages may be owned by the corresponding realm. This can be used to protect against a malicious ancestor realm reclaiming ownership of an area previously assigned to a child realm in an attempt to access child realm data, because by comparing the protected address range defined in the realm descriptor to subsequent addresses of memory accesses, it can be identified that a memory area previously owned by a realm is no longer owned by the realm.

[0101] • One or more encryption keys used by cryptographic circuitry 104 to encrypt or decrypt data associated with a given realm. In this example, two separate encryption keys are provided: a memory key for encrypting / decrypting content and memory owned by the realm, and a paging key for encrypting / decrypting data exported / imported between memory 16 and persistent storage 6 as discussed above. However, in other examples, the same key may be used for both purposes, or further may be provided for other specific purposes.

[0102] • Domain Description Tree Entry (RDTE) which identifies the root of the Domain Descriptor tree. The RDTE in the Domain Descriptor provides a pointer to access the root RDTG (and an order value that defines how many bits are to be used as an index to that RDTG).

[0103] • A pointer to the main REC (Domain Execution Context) memory area used to save or restore architectural state related to the execution of the domain.

[0104] As discussed in more detail below, a realm descriptor may also include other information, such as identification of trusted intermediate realms, information defining whether debugging or output is enabled for the realm, and expected signatures for signatures used to check parameters of the realm when the realm is launched.

[0105] Fig.10The set of lifecycle states that can exist for a given domain is shown, which in this example include a clean state, a new state, an active state, and an invalid state. Fig.10 Summarizing the properties of each state, for each state, it is indicated whether the realm in the corresponding state can have the parameters of the realm descriptor 166 of the realm modified by the realm's ancestor realm, whether the encryption key specified for the realm can be used effectively, whether the realm can own any memory area (RPG), and whether the code associated with the realm is executable. It should be noted that the parameters of the realm descriptor are modifiable in the clean state, but not in any of the other states. This prevents malicious ancestor realms from updating the properties of a given realm after it has become active. In addition, realms are only executable in the active state.

[0106] Fig.11 is a state machine diagram showing the allowed transitions of the life cycle states of a realm. Fig.11 Each state transition shown in is triggered by an ancestor realm issuing a realm management command to the RMU 20 that specifies the local RID of the child target realm (a Realm.Invalidate command 212 may also be issued by the target realm itself). When no previous realm has been defined for that local RID and a Realm Descriptor Register Block Group command 200 is executed by the ancestor realm, this triggers the configuration of a given memory area owned by the ancestor realm because the realm descriptor for the child realm has the specified local RID. The global RID for the child realm may be set based on a sequential connection of the global RID of the ancestor realm and the new local RID specified in the realm descriptor register block group command 200. The specified child realm then enters the clean state 202. In the clean state, the ancestor realm may set properties of the child realm by updating various parameters of the realm descriptor of the child realm. These properties may be modified using further RMU commands issued by the ancestor realm (such realm descriptor modification commands may be rejected if the specified child realm is not in the clean state). In addition, for a realm associated with a trusted intermediate realm, a realm descriptor modification command may also be accepted if it is issued by a specified trusted intermediate realm identified in the realm descriptor of the target realm (whose parameters are being modified). When the parent realm has completed setting the parameters of the domain descriptor of the child realm, the parent realm executes a realm initialization command 204 that specifies the LRID of the child realm and this triggers the transition of the child realm from the clean state 202 to the new state 206, and at this point, the parameters of the realm descriptor are no longer modifiable by the parent realm. If the specified realm is not currently in the clean state, the realm initialization command 204 will fail.

[0107] When a domain is in the new state 206, execution of a domain active command 208 specifying the local RID of the domain triggers a transition from the new state 206 to the active state 210, in which the domain is now executable and after this moment, domain entry into the corresponding domain will no longer trigger a fault. The domain is now fully operational. As discussed below, in some examples, startup may depend on the verification of parameter signatures. A subsequent domain invalidate command 212 triggered by an ancestor domain of a child domain in any of the clean state 202, the new state 206, and the active state 210 causes a transition to the invalid state 214. To leave the invalid state 214 and return to the clean state 202, the ancestor domain must execute a domain wash command 216. If the resource count that tracks the number of pages owned by the domain has a value other than zero, the domain wash command 216 is rejected. Therefore, in order for the domain wash command 216 to succeed, the ancestor domain must first issue a Granule.Reclaim command for each page owned by the invalid domain. The block.reclaim command specifies a target memory page and triggers invalidation of the target page to render the page inaccessible and also decrements the reference count of the owner domain of the page by one. When the block.reclaim or domain scrub command 216 is executed, it is not necessary to actually overwrite the data in the invalid region, as this can be done when a clean command is subsequently issued to transition the memory page from invalid to valid (see discussion below). Fig.15 ). In addition, in response to the realm flush command, any cached data associated with the invalid realm may also be invalidated, such as within the TLB 100 or cache 110 of any of the processing components 8, 10, 12 (not just the processing component executing the RMU command). The global RID may be used to trigger such invalidation of cached data.

[0108] Thus, by providing a managed lifecycle of a realm associated with a given realm identifier, this ensures that before a realm can be returned to a clean state in which parameters of the realm can be modified (and therefore before a given realm identifier can be recycled for use by a different realm), data associated with a previous realm using the same realm identifier must be flushed from memory and any caches to prevent any data associated with the old realm from leaking to other realms by reuse of the same realm identifier. While a realm is in the clean state 202, the realm descriptor for that realm may also be revoked by executing a realm descriptor release command 218, which enables the memory area stored in the realm descriptor to be allocated for other purposes (at this point, no flushing is required because the realm is clean).

[0109] Fig.12An example of the contents of an entry of a domain region group table 128 (or ownership table) is shown. Each entry corresponds to a given memory region of the memory address space. The size of a given memory region may be fixed or variable, depending on the implementation. The specific manner in which ownership table 128 is structured may vary significantly depending on implementation requirements, and thus the specific manner in which the corresponding memory region for a given entry is identified may vary (e.g., data may be stored in each entry identifying the corresponding region, or alternatively, the corresponding entry may be identified based at least in part on the location of the corresponding ownership entry within the table itself). In addition, Fig.12 Specific examples of parameters that may be specified for a given memory region are shown, but other examples may provide more information or may omit some of the types of information shown.

[0110] like Fig.12 As shown in , each ownership table entry may specify the following items for the corresponding memory region:

[0111] • A global RID identifying the owner realm for the memory region. The owner realm may be a realm that has permissions to set attributes that control which other realms are allowed to access the memory region.

[0112] • The lifecycle state of the corresponding memory region, which is used to control which RMU commands are allowed to be executed on the memory region.

[0113] • The mapped address to which the MMU 26 maps a memory region when it becomes owned by the owner realm. The mapped address may be a virtual address or an intermediate physical address. By specifying this address in the ownership table, this may prevent possible attempts to exceed the security provided by the realm structure by remapping the address translation table after a realm has taken ownership of a given memory region.

[0114] • Visibility attributes that specify which fields other than the owner can access the memory region. For example, Fig.13As shown in , the visibility attribute may specify the visibility bit of the previous generation that controls whether the previous generation domain of the current domain is allowed to access the region, and the global visibility bit that may specify whether any domain can access the corresponding memory region. In general, the domain protection scheme may assume that the descendant domain of the current domain is always allowed to access the memory region owned by the previous generation or predecessor domain of the current domain (subject to whether access is allowed based on the conversion table 120, which provides protection based on the privilege level), but a given domain may control whether the previous generation of the given domain or any other domain that is not a direct descendant of the given domain can access the memory region. In some embodiments, both the previous generation visibility bit and the global visibility bit can be set by the owner domain itself. Alternatively, although the previous generation visibility bit can be set by the owner domain, the global visibility bit may be able to be set by the previous generation domain of the owner domain (provided that the previous generation visibility bit for the memory region has been set to give the previous generation visibility of the memory region). It will be understood that this is only one example of how the owner domain can control which other processes can access the data of the owner domain.

[0115] Fig.14 is a table showing the different life cycle states in which a given memory region may exist, and Fig.15 is a state machine showing commands that trigger transitions between corresponding life cycle states. Fig.11 In a similar manner to the domain life cycle states shown in , the transitions between memory region life cycle states are managed to ensure that the memory region that is transferred from the ownership of one domain to the ownership of another domain must first undergo an invalidation process, in which the data in the region is washed (e.g., set to zero). Therefore, in order to transition from the invalid state 220 to the valid state 222 of the software accessible memory region, the cleaning command 224 must be executed by the RMU 20, triggered by the software executed on the processing component 8. The cleaning command 224 identifies a specific memory region (page) and controls the RMU to step through the memory addresses of the corresponding memory region to invalidate / zero the data in each position in the memory region. If the target memory region is in any state other than invalid, the cleaning command is rejected (e.g., triggered by a fault).

[0116] In some systems, it may be sufficient to provide the valid state 222 and the invalid state 220 as the only memory region life cycle states. Fig.15In the example of , a given memory region may also be designated as an "RMU-private" memory region that is reserved for exclusive access by the RMU 20 itself, such that access to the RMU-private memory region triggered by software executing on the processing circuit 32 (other than any RMU software) will be denied. This is particularly useful for storing domain management data, such as domain descriptors, domain descriptor tree entries, domain execution contexts, and metadata for paging as discussed above. By providing an attribute for designating a given memory region as an RMU-private memory region that is reserved for exclusive access by the RMU, software processes (including the owner process of the memory region itself) may be prevented from being able to access domain management data, which might otherwise allow the software process to circumvent the security protections provided by the domain scheme.

[0117] Therefore, cleaning command 224 can be used as one of the parameters of this cleaning command to specify privacy indication, and this privacy indication specifies whether this is a normal cleaning command or a private cleaning command. Alternatively, two fully separated commands can be provided for these purposes. When cleaning command was a normal cleaning command, this triggered the conversion to active state 222, as discussed above. However, when cleaning command was a private cleaning command 224, this triggered the conversion to RMU cleaning state 226, wherein the memory area was designated as the RMU-private memory area. In some instances, all types of RMU data can be stored in the RMU-private memory area corresponding to a single type of RMU cleaning state.

[0118] However, robustness can be improved by specifying multiple types of RMU-private memory areas, each corresponding to a specific form of domain management data. Fig.14 and Fig.15, a plurality of RMU registration states 228 are defined, each corresponding to an RMU private area, which is designated for a specific purpose. In this example, the RMU registration state 228 includes an RMU registration RDT (for storing RDTG of a domain descriptor tree), an RMU registration RD (for storing domain descriptors), an RMU registration REC (for storing domain execution context data), and an RMU registration MDT (for storing paging metadata used during output / input operations as discussed above). Different forms of registration commands 230 may be executed by the RMU for a memory area in the RMU clean state to convert the memory area to a corresponding one of the RMU registration states 228. Commands for storing data in an RMU-private memory area that does not correspond to a specified purpose (RDT, RD, REC, or MDT) may be rejected. Thus, in a first lifecycle state of the RMU registration state, a first type of RMU command for storing a first type of domain management data may be allowed, and in a second lifecycle state, a second type of RMU command for storing a second type of domain management data may be allowed, wherein the first RMU command is rejected when the target memory area is in the second lifecycle state, and the second RMU command is rejected when the target memory area is in the first lifecycle state. This can achieve further security by avoiding a malicious parent domain, which, for example, attempts to store a domain descriptor entry into a domain execution context area or vice versa in an attempt to split the operation of a child domain. According to each of the RMU registration states 228, a corresponding form of release command 232 may return the corresponding memory area to the invalid state 220. A further clean command may trigger the scrubbing of data from a previously defined RMU-private area before the area can be reallocated for general data.

[0119] Thus, in summary, at least one RMU-private memory region may be defined that is still owned by a given owner domain, but has an attribute specified in the ownership table that means that the at least one RMU-private memory region is reserved for exclusive access by the RMU. In this example, the attribute that controls the RMU-private state is the lifecycle state specified in the corresponding entry in the ownership table, but the attribute may also be identified in other ways. When a given memory region is specified as an RMU private memory region by at least one state attribute, the MMU may prevent access to the given memory region by one or more software processes. Thus, any software-triggered access that is not triggered by the RMU itself may be denied when it targets the RMU-private memory region. This includes preventing access to the RMU-private memory region by the owner domain itself.

[0120] A skilled person may ask why it is useful to define an owner realm for an RMU-private memory region if the owner realm cannot even access the data in the memory region. For example, an alternative approach for implementing access to data by the RMU only would be to define a special realm for the RMU, and allocate pages of the memory address space for storing data that would remain private to that special RMU owner realm. However, the inventors have recognized that when invalidating a realm, there may be a requirement to invalidate all control data associated with that realm, and this may make scrubbing of the invalidated realm's data more complicated if this control data is associated with the special RMU owner realm rather than the invalidated realm.

[0121] In contrast, by using the RMU-private attribute, memory regions storing control data for a given domain remain owned by the domain, even if the owner cannot access the control data, which means that it is simpler to identify which memory regions need to be invalidated when the owner domain is revoked. When invalidating a given domain, the parent domain can simply perform a sequence of reclaim operations (e.g., by executing a reclaim command that is then acted upon by the RMU) that triggers memory regions owned by the specified invalid domain (or descendants of the specified invalid domain) to be invalidated and made inaccessible, and ownership returned to the parent domain that triggered the reclaim command. Reclaim operations can affect not only pages accessible to the invalid domain, but also RMU-private memory regions owned by the invalid domain.

[0122] Another advantage of storing control data for a domain in an RMU-private memory area owned by the domain is when performing export operations. To reduce the domain's memory footprint to zero, during export operations, management structures associated with the domain can be exported in addition to normal memory. Requiring these structures to be owned by the domain simplifies management of the export operations.

[0123] In general, any kind of domain management data may be stored in the RMU-private area, but specifically, the domain management data may include any of the following: a domain descriptor defining properties of a given domain, a domain descriptor tree entry or further domain descriptor tree entries identifying a memory area in which domain descriptors for the given domain are stored, domain execution context data indicating an architectural state associated with at least one thread executing within the given domain, and temporary working data used at intermediate points of predetermined operations associated with the given domain.

[0124] Although RMU-private areas may generally be used to store domain-specific control data associated with a given domain, these RMU-private areas may also be used to increase security with respect to certain other operations performed once a domain is active. For example, when performing the paging-out or paging-in operations discussed above where data is encrypted or decrypted, and a check using metadata is performed to check that the data is still valid when it is input again, such operations may take many cycles and such long-running operations may be more likely to be interrupted midway. To avoid the need to restart the operation again, it is desirable to allow metadata or other temporary working data associated with such long-running operations to remain in cache / memory even upon interruption, without making this data accessible to other processes (including the owner domain itself). This temporary working data may be protected by temporarily designating an area of ​​the memory system as an RMU-private area. Thus, if Fig.14 As shown in , the page state may also include RMU Expressing and RMUI mporting states that can be used when the temporary working data is stored in the memory area, and when one of these states is selected, only the RMU can access the data.

[0125] Other examples of operations that may benefit from temporarily designating corresponding memory regions as RMU-private may include: generation or verification of encrypted or decrypted data during data transfer between at least one memory region owned by a given domain and at least one memory region owned by a domain other than the given domain; transfer of ownership of a memory region to another domain; and destructive reclaim operations performed to render data stored in an invalid memory region inaccessible. For example, a reclaim operation for scrubbing the entire contents of a given page of an address space may be interrupted midway, and thereby ensure that other processes cannot access the page until the scrubbing is complete, and the page may be temporarily designated as RMU-private. In general, any long-latency operation performed by the RMU may benefit from converting the lifecycle state of some memory regions to the RMU-private state before starting the long-running operation, and then converting the lifecycle state back when the long-running operation is complete so that the temporary working data of the long-latency operation is protected.

[0126] When a region is designated as RMU private, the region is reserved for access by the RMU 20, which is used to perform domain management operations. Domain management operations may include at least one of: creating a new domain; updating the properties of an existing domain; invalidating a domain; allocating a memory region for ownership by a given domain; changing the owner domain for a given memory region; changing the state of a given memory region; updating access control information used to control access to a given memory region in response to a command triggered by the owner domain for a given memory region; managing transitions between domains during processing of one or more software processes; managing the transfer of data associated with a given domain between a memory region owned by the given domain and a memory region owned by a different domain than the given domain; and encryption or decryption of data associated with a given domain. The RMU may be a hardware unit used to perform at least a portion of the domain management operations, or may include processing circuitry 32 that executes domain management software to perform at least a portion of the domain management operations, or may be a combination of both.

[0127] Fig.15 State transitions are shown that may be triggered by a given realm to clean a given page so it can be accessed validly, or to invalidate the corresponding page. Fig.16 This scenario is expanded to illustrate further commands that can be used to transfer ownership of a given page from one domain to another. If the memory region is currently in the invalid state 220 and is owned by an ancestor domain, execution of a region claim command 230 by the ancestor domain enables the corresponding memory region to be transferred to the specified child domain. When the target memory region is owned by any domain other than the ancestor domain of the given child domain, or if the memory region is valid or in one of the RMU-private lifecycle states 226, 228, the region claim command 230 is rejected. This prevents an ancestor domain from arbitrarily assigning ownership of pages that are not accessible to the ancestor domain itself or used by the RMU 20. Once a page has been assigned to a child domain, the child domain may execute a clean command to transfer the page to the specified child domain with the same ownership as the ancestor domain. Fig.15 222 in the same manner as shown in FIG. 224. For simplicity, the use of the RMU-private area is not shown in FIG. Fig.16 Not shown, but within any given domain, a private clean command may instead transition the memory region to the RMU clean state 226, as previously discussed.

[0128] The block group claim command 230 is used to transfer ownership to an already established child domain. In addition, the parent domain can execute a block group add command 232, which triggers the RMU 20 to assign ownership to the new child domain in a new state, so that the parent domain can write data to the area assigned to the child. For example, this can be used to install program code for the new child domain so that the child domain can be executed for the first time. Therefore, the add command 232 is different from the claim command 230 in terms of the life cycle state of the corresponding memory area assigned to the child domain. Only when the child domain is in Fig.11 , the add command 232 may be allowed. A child domain may release ownership of a given memory region back to the parent domain of the child domain by executing a block release command 234 that triggers the RMU to update the corresponding entry of the ownership table 128 and update properties such as resource counts in the domain descriptor of the child domain. If the specified memory region is not owned by the current domain issuing the command, or if the region is in a state other than invalid, the block release command 234 may be rejected (ensuring that destructive cleaning of the data is required before the data can be returned to the parent domain's ownership).

[0129] One advantage of using the hierarchical domain structure discussed above in which the domain of the parent generation initializes the domain of the child generation is that this greatly simplifies the invalidation of the domain and the descendants of the domain. It is relatively common that if a given virtual machine domain is to be invalidated, it is also desirable to invalidate the domain of any application running under the virtual machine. However, there may be a large amount of program code, data and other control information associated with each of the processes to be invalidated. It may be desirable to ensure that such invalidation occurs atomically so that when only part of the data scrubbing has been achieved, it is impossible to continue to access data associated with the invalid domain. If each domain is established completely independently of other domains without a domain hierarchy as discussed above, this may make such atomic invalidation difficult because multiple separation commands must be provided to individually invalidate each domain identified by the corresponding domain ID.

[0130] In contrast, by providing a domain hierarchy in which the RMU manages domains such that each domain except a root domain is a descendant domain initialized in response to a command triggered by an ancestor domain, when an invalid command requesting a target domain is received, the RMU 20 can use more efficient operations to make the target domain and any descendant domains of the target domain inaccessible to processing circuitry.

[0131] Specifically, in response to the invalidation of the target domain, the RMU may update the domain management data (e.g., domain descriptor) associated with the target domain to indicate that the target domain is invalid, but there is no need to update any domain management data associated with any descendant domain of the target domain. The domain management data associated with the descendant domain may remain unchanged. This is because even if the domain management data has not changed, simply invalidating the target domain may also make any descendant domain inaccessible, because access to a given domain is controlled by the previous generation of the given domain and therefore if the previous generation domain is invalidated, this means that it is not possible to access the descendants of the previous generation domain. Because each of the domains is entered using a domain entry instruction (ERET instruction discussed below), the domain entry instruction uses a local RID defined by the previous generation domain to identify a specific descendant of the previous generation domain, and this is used to step through the domain descriptors stored in the memory area owned by the previous generation domain of the given descendant domain, so no process other than the previous generation domain can trigger the RMU to access the domain management data of the descendant domain. Therefore, if the previous generation domain is invalidated, the RMU cannot access the domain management data of the given descendant domain, thereby ensuring that the given descendant domain becomes inaccessible.

[0132] After a realm has been invalidated, the realm's ancestor realm may trigger the RMU to perform a reclaim operation for reclaiming each memory region owned by the invalidated target realm. Fig.16 As shown in , a reclaim command 236 for a memory region owned by a descendant domain may trigger a return of the memory region to the invalid state 220 and also transfer ownership of the memory region back to the ancestor domain. However, this reclaim operation may be performed in the background of ongoing processing of other domains and need not be performed immediately in order to allow any descendant domains of the invalid domain to be rendered inaccessible. Fig.11 The single action of changing the activity shown in to invalid is sufficient to ensure that all data associated with any descendant domains of the invalidated domain is also inaccessible. Since any ancestor domain can only assign pages owned by the ancestor domain to the ancestor domain's children, and children can only assign pages owned by the children to grandchildren domains, this also means that tracking which pages need to be invalidated and reclaimed upon invalidation of a given domain is relatively straightforward, because of the protected address ranges defined in the domain descriptors of the invalidated domains (see Fig.16 ) can be used to identify which pages to reclaim, since any further descendant realms of the invalidated realm will also own pages in that range.

[0133] Therefore, in summary, the use of domain hierarchy greatly simplifies the management of domains and invalidations. When such invalidation and overwriting the data in the memory, invalidation can also trigger the invalidation of cache domain management data for the target domain and any descendant domain of the target domain, which is not only kept in the processing component 8 that triggers the invalidation, but also kept in other processing components such as another CPU or GPU. Therefore, there may be invalid broadcasts to other processing components to ensure that other processing components do not continue to have access to the invalid domain. When triggering such invalidation, it may be useful that the cache domain management data will be associated with the global domain identifier that uniquely identifies the corresponding domain, and form a global domain identifier as discussed above, so that the global RID of a given child domain shares a common prefix portion with the global RID of the previous generation domain of the given child domain. This enables a bit mask or other similar operations to be used to quickly compare whether a given domain is a descendant of a specified domain ID. If the invalidation of a predecessor domain renders a given domain inaccessible, then an attempt to enter the specified target domain is impossible (since there is no predecessor domain to execute the ERET instruction for that domain), but even in other implementations using different domain entry mechanisms, domain entry may fail and trigger a fault condition if the domain descriptor for the descendant domain is no longer locatable.

[0134] Fig.17A An example of a check performed by the MMU 26 and the RMU 20 to determine whether a given memory access is allowed is shown. The MMU 26 supports two levels of address translation, level 1 that translates virtual addresses (VA) to intermediate physical addresses (IPA) under the control of the level 1 page table 120-1 set by a given guest operating system, and level 2 address translation that translates the intermediate physical address provided by the level 1 translation to the physical address (PA) used to access memory 16 based on the level 2 page table 120-2 set by the hypervisor 38. The hypervisor may define multiple sets of level 2 page tables for different virtual machines, and the virtual machine ID (VMID) 250 provided with the memory access request may identify which particular level 2 page tables to use. Similarly, the operating system may define multiple sets of level 1 page tables for different applications, and the address space identifier (ASID) 252 may be used to identify which level 1 page tables to use. VMID 250 and ASID 252 may be collectively referred to as a translation context identifier 254, which identifies the current translation context associated with the memory access request. The memory access request also specifies various attributes 256, such as an attribute indicating whether the transaction is a read (R) or write (W) request, or indicating an exception level (X) associated with the process issuing the memory access request.

[0135] Upon receiving a memory access, the MMU 26 may determine whether the transaction attributes are valid based on information from the stage 1 page table. For example, the stage 1 page table may specify that only read transactions may be allowed for certain addresses, or both read and write access may be allowed for a given address (some embodiments may also allow only writes to a region of the address space to be defined). In addition, the attributes in the stage 1 page table may restrict access to processes operating at a given exception level or higher. If the transaction attributes are valid and the access is allowed by the stage 1 page table, the MMU may return the corresponding intermediate physical address (IPA). The IPA is then indexed into the stage 2 page table together with the VMID 250, which again verifies the attributes of the transaction and, if valid, returns the physical address. It should be noted that not all transactions need to go through two stages of address translation. For example, if the input memory transaction is issued at EL3 or EL2, or at EL1 or EL0 in the security domain, the output of the stage 1 MMU may be considered a physical address and the stage 2 MMU may be bypassed.

[0136] Having obtained the physical address, the physical address can then be looked up in the RMU table 128 (realm zone group table) to determine whether the realm protection implemented by the MMU allows the memory access to proceed. Fig.18 Domain checks are discussed in more detail in . If the check at stage 3 succeeds, then the confirmed physical address is output and the memory access is allowed to proceed. If either the check at stage 1 or stage 2 address translation or the RMU-implemented domain protection provided at stage 3 fails, then the memory access is denied. Thus, the protection provided by the domain management unit can be viewed as an additional layer of checks to be performed in addition to any existing address translation checks based on the page table 120. Fig.17A The checks shown in can be performed relatively slowly because there may be multiple tables in memory that need to be accessed and compared to the parameters of the memory access request or the current translation context or realm from which the access is made. Although it will be possible to perform these checks for each memory access, when the checks have been successfully performed for a given memory access request, the data within the TLB 100 can be cached more quickly so that the next time a similar memory access request is issued, the similar memory access request can be allowed without repeating all the checks again. Therefore, it may be desirable to perform these permission checks only when there is a miss in the TLB 100, and not for a hit.

[0137] Fig. 17B An example of a TLB structure 100 for caching data related to authenticated memory accesses is shown. Fig. 17BA single TLB is shown, but it will be appreciated that some systems may include multiple levels of TLBs in a cache hierarchy, with a level 1 TLB storing a smaller subset of translation entries for faster access, and a level 2 or further level TLB storing a larger set of translation entries that can be accessed in the event of a miss in the level 1 TLB. The TLB 100 (or "translation cache") has a plurality of entries 260, each entry specifying address translation data for a corresponding memory region. Each entry 260 includes a virtual addressing tag 262 that corresponds to a virtual address for which a corresponding physical address 264 is provided for the virtual address. In this example, the TLB is a combined level 1 and level 2 TLB, so that a virtual address can be directly translated to a physical address using the TLB without having to go through an intermediate physical address (although a corresponding level 1 and level 2 translation will be performed on a TLB miss in order to locate the correct physical address, the TLB does not need to store an intervening IPA and can map the VA directly to the OA). Other examples may use split stage 1 (S1) and stage 2 (S2) TLBs, in which case the VA-PA pairs 262, 264 may be replaced with VA-IPA pairs or IPA-PA pairs. The TLB entries 260 are also tagged with a translation context identifier 254 (formed by ASID 252 and VMID 250). Although this example provides two separate translation context identifiers, in other examples, a single unified translation context identifier may be used, or in the case of a split S1 / S2 TLB, the S1 TLB may use an ASID and the S2 TLB may use a VMID. The translation context identifiers allow different operating systems or applications that specify the same virtual address to have accesses by those different operating systems or applications mapped to different entries of the TLB 100 that provide different physical addresses.

[0138] A hit in the TLB 100 requires not only that the tag 262 matches the corresponding portion of the address 258 specified for the memory access request, but also that the translation context identifier stored in the same entry should match the current translation context from which the memory access is issued. It is expected that the comparison of the tag 262 and the translation context identifier 254 may be sufficient to locate the correct physical address 264 for a given memory access. However, if these are the only comparisons performed in the lookup, then there is a potential security vulnerability if a memory access hit in the TLB is received without further checking of the domainless management unit table 128. This is because it is possible to create a new process that has the same VMID 250 or ASID 252 as a previously executed process to trick the MMU into accepting a memory access that is actually from a different domain than the one previously accepted for accessing a given memory region.

[0139] To address this issue, the TLB 100 may specify within each TLB entry 260 a global RID 270 of the owner realm that owns the corresponding memory region, and a visibility attribute 272 set by the owner realm to control which other realms are allowed to access the corresponding memory region. When a given lookup of the translation cache 100 is performed in response to a memory access to a given target memory region issued from the current translation context and the current realm, if there is a miss in the translation cache 100, the TLB control circuit 280 may trigger the table walk unit 102 to access the associated page table 120 and the RMU table 128 to check whether the access is allowed. If the page table or the RMU table 128 excludes the current combination of the translation context, the exception level, and the realm from accessing the corresponding memory region, no data is allocated to the translation cache in response to the memory access. Specifically, when the lookup misses and the current realm is excluded from accessing the target memory region by the owner realm of the target memory region, subsequent allocation of address translation data to the translation cache is prevented. Thus, when the corresponding memory access passes checks of both the MMU page table 120 and the RMU table 128 , an entry is allocated to the TLB 100 .

[0140] Subsequently, when looking up the translation cache to check whether the translation cache already includes an entry 260 providing an address translation for a given address, the TLB control circuitry 280 determines whether the memory access matches a given entry of the translation cache 100 based on a first comparison between the translation context identifier 254 specified in the corresponding entry 260 and the translation context identifier 254 for the current translation context received in conjunction with the memory access request, and a second comparison between the global RID 270 specified by the entry 260 and the current global RID associated with the current realm issuing the memory access request. By providing an additional check that the TLB entry is still accessed from a realm previously verified as being allowed to access the memory region, this ensures that even if a malicious supervisory process regenerates another process having the same ASID 252 or VMID 250 as a previously existing process allowed to access data by the owner realm, since the global realm identifier 270 is not subjected to the same ASID 252 as the previously existing process allowed to access data by the owner realm, the memory access does not match the given entry of the translation cache 100. Fig.18 In the case of the realm flush command 216 in question, it cannot be reallocated to other processors, so this means that the global RID of the current realm can be trusted to be valid and not "fake", as is possible with an ASID or VMID. Therefore, if the global RID of the current realm still satisfies the permissions indicated by the owner GRID 270 and visibility attributes 272, then this indicates that the realm table check previously performed is still valid.

[0141] If the second comparison of the realm identifiers detects a mismatch, then even if the tag comparison and translation context comparison match, the access request is considered to have missed in the TLB because it indicates that there is a change in the mapping between the translation context ID 254 and the realm ID 270 because an entry was allocated. This does not necessarily imply that the access will be denied because another traversal of the page table and RMU table may be triggered by the table walk unit 102, and if the realm check is successful, this may result in the allocation of a different entry 260 in the TLB 100 and the servicing of the memory access based on the information from the newly allocated entry.

[0142] Fig.18 1 is a flow chart illustrating a method of determining whether a given memory access is allowed by MMU 26. At step 300, a memory access request is received and the memory access request is looked up in TLB 100. The memory access request specifies at least a virtual address to be accessed, one or more translation context identifiers indicating a current translation context, and a global realm identifier identifying a current realm. For example, the global RID may be read from a status register of processing component 8, which may be written with the global RID of the current realm upon entering a realm.

[0143] In response to a memory access request, the TLB control circuit 280 performs a search of these TLBs. The search accesses at least some entries of the TLB. Some methods may use a fully associative cache structure, and in this case, all entries of at least the first level TLB may be searched and compared with the parameters of the current request to identify whether there is a hit or a miss. Other methods may use a set associative cache allocation strategy, and in this case, only a subset of the entries of a given level of the TLB may need to be searched, indexed using the target address of the memory access. For each of the access sets of entries, the TLB control circuit 280 performs these multiple comparisons (in parallel or sequentially), including:

[0144] • a tag comparison 302 for comparing whether the address of the memory access request matches the tag 262 stored in the access entry;

[0145] • a first (context) comparison 304 of the translation context identifier stored in the access entry with the translation context identifier of the memory access request; and

[0146] • A second (field) comparison 306 for comparing the global RID of the memory access request with the owner RID 270 and the visibility attribute 272 for each of the entry's access set.

[0147] At step 308, the control circuit 280 determines whether there is an entry in the TLB that returns a match for all comparisons 302, 304, 306, and if so, a hit is identified, and at step 310, the physical address 264 specified in the matching entry is returned and the memory access is allowed to proceed based on the physical address. In the case of a hit, no lookup of the page table or RMU table needs to be performed (the ownership table lookup for memory access can be omitted). The protection provided by the page table and RMU table is only invoked on a miss.

[0148] If there is no entry matching all three of the comparisons 302, 304, 306, then a miss is detected. If further TLB levels are provided, then corresponding lookup steps 300-308 may be performed in a second or subsequent level TLB. If the lookup does not hit in the last level TLB, then a traversal of the various page tables and RMU tables is performed. Thus, a level 1 page table traversal is performed at step 311, and a determination is made at step 312 whether a level 1 page table fault has occurred (e.g., because there is no address mapping defined for a specified virtual address or because the current parameters of the access request violate the access permissions specified for the target virtual address). If a level 1 fault has occurred, then at step 314, memory access is denied and allocation of address mapping data to the TLB 100 in response to the memory access is prevented.

[0149] On the other hand, if the access request passes the stage 1 page table check, then at step 315, a stage 2 page table walk is triggered to obtain mapping data for the intermediate physical address returned by the stage 1 process, and at step 316, it is determined whether a stage 2 page table fault has occurred (again, because the address mapping is undefined or because the access is not allowed by the stage 2 access permissions). If a stage 2 fault has occurred, then the access request is again denied at step 314.

[0150] If no stage 2 failure has occurred, then at step 318, an RMU table lookup is triggered based on the physical address returned by stage 2, and at step 320, a determination is made as to whether a domain failure has been detected. A domain failure may be triggered if any of the following events occur:

[0151] • If the lifecycle state for the corresponding memory region is indicated as invalid in the domain ownership table 128. This ensures that Fig.15 The pages of the memory address space of the cleaning operation 224 shown in FIG. 2 are made inaccessible to protect any data previously stored in that memory region by another realm from being accessed by a different realm.

[0152] • The current domain is not allowed by the owner domain for the corresponding memory region to access the memory region. There may be multiple reasons why a given domain may not be allowed to access a given memory region. If the owner domain has specified that the memory region is visible only to the owner itself and the descendants of that owner, then another domain may not be allowed to access that domain. In addition, if the current domain is an ancestor domain of the owner domain and the owner domain has not defined an ancestor visibility attribute to allow the ancestor to access the region, then memory access may be denied. In addition, if the memory region is currently set to RMU-private as discussed above, then the owner domain itself may be prevented from accessing the memory region. At the RMU check stage, descendant domains of the owner domain may be allowed to access the memory region (as long as the memory region is not an RMU-private region). Therefore, this check enforces the access permissions set by the owner domain.

[0153] • If the physical address mapped by S1 / S2 for the current memory access does not match the virtual address or intermediate physical address in Fig.12 , memory access is denied if a mapping address specified in ownership table 128 for the corresponding memory region is not specified. This protects against the following situation: a malicious parent domain may assign ownership of a given memory region to a child domain, but then change the translation mapping in page table 120 so that subsequent memory accesses triggered by the child domain using the same virtual address that the child domain previously used to reference a page owned by the child domain now map to a different physical address that is not actually owned by the child domain itself. By providing a reverse mapping in the ownership table from the physical address of the corresponding memory region back to the mapping address used to generate the physical address when ownership was asserted, this allows security breaches caused by changes in the address mapping to be detected so that memory accesses will fail.

[0154] It will be appreciated that other types of checks may also be performed. If the realm check is successful, then the physical address is returned at step 322, the memory access is allowed to proceed using the physical address, and a new entry is allocated to the TLB indicating the physical address obtained from the page table 120 and the owner realm and visibility attributes obtained from the ownership table 128 corresponding to the requested virtual address and translation context.

[0155] When entering or exiting a domain, the processing component 8 and / or RMU 20 may need to perform a number of operations for ensuring safe handling of the domain entry or exit. For example, when entering a domain, a number of checks may need to be performed to check that the target domain is in the correct lifecycle state (to avoid exceeding the safety measures by attempting to enter a non-existent domain or a domain that has not, for example, undergone a scrubbing of data from its owned pages). In addition, when exiting a domain, it may be desirable to mask the architectural state stored in the registers of the processing component so that a higher privileged level process cannot access state data used by a lower privileged level domain (which would otherwise cause the safety measures provided by the domain protection to be exceeded). One method for handling domain entry and exit may provide a dedicated domain entry or domain exit instruction that triggers the RMU 20 to perform the associated operations for entering or exiting a domain.

[0156] Another approach may be to reuse mechanisms already provided for exception entry and return to enter and exit domains. This reduces the amount of software modifications required to support domain entry and exit, and simplifies the architecture and hardware. This is particularly useful because typically domain boundaries may correspond to exception level boundaries anyway, and even if new instructions are provided to control entry and exit, behavior for handling exceptions will still be required, so overall, extending the exception mechanism to also control entry and exit may be less expensive.

[0157] Thus, an exception return (ERET) instruction that would normally cause processing to return from an exception handled in the current domain to another process also being handled in the current domain (where the other process may be handled at the same exception level or a less privileged exception level than the exception) may be reused to trigger a domain entry from the current domain to a destination domain. In response to a first variant of the exception return instruction, the processing circuitry may switch processing from the current exception level to a less privileged exception level (without changing domains), while in response to a second variant of the exception return instruction, the processing circuitry may switch processing from the current domain to a destination domain, which may operate at the same exception level or a reduced (less privileged) exception level as the current domain. Using an exception return instruction to trigger domain entry may greatly simplify the architecture and hardware management burden and reduce software modification requirements to support the use of domains.

[0158] Another advantage of using the exception return instruction is that, usually when returning from an exception, the processing circuit can execute an atomic set of operations in response to the exception return instruction. The set of operations required when returning from an exception can be executed atomically, so that these operations cannot be divided midway, and therefore the instruction fails and none of the atomic set of operations is executed, or the instruction is successfully executed and all of the atomic set of operations are executed. For the second variant of the exception return instruction, the processing circuit can similarly execute an atomic set of second operations, which can be different from the atomic set of the first operation. The mechanism provided in the processor to ensure that the exception return instruction is completed atomically can be reused for domain entry in order to avoid situations where domain entry can only be partially executed, which can lead to security weaknesses. For example, the atomic set of the second operation can include making the domain execution context state available, changing the current domain being executed, and controlling the branch to the program counter address where the process was previously executed when the same domain was last executed.

[0159] The first variant and the second variant of the exception return instruction may have the same instruction encoding. Therefore, no modification of the exception return instruction itself is necessary in order to trigger the domain entry. This improves compatibility with legacy code. Whether a given exception return instruction is executed as the first variant or the second variant may depend on a control value stored in a state register for the given exception return instruction (e.g., the first value and the second value of the control value may represent the first variant and the second variant of the exception return instruction, respectively). Therefore, the current architectural state when the exception return instruction is executed controls whether the exception return instruction returns the processor to a lower privilege level in the same domain, or triggers entry to a new domain.

[0160] This approach enables domain entry to be controlled with fewer software modifications, particularly when the value in the status register can be set automatically by hardware in response to certain events that suggest a domain switch is possible (in addition to allowing voluntary setting of the control value in response to software instructions). For example, when an exception condition occurs that triggers an exit to a given domain, the processing circuitry may set the control value to the second value for the given domain, so that a subsequent exception return instruction will automatically return processing to the domain where the exception occurred, even considering that the exception handler code used to handle the exception is the same as the previous legacy code that was not written in the domain. Alternatively, it may be expected in some architectures that when exiting from a domain, the control value in the status register will still contain the second value that was set prior to triggering domain entry to that domain, and thus explicit setting of the control value in the status register may not be required.

[0161] At least one realm identifier register may be provided, and in response to the second variant of the exception return instruction, the processing circuit may identify the destination realm from the realm identifier stored in the realm identifier register. The realm identifier register may be grouped so that there are multiple realm identifier registers each associated with one of the exception levels, and in response to the second variant of the exception return instruction, the processing circuit may identify the destination realm from the realm identifier stored in the realm identifier register associated with the current exception level. By using the realm identifier register to store the target realm identifier, this does not need to be included in the instruction encoding of the ERET instruction, which enables the existing format of the ERET instruction to be used to trigger realm entry, thereby reducing the amount of software modification required. The realm identifier in the realm identifier register may be a local realm identifier used by the parent realm to reference the child realm of the parent realm, and thus realm entry may be limited to passing from the parent realm to the child realm, and it is not possible to go from the first realm to another realm that is not a direct child of the first realm. In response to the second variant of the exception return instruction, the processing circuit may trigger a fault condition when the realm associated with the realm ID identified in the RID register is an invalid realm (no realm descriptor has been defined or the realm descriptor defines a RID of a life cycle state other than active).

[0162] In response to the second variant of the exception return instruction, the processing circuit may restore the architectural state associated with the thread to be processed in the destination domain from the domain execution context (REC) memory area specified for the exception return instruction. The state restoration may be performed immediately in response to the second variant of the exception return instruction (e.g., as part of an atomic set of operations), or may be performed later. For example, the state restoration may be performed in a lazy manner, so that the state required to start processing in the destination domain may be restored immediately (e.g., program counter, processing mode information, etc.), but other states such as general registers may be gradually restored when needed at a later time, or in the background of continued processing in the new domain. Therefore, the processing circuit may start processing in the destination domain before all required architectural states have been restored from the REC memory area.

[0163] In response to the first variant of the exception return instruction, the processing circuit may branch to the program instruction address stored in the link register. In contrast, for the second variant of the exception return instruction, the processing circuit may branch to the program instruction address specified in the domain execution context (REC) memory area. Because the link register will not be used for the second variant of the exception return instruction to directly identify any architectural state for the new domain, the link register can be reused to instead provide a pointer to the REC memory area from which the architectural state of the new domain will be restored. This avoids the need to provide a further register for storing the REC pointer.

[0164] Therefore, prior to executing an exception return instruction that attempts to cause a realm entry to a given realm, some additional instructions may be included to set the RID register to the realm identifier of the destination realm and to set the link register to store a pointer to the REC memory area associated with the destination realm. The REC pointer may be obtained by the parent realm from the realm descriptor of the destination realm.

[0165] In response to the second variant of the abnormal return instruction, when the REC memory area is associated with the owner domain other than the destination domain or the REC memory area specified for the abnormal return instruction is invalid, the fault condition can be triggered by the processing circuit. The first check prevents the previous generation domain from inducing the child domain to execute with the processor state that the child domain does not create itself, because the memory area owned only by the child domain can be stored in the REC memory area that can be accessed when entering the domain (and as discussed above, the REC memory area will be set to RMU private). The second check of the validity of the REC memory area can be used to ensure that the REC memory area can be used only once to enter the domain, and subsequent attempts to enter the domain with the same REC data will be rejected. For example, each REC can have a life cycle state that can be invalid or valid. In response to the exception that occurs during the processing of a given thread in the current domain, the architecture state of the thread can be saved to the corresponding REC memory area, and the corresponding REC memory area can then be converted from invalid to valid. In response to the successful execution of the second variant of the abnormal return instruction, the REC memory area can then be converted back from valid to invalid. This prevents an ancestor realm from maliciously causing a child realm to behave incorrectly by specifying a pointer to a stale REC memory area, a REC memory area associated with a different thread, or some other REC that is associated with the destination realm but is not the correct REC used to store the architectural state at the previous exit of the realm.

[0166] In a corresponding manner, an exit from a domain may reuse the mechanisms provided for exception handling. Thus, in response to an exception condition occurring during processing of a first domain that cannot be handled by the first domain, the processing circuitry may trigger a domain exit to a parent domain that initialized the first domain. Upon exception occurrence / domain exit, some additional operations may be performed that would not be performed for an exception occurrence that could be handled within the same domain. For example, this may include masking or scrubbing of architectural state and triggering of state storage to REC.

[0167] However, in some cases, an exception may occur that cannot be handled by the domain of the previous generation of the first domain in which the exception occurred. Therefore, in this case, it may be necessary to switch to a domain of a further previous generation that is beyond the previous generation. Although it may be possible to provide the ability to switch directly from a given domain to a domain of a previous generation that is more than one generation older, this may increase the complexity of the state registers required to handle exception entry and return or domain exit and entry.

[0168] Alternatively, a nested domain exit may be performed when an exception condition is to be processed at a target exception level having a greater privilege level than the most privileged exception level that is allowed to be executed in the parent domain of the first domain. A nested domain exit may include two or more successive domain exits from the child domain to the parent domain until a second domain is reached, which is allowed to be processed at the target exception level of the exception that occurred. Thus, by raising the domain hierarchy one level at a time, this can simplify the architecture. At each successive domain exit, there may be an operation that is performed to save a subset of the processor state to a REC associated with the corresponding domain.

[0169] Fig.19 The concept of a child domain that can be initialized by a parent domain is shown in Figure 1. Fig.19 As shown in , a given upper-generation domain 600 operating at a specific abnormal level can initialize a child domain 602, which operates at the same abnormal level as the upper generation of the child domain. The complete domain 600 corresponds to a given software process (or a set of two or more processes), but the child domain corresponds to a predetermined address range within a given software process. Because the complete domain is the upper generation of the child domain, as discussed above, the child domain may have the authority to access data stored in a memory area owned by the upper-generation complete domain, but the child domain may have the authority to exclude the upper-generation complete domain of the child domain from accessing data stored in a memory area owned by the child domain 602. This can be used to allow a certain part of a given software process to be safer than other parts of the software process. For example, a part of a code for checking a password in a mobile banking application or for processing other sensitive information can be assigned to the child domain to prevent other parts of the same application or operating system from accessing the sensitive information.

[0170] The child domain can be generally handled in the same manner as the complete domain, with some differences as explained below. Entry to the child domain and exit from the child domain can be handled using an exception return instruction and an exception event in the same manner as discussed above. Therefore, the child domain can have a child domain ID constructed in the same manner as the complete child domain of the same previous generation, and can have a domain descriptor in the domain descriptor tree as discussed above. Entry to the child domain can be simply triggered by executing an ERET instruction, which has placed the appropriate child domain RID in the RID register before executing the ERET instruction. Therefore, the same type of ERET instruction (belonging to the second variant) can be used to trigger entry to the complete domain or the child domain.

[0171] One way that child domains may differ from full domains may be that child domains may not be allowed to initialize their own child domains. Thus, if the current domain is a child domain, a domain initialization command for initializing a new domain may be rejected. The RMU may use the domain type value in the domain descriptor of the current domain to determine whether the current domain is a full domain or a child domain. By disabling domain initialization when currently in a child domain, this simplifies the architecture because no additional status registers need to be provided for use by child domains in initializing further domains.

[0172] Similarly, when currently in a child domain, the execution of the domain entry instruction can be prohibited. This simplifies the architecture because it means that the grouped registers for handling domain entry and exit (and exception entry and return) that are copied for different exception states do not need to be grouped again for each child domain, which will be difficult to manage because it may not be known at design time how many child domains a given process will create. Similarly, when the current domain is a child domain rather than a complete domain, the exception return event that triggers the switch to the process operating at a lower privilege level can be prohibited. Although a single type of ERET instruction is used as both a domain entry instruction and an exception return instruction in the example discussed above, this is not necessary for all embodiments, and in the case of providing a separation instruction, both exception return instructions can be prohibited when the current domain is a child domain.

[0173] Similarly, when an exception occurs while in the child domain, the processing circuit may trigger an exit from the child domain to the parent complete domain that initializes the child domain before handling the exception, rather than taking the exception directly from the child domain. Therefore, the exception triggers a return to the parent complete domain. The exception return to the parent complete domain may include state masking, washing, and saving operations on REC, but by avoiding the exception from going directly from the child domain to the domain of the higher exception level, this avoids the need to group the exception control registers again for the child domain, thereby simplifying the architecture.

[0174] For a child domain, the boundary exception level indicating the maximum privilege level of processing allowed for the domain is equal to the boundary exception level for the ancestor full domain of the domain. Conversely, for a child full domain, the boundary exception level is a less privileged exception level than the boundary exception level of the ancestor domain of the child full domain.

[0175] When a Realm is initialized by an Ancestor Realm, the Ancestor Realm can choose whether the new Realm will be a child Full Realm or a child Child Realm, and can set the appropriate Realm Type parameter in the Realm Descriptor accordingly. Once a Realm is operational, the Ancestor Realm can no longer change the Realm Type, as modifications to the Realm Descriptor are blocked by the above description of the Realm Type parameter. Fig.11 The management domain lifecycle in question is prohibited.

[0176] In summary, the ability to introduce a child domain that is managed similarly to the full domain but where exception handling, domain initialization, and domain entry functionality are prohibited within the child domain enables smaller portions of code corresponding to a given address range within a software process within the full domain to be isolated from other portions of the software to provide additional security for certain segments of sensitive code or data.

[0177] Parameter Signature

[0178] The access control model described above protects the realm from any other agent on the system, including other software at the same privilege level, other software at higher privilege levels, and other realms. When a realm is established, the realm is populated with content (memory pages) representing the initial contents of the realm. The initial contents are measured. The realm is also assigned security configurations, such as whether to start the realm in debug mode, scope parameters for exporting realm secrets, and so on. These realm secrets are typically used by the realm to protect its own internal boot process and keep its data private. The process of establishing a realm, measuring the realm, and enforcing its security parameters (including the export of domain secrets) is managed by the realm management unit.

[0179] Once a realm is built and executed, some external consumer (e.g., a client connected to a server application executing inside the realm) can connect to the realm and request an attestation report. The attestation report allows the external consumer to verify that the realm is executing on a trusted system, and that the realm was initially populated with the expected software (realm measurements), as well as verify that the realm is configured as expected (e.g., not started with debug enabled). This is useful for applications where data is only provided or becomes available after a successful attestation.

[0180] However, providing attestation after realm establishment and execution may not be sufficient for the following example use cases:

[0181] Where data needs to be persistently stored on the system so that it remains available across reboots of the domain or system,

[0182] If you need to make data available to multiple instances of the "same" realm for load balancing, redundancy, etc.

[0183] If the realm needs to access some boot secrets before it has authenticated, such as accessing a boot image stored in a protected file system. This includes the "same" realm, or subsequent reboots of the system.

[0184] Here, "same" realm means one or more realm instances that are populated with the same initial content and use the same security configuration.

[0185] These problems can be solved by introducing the concept of signed realm parameters. The security parameters of a realm are extended to include expected measurements. The security configuration of a realm is signed by a parameter signer. The parameter signer identity is included with the signature. For example, using asymmetric cryptography, the parameters can be signed using a private key owned by the parameter signer, and a hash of the corresponding public key can be used as the parameter signer identity.

[0186] The rules for establishing a realm are extended so that if signed parameters are used, the signature of the actual security configuration must match the expected signature before the realm can be started, and the signer ID is included in the key derivation for deriving the realm secret. These rules are enforced by the realm management unit 20 and cannot be blocked by software.

[0187] This means that a realm can be started and its secrets accessed only if: (i) its security configuration has been correctly signed; and (ii) the signer is the correct entity. If either of these two conditions is not met, then either realm will not start, or the realm will start but will not be able to access its secrets.

[0188] For example, Fig. 20 An example is shown of using such parameter signatures to verify that the security configuration parameters of a realm have been set as intended by a party requesting that the realm be installed on a given hardware platform when a given realm is launched.

[0189] As in Fig. 20 As shown at the top of , when establishing a domain, the party that needs to use the domain requests the parent domain to start the target domain and establish the target domain with some set of domain security configuration parameters 400. For example, the initial domain parameters may be specified in a command sent to the parent domain by some external party (e.g., a banking provider, a healthcare provider), or other party that wants the hardware part to install a secure domain for interacting with that provider. It is expected that the initial set of domain security configuration parameters 400 will be added to the domain descriptor of the target domain by the parent domain using a domain parameter update command.

[0190] For example, the initial realm parameters may include some of the content of the realm descriptor described above (such as the realm type 402), as well as other security configuration parameters, such as an indication 406 of whether to enable the output of data from the first memory 16 (with domain ownership protection) to the second external memory 6, or an indication 408 of whether debugging is enabled for the realm. Other realm security configuration parameters (such as protected address ranges), and key data for deriving root keys may not be included in the initial parameter set given to the previous generation realm, but may instead be generated by the RMU when the realm is established, the RMU being provided to the realm by a trusted intermediate realm as described below, or generated by the realm itself.

[0191] The initial domain parameters 400 also include an expected signature 410 corresponding to a signature of a subset of security configuration parameters that are expected to be established for the domain. The expected signature 410 is calculated by the parameter signatory (e.g., the party requesting the domain installation) based on the expected security configuration parameters and is given to the parent domain along with the security configuration parameters for the established domain. The initial domain parameters also include an indication of a signatory ID 412 that identifies the parameter signatory. When configuring the target domain, the expected signature 410 and the signatory ID 412 can be recorded by the parent domain in the domain descriptor of the target domain while the target domain is in a clean state.

[0192] For example, expected signature 410 may be generated by a parameter signer by generating a hash value based on a hash function of the expected domain parameters and encrypting the hash function using a private key associated with the parameter signer. Signer ID 412 may be a public key of the parameter signer that corresponds to a private key used to generate signature 410 using an asymmetric cryptographic scheme.

[0193] Expected signature 410 may be computed not only on a subset of the expected domain security configuration parameters themselves, but may also be based on measurements computed as a function of the expected domain content (data and code) that is expected to be stored in a memory area owned by the target domain when the domain is booted.

[0194] The expected signature 410 may not cover all security configuration parameters of a domain. Some security configuration parameters that would be set in a domain descriptor for a given domain may be excluded from the calculation of the expected signature 410. This may include the expected signature 410 itself and the signer ID 412. In addition, some domain parameters in the domain descriptor may depend on local characteristics of a particular entity platform, rather than on security configuration settings desired by an external party that needs to establish a domain. For example, specific addresses defined for a protected address range may depend on a specific address mapping established for a domain on a given entity instance, or some hardware instance-unique keys may be generated by the RMU 20 of a particular entity instance and therefore may not be predictable by a parameter signer and therefore may not undergo parameter signing.

[0195] When the target domain is started to make it available for processing by the processing circuitry, the RMU 20 verifies the actual domain parameters 420 represented in the domain descriptor of the target domain based on the expected signature 410 provided by the parameter signer when the domain was established. At this time, the RMU determines the parameter signature 422 based on: (i) a subset of the actual security configuration parameters 420 of the domain (again excluding certain parameters as shown above), and (ii) a measurement 421 of the actual domain contents of the memory area owned by the target domain. For example, some hash function 424 may be applied to the domain security configuration parameters 420 and the measurement 421 to generate the parameter signature 422. The hash function 424 may correspond to such a hash function that is used by the parameter signer to generate the expected signature 410 based on the expected domain parameters and the expected domain contents.

[0196] The RMU 20 also obtains the expected signature 410 and the signer ID 412 from the realm descriptor of the target realm, and verifies whether the expected signature 410 and the parameter signature 424 match. For example, if the expected signature 410 is calculated by the parameter signer by decrypting the expected parameters using a private key, the RMU 10 may decrypt the expected signature 410 using the signer's public key as represented by the signer ID 412, and then compare the decrypted signature to the parameter signature 422 generated from the actual realm parameters. Alternatively, other cryptographic techniques may be used to verify whether the parameter signature 422 derived from the actual parameters 420 matches the expected signature.

[0197] Typically, if a match is detected between the actual parameter signature 422 derived from the security configuration parameters 420 and the expected signature 410 provided when the realm was established, then the booting of the target realm is allowed to proceed (assuming any other security checks are met). On the other hand, if a mismatch is detected between the parameter signature 422 and the expected signature 410, then the booting is restricted by one of the following: generating a fault so that the realm is not allowed to boot at all, or allowing the realm to boot but denying access to the keys used to protect the realm content, which prevents the realm from operating incorrectly. In either case, by using signature verification, the RMU can enforce a match between the actual parameters at the time of realm booting and the expected parameters having the parameter signature expected to be installed by the realm, so as to warn the previous generation realm without maliciously changing the realm parameters, which are given to the realm by the party requesting the installation of the realm.

[0198] The signer ID 412 is also included in the key material for deriving the target realm's realm secrets. This means that if a given realm is established and its realm parameters are verified as authentic based on a signature provided by the wrong signer, then although the realm can be started, the realm will not have the correct keys for accessing data protected by the keys associated with the correct signer.

[0199] This method of using parameter signatures is relatively uncommon, as typically cryptographic signatures will be used to verify that the identity of a party providing some information matches some known identity. Fig. 20 In the scenario shown in , the actual identity of the party requesting realm establishment is not verified against any known identity. In practice, any party is allowed to request the establishment of a given realm and have their realm started if the expected signature given at realm establishment time matches the actual signature generated from the actual parameters at realm startup time. Therefore, if an attacker provides a signature that is different from the expected signature, and the actual parameters are established in a way that matches the different signature, the realm will be allowed to be started. However, including the signer's public key in the realm's keying material prevents a realm configured by an attacker from being allowed to access data protected by the parameter signer, so security is still implemented. The purpose of the signature check is not to verify the identity of the party requesting the installation of the realm, but to check whether the parameters defined at startup (regardless of who has requested the realm to be installed) match the parameters provided with the signature when the realm was requested to be installed, to prevent the parameters from being modified inappropriately by the previous generation realm.

[0200] like Fig. 20As shown in , the domain parameters also optionally include an age indication 430, which can be represented as the version of the software installed for a given domain. The age 430 is covered by the expected signature 410 and the parameter signature 422. In addition, the age 430 is also included in the key material used to derive the domain secret. This allows the version of the installed domain software to be verified, and allows checking which versions of the domain software are allowed to derive or use secrets established by earlier or later domains / versions. Therefore, if a security weakness identified with a specific version of the domain software has a given age value, a later update to fix the problem can be given a later age value. The domain secret export can allow the domain to be allowed to export or use secrets of any security age (earlier than or the same as the age of the domain itself), but it is impossible to export secrets of any security age that is newer than the age of the domain itself. By including the age in the parameters covered by the domain signature, this prevents the previous generation domain from trying to update the age between the initial domain parameters given when the domain is established and the domain is started.

[0201] Fig.21 is a flow chart illustrating a method for verifying domain parameters based on parameter signatures. At step 440, the parent domain of the target domain to be started issues a domain startup command that specifies the target domain. At step 442, the RMU 20 checks whether the target domain is in a new state, and if not, at step 444, a fault is triggered. If the domain is in a new state, then at step 446, the RMU checks whether the parameter signature is enabled. In some systems, parameter signatures may enable or disable the system as a whole. In other embodiments, parameter signatures may be enabled or disabled for individual domains (e.g., security configuration parameters of domain descriptors that are not allowed to be updated using the parent domain). If the parameter signature is disabled, then at step 448, the startup of the target domain is allowed regardless of any parameter signature.

[0202] However, if parameter signing is enabled, then at step 450, the RMU obtains the expected signature 410 for the domain parameters from the domain descriptor of the target domain. At step 452, the RMU generates a parameter signature 422 based on a subset of the actual security configuration parameters 420 defined in the domain descriptor of the target domain, and based on a measurement of the domain content 421. At step 454, the RMU determines whether the parameter signature 422 matches the expected signature 410, and if so, then at step 456, the launch is allowed and the signer ID 412 and time period 430 are included in the key data for deriving the domain secrets. If the parameter signature does not match the expected signature, then at step 458, launch restrictions are applied. This may be to generate a fault to prevent the launch from succeeding, or alternatively, the launch may be allowed but the configuration settings may be specified to prevent the domain from accessing its domain secrets.

[0203] Trusted Intermediate Realm

[0204] like Fig. 22 As shown in , a realm may be initially established on a specific system managed by a specific entity system. Later, the realm may be terminated and subsequently restarted on the same or a different system, or multiple instances of the same realm may be established on the same or different systems for load balancing and redundancy purposes. In either case, it may be necessary to share the same data set, which is protected by keys that are exportable by all instances of the same realm. Similarly, the security configuration parameters of the realm may need to be consistent across multiple instances of the same realm. Any links that need to survive a realm restart, or that may be reestablished on a different system, cannot themselves be managed by a specific instance of the entity system.

[0205] like Fig.23 As shown in , a related problem is that a service provider may need to migrate domains between different systems in a data center, or between different data centers to manage load, redundancy, etc. across all available computing resources. In the absence of a system based on domain protection as described above, migration can be implemented, for example, by pausing the virtual machine, paging the entire virtual machine, restoring the virtual machine on a different machine, and then starting it again. The destination is usually not known at the beginning of the migration process, but is determined at some later time, so the migrated virtual machine may eventually be restored on any system. In some cases, the process can be started while the virtual machine is still executing ("online migration"). For systems using the above-mentioned domain-based protection, this existing migration process does not work because it will damage the basic security guarantee of the domain-based system. For example, the domain may have been started and certified on a system with known security attributes. Because the ordinary migration process involves untrusted system software in the data center, for this migration through paging, the domain or RMU 20 on a given physical system cannot implement the following items: before the domain has been started on the new system, the target system has the same security attributes.

[0206] These issues can be addressed by defining a trusted intermediate realm that is associated with a given target realm and is allowed to manage the target realm on behalf of external parties associated with the target realm. The trusted intermediate realm may, for example, be allowed to perform certain realm management functions, including injecting "provided" secrets and / or saving and restoring security configuration parameters, so that a realm can be migrated between different physical platforms or instances of a realm can be terminated and later restored while having a consistent set of keys and security configuration parameters for each instance of the "same realm".

[0207] like Fig.24As shown in , a given domain A may specify in its domain security configuration parameters 400 (i.e., in its domain descriptor 124) an identifier 500 of a trusted intermediate domain, which is another domain operating on the same entity instance. For example, a global domain identifier (GRID) as described above may be used to identify a trusted intermediate domain. In some cases, the security configuration parameters in the domain descriptor of a given domain A may also include a flag indicating whether the domain is associated with a trusted intermediate domain. Alternatively, if the flag can be derived from the value in the trusted intermediate domain identifier field 500, the flag may not be required in some implementations. For example, if the trusted intermediate domain identifier 500 is set to a value that is not an allowed identifier of a real domain, this may implicitly identify that there is no trusted intermediate domain associated with the given domain. A domain may be managed by only one trusted intermediate domain, but one trusted intermediate domain may manage multiple other domains, each of which specifies the same domain as the trusted intermediate domain.

[0208] The trusted intermediate domain may store information for managing the associated domain A in its owned memory pages 502. For example, the trusted intermediate domain may store a plurality of provided secrets 504 that may be injected into domain A as key material for deriving keys to protect the data and code of domain A, and a key management policy 506 that may specify information about how and when these keys may be injected. In addition, the pages 502 owned by the trusted intermediate domain may store configuration records 508 that may indicate a set of security configuration parameters that may be injected into the domain descriptor of domain A. Updates to the security configuration parameters of domain A by the trusted intermediate domain may be limited to before the domain is started. Some parameters of the domain descriptor may not be allowed to be set by the trusted intermediate domain (e.g., the identifier of the trusted intermediate domain itself).

[0209] In some instances, the security configuration record 508 may have been provided to the trusted intermediate domain when the trusted intermediate domain was established (e.g., the security configuration record 508 for domain A to be managed by the trusted intermediate domain may be included in the information bundle provided to the parent domain of the trusted intermediate domain when the trusted intermediate domain was established).

[0210] Alternatively, the security configuration record may be generated as a snapshot of the configuration parameters of domain A, which snapshot is taken after domain A is started. For example, the trusted intermediate domain may be allowed to issue a command to the RMU 20 requesting that a snapshot of the security configuration parameters of domain A be returned and stored as a security configuration record in a memory area owned by the trusted intermediate domain. If the domain issuing the command is any domain other than the trusted intermediate domain specified in the identifier 500 within the domain security configuration parameters 400 defined for domain A, the command may be rejected by the RMU. This allows the parameters of the valid domain to be backed up so that they can be restored later, for example to allow, for example, Fig. 22 to resume a previously terminated field as shown in , or to Fig.23 , or for rolling back the configuration of a given domain to an earlier state. Security configuration record 508 may be associated with migration policy 510, which may define properties for controlling how, when, and whether a domain is allowed to migrate to a different platform and under what conditions.

[0211] A trusted intermediate realm does not necessarily support both injection of provided secrets and preservation and restoration of security configuration records. Some intermediate realms (or the entirety of some embodiments of a realm-based architecture) may only be able to handle one of these functions.

[0212] When a domain is established, the association of a domain with a trusted intermediate domain can be verified by an external party or by other domains by requesting the RMU 20 to generate a certificate for the target domain and / or a certificate for the trusted intermediate domain. These certificates may include signatures of security configuration parameters of the domain, or domain content of the target domain A managed by the trusted intermediate domain. When a certificate is generated for domain A, the fact that domain A is associated with a trusted intermediate may be apparent from the domain certificate. When certifying the target domain A, the verification entity that examines the certificate may also certify the associated trusted intermediate domain, either because the direct certificate of the intermediate domain is included in the certificate of the target domain A, or because the certificate for the target domain may specify an identifier of the trusted intermediate domain so that a separate certificate generation command may be issued to request a separate certificate for the intermediate domain.

[0213] Thus, by defining trusted intermediate realms, this allows multiple instances of a given realm to be established at different times or on different physical platforms, each instance sharing access to shared keys or security configuration parameters that would be difficult to manage securely through the RMU alone or through the realm's own code.

[0214] Fig.25A method of processing a security configuration parameter update command for updating security configuration parameters associated with a target domain is shown. This command may be used to update security configuration parameters associated with a target domain. At step 520, a security configuration parameter update command is received that specifies a target domain whose parameters are to be updated.

[0215] At step 522, the RMU 20 checks whether the target domain identified by the command is currently in a clean state. If not, a fault is generated at step 524 because once the domain has been transferred from the clean state to the new state, the security configuration parameters cannot be updated. If the domain is in a clean state, then at step 524, it is determined whether the domain issuing the command is the previous domain of the target domain. If so, then at step 528, the RMU allows the requested parameter update as long as the update is a subset of the security configuration parameters that are allowed to be updated for the previous domain. Some contents of the domain descriptor of a given domain (such as keys) may be inaccessible to the previous domain of the given domain. In addition, the previous domain may not be allowed to update some parameters, such as whether the domain is associated with a trusted intermediate domain, the identity of the trusted intermediate domain, the expected signature 410, the signer ID 412, etc.

[0216] If the command is not issued by the previous generation domain, then at step 530, the RMU 20 checks whether the target domain is associated with a trusted intermediate domain and whether the command is issued by the trusted intermediate domain. If the target domain is not associated with any trusted intermediate domain, or the command is not issued by a trusted intermediate domain associated with the target domain, a fault is triggered at step 532. In addition, if the command is issued by a trusted intermediate domain associated with the target domain, then at step 534, parameter updates of the domain descriptor are allowed. In addition, there may be some parameters that the trusted intermediate domain is not allowed to update, but these parameters may be fewer parameters than those that the previous generation domain is not allowed to update. For example, the trusted intermediate domain may not be allowed to change which domain is identified as a trusted intermediate domain. However, unlike the previous generation domain, the trusted intermediate domain may be allowed to update the provided secret, which is the key material used to generate keys to protect data / code associated with the domain.

[0217] The RMU may also support commands for triggering the acquisition of a security configuration record 508 that represents a snapshot of a subset of the target realm's security configuration parameters. These commands can only be accepted if they are issued by a trusted intermediate realm defined in the realm descriptor of the target realm.

[0218] Fig.26A method for processing a certification command is shown, which is used to trigger the generation of a certification for a target domain. At step 550, the RMU 20 receives a certification command that identifies the target domain for which the certification will be generated. At step 552, it is determined whether the certification command is acceptable, and if not, a fault is generated at step 554. Various checks can be performed to determine whether the certification command is acceptable. If the target domain identified by the certification command is invalid, the certification command can be rejected and a fault is triggered. In addition, if the certification command is issued by a domain other than a trusted intermediate domain associated with the target domain, the certification command can be accepted if the target domain is in a valid state; if the target domain is in another state, the certification command can be rejected. If the certification command is issued by a trusted intermediate domain, the certification command can be accepted if the target domain is in any one of a clean state, a new state, or a valid state.

[0219] If the certification command is accepted, then at step 556, certification information is generated based on the security configuration parameters of the target domain, wherein the certification information provides some information that enables the verification entity to check whether the target domain satisfies certain properties. At step 558, the RMU 20 checks whether the target domain is associated with a trusted intermediate domain. If so, then at step 560, the RMU 20 then includes in the certification information information indicating that the target domain is associated with a trusted intermediate domain, and also includes intermediate domain certification information, which identifies the trusted intermediate domain or provides certification information that certifies the properties of the intermediate domain. If the target domain does not have an associated trusted intermediate domain, step 560 is omitted. In any case, at step 562, the certification information is signed with a key that certifies the validity of the certification, and the certification is output to the party requesting it.

[0220] Thus, when a target realm is associated with a trusted intermediate realm, the verifier can use the attestation to check whether the trusted intermediate realm has certain properties, either by checking the attestation of the target realm itself, or by using an identifier included in the attestation of the target realm to request further attestation of the trusted intermediate realm. In this way, reliance can be ensured on the fact that the target realm is correctly configured by a properly functioning trusted intermediate realm.

[0221] So, in summary, a trusted intermediate realm is defined for managing a given realm, which itself is a realm associated with the same realm administrator (e.g., the same banking provider, healthcare provider, etc.) as the given realm to be managed, with special properties that allow it to manage other realms on that party's behalf. In the simplest implementation, one instance of a trusted intermediate realm (per realm administrator) may exist on each system where a realm may exist. Because the trusted intermediate realm is itself a realm, it may be attested by a realm administrator as part of commissioning, ensuring that the trusted intermediate may only be valid / commissioned on systems with the required security properties.

[0222] Thus, a domain may be associated with a trusted intermediary when the domain is established, such that: only an identified trusted intermediary domain may manage the domain; the fact that a domain is associated with a trusted intermediary domain is apparent from the domain certification; and when certifying a domain, the verification entity may also certify the associated trusted intermediary. The trusted intermediary domain may receive the security environment of the domain from a given entity instance of device 2, and restore the security environment of the domain on the same instance or a different instance. The migration policy of the domain owner is encoded within the trusted intermediary domain associated with the domain owner. The policy itself may be proven by certifying the trusted intermediary domain. This includes policies on how and when to transfer the security environment of the domain between different systems. As a secondary use, the same approach may support related use cases, such as backing up / restoring a complete domain, or obtaining a snapshot / checkpoint of a domain that allows the domain to roll back to a previously known state, etc.

[0223] A trusted intermediate realm can attest to a managed realm before the realm is launched. A trusted intermediate realm is allowed to inject a provided root secret during realm establishment before the realm is launched. The realm owner's key management policy is encoded within the trusted intermediate realm associated with the realm owner. The policy itself can be proven by attesting the trusted intermediate realm. This includes providing the same root secret after restarting the realm, or providing the root secret to multiple instances of the same realm, or providing the same root secret regardless of which system the realm is launched on, etc.

[0224] Fig. 27Shown is a usable simulator implementation. Although the earlier described embodiments implement the present invention with respect to the apparatus and method for operating the specific processing hardware of the technology under consideration, it is also possible to provide an instruction execution environment according to the description herein by using a computer program. In the scope of the software-based implementation of the hardware architecture provided by such computer programs, these computer programs are generally referred to as simulators. Various simulator computer programs include simulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, simulator implementations can be run on a host processor 730, which optionally runs a host operating system 720 to support simulator programs 710. In some configurations, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple different instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that are executed at reasonable speeds, but this method can be adjusted in certain environments, such as when it is necessary to run a code that is native to another processor for compatibility or reuse reasons. For example, simulator implementations can provide an instruction execution environment with additional functions that are not supported by the host processor hardware, or 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, pages 53–63.

[0225] To the extent that embodiments have been previously described with reference to specific hardware constructs or features, in simulated embodiments, equivalent functionality may be provided by appropriate software constructs or features. For example, specific circuits (such as MMU 26 and RMU 20) may be implemented as computer program logic (e.g., memory access program logic and domain management program logic) in the simulator program 710 in simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in simulated embodiments. In previously described embodiments, one or more of the hardware components referenced are present in a configuration on host hardware (e.g., host processor 730), and some simulated embodiments may utilize host hardware where appropriate.

[0226] The simulator program 710 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provided to the target code 700 (which may include, for example, Figure 2The emulator program 710 is a program interface (instruction execution environment) of the application program operating system and manager (as shown in FIG. 1 ), which is the same as the application programming interface of the hardware architecture modeled by the emulator program 710. Thus, the program instructions of the target code 700 (including the control of memory access based on the domain protection function described above) can be executed in the instruction execution environment using the emulator program 710, so that the host computer 730 that does not actually have the hardware features of the device 2 discussed above can emulate these features.

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

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

Claims

1. A data processing device, comprising: processing circuitry for performing data processing in response to one or more software processes; a memory access circuit for controlling access to the plurality of memory regions based on ownership information, the ownership information defining, for a given memory region, an owner domain specified from a plurality of domains, each domain corresponding to at least a portion of at least one of the software processes, the owner domain having authority to prevent other domains from accessing data stored in the given memory region; as well as A domain management unit, configured to control the operation of a given domain based on security configuration parameters associated with the given domain; wherein: When the security configuration parameters of the given realm specify that the given realm is associated with a trusted intermediate realm identified by the security configuration parameters, the realm management unit is configured to allow the trusted intermediate realm to perform at least one realm management function of the given realm; and Each realm except the root realm is associated with the corresponding ancestor realm that created it; and The realm management unit is configured to support the security configuration parameter to define the trusted intermediate realm as a realm other than an ancestor realm of the given realm.

2. The device according to claim 1, wherein: The realm management function includes updating at least a portion of security configuration parameters of the given realm.

3. The device according to claim 1, wherein: The domain management unit is configured to set whether the given domain is associated with the trusted intermediate domain based on at least one command issued by the parent domain during establishment of the given domain.

4. The device according to any one of claims 1 to 3, wherein: The domain management unit is configured to, in response to a certification command identifying a target domain, provide a certification that proves a property of the target domain.

5. The device according to claim 4, wherein: When security configuration parameters of the given realm specify that the target realm is associated with the trusted intermediate realm, the attestation includes information indicating that the target realm is associated with the trusted intermediate realm.

6. The device according to claim 4, wherein: When the security configuration parameters of the target domain specify that the target domain is associated with the trusted intermediate domain, the certification of the target domain specifies intermediate domain certification information, which certifies the properties of the trusted intermediate domain, or provides information for enabling the recipient of the certification to request a certification for the trusted intermediate domain associated with the target domain.

7. The device according to claim 4, wherein: The domain management unit is configured to: prevent the processing circuit from processing a given domain until the given domain has been activated; and The realm management unit is configured to allow the trusted intermediate realm associated with the given realm to trigger generation of a certificate for the given realm before the given realm has been started.

8. The apparatus according to any one of claims 1 to 3, wherein: The realm management unit is configured to allow the trusted intermediate realm to provide at least one provided secret for the given realm, the provided secret comprising at least one of the following: at least one key for protecting data associated with the given realm; and Key material for deriving the at least one key.

9. The device according to claim 8, wherein: The realm management unit is configured to prohibit realms other than the trusted intermediate realm from providing the at least one provided secret to the given realm.

10. The device according to claim 8, wherein The domain management unit is configured to: prevent the processing circuit from processing a given domain until the given domain has been activated; The realm management unit is configured to: allow the trusted intermediate realm to provide the at least one provided secret to the given realm before the given realm has been started; as well as The realm management unit is configured to prevent the trusted intermediate realm from providing the at least one provided secret to the given realm after the given realm has been started.

11. The device according to claim 8, wherein: The realm management unit is configured to manage provision of the at least one provided secret based on key management policy information provided by the trusted intermediate realm.

12. The apparatus according to any one of claims 1 to 3, wherein: The realm management unit is configured to allow the trusted intermediate realm to record a security configuration record indicating at least a subset of security configuration parameters associated with the given realm.

13. The apparatus according to any one of claims 1 to 3, wherein: The realm management unit is configured to allow the trusted intermediate realm to update at least a subset of security configuration parameters associated with the given realm based on security configuration records previously recorded by the trusted intermediate realm.

14. The apparatus according to claim 12, wherein: The realm management unit is configured to manage recording the security configuration record or restore security configuration parameters from the security configuration record based on policy information provided by the trusted intermediate realm.

15. The apparatus according to any one of claims 1 to 3, wherein: The security configuration parameters of the given domain include at least one of the following items: Field type; a protected address range associated with the given realm; an indication of whether debugging is enabled within said given domain; an indication of whether to allow data to be output from a first memory access-controlled by the memory access circuit to a second memory; as well as Keying material for deriving at least one key to protect data associated with the given realm.

16. The apparatus according to any one of claims 1 to 3, wherein: The owner domain has the authority to prevent access to the given memory region by processes executing at a higher privilege level than the owner domain.

17. A data processing method, comprising: performing data processing in response to one or more software processes; implementing ownership rights for the plurality of memory regions based on ownership information, the ownership information defining, for a given memory region, an owner domain specified from a plurality of domains, each domain corresponding to at least a portion of at least one of the software processes, the owner domain having authority to prevent other domains from accessing data stored in the given memory region; as well as controlling the operation of a given realm based on security configuration parameters associated with the given realm; wherein: When security configuration parameters of the given realm specify that the given realm is associated with a trusted intermediate realm identified by the security configuration parameters, allowing the trusted intermediate realm to perform at least one realm management function of the given realm; and Each realm except the root realm is associated with the corresponding ancestor realm that created it; and The security configuration parameters support defining the trusted intermediate realm as a realm other than an ancestor realm of the given realm.

18. A storage medium storing a computer program for controlling a host data processing device to provide an instruction execution environment, the computer program comprising: a memory access program logic for controlling access to a plurality of memory regions of the emulated memory address space based on ownership information, the ownership information defining, for a given memory region, an owner domain specified from a plurality of domains, each domain corresponding to at least a portion of at least one software process among a plurality of software processes executed in the instruction execution environment, the owner domain having authority to prevent other domains from accessing data stored in the given memory region; as well as Realm manager logic for controlling operation of a given realm based on security configuration parameters associated with the given realm; wherein: When security configuration parameters of the given realm specify that the given realm is associated with a trusted intermediate realm identified by the security configuration parameters, the realm manager logic is configured to allow the trusted intermediate realm to perform at least one realm management function of the given realm; and Each realm except the root realm is associated with the corresponding ancestor realm that created it; and The security configuration parameters support defining the trusted intermediate realm as a realm other than an ancestor realm of the given realm.

Images