Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
VIRTUALIZATION UNDER MULTIPLE LEVELS OF SECURITY PROTECTIONS
Document Type and Number:
WIPO Patent Application WO/2020/005984
Kind Code:
A1
Abstract:
Systems, apparatuses, methods, and computer-readable media associated with virtualization under multiple levels of security protections are presented. A computing platform includes a processor, a storage device having a secure storage block, a hypervisor, and a first VM, e.g., a service VM, and a second VM, e.g., a user VM, managed by the hypervisor. The second VM includes a first operating system to operate a first set of applications in a first execution environment having a first level of security protection, and a second operating system to operate a second set of applications in a second execution environment having a second level of security protection. The first VM is configured to authenticate the second VM for accessing a secure storage block. The hypervisor manages operations of the first operating system and the second operating system on different virtual processors. Other embodiments may be described and/or claimed.

Inventors:
ZHU BING (CN)
HUANG YANG (CN)
WANG KAI (CN)
DONG YAO ZU (CN)
DENG WEI (CN)
QI YADONG (CN)
SMITH NED (US)
Application Number:
PCT/US2019/039049
Publication Date:
January 02, 2020
Filing Date:
June 25, 2019
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
INTEL CORP (US)
International Classes:
G06F21/53; G06F21/60; G06F21/62
Foreign References:
US20150082305A12015-03-19
US20140020086A12014-01-16
US20170132158A12017-05-11
US20140059680A12014-02-27
US20150220709A12015-08-06
Attorney, Agent or Firm:
WANG, Yuke et al. (US)
Download PDF:
Claims:
Claims

What is claimed is:

1. A method for computing, comprising:

managing, by a hypervisor of a computing device, on at least a first virtual processor of the hypervisor with a first set of memory pages, operations of a first set of applications of a first operating system of a virtual machine (VM);

managing, by the hypervisor, on at least a second virtual processor of the hypervisor with a second set of memory pages separated from the first set of memory pages, operations of a second set of applications of a second operating system of the VM, wherein the VM includes the first operating system to operate the first set of applications in a first execution environment having a first level of security protection, and the second operating system to operate the second set of applications in a second execution environment having a second level of security protection; and

scheduling, by the hypervisor, alternate execution of the operations of the first set of applications and the first operating system, and execution of the operations of the second set of applications and the second operating system, respectively on the first virtual processor and the second virtual processor.

2. The method of claim 1, further comprising:

storing a first operational context for the operations of the first set of applications and the first operating system in the first set of memory pages; and

storing a second operational context for the operations of the second set of applications and the second operating system in the second set of memory pages; and wherein the scheduling of execution of the operations includes switching from the first operational context stored in the first set of memory pages to the second operational context stored in the second set of memory pages.

3. The method of claim 1, further comprising:

managing, by the hypervisor with a first memory page table, accesses by applications of the first operating system, to a first storage device or a first functional device; and

managing, by the hypervisor with a second memory page table, accesses by applications of the second operating system, to a second storage device or a second functional device, wherein the second storage device or the second functional device is only visible or accessible by the second operating system in the second execution environment with the second level of security protection, and wherein the first storage device or the first functional device is visible or accessible to both the first operating system and the second operating system.

4. The method of claim 1, wherein the scheduling of execution includes scheduling execution quanta by assigning a first portion of time or resources for operations of the first set of applications or the first operating system, and assigning a second portion of time or resources for operations of the second set of applications or the second operating system.

5. The method of claim 1, wherein the scheduling of execution includes switching execution of the first set of applications or the first operating system to execution of the second set of applications or the second operating system when operations of the first set of applications of the first operating system are blocked by tasks to be performed by the second set of applications or the second operating systems.

6. The method of claim 1, wherein the scheduling of execution includes switching execution from the first set of applications of the first operating system to execution of the second set of applications of the second operating system when there is a service request from execution of the first set of applications or the first operating system for one or more operations to be performed by the second set of applications or the second operating system.

7. The method of claim 1, wherein the VM is a first user VM, and the method further includes:

managing, by the hypervisor, operation of a second user VM, on at least a third virtual processor of the hypervisor, wherein the second user VM includes only a third operating system.

8. A method for computing, comprising:

authenticating, by a first virtual machine (VM) of a computing device, based on an authentication key stored in the first VM, a second VM of the computing device, wherein execution of the first VM and the second VM are managed by a hypervisor of the computing device, and wherein the computing device includes a storage device having a secure storage block, and wherein the second VM includes a first operating system to operate a first set of applications with a first set of memory pages in a first execution environment with a first level of security protection, and a second operating system to operate a second set of applications with a second set of memory pages in a second execution environment with a second level of security protection, the second set of memory pages being separated from the first set of memory pages; and

granting the second VM, by the first VM, access to the secure storage block of the storage device, after the first VM has successfully authenticated the second VM based on the authentication key.

9. The method of claim 8, wherein authenticating the second VM includes receiving a copy of a guest authentication key from a secure memory page associated with the second VM, and wherein the guest authentication key is stored in the secure memory page, which is one of the second set of memory pages.

10. The method of claim 9, wherein receiving the copy of the guest authentication key from the secure memory page associated with the second VM includes receiving the copy of the guest authentication key from the secure memory page associated with the second VM on provision of the guest authentication key by the hypervisor to the second VM.

11. The method of claim 9, wherein authenticating the second VM includes comparing the authentication key stored in the first VM with the copy of the guest authentication key received from the secure memory page associated with the second VM.

12. The method of claim 8, further comprising:

receiving the authentication key from the hypervisor to be stored in the first VM and to be used in authenticating the second VM.

13. The method of claim 8, wherein granting the access to the secure storage block includes providing a copy of an encryption key to the second VM to access the secure storage block that is encrypted by the encryption key.

14. The method of claim 8, wherein granting the access to the secure storage block includes providing a copy of an encryption key to the hypervisor to decrypt the secure storage block that is encrypted by the encryption key, for the second VM.

15. The method of claim 14, further comprising providing, by the first VM, the decrypted secure storage block to the second VM; and wherein the first VM is a service VM, and the second VM is a user VM.

16. The method of claim 8, wherein granting the second VM access to the secure storage block of the storage device includes granting the second VM access to the secure storage block of a volatile memory device, a non-volatile memory device, a semi -volatile memory, a secondary storage device, universal flash storage (UFS), enhanced memory management controller (eMMC), non-volatile memory express (NVMe), solid-state drive (SSD), Intel® Optane™ memory, trusted platform module (TPM) NV, Intel® Converged Security and Management Engine (CSME) NV, a replay protected memory block (RPMB), or a unit of RPMB.

17. The method of claim 16, further comprising:

partitioning the storage device without replay protected memory blocks (RPMB) into a series of RPMBs, and

assigning one RPMB of the series of RPMBs to be accessed by the second VM as the secure storage block.

18. The method of claim 17, wherein the authentication key is a first

authentication key, the secure storage block is a first secure storage block, and the storage device further includes a number of secure storage blocks, a second secure storage block of the number of secure storage blocks being assigned to a third VM managed by the hypervisor; and the method further comprises:

authenticating, by the first VM, the third VM, based on a second authentication key stored in the first VM; and

granting, by the first VM, the third VM access to the second secure storage block, after the first VM has successfully authenticated the third VM based on the second authentication key.

19. A method for computing, comprising:

providing, by a first virtual machine (VM) to be operated by a hypervisor of a computing device, an authentication key stored in a secure memory page associated with the first VM to a second VM for authenticating the first VM by the second VM, wherein the first VM includes a first operating system to operate a first set of applications with a first set of memory pages in a first execution environment with a first level of security protection, and a second operating system to operate a second set of applications with a second set of memory pages in a second execution environment with a second level of security protection, the second set of memory pages being separated from the first set of memory pages, and wherein the authentication key is stored in the secure memory page, which is one of the second set of memory pages; and

gaining access to a secure storage block of a storage device of the computing device, after the first VM has successfully been authenticated by the second VM based on the authentication key.

20. The method of claim 19, wherein the gaining access to the secure storage block includes receiving a copy of an encryption key from the second VM to access the secure storage block that is encrypted by the encryption key.

21. The method of claim 19, wherein the secure memory page storing the authentication key is not accessible by the first set of applications of the first operating system operating in the first execution environment.

22. A computer readable media (CRM) comprising a plurality of instructions arranged to cause one or more processors of a computing platform, in response to execution of the plurality of instructions, to perform any operations of the methods of any one of claims 1-21.

23. A computing platform, comprising:

one or more processors;

a storage device coupled to the one or more processors, and having a secure storage block;

a hypervisor arranged to operate on the one or more processors;

a first virtual machine (VM) and a second VM managed by the hypervisor;

wherein the first VM is configured to:

