Data processing device and method

Abstract

The memory access circuit (26) controls access to the memory based on ownership information, the ownership information defining an owner domain specified from two or more domains for a given memory region, 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 starting a target domain, detecting whether a parameter signature derived from security configuration parameters established for the target domain matches an expected signature; and in response to detecting a mismatch between the parameter signature and the expected signature, applying a startup restriction to the target domain to prevent the startup of the target domain or prevent the target domain from running correctly after startup.

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 right 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 starting a target domain so that the target domain can be processed by the processing circuit, the domain management unit is configured to: detect whether a parameter signature derived from the security configuration parameters established for the target domain matches an expected signature; and in response to detecting a mismatch between the parameter signature and the expected signature, impose startup restrictions on the target domain to prevent the startup of the target domain or prevent the target domain from running correctly after startup.

[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 starting a target domain so that the target domain can be processed by a processing circuit, the method comprises: detecting whether a parameter signature derived from the security configuration parameters established for the target domain matches an expected signature; and in response to detecting a mismatch between the parameter signature and the expected signature, imposing startup restrictions on the target domain to prevent the startup of the target domain or prevent the target domain from running correctly after startup.

[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 starting a target domain so that the target domain can be processed by a processing circuit, the domain management program logic is configured to: detect whether a parameter signature derived from the security configuration parameters established for the target domain matches an expected signature; and in response to detecting a mismatch between the parameter signature and the expected signature, impose startup restrictions on the target domain to prevent the startup of the target domain or prevent the target domain from running correctly after startup.

[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.19 shows 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, the ownership information defining, 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, with a domain-based approach, the owner domain has the ability to control which other domains access the memory regions 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 is capable of), 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 using a memory access circuit for debugging, 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 for protecting 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] Once a domain is established and executed, the ownership information used by the memory access circuit can protect its memory area from improper access by other domains. However, in order to establish and configure a given domain, another domain may need to initialize the domain and set security configuration parameters for the domain before the domain is started. Therefore, for some applications, it may be important to be able to check whether the security configuration parameters of a given domain have been correctly established. For example, a banking provider may want to check the proof of security parameters before interacting with a given domain to check whether the domain has been correctly established, so that the banking provider can trust that sensitive information shared with a given domain will be protected from unauthorized access. A method for providing such proof can be for a domain management unit to support the generation of proof based on the security configuration parameters of a given domain, and these parameters can be signed to prove their authenticity, so that other processes or domains or external devices can verify whether the security configuration parameters are correctly established. However, this proof can usually be limited to after a given domain is started and running. A problem with this method is that if the domain cannot be verified until the proof moment after the domain is started, this may limit certain use cases of the domain. While verification at attestation time may be acceptable for applications where data is only provided to the realm or is available upon successful attestation, there are other use cases where secret data (such as key data used to derive keys) needs to be provided to the realm before the realm is started, and therefore some trust needs to be established to check whether it is safe to provide secret data to the realm.

[0040] In the techniques discussed below, a domain management unit may support the ability to check parameter signatures when a target domain is started. The startup of a domain may be a procedure that enables a target domain to be processed by a processing circuit (a domain that has not yet been started may not be allowed to be processed as a current domain executed on the processing circuit). For at least some domains, when a target domain is started, the domain management unit may detect whether a parameter signature derived from security configuration parameters established for the target domain matches an expected signature. If a mismatch is detected between the parameter signature and the expected signature, the domain management unit may impose startup restrictions on the target domain to prevent the startup of the target domain or prevent the normal operation of the target domain after startup. Therefore, the domain management unit enforces that the security configuration parameters meet certain properties, and if this operation has not been completed, the domain management unit may prevent the domain from being enabled, or from running correctly after startup. This prevents the risk that an older domain (which initializes a given domain on a device) establishes security parameters that are different from the parameters expected by the party requesting the initialization of the given domain. This can be useful for use cases where data needs to be stored persistently on the system so that it remains available after a restart of the realm, or if common shared data needs to be available to multiple instances of the same realm operating in parallel on the same system or on different systems for load balancing and redundancy reasons. This can be very useful for situations where a realm needs to access some boot secrets before it starts, for example, for accessing a boot image stored in a protected file system.

[0041] Therefore, confidence in the fact that the realm has been correctly configured can be increased, typically by checking whether the parameter signature derived from the realm's security configuration parameters matches the expected signature when the realm is started.

[0042] In one example, each realm (except the root realm) may be initialized by an ancestor realm. The ancestor realm may receive a request from an external source or from another realm operating on the same device that is requesting the establishment of a child realm (e.g., in the example provided above, the requestor may be acting on behalf of a banking provider). When requesting the establishment of a child realm, the requestor may provide an ancestor realm having an information bundle that defines the properties of the child realm to be established, including a specification of security configuration parameters for a given realm, and an indication of an expected signature for those security configuration parameters. Thus, a comparison of the actual parameter signature derived from the security configuration parameters at startup with the expected signature allows the realm management unit to verify that the ancestor realm correctly established the requested security configuration parameters as expected by the requestor.

[0043] In one example, the launch restrictions may prevent the launch of a target domain. Thus, if a domain attempts to launch and the parameter signature does not match the expected signature, the domain may be prevented from launching so that the domain cannot be processed by the processing circuitry. This means that if a previous domain provides incorrect security configuration parameters, this may be detected to prevent the target domain from running.

[0044] In other examples, the launch restrictions may include preventing the target realm from accessing at least one of: at least one key used to protect data associated with the target realm, and key material used to derive the at least one key. The data protected by the key may be a data value, program code, or any other asset controlled or owned by the realm. Thus, subsequently for this example, even if the parameter signature does not match the expected signature, the realm may still be launched, but subsequently when the realm attempts to run, the lack of access to the key or key material used to derive the key may prevent the realm from running correctly because it will not be able to access encrypted data shared with the realm.

[0045] The expected signature may be signed using a key associated with some parameter signer (e.g., the parameter signer may be a banking provider or another relying party associated with the banking provider). For example, the expected signature may be derived based on a private key of the parameter signer, and the public key of the parameter signer may be provided with the expected signature to enable the realm management unit to check whether the expected signature matches the parameter signature derived from the security configuration parameters of the target realm at startup.

[0046] The domain management unit may include a signer identifier in the key material used to derive at least one key to protect data (including program code) associated with the target domain, which identifies the parameter signer that authenticates the parameter signature. For example, the signer identifier may be the public key of the parameter signer. By including the signer identifier in the key material, this improves security because it means that once launched, if the parameter signature used to verify the properties of the target domain is signed by the correct party, the domain will only be able to access information protected using the corresponding key.

[0047] For example, using again the banking example discussed above, a banking provider acting as a parameter signer may use a key derived from its private key to encrypt data to be provided to the target realm after booting. When establishing the target realm, the banking provider may request the parent realm to establish the target realm, and provide the parent realm with the security configuration parameters to be installed, the expected signature of the parameter signer, and the signer identifier (public key). If the correct parameters are installed and the correct expected signature is verified against the actual signature derived from the parameters of the target realm at booting, then the booting is successful, and the inclusion of the signer identifier (public key) in the key material of the target realm indicates that the data shared with the target realm (encrypted with the corresponding key) can be successfully decrypted by the target realm after the target realm is booted.

[0048] On the other hand, if an attacker attempts to bypass the signature check by installing different security configuration parameters for the target realm and providing an expected signature that is different from that provided by the actual parameter signer, where the different expected signature is signed by a different key and therefore corresponds to a different signer identifier, then even if this enables the attacker to pass the parameter signature check and allows the pseudo-realm to be started with incorrect security configuration parameters, the pseudo-realm will still not be able to access sensitive information shared by the banking provider because the key material provided for the pseudo-realm will be based on the wrong signer identifier and therefore the pseudo-realm will not be able to decrypt information encrypted by the banking provider using the correct key based on the identifier of the actual parameter signer.

[0049] So this means that if the security configuration has been signed correctly and the parameter signer is the correct entity, then the realm can be started and the realm can access the correct secrets. If either of these conditions are not met, then the realm will not be started, or it can be started but the realm cannot access the correct secrets to decrypt data shared with it.

[0050] When the target domain is started, the actual parameter signature of the target domain can be derived based on the security parameters established for the target domain and the measurement indication, which is determined based on the contents of at least one memory area, and the target domain is defined as the owner domain for the at least one memory area. Similarly, the parameter signer may have generated the expected signature based not only on the expected security configuration parameters, but also on the expected measurements, which correspond to the expected contents of the memory area to be owned by the target domain. Therefore, this means that the check of the parameter signature can not only check whether the security configuration parameters themselves have been correctly established for the target domain, but also check whether any data (including program code) provided to the owned memory area of ​​the target domain before startup is correct. For example, the expected measurement may include a hash of the contents of the owned area corresponding to the address space of the target domain.

[0051] In some instances, the security configuration parameters of a given domain may also specify a security period associated with the given domain. For example, the security period may be used to represent the version of software associated with the given domain. This may be used to provide additional security. The domain management unit may include the security period in the key material used to derive at least one key to protect data associated with the target domain. The domain management unit may prohibit the domain associated with the given security period from using or deriving at least one key associated with a security period later than the given security period. Therefore, if a security weakness or other problem is identified in association with software of a given security period, a later update of the software for the domain may use a later security period definition, and any earlier version of the software will not be able to use or derive keys for a later security period. Therefore, when a domain may be allowed to derive secrets associated with a security period earlier than the domain itself or use these secrets, the domain may not derive secrets for a newer security period. These checks may be implemented by the domain management unit. The parameter signature of the target domain may depend on the security period associated with the target domain. Therefore, if the security period matches a given version, a trusted party in the domain may redefine its expected signature so that the domain can only pass its parameter signature check.

[0052] The security configuration parameters of a given realm may be limited to updating before the given realm is started. After the given realm is started, the realm management unit may prohibit updating the security configuration parameters.

[0053] Parameter signature checking need not be used for all domains. For example, a security configuration parameter defined by a party requesting the creation of a new domain (which may not be editable by the domain that actually created the domain) may specify whether the domain requires parameter signature checking at startup. In addition, as an alternative, configuration parameters associated with the domain management unit itself may specify whether it should perform parameter signature checking when starting the domain. Therefore, configuration settings can be provided in the architecture of the domain management platform, and / or in the security configuration of a given domain to control whether parameter signing is enabled or disabled. An unsigned domain (for which parameter signing is disabled) does not have a signer identifier added to its key derivation and therefore will not be able to derive the same secret as a signed domain, which does have a signer identifier included in its key derivation. Therefore, including a signer identifier in the key derivation also protects data / code used by a signed domain from being accessed by an unsigned domain that is not verified at startup.

[0054] The domain management unit can be implemented in different ways. In some examples, the domain management unit may include a hardware unit. Alternatively, the domain management unit may include a processing circuit that executes domain management software.

[0055] The above example describes a device with the memory access circuit and domain management unit discussed above. However, in another example, a corresponding computer program can be provided to control a host data processing device to provide an instruction execution environment for executing instructions. The computer program may include a memory access program logic and a domain management program logic, both of which correspond to the memory access circuit and domain management unit discussed above in function. For example, the computer program may be an emulator program, which can be presented to the software executed on the emulator, and an execution environment similar to it will be provided by an actual hardware device, even if 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 functions of the desired hardware architecture (including the implementation of ownership rights and parameter signature checks) can be simulated by providing program logic (such as a set of instructions or data structures), which enables a general host computer to execute code for execution on a device with the above-mentioned domain protection in a manner compatible with the following results, which will be realized 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.

[0056] 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.

[0057] 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 116 is on chip, but in other embodiments, the memory 16 may be implemented as 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 within 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.

[0058] 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.

[0059] 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.

[0060] The division of the memory address space into realms and the control of ownership of these realms are managed by a realm 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 realm 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 realm 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 realm 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 realm 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.

[0061] The processing assembly including general purpose processor 8,10 is shown as including corresponding decoding and execution circuit 32,34, and these corresponding decoding and execution circuits decode and execute program instructions.These program instructions include the command (domain management command or RMU command) of the management of the memory area in the different ownership domains of the control memory address space.As an example, the program instruction executed may include the program instruction designated as the domain management unit command, and when encountering these program instructions in the program instruction stream, these program instructions are directed to the associated domain management unit 20,22,24, so that these program instructions can be executed (take action) by the associated domain management unit 20,22,24.The example of the domain management unit command includes the command used to initialize a new domain or invalidate an existing domain, to allocate a memory area to a specific domain, to remove a memory area from a specific domain, to encrypt the output data and other processes so that the output data is protected in the second memory 6, and the data contained in the memory area is output from the first memory 16 to 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.

[0062] 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.

[0063] 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 inaccessible 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 is 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.

[0064] 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 having 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 is able to allocate, de-allocate 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 memory areas that are 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.

[0065] When the given data stored in a given memory area is output, the memory area under consideration is then invalidated so that the content is inaccessible. To reuse this page, the page is made "valid" by using a clean command, which overwrites the memory area with other data 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 all written as zero values, or as fixed values, or as random values, to overwrite the original content of the memory area. In other examples, the overwriting of the content of the output memory area can be triggered by the output command itself rather than subsequent cleaning commands. In a word, before making a given memory area accessible to a process other than a given owning process, the given owned data outputted can be overwritten by a value 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 with respect 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.

[0066] Figure 2 The relationship between multiple processes (programs / threads), multiple exception levels (privilege 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 privilege 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, the secure operating state and the non-secure operating state as determined by the use of The architecture is represented by the secure domain and non-secure domain in the processor, for example. Architecture by Limited (Cambridge, UK).

[0067] 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)). Ownership is given to memory areas of domain A so that ownership of these memory areas is then 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 domains 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), which are grandchild domains of the original domain (i.e., domain A). Processes within a given domain may execute 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).

