System and method for establishing trust between virtual machines and physical devices

Abstract

A system comprises at least one processor core supporting a virtual machine, an interface for communication between the processor core and a memory, a resource domain controller, RDC, controlling access to the memory, and a secure enclave; wherein the resource domain controller, RDC, is configured by the secure enclave. A method for controlling access to a memory and / or a device assigned to a virtual machine comprises allocating, by the secure enclave, at least one memory region of the memory to the virtual machine, assigning, by the secure enclave, a domain identifier to the processor core supporting the virtual machine and / or the device, and providing, by the secure enclave, the domain identifier and information identifying the at least one memory region allocated to the virtual machine to a resource domain controller.

Description

Technical Field

[0001] This disclosure relates to a system and method. More specifically, but not exclusively, this disclosure relates to a computer-implemented system and method. More specifically, but not exclusively, this disclosure relates to a system and method for establishing trust between a virtual machine and a physical device. Background Technology

[0002] Directly assigned devices cannot access the dedicated memory associated with security-sensitive virtual machines (VMs). Therefore, the device can only have DMA (direct memory access) to the shared memory area, requiring a separate memory copy from the shared memory area to the VM's dedicated memory. This increases latency and / or requires additional resources. Summary of the Invention

[0003] The features of the invention are set forth in the appended claims.

[0004] According to a first aspect, a system is provided, comprising: at least one processor core supporting a virtual machine; an interface configured for communication between the processor core and memory; a resource domain controller (RDC) configured to control access to the memory; and a secure enclave; wherein the resource domain controller (RDC) is configured by the secure enclave.

[0005] By configuring (e.g., programming) resource domain controllers, secure enclaves securely set or control access permissions to memory. Therefore, the system ensures that only virtual machines or devices directly assigned to virtual machines can access the allocated or associated memory regions, including device memory-mapped registers, of that virtual machine. In other words, DMA access is associated with a specific virtual machine, such that when an I / O device is assigned to a specific virtual machine, that I / O device can only access the memory assigned to that virtual machine. This helps prevent a hypervisor, another virtual machine, or another untrusted entity from maliciously attempting to gain access to the virtual machine's memory or the I / O devices assigned to the virtual machine.

[0006] The systems and methods disclosed herein can thereby establish trust between a secure virtual machine and the physical device assigned to that secure virtual machine via a secure enclave. Allowing the device direct access to the virtual machine's memory requires trust. This may also require that only specific virtual machines can access the device.

[0007] Optionally, the secure enclave is configured to provide information identifying at least one memory region associated with a virtual machine to the resource domain controller, the memory region being included in the memory.

[0008] Optionally, the memory area is allocated to the virtual machine by a secure enclave.

[0009] Optionally, the secure enclave is configured to obtain the virtual machine identifier of the virtual machine from at least one processor core.

[0010] Optionally, a secure enclave is configured to assign a domain identifier to a processor core that supports virtual machines.

[0011] Optionally, the secure enclave is configured to provide the processor core's domain identifier along with an indication of the memory area assigned to the virtual machine to the resource domain controller for controlling access to memory.

[0012] Optionally, the domain identifier is based at least in part on the core identifier associated with at least one processor core.

[0013] Optionally, the interface is further configured for communication between the processor core and the device assigned to the virtual machine.

[0014] Optionally, the security enclave is further configured to assign a domain identifier to the device. The security enclave may also be further configured to provide the device's domain identifier to a resource domain controller for controlling device access to memory.

[0015] Optionally, the Resource Domain Controller (RDC) is further configured to control access to the device; and the secure enclave is configured to provide the processor core's domain identifier along with an indication of the device's memory blocks to the Resource Domain Controller for controlling access to the device. Specifically, the Resource Domain Controller can control access to the device such that only the virtual machine to which the device is assigned can access the device's memory.

[0016] Optionally, the resource domain controller (RDC) includes at least one domain assignment controller (DAC) configured to append a domain identifier of a processor core to an access request originating from the processor core and / or append a domain identifier of a device to an access request originating from the device.