authenticate, based on an authentication key stored in the first VM and a guest authentication key stored in a secure memory page associated with the second VM, the second VM, wherein the second VM includes a first operating system to operate a first set of applications with a first set of memory pages in a first execution environment having a first level of security protection, and a second operating system to operate a second set of applications with a second set of memory pages in a second execution environment having a second level of security protection, and wherein the guest authentication key is stored in the secure memory page included in the second set of memory pages; and

grant the second VM access to the secure storage block of the storage device, after the first VM has successfully authenticated the second VM based on the authentication key.

24. The computing platform of claim 23, wherein the hypervisor includes a first virtual processor, a second virtual processor, and a scheduler, and wherein the first operating system of the second VM is to operate at least on the first virtual processor, the second operating system of the second VM is to operate at least on the second virtual processor, and the scheduler of the hypervisor is to switch execution of the second VM between the first and second virtual processors for operations performed by the first operating system and operations performed by the second operating system.

25. The computing platform of claim 23, wherein the first VM is a service VM, the second VM is a user VM, and the first VM is further configured to:

partition the storage device into one or more secure storage blocks that includes the secure storage block to be granted access to the second VM, wherein the storage device includes a volatile memory device, a non-volatile memory device, a semi-volatile memory, a secondary storage device, universal flash storage (UFS), enhanced memory management controller (eMMC), non-volatile memory express (NVMe), solid-state drive (SSD), Intel® Optane™ memory, trusted platform module (TPM) NV, Intel® Converged Security and Management Engine (CSME) NV, a replay protected memory block (RPMB), or a unit of RPMB.

Description:
VIRTUALIZATION UNDER MULTIPLE LEVELS OF SECURITY

PROTECTIONS

Cross Reference to Related Application

The present application claims priority from a PCT International Application PCT/CN2018/092690, filed June 25, 2018 in China Intellectual Property Office, and entitled,“World-switch as a way to schedule multiple isolated tasks within a VM,” the entire disclosure of which is hereby incorporated by reference in its entirety.

BACKGROUND

With advances in integrated circuit (IC) and computing technologies, computing processors and platforms are increasingly more powerful, and capable of handling more computation, and of increasing complexity at the same time. Concurrently, as advanced computing are being employed for more applications, increased security is needed. For example, automotive automation and embedded control systems today use hundreds or more discrete Embedded Control Units (ECUs), each programmed to perform specific tasks, to function together as a coherent embedded control system. Multiple such ECUs communicate over a field bus, e.g. Controller Area Network (CAN), to achieve distributed application goals. Unfortunately, an architecture based on multiple ECUs coupled by a field bus doesn’t scale well across many vectors, safety, complexity, performance, and security. Consolidation and virtualization of ECUs using general purpose application processors, e.g., Intel® Core, Intel® Atom or Intel® Xeon, would be desirable. Security and safety are potentially important considerations for consolidation and virtualization of multiple ECUs.

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 illustrates an example of trusted virtualization, in accordance with some embodiments.

Figure 2 illustrates an example of replay protected memory block (RPMB) virtualization, in accordance with some embodiments.

Figure 3 illustrates an alternative embodiment where the number of guest virtual machines (VMs) is less than the number of RPMB partition units, in accordance with some embodiments.

Figure 4 illustrates a computing platform including a hypervisor managing a service VM and one or more user VMs under multiple levels of security protections, in accordance with some embodiments.

Figure 5 illustrates a process performed by a hypervisor to manage various VMs under multiple levels of security protections, in accordance with some embodiments. Figure 6 illustrates a process performed by a service VM to manage a storage device under multiple levels of security protections, in accordance with some embodiments.

Figure 7 illustrates a process performed by a user VM to support multiple operating systems to operate applications in execution environments with multiple levels of security protections, in accordance with some embodiments.

Figure 8 illustrates a software component view of an in-vehicle system, according to various embodiments.

Figure 9 illustrates a hardware component view of a computer platform, suitable for use as an in-vehicle system or a cloud server, according to various embodiments.

Figure 10 illustrates a storage medium having instructions for practicing methods described with references to Figures 1-7, according to various embodiments.

DETAILED DESCRIPTION

Many hardware elements, e.g., embedded control units (ECUs), are used to perform safety and security critical functions, which are hard to scale for complex systems. It is desirable that for scalability, security and safety be consolidated and virtualized using powerful general purpose application processors such as Intel® Core, Intel® Atom or Intel® Xeon. The differences between virtualization of some secure operations and virtualization of some unsecure operations have been a challenge for the virtualization of ECUs. In general terms, some operations may require more security protections while some other operations may require less security protections. Sometimes, operations performed under same or similar security protections may be referred to as operations in a same“world” or “execution environment.” For example, some operations may be performed in a secure world or a trusted world, while some other operations may be performed in an unsecure world or an untrusted world. Besides the secure or unsecure, trusted or untrusted worlds, there may be multiple levels of different security protections for operations. Hence, virtualization under multiple levels of security protections may be desirable.

Some existing approaches, e.g., ARM® TrustZone, may allow separation of certain critical functionality from less critical functionality. Some other solutions may combine secure and non-secure functionality based on ARM® TrustZone to provide hardware separation of both application and operating systems. Still in some approaches, a hypervisor may assign a physical TrustZone core to a virtual machine (VM) and allow the operating system (OS) on the untrusted world to call into the TrustZone core. However, such approaches may be limited to ARM® TrustZone, and may not function in general architecture solutions. In addition, some approaches, called“side-car VM,” may use a first VM for untrusted operations and a second VM for trusted operations. Two side-car VMs have affinity and may be treated by a hypervisor as companion VMs in terms of scheduling and inter-VM accesses. However, the use of side-car VMs places excessive overhead on the hypervisor in terms of scheduling and requires additional resources to ensure VM affinity.

It should be noted that an unsecured world/execution environment may not be totally “unsecured,” some security may be provided, and similarly, a secured world/execution environment may not be totally‘secured,” but a“heightened” level of security (especially in contrast with the unsecured world/execution environment) is provided. Hereafter, unless the context clearly indicates otherwise, the terms“world,” and“execution environment” may be considered synonymous, and the terms“secured/trusted” world/environment and “unsecured/untrusted” world/environment may be considered as a world/environment having a first level of security and/or trust, and another world/environment having a second level security and/or trust, where the first level is higher than the second level. It should be also noted that while in general a more secured world/environment is more trustworthy than a less secured world/environment, security and trust may be two separate issues, and handle independently.

Embodiments herein provide virtualization under multiple levels of security protections, e.g., in a trusted and an untrusted worlds or environments, by effectively bundling two operating systems and their applications into a single composite VM. A hypervisor maintains separate memory pages and assigns a different virtual processor core to each of the trusted and the untrusted worlds. In addition, the hypervisor divides the VM execution quanta between virtual processor cores giving operations in each world an opportunity to execute. Accordingly, embodiments herein support virtualized applications, e.g., ECUs, designed with a“trusted” and“untrusted” world context to run on general processors by using only one VM.

Additionally, replay protected memory block (RPMB) is a technology for storage devices having operations with multiple levels of security protections. The RPMB technology partitions a memory device into blocks, where RPMB blocks have additional security semantics beyond non-RPMB blocks. Values written to memory locations that are replay protected cannot be overwritten under normal conditions. For example, RPMB blocks may be used to implement monotonic counters where a counter value can be incremented but not decremented until the counter word length overflows and rolls over to an initial value (e.g. zero). However, the implementation of RPMB technology may need some special hardware, e.g., enhanced memory management controller (eMMC). Without eMMC, applications operating in a secure world may not have access to RPMB functionality. Embodiments herein provide virtualization of an eMMC, e.g., through a service VM, such that a traditional storage device can be used in place of a physical eMMC. The service VM may be the first VM instance created by a hypervisor and may be co-resident with the hypervisor image that is securely bootstrapped.

Embodiments herein present a computing platform including one or more processors, a storage device coupled to the one or more processors having a secure storage block, a hypervisor arranged to operate on the one or more processors, and a first VM and a second VM managed by the hypervisor. The first VM is configured to authenticate, based on an authentication key stored in the first VM, the second VM. The first VM is further configured to grant the second VM access to the secure storage block of the storage device, after the first VM has successfully authenticated the second VM based on the authentication key. The first VM may be a service VM managing a storage device like RPMB blocks, while the second VM may be a user VM, including a composite VM of the present disclosure.