[0068] 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 (instead 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).

[0069] 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 distributed within the system-on-chip integrated circuit 4 using translation lookaside buffers and other distributed control mechanisms.

[0070] 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 110 of GPU 12 or any other processing component within data processing device 2. Figure 4As shown in FIG. 1 , 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 a 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 an 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.

[0071] 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 may 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.

[0072] 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.

[0073] 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 may 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 may 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).

[0074] 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, for each region of the memory address space, which domain is the owner domain of the memory region. 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 this domain management data is discussed in more detail below. In general, the domain management unit 20 and the MMU 26 can be viewed as memory access circuits that enforce 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 hypervisor 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 hypervisor. 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.

[0075] 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.

[0076] 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 translation 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 translation 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 realms (different child realms that share the same parent realm), then a given child realm may exclude a sibling realm from accessing data stored in a given memory region owned by the given child realm. Additionally, visibility attributes set in ownership table 128 may control the extent to which a sibling realm may access data from each other generation realm. Alternatively, access to sibling realms may be controlled based on a parent visibility attribute, such that if a child realm makes a page visible to its parent realm, the same page also becomes visible to the sibling realms of the child realm and further descendants of the sibling realm. In some cases, ownership table 128 may have a global visibility attribute that may allow a given owner process to enable any process executing under any realm to access data within the memory region owned by the given owner process.