[0017] Optionally, the resource domain controller includes a memory area checker (MRC) configured to allow access to memory in response to an access request based on the domain identifier and memory area specified in the access request. The access request may originate from a processor core (e.g., from a virtual machine or another virtual machine supported by the processor core) or from a device.

[0018] Optionally, the resource domain controller includes a memory block inspector (MBC) configured to allow access to the device in response to an access request based on the domain identifier and memory block specified in the access request. The access request may originate from a processor core (e.g., from a virtual machine or from another virtual machine supported by the processor core).

[0019] Optionally, at least one processor core further includes: a hypervisor for initializing and managing virtual machines on the processor core; and a BootROM extension. The BootROM extension can act as a hypervisor monitor, controlling privileged operations of the hypervisor to establish a confidential computing environment on the core. The BootROM extension can be configured to reboot translation table settings for virtual machines from the hypervisor to the BootROM extension via a stub.

[0020] Optionally, the BootROM extension performs translation table setup in response to the verification of the virtual machine identifier and associated memory area details by the secure enclave.

[0021] Optionally, the system includes a system-on-a-chip (SoC), wherein the SoC includes at least one processor core and a secure enclave. The SoC may additionally include a resource domain controller.

[0022] Optionally, the system may further include a memory and / or a device.

[0023] According to a second aspect, a method is provided for controlling access to memory and / or devices assigned to a virtual machine, wherein the virtual machine is hosted by a system including at least one processor core supporting the virtual machine, a resource domain controller, a security enclave, memory, and devices. The method may include configuring the resource domain controller by the security enclave.

[0024] Optionally, the method may include allocating at least one memory region of memory to a virtual machine by a secure enclave. The method may include assigning a domain identifier to a processor core and / or device supporting the virtual machine by the secure enclave. The method may include providing a domain identifier and information identifying the at least one memory region allocated to the virtual machine to a resource domain controller by the secure enclave.

[0025] Optionally, the method further includes controlling access to memory and / or devices by a resource domain controller based on a domain identifier.

[0026] Optionally, the method further includes assigning a domain identifier to a device by a secure enclave. The method may include providing a domain identifier and information identifying the at least one memory region assigned to the virtual machine to a resource domain controller by the secure enclave. The method may include controlling access to the memory and / or device by the resource domain controller based on the domain identifier.

[0027] Optionally, the method further includes having a resource domain controller append a domain identifier of a processor core to an access request originating from at least one processor core and / or append a domain identifier of a device to an access request originating from the device.

[0028] Optionally, the method further includes allowing access to the memory in response to an access request based on a domain identifier and memory region specified in the access request.

[0029] Optionally, the method further includes granting access to the device in response to an access request based on a domain identifier and a memory block specified in the access request.

[0030] According to a third aspect, a non-transitory computer-readable storage medium is provided, the non-transitory computer-readable storage medium including instructions that, when executed by a processing means, cause the processing means to perform the method according to a second aspect of the present disclosure. Attached Figure Description

[0031] A more complete understanding of the subject matter can be obtained by considering the following figures, with reference to the detailed embodiments and claims, wherein similar reference numerals in the figures refer to similar elements.

[0032] Figure 1 A system according to a first embodiment of the present disclosure is shown;

[0033] Figure 2 This illustration shows an embodiment of the invention for use in... Figure 1 The process of instantiating a secure confidential virtual machine (VM) on a system; and

[0034] Figure 3 Show Figure 1 The system controls memory access operations during the runtime of the virtual machines supported by the system. Detailed Implementation

[0035] The following detailed descriptions are illustrative in nature only and are not intended to limit the subject matter or the application and use of such embodiments. As used herein, the terms "exemplary" and "example" mean "serving as an example, instance, or illustration." Any embodiment described herein as exemplary or illustrative is not necessarily to be construed as preferred or advantageous over other embodiments. Furthermore, there is no intention to be bound by any express or implied theory presented in the foregoing technical field, background art, or the following detailed descriptions.