Embodiments presents methods for a hypervisor to manage the operations of a composite VM. The method includes managing, by a hypervisor of a computing device, on at least a first virtual processor of the hypervisor with a first set of memory pages, operations of a first set of applications of a first operating system of the composite VM. The method further includes managing, by the hypervisor, on at least a second virtual processor of the hypervisor with a second set of memory pages separated from the first set of memory pages, operations of a second set of applications of a second operating system of the composite VM. The composite VM includes the first operating system to operate the first set of applications in a first execution environment having a first level of security protection, and the second operating system to operate the second set of applications in a second execution environment having a second level of security protection. Moreover, the method includes scheduling, by the hypervisor, alternate execution of the operations of the first set of applications and the first operating system, and execution of the operations of the second set of applications and the second operating system, respectively on the first virtual processor and the second virtual processor.

Embodiments presents methods for a first VM, which may be a service VM. The method includes authenticating, by the first VM of a computing device, based on an authentication key stored in the first VM, a second VM of the computing device (which may be a composite VM of the present disclosure). The execution of the first VM and the second VM are managed by a hypervisor of the computing device. The computing device includes a storage device having a secure storage block. In addition, the method includes granting the second VM, by the first VM, access to the secure storage block of the storage device, after the first VM has successfully authenticated the second VM based on the authentication key.

Embodiments presents methods for a first VM, which may be a user VM (e.g., a composite VM of the present disclosure). The method includes providing, by the first VM, to be operated by a hypervisor of a computing device, an authentication key stored in a secure memory page associated with the first VM to a second VM for authenticating the first VM by the second VM. The first VM includes a first operating system to operate a first set of applications with a first set of memory pages in a first execution environment with a first level of security protection, and a second operating system to operate a second set of applications with a second set of memory pages in a second execution environment with a second level of security protection. The second set of memory pages are separated from the first set of memory pages. The authentication key is stored in the secure memory page, which is one of the second set of memory pages. The method further includes gaining access to a secure storage block of a storage device of the computing device, after the first VM has successfully been authenticated by the second VM based on the authentication key.

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail.

Operations of various methods may be described as multiple discrete actions or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order than the described embodiments. Various additional operations may be performed and/or described operations may be omitted, split or combined in additional embodiments.

For the purposes of the present disclosure, the phrase“A or B” and“A and/or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase“A, B, and/or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C).

The description may use the phrases“in an embodiment,” or“in embodiments,” which may each refer to one or more of the same or different embodiments. Furthermore, the terms“comprising,”“including,”“having,” and the like, as used with respect to embodiments of the present disclosure, are synonymous.

Where the disclosure recites“a” or“a first” element or the equivalent thereof, such disclosure includes one or more such elements, neither requiring nor excluding two or more such elements. Further, ordinal indicators (e.g., first, second or third) for identified elements are used to distinguish between the elements, and do not indicate or imply a required or limited number of such elements, nor do they indicate a particular position or order of such elements unless otherwise specifically stated.

The terms“coupled with” and“coupled to” and the like may be used herein. “Coupled” may mean one or more of the following. “Coupled” may mean that two or more elements are in direct physical or electrical contact. However,“coupled” may also mean that two or more elements indirectly contact each other, but yet still cooperate or interact with each other, and may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other. By way of example and not limitation,“coupled” may mean two or more elements or devices are coupled by electrical connections on a printed circuit board such as a motherboard, for example. By way of example and not limitation,“coupled” may mean two or more elements/devices cooperate and/or interact through one or more network linkages such as wired and/or wireless networks. By way of example and not limitation, a computing apparatus may include two or more computing devices“coupled” on a motherboard or by one or more network linkages.

As used hereinafter, including the claims, the term“unit,”“engine,”“module,” or “routine” may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality.

As used herein, the term“circuitry” refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD), (for example, a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high- capacity PLD (HCPLD), a structured ASIC, or a programmable System on Chip (SoC)), digital signal processors (DSPs), etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality.

As used herein, the term“processor circuitry” may refer to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations; recording, storing, and/or transferring digital data. The term“processor circuitry” may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a general purpose processing unit (GPU), a single-core processor, a processor core, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and/or functional processes.

As used herein, the term“interface circuitry” may refer to, is part of, or includes circuitry providing for the exchange of information between two or more components or devices. The term“interface circuitry” may refer to one or more hardware interfaces (for example, buses, input/output (I/O) interfaces, peripheral component interfaces, network interface cards, and/or the like).

As used herein, the term“computer device” may describe any physical hardware device capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, equipped to record/store data on a machine readable medium, and transmit and receive data from one or more other devices in a communications network. A computer device may be considered synonymous to, and may hereafter be occasionally referred to, as a computer, computing platform, computing device, etc. The term“computer system” may include any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term“computer system” and/or“system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term“computer system” and/or“system” may refer to multiple computer devices and/or multiple computing systems that are communicatively coupled with one another and configured to share computing and/or networking resources. Examples of “computer devices”,“computer systems”, etc. may include cellular phones or smart phones, feature phones, tablet personal computers, wearable computing devices, an autonomous sensors, laptop computers, desktop personal computers, video game consoles, digital media players, handheld messaging devices, personal data assistants, an electronic book readers, augmented reality devices, server computer devices (e.g., stand-alone, rack-mounted, blade, etc.), cloud computing services/sy stems, network elements, in-vehicle infotainment (IVI), in-car entertainment (ICE) devices, an Instrument Cluster (IC), head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminals (MDTs), Electronic Engine Management Systems (EEMSs), electronic/engine control units (ECUs), vehicle-embedded computer devices (VECDs), autonomous or semi- autonomous driving vehicle (hereinafter, simply ADV) systems, in-vehicle navigation systems, electronic/engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or“smart” appliances, machine-type communications (MTC) devices, machine-to-machine (M2M), Internet of Things (IoT) devices, and/or any other like electronic devices. Moreover, the term“vehicle- embedded computer device” may refer to any computer device and/or computer system physically mounted on, built in, or otherwise embedded in a vehicle.

Figure 1 shows an example world switch architecture in a general purpose processor (such as Intel X86) virtualization environment 100 having a processor 152, a memory 154, a hypervisor 116, a service VM 101 and a user VM 102, coupled with each other as shown. The processor 152 and the memory 154 are arranged to perform conventional processor and memory known in the art, and may be any one of these elements known. The hypervisor 116 is incorporated with the virtualization technology of the present disclosure to manage execution the service VM 101, and the user VM 102, which is a composite VM including at least two execution environments with respective operating systems.

In embodiments, the user VM 102 is a composite VM. Within the composite VM, a normal (untrusted or unsecured) world 104 is isolated from a trusted (secure) world 106 using hypervisor separation of memory pages, where the normal (unsecure) world 104 may host a virtual kernel 108, which represents a normal or unsecure operating system, and user environment 110 that includes one or more applications. In addition, the VM 102 hosts a trusted kernel 112, which represents a secure operating system, and a trusted (secure) user environment 114 that includes one or more secure applications, using a different set of memory pages. The two worlds 104 and 106 may be used to respectively host a number of untrusted/unsecured and trusted/secured applications, e.g., untrusted/unsecured and trusted/secured virtual ECU. In other embodiments, the user VM 102 may be used for applications other than virtual ECU. In addition, other VMs may contain other ECUs that require ECU-ECU separation.

The hypervisor 116 includes a scheduler 117 that does two-layer scheduling where the first layer schedules VM execution quanta and the second-level scheduler performs task switching between trusted (secure) and untrusted (unsecure)“worlds” by assigning a portion of the VM execution quanta to the first world. Any unused VM quanta is given to the second world. In various embodiments, if the first world is blocked on the second world task, the first world immediately yields its execution time back to the hypervisor that assigns it to the second world. This repeats until the second world task completes.

As illustrated, for the embodiments, the hypervisor 116 provides different virtual central processing units (vCPU) 118 with different contexts for normal (unsecure) world 104 and trusted (secure) world 108. Normal (unsecure or untrusted) world 104 and trusty (secure) world 106 can trigger switching between the two worlds through hyper calls 121. In various embodiments, the hypervisor 116 respectively maintains two extended page tables (EPT) 120 for the different worlds 104 and 108. The trusted (secure) world memory is invisible for the normal (unsecure) world, but not vice versa, as illustrated by memory views 156 and 158.