[0077] 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 then 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.

[0078] 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.

[0079] 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.

[0080] 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 whether it only requires a small and fixed number of child realms (which may be the case for low-level firmware), or requires many realms or a varying number of realms (for example, this may be used for a hypervisor on a cloud platform that may manage an unknown number of guest virtual machines).

[0081] 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.

[0082] 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 RDTG. For example, the order value may indicate a power of 2 corresponding to the total number of entries in the pointed 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 the existing RDTG.

[0083] 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.

[0084] like Figure 8 As shown in , each of the child domains of a given parent domain may have a corresponding domain identifier (RID) 168 that is used by the parent domain to identify the particular child domain. A RID is a local domain identifier because the RID is specific to a particular parent domain. Child domains of different parent domains may have the same local RID. Although it is possible to use a local RID with an arbitrary value selected by the parent 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.

[0085] 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.

[0086] Some embodiments may apply this RID construction technique 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 parent domain in a tree and then using a separate tree for each other parent domain to track the child domain of the parent domain. Therefore, the domain descriptor tree can be a local domain descriptor tree associated with a given parent domain for storing domain management data for child domains initialized by a given parent domain. The domain identifier can therefore be a local domain identifier that identifies a specific child domain used by a given parent domain. Child domains initialized by different parent domains may be allowed to have the same value of a local domain identifier. In this way, a parent domain can select which RIDs are used for the child domains of the parent domain without knowing what other domains have been established by other parent domains, wherein the RIDs used for the child domains are constructed according to the way in which the parent domain configures its domain descriptor tree.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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 allowed to be 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 an appropriate response may be hardwired for a particular processor implementation), and may also check for information specifying how many bits of the identifier have been used up by the previous domain in the global domain identifier in order to determine how many bits are available remaining for the current domain to define further children. The previous domain may use the response to the query command to determine how to construct the RDT of the previous domain.