[0036] Figure 1System 100 according to an embodiment of this disclosure is shown as a confidential computing system. System 100 includes at least one processor 110 supporting one or more virtual machines (VM1, VM2) 120, a resource domain controller (RDC) 130, and a secure enclave 140. The system further includes an interface 150 (e.g., a bus or interconnect) for communicating with memory 160, an inline encryption engine (IEE) 165 for encrypting all data sent to memory 160, and I / O devices 170. System 100 may be implemented as a system-on-a-chip (SoC).

[0037] In this embodiment, processor 110 is implemented as core cluster 110. As an example, processor 110 may be powered by an ARM processor. ® The processor core 110 is implemented using the v8 core. The processor core 110 includes trusted firmware 111 and a trusted operating system (OS) 112 supporting trusted applications 113. The processor core 110 also includes a Boot ROM 114, a Boot ROM extension 116, a hypervisor 118, and a VM kernel 119 for supporting the corresponding VM 120. Figure 1 The illustration shows two virtual machines 120 supported by processor core 110. However, those skilled in the art will understand that in other embodiments, processor core 110 may support one or more virtual machines.

[0038] BootROM 114 and BootROM extension 116 can be implemented as firmware on core 110. BootROM 114 controls the execution of trusted firmware 111 and has full control over the EL3 (exception level 3) privilege level. BootROM is active during system operation, catches exceptions, and forwards them to trusted firmware 111 as needed.

[0039] BootROM extension 116 and hypervisor 118 operate at exception level 2 (EL2), where the BootROM extension controls privileged operations of the hypervisor, thereby providing a confidential computing environment on the kernel. The BootROM extension achieves this by binary-translating EL2 privileged register access instructions in the hypervisor code. Upon detection of hypervisor instantiation, the BootROM extension is dynamically authenticated and instantiated by the BootROM. BootROM extension 116 handles virtual machine identifier (VMID) setting, EL2 exception handling, stage 2 page table configuration, and VM state saving.

[0040] Each virtual machine 120 supported by core 110 can be associated with a corresponding memory region of memory 160. As an example, memory 160 can be provided in the form of DDR and can be accessed via interface 150.

[0041] I / O device 170 can be directly assigned to VM 120 and can be accessed via interface 150.

[0042] Resource Domain Controller (RDC) 130 controls access to memory 160 by virtual machine (VM) 120 and any assigned device 170, and controls VM 120 access to memory-mapped registers of any assigned device. RDC 130 includes Domain Assignment Controllers (DACs) 132, 132a, and 132b, a Memory Block Checker (MBC) 134, and a Memory Region Checker (MRC) 134. In this embodiment, multiple DAC registers 132a and 132b exist in RDC 130, each DAC register associated with a different master device (i.e., DAC 132a is associated with core 110, and DAC 132b is associated with I / O device 170).

[0043] Security Enclave 140 is the primary trusted entity in System 100. The security enclave may be implemented by firmware on a security subsystem isolated from the main processor core 110, including, for example, the processor, ROM storing the security enclave firmware, and RAM. As an example, the security enclave may be implemented by NXP's Edgelock® security enclave. According to this disclosure, Security Enclave 140 is responsible for configuring RDC 130 to control device access to VM memory and VM access to the device. In this way, the security enclave is used to establish trust between the device and the secure VM, enabling direct memory access (DMA) between the device and VM memory and allowing device access from the virtual machine. The configuration of RDC by Security Enclave 140 protects VM data from malicious attacks by untrusted entities.

[0044] Secure Enclave 140 communicates with BootROM Extension 116 on Core 110. BootROM 114 and BootROM Extension 116 can be instantiated and / or authenticated by Secure Enclave 140. This establishes a chain of trust between Secure Enclave 140 and BootROM 114 and BootROM Extension 116. Secure Enclave 140 is the root of trust, where trust flows from Secure Enclave 140 to BootROM and from BootROM 114 to BootROM Extension 116.

[0045] BootROM 114 is a trusted entity at the EL3 privilege level (MMU and exceptions). BootROM 114 authenticates and loads BootROM extension 116 at the EL2 level and is part of the root of trust. Security enclave 140 is the root of trust and authenticates and loads BootROM 114.