In embodiments, for the“second-level scheduler,” the normal (unsecure) world 104 is event-driven. Whenever there is a request from the normal (unsecure) world 104, which sends a request to the hypervisor 116 that requires secure processing, the hypervisor 116 will schedule the secure context (and appropriate one of memory page tables 120) of the trusted (secure) world 106. Then the trusted (secure) world 106 starts to execute its security task(s), and eventually, exits back to hypervisor 116 whenever either the secure task(s) in the trusted (secure) world 106 is (are) completed, or there is a block event/like interrupt that doesn’t belong to the trusted (secure) world 106. After exiting to hypervisor 116, the hypervisor 116 will schedule the context (and appropriate one of memory page tables 120) back to the normal (unsecure) world 104 to continue to execution in the normal (unsecure) world 104. Since the trusted (secure) world 106 is event-driven (or request-driven), thus when there is no request from the normal (unsecure) world 104 for the trusted (secure) world 106, the trusted (secure) world 108 will not be scheduled. In embodiments, the trusty world 106 may be provisioned with the trusty OS released by Google for Android secure world. In embodiments, the hypervisor 116 may be built by further enhancing the ACRN™ hypervisor, an open source project. The current ACRN™ hypervisor does not include or support the functions disclosed herein. For example, the ACRN™ hypervisor does not include or support methods to manage the operations of a composite VM that includes a first operating system to operate a first set of applications in a first execution environment having a first level of security protection, and a second operating system to operate a second set of applications in a second execution environment having a second level of security protection. For another example, the current ACRN™ hypervisor does not include or support methods for a first VM to authenticate a second VM for accessing a secure storage block. From the descriptions to follow, those skilled in the art will recognize, other functions presented in the current disclosure not supported by the current ACRN™ hypervisor, and would require its enhancement.

It is noted that the hypervisor 116 need not be restricted to supporting only composite VMs that implement trusted/untrusted worlds. It may support tradition“singleton” VM environments or it may support various container environments where a container may be one or more namespace and resource restricted application execution environments.

Figure 2 illustrates an example of replay protected memory block (RPMB) virtualization, according to some embodiments. Replay protected memory block (RPMB) may be implemented in an embedded multi-media controller for non-volatile memory (eMMC NV). RPMB partitions NV memory into blocks where RPMB blocks have additional security semantics beyond non-RPMB blocks. These semantics include NV locations that are replay protected meaning values written cannot be overwritten under normal conditions. They may be used to implement monotonic counters (MC) where a first value can be incremented but not decremented. Current RPMB specification doesn’t allow overflow of MC. If overflow occurs, then any write access request will be rejected. There is no software interface to allow software reset to this MC.