[0092] 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:

[0093] The global RID of the realm. Thus, by traversing the realm descriptor tree based on the local RID, 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.

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

[0095] 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.

[0096] A boundary exception level (BEL) value that identifies the boundary 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.

[0097] A resource count indicating the total number of memory regions (realm protection group or RPG) 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 of data) before these memory regions can be allocated to a different realm. For example, the resource count can be used to track how many regions still need to be scrubbed.

[0098] The start and end addresses of protected addresses for a 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 may be used to protect against a malicious ancestor realm reclaiming ownership of an area previously allocated 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 may be identified that a memory area previously owned by a realm is no longer owned by the realm.

[0099] 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 used to encrypt / decrypt content and memory owned by a realm, and a paging key used to encrypt / decrypt data exported / imported between memory 16 to 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.

[0100] • 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 will be used as an index to that RDTG).

[0101] - 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.

[0102] 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.

[0103] 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 keys specified for the realm can be used effectively, whether the realm can own any memory areas (RPGs), 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 a malicious ancestor realm from updating the properties of a given realm after it has become active. Additionally, realms are only executable in the active state.

[0104] 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 region 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 domain 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.

[0105] When a realm is in the new state 206, execution of a realm active command 208 specifying the local RID of the realm triggers a transition from the new state 206 to the active state 210, in which the realm is now executable and after this moment, a realm entry into the corresponding realm will no longer trigger a fault. The realm is now fully operational. As discussed below, in some examples, startup may depend on checking parameter signatures. A subsequent realm invalidate command 212 triggered by an ancestor realm of a child realm 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 realm must execute a realm wash command 216. If the resource count that tracks the number of pages owned by the realm has a value other than zero, the realm wash command 216 is rejected. Therefore, in order for the realm wash command 216 to succeed, the ancestor realm must first issue a Granule.Reclaim command for each page owned by the invalid realm. 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 the overwrite can be done when a clean command is subsequently issued to transition the memory page from invalid to valid (see the 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.

[0106] 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).