[0046] BootROM extension 116 controls the execution of hypervisor 118 to prevent untrusted hypervisor 118 from accessing VM memory or VM state. To achieve this, BootROM extension 116 takes control of the memory management unit (MMU) and exception vectors from hypervisor 118 at the EL2 privilege level. In one embodiment, BootROM extension 116 does this by binary translating instructions from hypervisor 118 that access higher privilege system registers at the EL2 privilege level, such that the instructions accessing higher privilege system registers are routed via BootROM extension. BootROM extension 116 also handles exceptions and can forward exceptions to hypervisor 118 as needed.

[0047] Memory partitioning and protection for virtual machine 120 are configured by a secure enclave 140, which interacts with BootROM extension 116 and uses RDC 130 to isolate DMA transactions. This ensures that DMA access to a particular VM 120 is restricted to a dedicated memory area associated with that VM, so that I / O devices assigned to a particular VM can only access the memory area assigned to that VM. Unauthorized access (e.g., by hypervisor 118 or another untrusted entity) is prevented by controlling access to memory 160 by kernel 110 and I / O devices.

[0048] Trusted device access and DMA configuration are also controlled by the secure enclave 140 using RDC 130. This ensures that when I / O device 170 is assigned to a specific VM, i.e., when a memory-mapped access to the device is created, device 170 is isolated so that it cannot be accessed by any other entity.

[0049] As discussed above, the secure enclave 140 configures the RDC 130 to control access to memory 160 by core 110 and I / O devices, and access to memory-mapped registers of I / O devices by virtual machine (VM) 120. The RDC 130 includes DACs 132, 132a, 132b, MBC 134, and MRC 136. DAC 132a is configured by the secure enclave 140 to generate a set of domain IDs (DIDs) associated with the core cluster 110 executing VM execution threads. The secure enclave 140 is configured to assign domain identifiers to processor core 110 or each processor core 110 supporting VM 120. The secure enclave 140 also assigns domain identifiers to each device 170 assigned to VM 120. These DIDs are programmed into DAC 132a by the secure enclave 140. In some embodiments, RDC 130 generates a DID based on a combination of the primary domain identifier set by the security enclave 140 and the core cluster identifier (CID) in DAC 132a. As an example, the CID is output as a sideband signal from core 110. The VMID is obtained from BootROM extension 116 by the security enclave 140. One or more VMIDs may exist associated with a specific core cluster 110. In MRC, the memory area allocated to a specific virtual machine is associated with the DID of all core clusters executing the virtual machine, and with the DID of any device assigned to the virtual machine.

[0050] The memory block checker (MBC) 134 is configured to restrict access to the device memory-mapped registers to a specific VM 120. Access to the memory-mapped registers of device 170 is controlled by the MBC 134 based on the DID.

[0051] The Memory Area Checker (MRC) 136 is configured to restrict access to memory areas (e.g., DDR) of memory 160 to a specific VM 120.

[0052] Figure 2 The present disclosure illustrates a process 200 for instantiating a secure confidential virtual machine (VM) 120 on a system 100, according to an embodiment of the present disclosure.

[0053] In step 210, the hypervisor 118 sends the encrypted VM image and configuration to the secure enclave 140. It is known that the VM image is encrypted when deployed in a confidential computing scenario, and technicians will be familiar with the techniques used to supply encryption keys to the secure enclave 140.

[0054] In step 220, the secure enclave 140 decrypts the VM image and copies it to the DDR memory 160. When the VM image is copied to the DDR memory 160, it is encrypted by the inline encryption engine (IEE) 165 using a (new) IEE key 166 programmed by the secure enclave 140. It should be noted that any data sent to the DDR 160 will also be encrypted with this new IEE key 166. Inline encryption protects the VM memory from physical attacks because the DDR 160 is available external to the system-on-a-chip (SoC).

[0055] In step 230, the security enclave 140 responds to the hypervisor 118 by sending details of the VMID and memory area settings to the hypervisor 118. That is, the security enclave 140 notifies the hypervisor 118 of the VMID associated with the virtual machine 120 and the address area of ​​the loaded VM memory.