For many current architectures, the lack of an eMMC means application that run in a secure world (see Figure 1) do not have access to RPMB functionality. The present disclosure virtualizes an eMMC such that a traditional NVMe storage device can be used in place of a physical eMMC. This is achieved by providing a hypervisor 210 to a virtualization environment 200, to host a Service VM (or Service OS (SOS)) (VM#0) 202 and a number of user VM (or user OS) 208. Service OS (SOS) 202 may be otherwise referred to as“VM#0,” because it is often the first VM instance created and may be co- resident with the hypervisor (which may also be referred to as virtual machine manager (VMM)) that is securely bootstrapped.

The hypervisor 210 is configured to partition an NVMe storage device 204 into a series of RPMB blocks (Blk#0, ... Blk#n) 206 where each block 206 is assigned to an appropriate guest VM (also known as a“User OS” - UOS) 208. The SOS 202 maintains an array of Device Module structures 212 containing information associated with the NVMe block assignment(s) corresponding to a guest VM 208, including information to protect and maintain the security of the content of the RPBM blocks.

One of the challenges associated with virtualizing an RPMB is integrity and confidentiality protection of RPMB contents. The hypervisor 210 uses strong cryptography to encrypt RPMB blocks. Each block may be encrypted and bound to a particular guest VM 208. In embodiments, a different encryption key (eKey) is employed to encrypt the RPMB blocks assigned to a particular guest VM 208 (i.e. eKey#0 - RPMB of VM#0, eKey# l- RPMB of VM#l etc... ). With this approach, even the SOS 202 cannot decrypt the data of the VMs 208.

In various embodiments, one VrKey (virtual RPMB key) is provided for each VM 208 and stored in the corresponding DM context 212 withing SOS 202 for use to authenticate communication between SOS 202 and Secure world of UOS 208, so that the secure world of UOS thought it was talking to a physical RPMB device.

Further, in various embodiments, a common rkey is used for authentication between the SOS 202 and the hypervisor 210, which in turn talks to physical RPMB controller in NVMe storage device 204 with a physical/real RPMB key. In alternate embodiments, the hypervisor 210 is arranged to operate in a pass-through mode, which means that the rKey can behave as the physical/real RPMB key, which then is directly used for authentication between the SOS 202 and the physical RPMB controller in NVMe storage device 204, thus the hypervisor 210 is bypassed in this embodiments.

In alternate embodiments, the same eKey may be used for each RPMB block that is under the supervision of the SOS VM 202. Each approach has different security, availability and performance trade-offs. Use of the eKey by the SOS 202 is authorized by the associated VM guest 208.

In some embodiments, the VrKey established for each VM, and store in the corresponding DM 212 context structure within SOS 202 may also be used to authenticate and protect the communication channel between the SOS 202 the VM guest 208. The hypervisor 210 may play a role in provisioning the VrKey by generating and provisioning the VrKey into memory pages corresponding to the VM guest 208 and the corresponding DM context 212 within SOS 202. The SOS 202 is trusted to maintain the integrity of the DM context structures 212. If the VM Guest 208 implements“world” separation, as earlier described with references to Figure 1, a“trusted” world memory page is used to provision the VrKey and the world switch isolation mechanism helps ensure the untrusted world cannot obtain a copy of the VrKey. Consequently, the VrKey is inaccessible by the untrusted world within a UOS 208 except through an application programming interface (API) designed to control and restrict VrKey usage.

In some embodiments, an alternative approach may allow the RPMB block data to remain encrypted until it reaches the SOS 202 where the SOS driver applies the encryption/decryption operation.

In other embodiments, the RPMB driver 214 in the kernel of the SOS 202 can implement read or write, monotonic counter and other RPMB defined NV functions in compliance with an eMMC expected behavior.

In various embodiments, except for the RPBM virtualization techniques of the present disclosure incorporated, SOS 202 may operate a Linux kernel, UOS 208 may be user OS 102 of Figure 1, and the hypervisor 210 may be hypervisor 116 of Figure 1.

In alternate embodiments, instead of having each DM context 212 within SOS 202 having a copy of the rkey, an optional RPBM raw access module (216) may be provided to the kernel (as a companion to RPBM driver 214) to handle the rkey for all DM contexts 212, and interface between the DM contexts 212 and the hypervisor 116. Under these embodiments, the rkey is kept out of the user space of the SOS 202, which is likely to further increase security.

Figure 3 illustrates an alternate embodiment where the number of guest VMs is less than the number of RPMB partition units, in accordance with some embodiments. As shown, for the example virtualization environment 300, a hypervisor 310 is hosting service VM 302 and two example guest VMs 308a and 308b, where each VM 308a or 308b may be a composite VM respectively having two different operating systems. NVMe storage device 303 include 4 RPBM partitions, more than the number of guest VMs 308a and 308b being hosted. (Note than the number of 2 VMs and 4 RPBM partitions shown here are illustrative, and not to be read as limiting. In alternate embodiments, virtualization environment 300 may include any number of M VMs and N partitions, where M & N are integers.) In these embodiments, In an alternate embodiment, when the number of guest VM (User OS) 308a-308b is less than or equal to the number of physical RPMB partitions or units 303a-303n, then each guest VM (User OS) 308a or 308b can have its own dedicated physical RPMB partitions/units 303a, 303b, ... or 303n. Thus, for these embodiments, the dedicated physical rKeys (or RPMB key #l/#2 ... ) may be used for authentication between guest VM (User OS) 308a or 308b and physical storage devices 303. In these embodiments, the SOS (Services OS) 302 doesn’t have to implement RPMB virtualization (described earlier with reference to Figure 2). For data encryption, just like RPMB virtualization embodiment aforementioned, the per-guest eKey can be dedicated for each guest VM to ensure the data confidentiality protection. (Note that, unlike the RPMB virtualization of Figure 2, there is no need to split each RPBM partition unit 303a, 303n ... 303n into “RPBM BLOCKS”).

Additionally, in some embodiments, a“Multiplex and filter services” module 320 may be provided to forward/filter RPMB data frame from User OS (UOS) 308a or 308b to the physical RPMB driver/device 322 (and back forth). This may increase operational efficiency, since each virtual guest VM / UserOS 308a and 308b doesn’t have directly physical RPMB device access.

In embodiments, the general purpose processor (such as Intel X86) virtualization environment 100, 200, 300 of Figures 1-3 may be a virtualization environment in a client computing device, an edge computing device (near the edge of a network), a fog networking device (to provide near end fog computing to client devices), a hybrid edge/fog device, or a cloud server. In particular, an example client computing device may be an on-board computing device in a computer-assisted or autonomous driving vehicle. Further, the client, edge, fog networking or cloud computing device may be any one of such devices in the various computing systems and frameworks described with references to the remaining figures.

Figure 4 illustrates a computing device 400 including a computing platform 410, a hypervisor 405 managing a service VM, e.g., a VM 407 and one or more composite user VMs, e.g., a VM 408, aVM 406, a VM 409, under multiple levels of security protections, in accordance with some embodiments. Figure 5 illustrates a process performed by a hypervisor, e.g., the hypervisor 405, to manage various VMs under multiple levels of security protections. Figure 6 illustrates a process performed by a service VM, e.g., the VM 407, to manage a storage device under multiple levels of security protections. Figure 7 illustrates a process performed by a user VM, e.g., the VM 408, to support multiple operating systems to operate applications in execution environments with multiple levels of security protections.

In embodiments, the computing platform 410 of computing device 400 includes one or more processors 401, a memory device 402 coupled to the one or more processors 401, and a storage device 403 coupled to the one or more processors 401. The memory device 402 includes a first set of memory pages 421 and a second set of memory pages 422. The computing platform 410 may further include other storage devices or functional devices, e.g., a functional device 441, and a functional device 442.

The storage device 403 may include a volatile memory device, a non-volatile memory device, a semi-volatile memory, a secondary storage device, universal flash storage (UFS), eMMC, non-volatile memory express (NVMe), solid-state drive (SSD), Intel® Optane™ memory, trusted platform module (TPM) NV, Intel® Converged Security and Management Engine (CSME) NV, a replay protected memory block (RPMB), or a unit of RPMB. The storage device 403 includes one or more secure storage blocks, e.g., a secure storage block 431, a secure storage block 432. The storage device 403 may also include some unsecure storage blocks, e.g., an unsecure storage block 433. The terms“secure” and “unsecure” may refer to relative security protection levels. A secure storage block or a secure operation may have a first level security protection, while an unsecure storage block or an unsecure operation may have a second level security protections, where the second level security protection may have more security protections than the first level security protections. In some other embodiments, it may be possible that the first level security protection may have more security protections than the second level security protections.

In embodiments, the computing platform 410 hosts the hypervisor 405, operated on the one or more processors 401, to manage various VMs, e.g., the Service VM 407, the User VM 408, the user VM 406, and the User VM 409. The hypervisor 405 includes one or more virtual processors, e.g., a first virtual processor 451, a second virtual processor 452, and a scheduler 453. In addition, the hypervisor 405 may include memory page tables, e.g., a memory page table 454, a memory page table 455. In some embodiments, the hypervisor 405 may provide various security keys and perform various key management functions for the VMs. For example, the hypervisor 405 may provide an authentication key 456 and an encryption key 457.

In embodiments, the VM 408 is a composite user VM, similar to User VM 102 of Figure 1 and/or User VM 208 of Figure 2, and includes a first operating system 482 and a second operating system 485. In detail, like User VM 102 of Figure 1, the first operating system 482 is to operate a first set of applications 483 with the first set of memory pages 421 in a first execution environment 481 having a first level of security protection. In addition, the second operating system 485 to is to operate a second set of applications 486 with the second set of memory pages 422 in a second execution environment 484 having a second level of security protection. The second level of security protections may be different from the first level of security protection. For example, the second level of security protection may be secured or trusted, while the first level of security protection may be unsecured or untrusted. Moreover, the first operating system 482 is to operate at least on the first virtual processor 451, while the second operating system 485 is to operate at least on the second virtual processor 452. Execution of operations performed by the first operating system 482 and operations performed by the second operating system 485 may be switched by the scheduler 453 of the hypervisor 405, to be operated on the first virtual processor 451 and the second virtual processor 452.

In some other embodiments, the VM 408 may include more than one operating systems, or just one operating system. For example, the VM 406 includes only one operating system 462 to operate a set of applications 463. The VM 409 may be similar to the VM 408 to include multiple operating systems, or the VM 406 including only one operating system.

In embodiments, the VM 407, which may be a service VM similar to Service VM 101 of Figure 1 and/or Service VM 202 of Figure 2, may perform functions related to the management of the storage device 403 and other VMs accessing the storage device 403. For example, the VM 407 may store an authentication key 471 for authenticating various VMs, or an encryption key 472 to provide secure protections of the storage device, e.g., the secure storage block 431. In detail, the VM 407 may partition the storage device 403 into one or more secure storage blocks that includes the secure storage block 431 and the secure storage block 432, and the unsecure storage block 433. The secure storage block 431 and the secure storage block 432 may be accessed by the VM 408 after the VM 408 has been authenticated by the VM 407. For example, the VM 407 may authenticate, based on the authentication key 471 stored in the VM 407, the VM 408, and further grant the VM 408 access to the secure storage block 431 of the storage device 403, after the VM 407 has successfully authenticated the VM 408 based on the authentication key. In detail, the VM 407 may authenticate the VM 408 based on a guest authentication key 487 stored in a secure memory page associated with the VM 408, wherein the guest authentication key 487 may be store in a secure memory page of the second set of memory pages 422. The VM 408 may store a local copy of the guest authentication key 487 as well. In addition, the VM 408 may access the secure storage block 431 through an encryption key 488.

In embodiments, the hypervisor 405 may be an example of the hypervisor 116 shown in Figure 1, the hypervisor 210 shown in Figure 2, or the hypervisor 310 shown in Figure 3. The VM 407 is a service VM, which may be an example of the service VM 101, the service OS (SOS) 202 or the SOS 302. The VM 408 is a user VM, which may be an example of the User OS 102, the User OS 208, the guest VMs 308a, or 308b. The storage device 403 may be an example of the NVMe storage device 204, or the physical storage devices 303. The first virtual processor 451 or the second virtual processor 452 may be examples of the vCPU 118. The first execution environment 481 and the second execution environment 484 may be examples of the normal (untrusted or unsecured) world 104 and the trusted (secure) world 106, respectively. The secure storage block 431 and the secure storage block 432 may be examples of the RPMB blocks 206. The authentication key 471, the authentication key 487, the authentication key 456 may be examples of the VrKey shown in Figure 2, or the RPMB key shown in Figure 3. Furthermore, the encryption key 488, the encryption key 472, the encryption key 457, may be examples of the rKey shown in Figure 2, or the Encryption key shown in Figure 3.

Figure 5 illustrates an example process 500 performed by a hypervisor, e.g., the hypervisor 405, to manage various VMs, e.g., the VM 407, the VM 408, the VM 406, or the VM 409, under multiple levels of security protections, e.g., secured or unsecured, or trusted or untrusted. For example, the hypervisor 405 may manage the operations of the VM 408, where the VM 408 includes the first operating system 482 to operate the first set of applications 483 in the first execution environment 481 having a first level of security protection, and the second operating system 485 to operate the second set of applications 486 in the second execution environment 484 having a second level of security protection.

The process 500 may start at an interaction 501. During the interaction 501, the hypervisor manages operations of a first set of applications of a first operating system of a VM, on at least a first virtual processor of the hypervisor with a first set of memory pages. For example, the hypervisor 405 manages operations of the first set of applications 483 of the first operating system 482 of the VM 408, on at least a first virtual processor 451 of the hypervisor 405 with the first set of memory pages 421.

During an interaction 503, the hypervisor manages operations of a second set of applications of a second operating system of the VM, on at least a second virtual processor of the hypervisor with a second set of memory pages separated from the first set of memory pages. For example, the hypervisor 405 manages operations of the second set of applications 486 of the second operating system 485 of the VM 408, on at least the second virtual processor 452 of the hypervisor 405 with the second set of memory pages 422. The second set of memory pages 422 are separated from the first set of memory pages 421.

During an interaction 505, the hypervisor schedules alternate execution of the operations of the first set of applications and the first operating system, and execution of the operations of the second set of applications and the second operating system, respectively on the first virtual processor and the second virtual processor. For example, at the interaction 505, the hypervisor 405, or more specifically, the scheduler 453, schedules alternate execution of the operations of the first set of applications 483 and the first operating system 482, and execution of the operations of the second set of applications 486 and the second operating system 485, respectively on the first virtual processor 451 and the second virtual processor 452.

In more details, at the interaction 505, the hypervisor 405, or more specifically, the scheduler 453, may switch from a first operational context 423 stored in the first set of memory pages 421 to a second operational context 424 stored in the second set of memory pages 422. The first operational context 423 may be stored in the first set of memory pages 421 by the hypervisor 405, while the second operational context 424 may be stored in the second set of memory pages 422 by the hypervisor 405.

In embodiments, the interaction 505, e.g., scheduling alternate execution of the operations may happen in various situations. For example, the hypervisor 405, or more specifically, the scheduler 453, may schedule execution quanta by assigning a first portion of time or resources for operations of the first set of applications or the first operating system, and assigning a second portion of time or resources for operations of the second set of applications or the second operating system. The hypervisor 405, or the scheduler 453, may schedule execution in many other ways. For example, the first portion of time or resources may not be the same length or amount as the second portion of time or resources. The first portion of time or resources may be shared by operations of the first set of applications operating on the first operating system, and the second portion of time or resources may be shared by operations of the second set of applications operating on the second operating system. There may be further scheduling within the first set of applications operating on the first operating system to share the first portion of time or resources. The scheduling of alternate execution may be predefined with approximately equal time intervals, or with different time intervals, or adjusted dynamically. In some other embodiments, the hypervisor 405, or more specifically, the scheduler 453, may switch execution of the first set of applications or the first operating system to execution of the second set of applications or the second operating system when operations of the first set of applications of the first operating system are blocked by tasks to be performed by the second set of applications or the second operating systems. In some other embodiments, the hypervisor 405, or more specifically, the scheduler 453, may switch execution from the first set of applications of the first operating system to execution of the second set of applications of the second operating system when there is a service request from execution of the first set of applications or the first operating system for one or more operations to be performed by the second set of applications or the second operating system.

In embodiments, the hypervisor may manage operations of multiple VMs. During an interaction 507, the hypervisor may manage operation of a second user VM, on at least a third virtual processor of the hypervisor, where the second user VM includes only a third operating system. For example, at the interaction 507, the hypervisor 405 may manage operation of the VM 406, on at least a third virtual processor of the hypervisor, not shown. The VM 406 includes only one operating system, e.g., a third operating system.

In embodiments, the process 500 may include other operations and interactions. For example, the hypervisor 405 may manage, with a first memory page table, accesses by applications of the first operating system, to a first storage device or a first functional device, e.g., the functional device 441; and manage, with a second memory page table, accesses by applications of the second operating system, to a second storage device or a second functional device, e.g., the functional device 442. The second storage device or the second functional device is only visible or accessible by the second operating system in the second execution environment with the second level of security protection. On the other hand, the first storage device or the first functional device is visible or accessible to both the first operating system and the second operating system.

Figure 6 illustrates an example process 600 performed by a service VM, e.g., the VM 407, to manage a storage device, e.g., the storage device 403 having the secure storage block 431, under multiple levels of security protections, e.g., secured or unsecured, or trusted or untrusted, in accordance with some embodiments. For example, the VM 407 may work with the hypervisor 405 to manage the storage device 403, and the VM 408 for accessing the storage device 403. The VM 408 includes the first operating system 482 to operate the first set of applications 483 in the first execution environment 481 having a first level of security protection, and the second operating system 485 to operate the second set of applications 486 in the second execution environment 484 having a second level of security protection.

The process 600 may start at an interaction 601. During the interaction 601, a first VM may authenticate, based on an authentication key stored in the first VM, a second VM of the computing device, where execution of the first VM and the second VM are managed by a hypervisor of the computing device, and where the computing device includes a storage device having a secure storage block. For example, the VM 407 may authenticate the VM 408, both managed by the hypervisor 405, based on the authentication key 471 stored in the VM 407.

In embodiments, the VM 407 may authenticate the VM 408 based on receiving a copy of a guest authentication key from a secure memory page associated with the VM 408. For example, the VM 407 may receive a copy of the authentication key 487 from a secure memory page associated with the VM 408, and authenticate the VM 408 based on the received copy of the authentication key 487. The VM 407 may authenticate the VM 408 by comparing the authentication key 471 stored in the VM 407 with the received copy of the authentication key 487. In some embodiments, the authentication key 487, or the authentication key 471 may be provided by the hypervisor 405 based on an authentication key 456 determined by the hypervisor 405.

During an interaction 603, the first VM grants the second VM access to the secure storage block of the storage device, after the first VM has successfully authenticated the second VM based on the authentication key. For example, the VM 407 grants the VM 408 access to the secure storage block 431 of the storage device 403, after the VM 407 has successfully authenticated the VM 408 based on the authentication key 471.

In embodiments, the first VM may grant the access to the secure storage block by providing a copy of an encryption key to the second VM to access the secure storage block that is encrypted by the encryption key. For example, the VM 407 may grant the access to the secure storage block 431 by providing a copy of the encryption key 472 to the VM 408 to access the secure storage block 431 that is encrypted by the encryption key 472. The VM 408 may save the received copy of the encryption key 472 to be the encryption key 488. The VM 408 may fetch the content of the secure storage block 431 that may be encrypted for security protections, and decrypt the fetched content using the encryption key 488.

Additionally and alternatively, the hypervisor 405 may use the encryption key 457 to decrypt the secure storage block that is encrypted by the encryption key, for the VM 408. Still in some other embodiments, the VM 407 may provide the decrypted secure storage block to the VM 408. Many implementation options may be available for the VM 407 to gain access to the secure storage block 431 after being authenticated by the VM 407.

During an interaction 605, the first VM may receive the authentication key from the hypervisor to be stored in the first VM and to be used in authenticating the second VM. For example, the VM 407 may receive the authentication key 471 from the hypervisor 405 to be stored in the VM 407 and to be used in authenticating the VM 408.

During an interaction 607, the first VM may partition the storage device without replay protected memory blocks into a series of RPMBs. For example, the VM 407 may partition the storage device 403 without replay protected memory blocks into a series of RPMBs, e.g., the secure storage block 431, and the secure storage block 432.

During an interaction 609, the first VM may assign one RPMB of the series of RPMBs to be accessed by the second VM as the secure storage block. For example, the VM 407 may assign one RPMB of the series of RPMBs to be accessed by the VM 408 as the secure storage block 431. The VM 407 may assign a secure storage block, e.g., the secure storage block 432, to a third VM, e.g., the VM 409 managed by the hypervisor 405. The VM 407 may authenticate, based on another authentication key stored in the VM 407, and grant the VM 409 access to the secure storage block 432, after the VM 407 has successfully authenticated the VM 409 based on the another authentication key.

Figure 7 illustrates an example process 700 performed by a user VM, e.g., the VM 408, to support multiple operating systems to operate applications in execution environments with multiple levels of security protections, in accordance with some embodiments. The VM 408 includes the first operating system 482 to operate the first set of applications 483 in the first execution environment 481 having a first level of security protection, and the second operating system 485 to operate the second set of applications 486 in the second execution environment 484 having a second level of security protection.

The process 700 may start at an interaction 701. During the interaction 701, the first VM may provide an authentication key stored in a secure memory page associated with the first VM to a second VM for authenticating the first VM by the second VM. For example, the VM 408 may provide the authentication key 487, which may be stored in a secure memory page associated with the VM 408, to the VM 407 for authenticating the VM 408 by the VM 407.

During an interaction 703, the first VM may gain access to a secure storage block of a storage device of the computing device, after the first VM has successfully been authenticated by the second VM based on the authentication key. For example, the VM 408 may gain access to the secure storage block 431 of the storage device 403, after the VM 408 has successfully been authenticated by the VM 407 based on the authentication key 487.

Figure 8 illustrates a software component view of an in-vehicle system (IVS) of a computer assisted/autonomous driving (CA/AD) vehicle, according to various embodiments. As shown, for the embodiments, IVS system 800, which could be the virtualization environment 100, the virtualization environment 200, or the virtualization environment 300, or the computing device 400, includes hardware 802 and software 810. Software 810 includes hypervisor 812 hosting a number of virtual machines (VMs) 822 - 828. Hypervisor 812 is configured to host execution of VMs 822-828. The hypervisor 812 may be similar to the hypervisor 116, the hypervisor 210, the hypervisor 310, or the hypervisor 405. The VMs 822-828 include a service VM 822 and a number of user VMs 824-828. Service machine 822 includes a service VM, e.g., the service VM 101, the service OS (SOS) 202, the SOS 302, the VM 407, to manage a storage device under multiple levels of security protections. The user VMs 824-828 may include user VMs similar to the User OS 102, the User OS 208, the guest VMs 308a, or 308b, or the VM 408 to support multiple operating systems to operate applications in execution environments with multiple levels of security protections.

Elements 812-838 of software 810 may be built based on any one of a number of these elements known in the art. For example, hypervisor 812 may be built based on any one of a number of hypervisors known in the art, such as KVM, an open source hypervisor, Xen, available from Citrix Inc, of Fort Lauderdale, FL., or VMware, available from VMware Inc of Palo Alto, CA, and so forth. Similarly, service OS of service VM 822 and user OS of user VMs 824-828 may be built on any one of a number of OS known in the art, such as Linux, available e.g., from Red Hat Enterprise of Raleigh, NC, or Android, available from Google of Mountain View, CA. However, none of those known hypervisors currently have the functions of the hypervisors, e.g., the hypervisor 812, the hypervisor 116, the hypervisor 210, the hypervisor 310, or the hypervisor 405.

Figure 9 illustrates a hardware component view of a computer platform, suitable for use as an in-vehicle system or a cloud server, according to various embodiments. As shown, computing platform 900, which may be hardware 802 of Figure 8, or the computing device 400, include one or more system-on-chips (SoCs) 902, ROM 903 and system memory 904. Each SoCs 902 may include one or more processor cores (CPUs), one or more graphics processor units (GPUs), one or more accelerators, such as computer vision (CV) and/or deep learning (DL) accelerators. ROM 903 may include basic input/output system services (BIOS) 905. CPUs, GPUs, and CV/DL accelerators may be any one of a number of these elements known in the art. Similarly, ROM 903 and BIOS 905 may be any one of a number of ROM and BIOS known in the art, and system memory 904 may be any one of a number of volatile storage devices known in the art.

Additionally, computing platform 900 may include persistent storage devices 906. Example of persistent storage devices 906 may include, but are not limited to, flash drives, hard drives, compact disc read-only memory (CD-ROM) and so forth. Further, computing platform 900 may include one or more input/output (I/O) interfaces 908 to interface with one or more I/O devices, such as sensors 920. Other example I/O devices may include, but are not limited to, display, keyboard, cursor control and so forth. Computing platform 900 may also include one or more communication interfaces 910 (such as network interface cards, modems and so forth). Communication devices may include any number of communication and I/O devices known in the art. Examples of communication devices may include, but are not limited to, networking interfaces for Bluetooth®, Near Field Communication (NFC), WiFi, Cellular communication (such as LTE 4G/5G) and so forth. The elements may be coupled to each other via system bus 911, which may represent one or more buses. In the case of multiple buses, they may be bridged by one or more bus bridges (not shown).

Each of these elements may perform its conventional functions known in the art. In particular, ROM 903 may include BIOS 905 having a boot loader. System memory 904 and mass storage devices 906 may be employed to store a working copy and a permanent copy of the programming instructions implementing the operations associated with hypervisor 812, service/user OS of service/user VM 822-828, collectively referred to as computational logic 922. For example, the computational logic 922 may include functions of the hypervisor 812, the hypervisor 116, the hypervisor 210, the hypervisor 310, the hypervisor 405, the service VM 101, the service OS (SOS) 202, the SOS 302, the VM 407. The various elements may be implemented by assembler instructions supported by processor core(s) of SoCs 902 or high-level languages, such as, for example, C, that can be compiled into such instructions.

As will be appreciated by one skilled in the art, the present disclosure may be embodied as methods or computer program products. Accordingly, the present disclosure, in addition to being embodied in hardware as earlier described, may take the form of an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to as a“circuit,”“module” or“system.” Furthermore, the present disclosure may take the form of a computer program product embodied in any tangible or non-transitory medium of expression having computer-usable program code embodied in the medium. Figure 10 illustrates an example computer-readable non-transitory storage medium that may be suitable for use to store instructions that cause an apparatus, in response to execution of the instructions by the apparatus, to practice selected aspects of the present disclosure described with references to Figures 1-7. As shown, non-transitory computer-readable storage medium 1002 may include a number of programming instructions 1004. Programming instructions 1004 may be configured to enable a device, e.g., computing platform 1000, in response to execution of the programming instructions, to implement (aspects of) hypervisor 812, service/user OS of service/user VM 822-828, the hypervisor 116, the hypervisor 210, the hypervisor 310, the hypervisor 405, the service VM 101, the service OS (SOS) 202, the SOS 302, the VM 407. In alternate embodiments, programming instructions 1004 may be disposed on multiple computer-readable non-transitory storage media 1002 instead. In still other embodiments, programming instructions 1004 may be disposed on computer-readable transitory storage media 1002, such as, signals.

Any combination of one or more computer usable or computer readable medium(s) may be utilized. The computer-usable or computer-readable medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non- exhaustive list) of the computer-readable medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a transmission media such as those supporting the Internet or an intranet, or a magnetic storage device. Note that the computer- usable or computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer- usable medium may include a propagated data signal with the computer-usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc.

Computer program code for carrying out operations of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the“C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user’s computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user’s computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

The present disclosure is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used herein, the singular forms “a,”“an” and“the” are intended to include plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specific the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operation, elements, components, and/or groups thereof.

Embodiments may be implemented as a computer process, a computing system or as an article of manufacture such as a computer program product of computer readable media. The computer program product may be a computer storage medium readable by a computer system and encoding computer program instructions for executing a computer process.

The corresponding structures, material, acts, and equivalents of all means or steps plus function elements in the claims below are intended to include any structure, material or act for performing the function in combination with other claimed elements are specifically claimed. The description of the present disclosure has been presented for purposes of illustration and descriptions, but is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill without departing from the scope and spirit of the disclosure. The embodiment was chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure for embodiments with various modifications as are suited to the particular use contemplated.

Thus various example embodiments of the present disclosure have been described including, but are not limited to:

EXAMPLES

Example 1 may include a computer system, comprising a hypervisor having a plurality of vCPU, and a plurality of EPT to facilitate hosting of a virtual machine (VM) implementing an embedded control unit (ECU), the VM having an unsecured world and a secured world, the secured world being isolated from the unsecured world.

Example 2 may include the computer system of example 1 and/or some other examples herein, wherein the plurality of EPT comprises two EPT to manage two sets of memory pages, one set each for the unsecured world and the secured world, to isolate the secured world from the unsecured world.

Example 3 may include a computer system, comprising a hypervisor configured to manage a service machine and a plurality of virtual machines (VMs); wherein the hypervisor is configured to partition an NVMe storage device into a series of RPMB blocks (Blk#0, ... Blk#n), where each partition is assigned to one of the plurality of VMs; and wherein the service mahcine maintains a device module structure containing the NVMe block assignment(s) to the VMs.

Example 4 may include the computer system of example 3 and/or some other examples herein, wherein the hypervisor is configured to encrypt the RPMB blocks with one or more encryption keys (rkey).

Example 5 may include the computer system of example 4 and/or some other examples herein, wherein the hypervisor is configured to generate and use a different rKey is used to encrypt each RPMB block.

Example 6 may include the computer system of example 4 and/or some other examples herein, wherein usage of the rKey of a RPMB assigned to a VM by the service machinee is authorized by the VM, and the service machine uses the rkey to authenticate and protect a communication channel between the service machine and the VM. Example 7 may include at least one computer readable medium (CRM) having instructions stored therein to implement a hypervisor on a computer system, in response to execution of the instructions by the computer system, to facilitate hosting of a virtual machine (VM) implementing an embedded control unit (ECU), wherein the hypervisor having a plurality of vCPU, and a plurality of EPT, and wherein the VM has an unsecured world and a secured world, the secured world being isolated from the unsecured world.

Example 8 may include the CRM of example 7 and/or some other examples herein, wherein the plurality of EPT comprises two EPT to manage two sets of memory pages, one set each for the unsecured world and the secured world, to isolate the secured world from the unsecured world.

Example 9 may include at least one computer readable medium (CRM) having instructions stored therein to implement a hypervisor on a computer system, in response to execution of the instructions by the computer system, to manage a service machine and a plurality of virtual machines (VMs); wherein the hypervisor is configured to partition an NVMe storage device into a series of RPMB blocks (Blk#0, ... Blk#n), where each partition is assigned to one of the plurality of VMs; and wherein the service mahcine maintains a device module structure containing the NVMe block assignment(s) to the VMs.

Example 10 may include the CRM of example 9 and/or some other examples herein, wherein the hypervisor is to encrypt the RPMB blocks with one or more encryption keys (rkey).

Example 11 may include the CRM of example 10 and/or some other examples herein, wherein the hypervisor is to generate and use a different rKey is used to encrypt each RPMB block.

Example 12 may include the CRM of example 10 and/or some other examples herein, wherein usage of the rKey of a RPMB assigned to a VM by the service machine is authorized by the VM, and the service machine uses the rkey to authenticate and protect a communication channel between the service machine and the VM.

Example 13 may include a method for computing, comprising: managing, by a hypervisor of a computing device, on at least a first virtual processor of the hypervisor with a first set of memory pages, operations of a first set of applications of a first operating system of a virtual machine (VM); managing, by the hypervisor, on at least a second virtual processor of the hypervisor with a second set of memory pages separated from the first set of memory pages, operations of a second set of applications of a second operating system of the VM, wherein the VM includes the first operating system to operate the first set of applications in a first execution environment having a first level of security protection, and the second operating system to operate the second set of applications in a second execution environment having a second level of security protection; and scheduling, by the hypervisor, alternate execution of the operations of the first set of applications and the first operating system, and execution of the operations of the second set of applications and the second operating system, respectively on the first virtual processor and the second virtual processor.

Example 14 may include the method of example 13 and/or some other examples herein, further comprising: storing a first operational context for the operations of the first set of applications and the first operating system in the first set of memory pages; and storing a second operational context for the operations of the second set of applications and the second operating system in the second set of memory pages; and wherein the scheduling of execution of the operations includes switching from the first operational context stored in the first set of memory pages to the second operational context stored in the second set of memory pages.

Example 15 may include the method of example 13 and/or some other examples herein, further comprising: managing, by the hypervisor with a first memory page table, accesses by applications of the first operating system, to a first storage device or a first functional device; and managing, by the hypervisor with a second memory page table, accesses by applications of the second operating system, to a second storage device or a second functional device, wherein the second storage device or the second functional device is only visible or accessible by the second operating system in the second execution environment with the second level of security protection, and wherein the first storage device or the first functional device is visible or accessible to both the first operating system and the second operating system.

Example 16 may include the method of example 13 and/or some other examples herein, wherein the scheduling of execution includes scheduling execution quanta by assigning a first portion of time or resources for operations of the first set of applications or the first operating system, and assigning a second portion of time or resources for operations of the second set of applications or the second operating system.

Example 17 may include the method of example 13 and/or some other examples herein, wherein the scheduling of execution includes switching execution of the first set of applications or the first operating system to execution of the second set of applications or the second operating system when operations of the first set of applications of the first operating system are blocked by tasks to be performed by the second set of applications or the second operating systems.

Example 18 may include the method of example 13 and/or some other examples herein, wherein the scheduling of execution includes switching execution from the first set of applications of the first operating system to execution of the second set of applications of the second operating system when there is a service request from execution of the first set of applications or the first operating system for one or more operations to be performed by the second set of applications or the second operating system.

Example 19 may include the method of example 13 and/or some other examples herein, wherein the VM is a first user VM, and the method further includes: managing, by the hypervisor, operation of a second user VM, on at least a third virtual processor of the hypervisor, wherein the second user VM includes only a third operating system.

Example 20 may include a method for computing, comprising: authenticating, by a first virtual machine (VM) of a computing device, based on an authentication key stored in the first VM, a second VM of the computing device, wherein execution of the first VM and the second VM are managed by a hypervisor of the computing device, and wherein the computing device includes a storage device having a secure storage block, and wherein the second VM includes a first operating system to operate a first set of applications with a first set of memory pages in a first execution environment with a first level of security protection, and a second operating system to operate a second set of applications with a second set of memory pages in a second execution environment with a second level of security protection, the second set of memory pages being separated from the first set of memory pages; and granting the second VM, by the first VM, access to the secure storage block of the storage device, after the first VM has successfully authenticated the second VM based on the authentication key.

Example 21 may include the method of example 20 and/or some other examples herein, wherein authenticating the second VM includes receiving a copy of a guest authentication key from a secure memory page associated with the second VM, wherein the second VM includes a first operating system to operate a first set of applications with a first set of memory pages in a first execution environment with a first level of security protection, and a second operating system to operate a second set of applications with a second set of memory pages in a second execution environment with a second level of security protection, the second set of memory pages being separated from the first set of memory pages, and wherein the guest authentication key is stored in the secure memory page, which is one of the second set of memory pages.

Example 22 may include the method of example 21 and/or some other examples herein, wherein receiving the copy of the guest authentication key from the secure memory page associated with the second VM includes receiving the copy of the guest authentication key from the secure memory page associated with the second VM on provision of the guest authentication key by the hypervisor to the second VM.

Example 23 may include the method of example 21 and/or some other examples herein, wherein authenticating the second VM includes comparing the authentication key stored in the first VM with the copy of the guest authentication key received from the secure memory page associated with the second VM.

Example 24 may include the method of example 20 and/or some other examples herein, further comprising: receiving the authentication key from the hypervisor to be stored in the first VM and to be used in authenticating the second VM.

Example 25 may include the method of example 20 and/or some other examples herein, wherein granting the access to the secure storage block includes providing a copy of an encryption key to the second VM to access the secure storage block that is encrypted by the encryption key.

Example 26 may include the method of example 20 and/or some other examples herein, wherein granting the access to the secure storage block includes providing a copy of an encryption key to the hypervisor to decrypt the secure storage block that is encrypted by the encryption key, for the second VM.

Example 27 may include the method of example 26 and/or some other examples herein, further comprising providing, by the first VM, the decrypted secure storage block to the second VM; and wherein the first VM is a service VM, and the second VM is a user VM.

Example 28 may include the method of example 20 and/or some other examples herein, wherein granting the second VM access to the secure storage block of the storage device includes granting the second VM access to the secure storage block of a volatile memory device, a non-volatile memory device, a semi-volatile memory, a secondary storage device, universal flash storage (UFS), enhanced memory management controller (eMMC), non-volatile memory express (NVMe), solid-state drive (SSD),

Intel® Optane™ memory, trusted platform module (TPM) NV, Intel® Converged Security and Management Engine (CSME) NV, a replay protected memory block

(RPMB), or a unit of RPMB.

Example 29 may include the method of example 28 and/or some other examples herein, further comprising: partitioning the storage device without replay protected memory blocks (RPMB) into a series of RPMBs, and assigning one RPMB of the series of RPMBs to be accessed by the second VM as the secure storage block.

Example 30 may include the method of example 28 and/or some other examples herein, wherein the authentication key is a first authentication key, the secure storage block is a first secure storage block, and the storage device further includes a number of secure storage blocks, a second secure storage block of the number of secure storage blocks being assigned to a third VM managed by the hypervisor; and the method further comprises: authenticating, by the first VM, the third VM, based on a second authentication key stored in the first VM; and granting, by the first VM, the third VM access to the second secure storage block, after the first VM has successfully authenticated the third VM based on the second authentication key.

Example 31 may include a method for computing, comprising: providing, by a first virtual machine (VM) to be operated by a hypervisor of a computing device, an authentication key stored in a secure memory page associated with the first VM to a second VM for authenticating the first VM by the second VM, wherein the first VM includes a first operating system to operate a first set of applications with a first set of memory pages in a first execution environment with a first level of security protection, and a second operating system to operate a second set of applications with a second set of memory pages in a second execution environment with a second level of security protection, the second set of memory pages being separated from the first set of memory pages, and wherein the authentication key is stored in the secure memory page, which is one of the second set of memory pages; and gaining access to a secure storage block of a storage device of the computing device, after the first VM has successfully been authenticated by the second VM based on the authentication key.

Example 32 may include the method of example 31 and/or some other examples herein, wherein the gaining access to the secure storage block includes receiving a copy of an encryption key from the second VM to access the secure storage block that is encrypted by the encryption key.

Example 33 may include the method of example 31 and/or some other examples herein, wherein the secure memory page storing the authentication key is not accessible by the first set of applications of the first operating system operating in the first execution environment.

Example 34 may include a computer readable media (CRM) comprising a plurality of instructions arranged to cause one or more processors of a computing platform, in response to execution of the plurality of instructions, to perform any operations of the methods of any one of examples 1-33.

Example 35 may include a computing platform, comprising: one or more processors; a storage device coupled to the one or more processors, and having a secure storage block; a hypervisor arranged to operate on the one or more processors; a first virtual machine (VM) and a second VM managed by the hypervisor; wherein the first VM is configured to: authenticate, based on an authentication key stored in the first VM and a guest authentication key stored in a secure memory page associated with the second VM, the second VM, wherein the second VM includes a first operating system to operate a first set of applications with a first set of memory pages in a first execution environment having a first level of security protection, and a second operating system to operate a second set of applications with a second set of memory pages in a second execution environment having a second level of security protection, and wherein the guest authentication key is stored in the secure memory page included in the second set of memory pages; and grant the second VM access to the secure storage block of the storage device, after the first VM has successfully authenticated the second VM based on the authentication key.

Example 36 may include the computing platform of example 35 and/or some other examples herein, wherein the hypervisor includes a first virtual processor, a second virtual processor, and a scheduler, and wherein the first operating system of the second VM is to operate at least on the first virtual processor, the second operating system of the second VM is to operate at least on the second virtual processor, and the scheduler of the hypervisor is to switch execution of the second VM between the first and second virtual processors for operations performed by the first operating system and operations performed by the second operating system.

Example 37 may include the computing platform of example 34 and/or some other examples herein, wherein the first VM is a service VM, the second VM is a user VM, and the first VM is further configured to: partition the storage device into one or more secure storage blocks that includes the secure storage block to be granted access to the second VM, wherein the storage device includes a volatile memory device, a non-volatile memory device, a semi-volatile memory, a secondary storage device, universal flash storage (UFS), enhanced memory management controller (eMMC), non-volatile memory express (NVMe), solid-state drive (SSD), Intel® Optane™ memory, trusted platform module (TPM) NV, Intel® Converged Security and Management Engine (CSME) NV, a replay protected memory block (RPMB), or a unit of RPMB.