[0107] 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.

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

[0109] • Identify the global RID for the owner realm of the memory region. The owner realm may be a realm that has the authority to set attributes that control which other realms are allowed to access the memory region.

[0110] 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.

[0111] The mapped address that is mapped by the MMU 26 when a memory region 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.

[0112] 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 previous visibility bit that controls whether the previous 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 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 visibility bit and the global visibility bit can be set by the owner domain itself. Alternatively, although the previous visibility bit can be set by the owner domain, the global visibility bit may be able to be set by the previous domain of the owner domain (provided that the previous visibility bit for the memory region has been set to give the previous 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.

[0113] 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, wherein 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., a fault trigger).

[0114] 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 circuitry 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.

[0115] 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.

[0116] 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 a domain descriptor tree RDTG), 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. A command 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.

[0117] 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.

[0118] 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.

[0119] 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 invalidating domain (or descendants of the specified invalidating 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 invalidating domain, but also RMU-private memory regions owned by the invalidating domain.

[0120] 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.

[0121] 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.

[0122] 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 regarding 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 checks using metadata are 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 are 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 at the time of an 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.

[0123] 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.

[0124] 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.

[0125] 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.

[0126] 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 realm may release ownership of a given memory region back to the parent realm of the child realm 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 realm descriptor of the child realm. If the specified memory region is not owned by the current realm 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 realm's ownership).

[0127] 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.

[0128] 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.

[0129] 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 ancestor of the given domain and therefore if the ancestor domain is invalidated, this means that it is not possible to access the descendants of the ancestor 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 ancestor domain to identify a specific descendant of the ancestor domain, and this is used to step through the domain descriptors stored in the memory area owned by the ancestor domain of the given descendant domain, so no process other than the ancestor domain can trigger the RMU to access the domain management data of the descendant domain. Therefore, if the ancestor 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.

[0130] 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 children of the ancestor domain, 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 are to be reclaimed, since any further descendant realms of the invalid realm will also own pages within that range.

[0131] 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 (because 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.

[0132] Fig.17A An example of a check performed by the MMU 26 and RMU 20 to determine whether a given memory access is allowed is shown. The MMU 26 supports two levels of address translation, level 1 which 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 which translates the intermediate physical address provided by the level 1 translation into a 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 a virtual machine ID (VMID) 250 provided with a memory access request may identify which particular level 2 page tables to use. Similarly, an operating system may define multiple sets of level 1 page tables for different applications, and an 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.

[0133] 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 along 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 both 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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 .

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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:

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

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

[0144] • 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.

[0145] 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.

[0146] 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 misses 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.

[0147] 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.

[0148] 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:

[0149] 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.

[0150] ·The current realm is not allowed by the owner realm for the corresponding memory region to access the memory region. There may be multiple reasons why a given realm may not be allowed to access a given memory region. If the owner realm has specified that the memory region is visible only to the owner itself and the descendants of that owner, then another realm may not be allowed to access that realm. In addition, if the current realm is an ancestor realm of the owner realm and the owner realm 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 realm itself may be prevented from accessing the memory region. At the RMU check stage, descendant realms of the owner realm 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 realm.

[0151] 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.

[0152] 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.

[0153] 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 privilege level process cannot access state data used by a lower privilege 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.

[0154] 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.

[0155] 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 a domain entry may greatly simplify the architecture and hardware management burden and reduce the software modification requirements to support the use of domains.

[0156] 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.

[0157] 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 the control value stored in the state register of the given exception return instruction (for example, 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 the exception return instruction to return the processor to a lower privilege level in the same domain, or trigger entry to a new domain.

[0158] 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.

[0159] 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 registers may be grouped so that there are a plurality of 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 need not 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 an ancestor realm to reference a descendant realm of the ancestor realm, and thus realm entry may be limited to passing from an ancestor realm to a descendant realm, and it is not possible to go from a first realm to another realm that is not a direct descendant 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 for a life cycle state other than active).

[0160] In response to the second variant of the exception return instruction, the processing circuitry may restore the architectural state associated with the thread to be processed in the destination domain from a domain execution context (REC) memory area specified for the exception return instruction. The state restoration may be performed immediately (e.g., as part of an atomic set of operations) in response to the second variant of the exception return instruction, 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 state 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 circuitry may begin processing of the destination domain before all required architectural state has been restored from the REC memory area.

[0161] 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 alternatively provide a pointer to the REC memory area, and the architectural state of the new domain will be restored from the REC memory area. This avoids the need to provide a further register for storing the REC pointer.

[0162] 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.

[0163] In response to the second variant of the exception 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 exception 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 has not created 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 an exception occurring 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 exception 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.

[0164] 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.

[0165] 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.

[0166] 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.

[0167] 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 previous domain 600 operating at a specific abnormal level can initialize a child domain 602, which operates at the same abnormal level as the previous 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 previous 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 previous generation complete domain, but the child domain may have the authority to exclude the previous 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.

[0168] The child domain may generally be handled in the same manner as the full domain, with some differences as explained below. Entry to and exit from the child domain may be handled in the same manner as discussed above using exception return instructions and exception events. Thus, the child domain may have a child domain ID constructed in the same manner as the full child domain of the same parent generation, and may have a domain descriptor within a domain descriptor tree as discussed above. Entry to the child domain may be simply triggered by executing an ERET instruction, which has placed the appropriate child domain RID in the RID register prior to the execution of the ERET instruction. Thus, the same type of ERET instruction (of the second variant) may be used to trigger entry to either the full domain or the child domain.

[0169] 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.

[0170] Similarly, when currently in a child domain, the execution of domain entry instructions may 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 would 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 full domain, an exception return event that triggers a switch to a process operating at a lower privilege level may be prohibited. Although a single type of ERET instruction is used as both a domain entry instruction and an exception return instruction in the examples discussed above, this is not necessary for all embodiments, and in the case of providing a separate instruction, both exception return instructions may be prohibited when the current domain is a child domain.

[0171] 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.

[0172] 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.

[0173] 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.

[0174] 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.

[0175] Parameter signature

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

[0177] Once a realm is built and executing, some external user (e.g., a client connecting to a server application executing inside the realm) can connect to the realm and request an attestation report. The attestation report allows the external user 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.

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

[0179] Where data needs to be persistently stored on the system so that it remains available after a restart of the domain or system,

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

[0181] 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.

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

[0183] 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.

[0184] 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.

[0185] 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.

[0186] 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.

[0187] As in Fig. 20 As shown at the top of , when a domain is established, 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.

[0188] 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 output of data from the first memory 16 (with realm 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.

[0189] The initial domain parameters 400 also include an expected signature 410 that corresponds 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 may be recorded by the parent domain in the domain descriptor of the target domain while the target domain is in a clean state.

[0190] 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.

[0191] 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.

[0192] 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.

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

[0194] 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.

[0195] 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 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 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 realm boot and the expected parameters having the parameter signature expected to be installed by the realm, to warn the previous realm without maliciously changing the realm parameters that were given to the realm by the party requesting the installation of the realm.

[0196] 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.

[0197] 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 case shown in , the actual identity of the party requesting the establishment of a realm is not verified against any known identity. In fact, if the expected signature given at realm establishment matches the actual signature generated from the actual parameters at realm startup, then any party is allowed to request the establishment of a given realm and have its realm started. Therefore, if an attacker provides a signature different from the expected signature, and the actual parameters are established in a way that matches the different signature, then the realm will be allowed to be started. However, including the signer's public key in the realm's key 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 installation of the realm) match the parameters provided with the signature when the realm was requested to be installed, to prevent the previous generation realm from inappropriately modifying the parameters.

[0198] 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. Age 430 is covered by expected signature 410 and parameter signature 422. In addition, age 430 is also included in the key material used to derive domain secrets. This allows verification of the version of the installed domain software 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. Domain secret derivation can allow a domain to be allowed to derive or use secrets of any security age (earlier than or the same as the age of the domain itself), but cannot derive 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 attempting to update the age between being given the initial domain parameters when the domain is established and starting the domain.

[0199] 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.

[0200] 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.

[0201] Trusted Intermediate Realm

[0202] 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.

[0203] 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 guarantees 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: the target system has the same security attributes before the domain has been started on the new system.

[0204] 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".

[0205] 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.

[0206] The trusted intermediate realm may store information for managing the associated realm A in its owned memory pages 502. For example, the trusted intermediate realm may store a plurality of provided secrets 504 that may be injected into realm A as key material for deriving keys to protect the data and code of realm 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 realm may store configuration records 508 that may indicate a set of security configuration parameters that may be injected into the realm descriptor of realm A. Updates to the security configuration parameters of realm A by the trusted intermediate realm may be limited to before the realm is started. Some parameters of the realm descriptor may not be allowed to be set by the trusted intermediate realm (e.g., the identifier of the trusted intermediate realm itself).

[0207] 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 ancestor domain of the trusted intermediate domain when the trusted intermediate domain was established).

[0208] 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.

[0209] 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.

[0210] 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.

[0211] 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.

[0212] 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.

[0213] 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.

[0214] 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.

[0215] 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.

[0216] 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.

[0217] 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.

[0218] 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.

[0219] Thus, 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 debugging, ensuring that the trusted intermediate may only be valid / debugged on systems with the required security properties.

[0220] 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.

[0221] 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.

[0222] 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.

[0223] 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 simulator program 710 in simulated embodiments. Similarly, memory hardware such as registers or caches may be implemented as software data structures in simulated embodiments. Where one or more of the hardware components referenced in the previously described embodiments are present in a configuration on host hardware (e.g., host processor 730), some simulated embodiments may utilize host hardware where appropriate.

[0224] 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 used to generate 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 within 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.

[0225] 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.

[0226] 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 device for data processing, 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 starting a target domain so that the target domain can be processed by the processing circuit, the domain management unit is configured to: detecting whether a parameter signature derived from security configuration parameters set for the target realm at startup matches an expected signature in a request to a parent realm to establish the target realm; and In response to detecting a mismatch between the parameter signature and the expected signature, a launch restriction is imposed on the target domain to prevent launch of the target domain or to prevent proper operation of the target domain after launch.

2. The device according to claim 1, wherein: The launch restriction includes preventing the target domain from accessing at least one of the following: at least one key for protecting data associated with the target domain; and Key material for deriving the at least one key.

3. According to the device according to claim 1 or 2, the domain management unit is configured to include a signer identifier in the key material used to derive at least one key, which signer identifier identifies the parameter signer who certifies the parameter signature, and the at least one key is used to protect data associated with the target domain.

4. The device according to claim 3, wherein: The signer identifier includes a public key of the parameter signer.

5. The device according to claim 3, wherein: The expected signature is derived based on the private key of the parameter signer.

6. The device according to claim 1 or 2, wherein: The domain management unit is configured to derive the parameter signature based on the security configuration parameters set for the target domain and a measurement indication, wherein the measurement indication is determined according to the content of at least one memory area, and the target domain is defined as the owner domain for the at least one memory area.

7. The device according to claim 1 or 2, wherein: The security configuration parameters for the given realm specify a security period associated with the given realm.

8. The device according to claim 7, wherein: The realm management unit is configured to include the security period in key material used to derive at least one key to protect data associated with the target realm.

9. The device according to claim 7, wherein: The realm management unit is configured to prohibit a realm associated with a given security epoch from using or deriving at least one key associated with a security epoch later than the given security epoch.

10. The device according to claim 7, wherein: The parameter signature of the target realm depends on the security period associated with the target realm.

11. The device according to claim 1 or 2, wherein: After starting a given realm, the realm management unit is configured to prohibit updating of security configuration parameters of the given realm.

12. The device according to claim 1 or 2, 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.

13. The device according to claim 1 or 2, 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.

14. 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 starting a target domain so that the target domain can be processed by a processing circuit, the method includes: detecting whether a parameter signature derived from security configuration parameters set for the target realm at startup matches an expected signature in a request to a parent realm to establish the target realm; and In response to detecting a mismatch between the parameter signature and the expected signature, a launch restriction is imposed on the target domain to prevent launch of the target domain or to prevent proper operation of the target domain after launch.

15. 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 starting a target domain so that the target domain can be processed by the processing circuit, the domain manager logic is configured to: detecting whether a parameter signature derived from security configuration parameters set for the target realm at startup matches an expected signature in a request to a parent realm to establish the target realm; and In response to detecting a mismatch between the parameter signature and the expected signature, a launch restriction is imposed on the target domain to prevent launch of the target domain or to prevent proper operation of the target domain after launch.

Images