[0056] In step 240, hypervisor 118 attempts to initialize VM 120 and set up the stage 2 translation table. (While the virtual machine is executing, it only has conceptual addresses in the address space, while the actual physical address space is controlled by hypervisor 118 using the stage 2 translation table.) However, because BootROM extension 116 performs binary translation on instructions accessing the EL2 privileged system register in the hypervisor, whenever the hypervisor attempts to access this register, it executes a stub that brings it to BootROM extension 116. In this case, hypervisor 116 attempts to set up the VTTBR (Virtualization Translation Table Base Register), which holds the base address and VMID used for the stage 2 translation table. Therefore, in step 250, a VTTBR access request (including the VMID and associated memory area details) is routed to BootROM extension 116 via a stub padded by BootROM extension 116 via binary translation.

[0057] In step 260, BootROM extension 116 sends a verification request to secure enclave 140 to verify the VMID and memory area details. This verification step ensures that hypervisor 118 does not attempt to assign the memory area to a different virtual machine.

[0058] In step 270, in response to the successful verification of VMID and memory area details to BootROM extension 116, secure enclave 140 configures RDC 130. Specifically, secure enclave 140 sets up RDC memory areas in MBC 134 and MRC 136. Secure enclave 140 also sets up DIDs for each memory area. That is, the MBC and MRC each store a table that associates each memory area or memory block with one or more DIDs that are authorized to access that memory area or memory block.

[0059] In step 280, in response to the verification of VMID and memory area details by the secure enclave 140, the BootROM extension 116 sets the stage 2 translation table (i.e., VTTBR setting). This is performed by the BootROM extension 116 because the BootROM extension 116 does not allow the hypervisor 116 to access this register.

[0060] In step 290, hypervisor 118 (now in the presence of its already set phase 2 translation table) completes the instantiation of virtual machine 120. Although Figure 2 The virtual machine is not shown in the diagram, but if the verification of VMID and memory area details fails at step 260, the virtual machine is not instantiated.

[0061] Figure 3 This illustrates the operations of RDC in controlling memory and device access during the runtime of virtual machine 120.

[0062] As indicated by reference numeral 310 in the attached figure, when an address access request is initiated in core 110, core 110 performs address translation via the Stage 2 Translation Table (VTTBR). If the address translation fails, an exception will occur in BootROM extension 116, and the requested access will not be allowed. For example, if a particular VM attempts to access an address region in the translation table that is not associated with that VM, the translation will fail.

[0063] After a successful address translation, the address access request originating from core 110 is output to DAC132a of RDC 130, as shown by arrow 320.

[0064] As indicated by reference numeral 330 in the figure, DAC 132a associates at least one domain identifier (DID) with a memory address and forwards the DID and memory address to interconnect 150.

[0065] If the access request is for memory (DDR) 160, the access request is passed to MRC 136, as indicated by arrow 340. MRC 136 checks whether the memory address is associated with a memory region enabled in the MRC, and then checks whether the DID is associated with that memory region in the MRC.

[0066] After successful verification by MRC 136, the transaction is forwarded to memory (DDR) 160, as indicated by arrow 350. If MRC 136 verification fails, access to memory (DDR) 160 is not permitted.

[0067] If the access request is for a memory-mapped register of I / O device 170, the access request is passed to MBC 134, as indicated by arrow 360. MBC 134 checks whether the memory address is associated with a memory block enabled in MBC 134, and whether the DID is associated with that memory block in MBC 134.

[0068] After successful authentication by MBC 134, the transaction is forwarded to I / O device 170, as indicated by arrow 370. If authentication by MBC 136 fails, access to device 170 is not permitted.

[0069] Similarly, DMA transactions originating from I / O device 170 are output from I / O device 170 to DAC 132b, as indicated by arrow 380. DAC 132b appends the DID to the address and floats the DID and address onto interconnect 150, as indicated by arrow 390. These transactions will be processed by MRC 136 in the same manner as described above.

[0070] In the foregoing description, system 100 and methods 200, 300 have been described according to embodiments of the present disclosure. Specifically, system 100 is disclosed, comprising at least one processor core 110 supporting virtual machines (VM1, VM2) 120, an interface 150 configured for communication between processor core 110 and memory 160, a resource domain controller (RDC) 130 configured to control access to memory 160, and a secure enclave 140. The resource domain controller (RDC) 130 is configured by the secure enclave 140.

[0071] The secure enclave 140 may be further configured to provide information identifying at least one memory region associated with the virtual machine 120 to the resource domain controller 130, said memory region being a memory region of the memory 160. The memory region may be allocated to the virtual machine 120 by the secure enclave 140.

[0072] The secure enclave 140 can be configured to obtain the virtual machine identifier (VMID1) of the virtual machine (VM1, VM2) 120 from at least one processor core 110.

[0073] The security enclave 140 can be configured to assign a domain identifier (DID) to the processor core 110 supporting the virtual machine 120. The security enclave 140 can provide the domain identifier (DID) of the processor core 110, along with an indication of the memory area allocated to the virtual machine 120, to the resource domain controller 130 for controlling access to memory. The domain identifier (DID) may be based in part on a core identifier (CID) associated with at least one processor core 110.

[0074] Interface 150 may be additionally configured for communication between processor core 110 and device 170 assigned to virtual machine 120.

[0075] The secure enclave 140 may be further configured to assign a domain identifier (DID) to the device 170 and to provide the domain identifier (DID) of the device 170 to the resource domain controller 130 for controlling the device 170’s access to the memory 160.

[0076] Resource Domain Controller (RDC) 130 may be additionally configured to control access to device 170. Secure Enclave 140 may be configured to provide the Domain Identifier (DID) of processor core 110 along with an indication of the memory blocks of device 170 to Resource Domain Controller 130 for controlling access to device 170.

[0077] Resource domain controller 130 may include at least one domain assignment controller (DAC) 132 / 132a / 132b, which is configured to append a domain identifier (DID) of processor core 110 to access requests originating from at least one processor core 110 and / or append a domain identifier (DID) of device 170 to access requests originating from device 170.

[0078] Resource domain controller 130 may include a memory area checker (MRC) 136, which is configured to allow access to memory 160 in response to an access request based on the domain identifier (DID) and memory area specified in the access request. Resource domain controller 130 may include a memory block checker (MBC) 134, which is configured to allow access to device 170 in response to an access request based on the domain identifier (DID) and memory block specified in the access request.

[0079] At least one processor core 110 may additionally include a hypervisor 118 for initializing and managing a virtual machine 120 on the processor core 110, and a BootROM extension 116. The BootROM extension 116 may be configured to reboot the translation table settings of the virtual machine 120 from the hypervisor 118 to the BootROM extension 116 via a stub. The BootROM extension 116 may perform translation table settings in response to verification of the virtual machine identifier (VMID) and associated memory area details by the secure enclave 140.

[0080] System 100 may include a system-on-a-chip (SoC), wherein the SoC includes at least one processor core 110 and a secure enclave 140.

[0081] The system may additionally include a memory 160 and / or a device 170.

[0082] Furthermore, a method for controlling access to memory 160 and / or device 170 assigned to virtual machine 120 has been disclosed, wherein virtual machine 120 is hosted by system 100, said system 100 including at least one processor core 110 supporting virtual machine 120, resource domain controller 130, security enclave 140, memory 160, and device 170. The method includes: allocating at least one memory region of memory 160 to virtual machine 120 by security enclave 140; assigning domain identifiers (DIDs) to processor core 110 and / or device 170 by security enclave 140; and providing the domain identifiers (DIDs) and information identifying said at least one memory region assigned to virtual machine 120 to resource domain controller 130 by security enclave 140. The method may further include configuring access to memory 160 and / or device 170 by resource domain controller 130 based on the domain identifiers (DIDs).

[0083] Those skilled in the art will understand from the foregoing description that the systems and methods of this disclosure enable the system to be controlled and configured to provide secure / trusted DMA for virtual machine 120. Specifically, trust relationships can be established via a secure enclave 140, which is the primary trusted entity within system 100. The secure enclave 140 communicates with the BootROM extension 116 on core 110 to obtain VMID information, which is used to generate domain IDs for transactions originating from core cluster 110. Similarly, domain IDs are also set for transactions initiated by devices. Device access requests and memory access requests are associated with domain IDs by resource domain controller 130. The secure enclave 140 configures resource domain controller 130 to allow / deny transactions corresponding to domain IDs, thereby maintaining control over the RDC configuration.

[0084] It will be readily understood that the components of the embodiments generally described herein and illustrated in the accompanying drawings can be arranged and designed in a wide variety of different configurations. Therefore, the foregoing detailed description of the various embodiments illustrated in the figures is not intended to limit the scope of this disclosure, but merely to illustrate various embodiments. While various aspects of the embodiments are presented in the figures, the figures are not necessarily drawn to scale.

[0085] The invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are to be considered in all respects merely illustrative and not restrictive. Therefore, the scope of the invention is indicated by the appended claims rather than by the specific embodiments described herein. All variations falling within the equivalent meaning and scope of the claims should be covered by the claims.

[0086] References to features, advantages, or similar language throughout this specification do not imply that all features and advantages achievable through the invention should be present in or in any single embodiment of the invention. In fact, language relating to features and advantages should be understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the invention. Therefore, discussions of features and advantages throughout this specification, as well as similar language, may (but not necessarily) refer to the same embodiment.

[0087] Furthermore, the features, advantages, and characteristics described in this invention can be combined in one or more embodiments in any suitable manner. Those skilled in the art will recognize that, in view of the description herein, this invention can be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages that may not be present in all embodiments of the invention can be identified in certain embodiments.

Claims

1. A system, characterized in that, include: At least one processor core that supports virtual machines; An interface configured for communication between the processor core and memory; A resource domain controller (RDC) is configured to control access to the memory; as well as Safe enclave; The Resource Domain Controller (RDC) is configured by the secure enclave.

2. The system according to claim 1, characterized in that, The secure enclave is configured as follows: Information identifying at least one memory region associated with the virtual machine is provided to the resource domain controller, the memory region being a memory region of the memory.

3. The system according to claim 1, characterized in that, The secure enclave is configured as follows: Assign a domain identifier to the processor core that supports the virtual machine.

4. The system according to any one of the preceding claims, characterized in that: The interface is further configured for communication between the processor core and the device assigned to the virtual machine.

5. The system according to claim 4, characterized in that, The secure enclave is further configured as follows: Assigning a domain identifier to the device; and The domain identifier of the device is provided to the resource domain controller for controlling the device's access to the memory.

6. The system according to claim 4, characterized in that: The Resource Domain Controller (RDC) is further configured to control access to the device; and The secure enclave is configured to provide the domain identifier of the processor core, along with an indication of the device's memory blocks, to the resource domain controller for controlling access to the device.

7. The system according to claim 4, characterized in that, The resource domain controller includes at least one domain assignment controller, which is configured to append the domain identifier of the processor core to access requests originating from the at least one processor core and / or append the domain identifier of the device to access requests originating from the device.

8. The system according to claim 4, characterized in that, The resource domain controller includes: A memory area checker (MRC) is configured to allow access to the memory in response to an access request based on the domain identifier and memory area specified in the access request; and / or A memory block checker (MBC) is configured to allow access to the device in response to an access request based on the domain identifier and memory block specified in the access request.

9. The system according to claim 1, characterized in that, The at least one processor core further includes: A hypervisor for initializing and managing the virtual machines on the processor core; and BootROM extension; The BootROM extension is configured to reboot the translation table settings for the virtual machine from the hypervisor to the BootROM extension via a stub.

10. A method for controlling access to memory and / or devices assigned to a virtual machine, characterized in that, The virtual machine is hosted by a system, which includes at least one processor core supporting the virtual machine, a resource domain controller, a secure enclave, memory, and devices; the method includes: The secure enclave allocates at least one memory region of the memory to the virtual machine; The secure enclave assigns a domain identifier to the virtual machine and / or the device; and The secure enclave provides the resource domain controller with the domain identifier and information identifying the at least one memory region assigned to the virtual machine; The resource domain controller is configured to control access to the memory and / or the device based on the domain identifier.

Images