Arbitrary target callback enabling between trusted execution environment and virtual machine

Abstract

Systems and techniques are provided for providing access to one or more execution environments. For example, a method can include receiving a listening call from a first virtual machine (VM); and registering a listener call context of the first VM with a callback service of a trusted execution environment (TEE). A return code indicating that no callback request is available causes the first VM to put the listener call context into hibernation. A call from the second VM proposes a service request for a VM service of the first VM. The wake-up return code to the second VM wakes up the listener call context of the first VM. A callback request sent to a VM service of the first VM corresponds to a service request proposed by the second VM. A response call received from the VM service of the first VM indicates a callback response to the callback request.

Description

TECHNICAL FIELD

[0001] The present disclosure relates generally to security protocols and devices. For example, aspects of the present disclosure relate to arbitrary target callback enablement between a trusted execution environment and a virtual machine. BACKGROUND

[0002] Modern software systems are often split into multiple modules / components, each having a different level of privilege or access to resources of a computing device (e.g., system resources, processor resources, memory resources, etc.). An example of such a split is between an operating system (OS) kernel and user applications, where user applications are given a more limited level of access to system resources compared to the OS kernel.

[0003] To facilitate similar splits on a chip-level, certain processors and computing architectures (e.g., ARM, RISC-V, Hexagonal DSP, etc.) include features that support hierarchical protection domains and / or implement different privilege levels. Such systems typically operate at only one privilege level at a time, and the privilege level (the “current privilege level”) can only change when the device processor takes an exception or returns from an exception. As a result, the privilege level is often referred to as an exception level (EL). These exception levels can be numbered (e.g., EL-0 to EL-3), such that a higher privilege level has a higher number. For example, software with the lowest privilege level (e.g., user applications, etc.) can operate at EL-0, while software with the highest privilege level (a system monitor, etc.) can operate at EL-3. SUMMARY

[0004] The following presents a simplified summary related to one or more aspects disclosed herein. Thus, the following summary should not be considered an extensive overview relating to all contemplated aspects, nor should the following summary be considered to identify key or critical elements relating to all contemplated aspects or to delineate the scope associated with any particular aspect. Accordingly, the following summary is merely presented in a simplified form to present some concepts relating to one or more aspects disclosed herein before the detailed description is presented in the following.

[0005] Systems, methods, apparatuses, and computer-readable media for providing secure access in a trusted execution environment (TEE) are disclosed. According to at least one illustrative example, a method of providing access to one or more execution environments is provided. The method includes receiving a listen call from a first virtual machine (VM) of a plurality of VMs, wherein the listen call registers a listener call context of the first VM with a callback service of a trusted execution environment (TEE); returning a return code to the first VM indicating that no callback request is available for the first VM, wherein the return code causes the first VM to put the listener call context to sleep; receiving a call from a second VM of the plurality of VMs, wherein the call from the second VM makes a service request to a VM service of the first VM; returning a wake-up return code to the second VM configured to wake up the listener call context of the first VM; sending a callback request to the VM service of the first VM corresponding to the service request made by the second VM; and receiving a response call from the VM service of the first VM indicating a callback response to the callback request.

[0006] In another illustrative example, an apparatus for providing access to one or more execution environments is provided. The apparatus includes at least one memory and at least one processor coupled to the at least one memory and configured to: receive a listen call from a first virtual machine (VM) of a plurality of VMs, wherein the listen call registers a listener call context of the first VM with a callback service of a trusted execution environment (TEE); return a return code to the first VM indicating that no callback request is available for the first VM, wherein the return code causes the first VM to put the listener call context to sleep; receive a call from a second VM of the plurality of VMs, wherein the call from the second VM makes a service request to a VM service of the first VM; return a wake-up return code to the second VM configured to wake up the listener call context of the first VM; send a callback request to the VM service of the first VM corresponding to the service request made by the second VM; and receive a response call from the VM service of the first VM indicating a callback response to the callback request.

[0007] In another illustrative example, a non-transitory computer-readable storage medium includes instructions stored thereon that, when executed by at least one processor, cause the at least one processor to: receive, from a first virtual machine (VM) of a plurality of VMs, a listen call, wherein the listen call registers a listener call context of the first VM with a callback service of a trusted execution environment (TEE); return, to the first VM, a return code indicating that no callback request is available for the first VM, wherein the return code causes the first VM to put the listener call context to sleep; receive, from a second VM of the plurality of VMs, a call, wherein the call from the second VM makes a service request to a VM service of the first VM; return, to the second VM, a wake-up return code configured to wake up the listener call context of the first VM; send, to the VM service of the first VM, a callback request corresponding to the service request made by the second VM; and receive, from the VM service of the first VM, a response call indicating a callback response to the callback request.

[0008] In another illustrative example, an apparatus for providing access to one or more execution environments is provided. The apparatus includes means for receiving, from a first virtual machine (VM) of a plurality of VMs, a listen call, wherein the listen call registers a listener call context of the first VM with a callback service of a trusted execution environment (TEE); means for returning, to the first VM, a return code indicating that no callback request is available for the first VM, wherein the return code causes the first VM to put the listener call context to sleep; means for receiving, from a second VM of the plurality of VMs, a call, wherein the call from the second VM makes a service request to a VM service of the first VM; means for returning, to the second VM, a wake-up return code configured to wake up the listener call context of the first VM; means for sending, to the VM service of the first VM, a callback request corresponding to the service request made by the second VM; and means for receiving, from the VM service of the first VM, a response call indicating a callback response to the callback request.

[0009] Aspects generally include a method, apparatus, system, computer program product, non-transitory computer-readable medium, user equipment, user equipment, wireless communication device, and / or processing system as substantially described with reference to and as illustrated by the drawings and specification.

[0010] Some aspects include a device having a processor configured to perform one or more operations of any of the methods outlined above. Further aspects include a processing device for use in a device, the processing device configured with processor-executable instructions to perform operations of any of the methods outlined above. Further aspects include a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a device to perform operations of any of the methods outlined above. Further aspects include a device having means for performing the functions of any of the methods outlined above.

[0011] The foregoing has outlined rather broadly the features and technical advantages of examples according to the disclosure in order that the detailed description that follows can be better understood. Additional features and advantages will be described hereinafter. The disclosed concepts and specific examples can be readily utilized as bases upon which the other structures can be built employing the principles of this disclosure. Such equivalent constructions do not depart from the scope of the claims. The characteristics of the concepts disclosed herein, both organizational and methodological, together with the associated advantages will be better understood from the following description taken in connection with the accompanying drawings. Each of the figures is provided to illustrate and describe aspects of the disclosure, and is not intended to limit the claims. The foregoing summary, as well as other features and aspects of the present disclosure, will become better understood when read in conjunction with the accompanying drawings, wherein:

[0012] This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. The subject matter should be understood from the description and illustrative embodiments described herein, and from the entire scope of the following claims. BRIEF DESCRIPTION OF DRAWINGS

[0013] The accompanying drawings are presented to aid in the description of various aspects of the disclosure and are provided solely for illustration of the aspects and are not intended to limit the aspects. For a more thorough understanding of the above-described features of the present disclosure, reference should be made to the detailed description below in connection with the accompanying drawings, in which:

[0014] Figure 1A and Figure 1B is a block diagram illustrating examples of privilege or exception levels (ELs) in an example computing device according to some examples;

[0015] Figure 2is a block diagram illustrating an example of a VM call to wake up a previously dormant call from a different virtual machine (VM) according to some examples;

[0016] Figure 3 is a diagram illustrating an example of a secure monitor call (SMC) and SMC callback sent between a VM and a trusted execution environment (TEE) according to some examples;

[0017] Figure 4 is a diagram illustrating an example call flow for providing arbitrary target callback enablement according to some examples;

[0018] Figure 5 is a flow diagram illustrating an example of a process for providing secure data access according to some examples; and

[0019] Figure 6 is a block diagram illustrating an example of a computing system that can be employed by the disclosed systems and techniques according to some examples. DETAILED DESCRIPTION

[0020] For purposes of illustration, certain aspects of the disclosure are provided below. Alternate aspects can be devised without departing from the scope of the disclosure. Additionally, well-known elements of the disclosure, related to those described below, can not be described or will be omitted so as to not obscure the relevant details of the disclosure. Some aspects described herein can be independently applied, and others can be applied in combination. This will be apparent from the following description.

[0021] The following description provides examples of aspects only and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the following description of the aspects is provided as illustrative examples only. Various changes can be made without departing from the scope of the disclosure as set forth in the appended claims. It should be understood that the detailed description is exemplary and explanatory only and is not intended to be limiting or to unduly limit the scope of the present disclosure.

[0022] The term "computing device" is used herein to refer to any of a variety of computing devices, including smartphones, wireless or mobile computing devices (e.g., tablet computers, laptop computers, wearable devices, etc.), cellular-based wireless hotspots, IoT devices, eMTC devices, desktop computers, workstations, servers, embedded systems of electromechanical systems (e.g., vehicles, industrial and agricultural machinery, medical devices, control systems, etc.), and the like. Wireless communication devices are also commonly referred to as user equipment (UE), mobile devices, and cellular devices. Computing devices can receive and / or transmit communications via a variety of wired and / or wireless communication networks, including wide area networks (e.g., mobile communication networks), local area networks (e.g., Wi-Fi, Bluetooth, etc.), geopositioning networks (e.g., Global Positioning System ("GPS")), personal area networks (e.g., wireless USB, Bluetooth, ZigBee, etc.), near field communication, and the like.

[0023] The term "monitor" is used herein to refer to any hardware or software component that can support virtualization technology and / or implement abstraction (or virtualization) of computing resources, and operate across execution environments (e.g., across non-secure or rich / normal execution environments and trusted / secure execution environments, etc.). This is used herein as the highest privilege level execution environment. A monitor can include any or all of the following: a hardware monitor, specialized hardware fabricated on a chip, a virtual machine monitor (VMM), a monitor software running outside of a high-level operating system (HLOS), and software monitor running as part of a device driver, which can be outside of the HLOS, its memory management system, and / or its allocator functionality. In some aspects, an example of a monitor is a "secure monitor," which refers to software designed to cause a processor to securely transition between different security states of the processor (e.g., when supported, such as in ARM processors with TrustZone technology) in order to separate software running at lower privilege levels.

[0024] The term "hypervisor" is used herein to refer to any hardware or software component that supports virtualization technology and / or implements abstraction (or virtualization) of computing resources, and operates within an execution environment (e.g., within a rich / normal execution environment, etc.). A hypervisor can create and operate virtual machines (VMs) and / or host multiple operating systems (referred to as guest operating systems), and can act as a virtual machine manager. The hypervisor presents a virtual operating platform to the guest operating systems and manages the execution of the guest operating systems. Each guest operating system can interact with the virtual operating platform as if it were operating on physical hardware. This allows each guest operating system to operate with the illusion of having exclusive access to the processor, peripherals, memory, and / or I / O of the computing system.

[0025] Figure 1A andFigure 1B is a block diagram illustrating examples of privilege or exception levels (ELs) that can be implemented in an example computing system 100a having a reduced instruction set computer (RISC) architecture (e.g., ARM, RISC-V, etc.). For example, components in the computing system 100a can be configured to execute within various exception levels (ELs) that control the execution privileges of the components executing within each respective EL. In one illustrative example, the exception levels can include a first exception level EL-0, a second exception level EL-1, a third exception level EL-2, and a fourth exception level EL-3.

[0026] Each exception level can be associated with different components of the computing system 100a, where components of a given EL have respective execution privileges corresponding to the given EL. For example, EL-0 can control a first set of execution privileges for components executing within EL-0; EL-1 can control a second set of execution privileges for components executing within EL-1; etc.

[0027] In some aspects, the first exception level EL-0 can be associated with a lowest execution privilege level, and can also be referred to as a least privileged level. Execution at EL-0 is unprivileged execution. Increasing exception level values (e.g., from 1 to 3) can correspond to increasing levels of execution privilege. For example, the fourth exception level EL-3 can be associated with a highest execution privilege level. Different exception levels can provide support for different functionality. For example, in the ARM architecture, EL-2 can provide support for processor virtualization via a hypervisor (e.g., a hypervisor 122 depicted in EL-2 of Figure 1A , described in more detail below). In the ARM architecture, EL-3 can provide support for two secure states.

[0028] An exception can be generated when a processor (e.g., a processor associated with the computing system 100a) first responds to an exceptional condition. The processor state at this time is the state taken from the exception. The processor state immediately after taking the exception is the state taken to the exception. To return from the exception, the processor must execute an exception return instruction. The processor state when the exception return instruction is committed for execution is the state returns from the exception. The processor state immediately after executing the instruction is the state returns to the exception.

[0029] Execution can move between different exception levels only upon taking an exception or upon returning from an exception. For example, upon taking an exception, the exception level will be raised or remain the same. The exception level cannot be lowered (e.g., cannot move to a lower execution level) upon taking an exception. Upon returning from an exception, the exception level is lowered or remains the same. The exception level cannot be raised (e.g., cannot move to a higher execution level) upon returning from an exception.

[0030] The exception level at which execution changes to (or remains at) upon taking an exception can be referred to as the target EL of the exception. In the ARM architecture, each exception type has a target EL that is either implicit in the nature of the exception or determined based on a corresponding configuration bit in a system register. An exception cannot target the EL-0 exception level (e.g., cannot target unprivileged execution).

[0031] In addition to the different exception levels EL-0 through EL-3, the computing system 100a can additionally include various execution environments, including a non-secure execution environment (e.g., also referred to as a rich OS execution environment) and a trusted or secure execution environment. The trusted or secure execution environment can also be referred to as a trusted execution environment (TEE) (e.g., such as an ARM TrustZone execution environment). In some cases, the TEE can reside in a virtual machine provided by a hypervisor without the need for a presence of a secure monitor, or can participate in the processor (e.g., CPU) control transition from one virtual machine through the hypervisor to the TEE. The rich execution environment can include the hypervisor 122 and the plurality of virtual machines 150, 160, 170. The secure execution environment can include the trusted application 105 and the TEE / trusted OS 115 (e.g., a TrustZone (TZ) component 115). The secure monitor 132 can operate across the various execution environments (e.g., the secure world and the non-secure world), and can be configured to control access to the secure execution environment (e.g., the TEE / trusted OS 115). Figure 1B is a schematic diagram 100b that depicts a first exception level EL-0 130 as including application and / or user space components; a second exception level EL-1 132 as including a kernel, kernel drivers, and / or VMs; a third exception level EL-2 134 as including a hypervisor and an access control (AC) driver; and a fourth exception level EL-3 136 as including a secure monitor. The exception levels are numbered (e.g., EL-0 through EL-3) such that a higher privilege level has a higher number. For example, the hypervisor 122 operating in EL-2 can have greater execution privileges than a software application 102 executing in EL-0.

[0032] As noted above, a trusted execution environment (TEE) can be used for secure execution of authorized secure software referred to as a “trusted application.” For example, Figure 1AThe depicted secure world can be associated with one or more trusted applications 105. Trusted applications 105 operate at an unprivileged exception level, EL-0, and can be similar to one or more of the non-secure world applications 102. For example, a first instance of a particular application can execute as a non-secure application instance 102 at EL-0 in the non-secure world, and a second instance of the particular application can execute as a trusted application 105 at EL-0 in the secure world. The secure world and TEE can be used to provide end-to-end security by enforcing protection, confidentiality, integrity, and data access permissions. Trusted applications 105 running in the secure world (e.g., executing in a TEE / trusted OS 115 at EL-1) can access the full performance of the device's main processor and memory, while hardware isolation protects the trusted applications 105 from non-secure applications 102 running in a rich OS associated with the HLOS VM 150. In some cases, trusted applications 105 may have limited access to the device's main processor and / or memory. Trusted applications 105 may be restricted to secure resources associated with or otherwise available to the TEE / trusted OS 115. For example, a trusted application 105 running in a VM may be restricted to access secure resources associated with or otherwise available to the TEE / trusted OS 115. In some examples, the secure world hypervisor ( Figure 1A The trusted application 105 (not shown) may be associated with the TEE / trusted OS 115 and may be used to control and / or limit access by the trusted application 105 to the device's main processor, memory, resources, etc. In some examples, the trusted application 105 may have limited access to device resources, where the access restrictions are implemented by the TEE / trusted OS 115. For example, the TEE / trusted OS 115 may isolate each of one or more trusted applications 105 from each other and from the TEE / trusted OS 115 itself.

[0033] An example TEE implementation can include, for example, OP-TEE by ARM, which supports the TrustZone secure state when implemented in a processor (e.g., CPU) implementing the ARM architecture. In addition to protecting trusted applications 105 from non-secure applications 102, a TEE 115 can also isolate trusted applications using operating system controls of the processor (e.g., CPU) with privilege levels and isolation protection features (e.g., memory management unit (MMU)). In some cases, a TEE can use cryptography to load and authenticate trusted applications 105. Example use cases for a TEE can include electronic financial services applications, such as mobile wallets, money transfers, bill payments, peer-to-peer payments, or contactless payments, among others. These financial services applications can involve user interaction, and it can be important for these applications to guarantee “What You See Is What You Sign.” This objective can be achieved by a dedicated trusted application 105 running in the TEE / secure OS 115 that takes over control of the device display from the rich OS of the HLOS VM 150 and provides secure and trusted user interaction.

[0034] Various usage models for exception levels can be utilized or implemented by computing system architectures (e.g., such as the architecture of computing system 100a). For example, a common usage model for exception levels is EL-0: applications; EL-1: OS kernel and associated functionality (often described as privileged); EL-2: hypervisor; EL-3: secure monitor. Figure 1A An example computing system 100a depicts an example implementation of this common usage model described above.

[0035] In some examples, a computing system can be used to provide multiple different virtual machines (VMs). For example, as described in the example of Figure 1A As depicted in the example of computing system 100a can be used to provide VMs 150, 160, 170. The VMs can execute using shared hardware resources associated with the computing system 100a, but remain logically separate and distinct. For purposes of explanation, when reference is made herein to a virtual machine performing an operation, the operation can be initiated by code running on a virtual execution context (e.g., a virtual CPU (VCPU) context). For example, a virtual machine can have at least one virtual execution context (or VCPU) that is given time to run on a CPU by a hypervisor, and the state of which can be saved by the hypervisor so that a different VCPU can be restored onto the CPU to run. Using such techniques, a hypervisor can run multiple VCPUs (and thus VMs) on an underlying physical CPU (e.g., by having each run for a period of time).

[0036] The first VM 150 can be provided as a VM associated with a high-level operating system (HLOS) of the computing system 100a. For example, the VM 150 can be associated with an HLOS such as Android or iOS (e.g., in examples where the computing system 100a is a smartphone or other mobile computing device). The remaining VMs 160, 170 can be used to provide various other functionality that is different from the functionality of the HLOS associated with the VM 150.

[0037] The EL-0 is associated with a plurality of applications 102 that operate in unprivileged execution on the computing system 100a (e.g., based on operating at the EL-0). Each application can be associated with a different one of the VMs 150, 160, 170. For example, respective first and second applications 102 are shown as being associated with each of the VMs 150, 160, 170. The applications 102 associated with a particular VM can be the same as the applications 102 associated with a different one of the VMs. The applications 102 associated with a particular VM can additionally or alternatively be different from the applications 102 associated with a different one of the VMs.

[0038] The EL-1 is associated with a plurality of kernel and device driver instances 112. For example, the kernel and driver instances 112 are associated with each respective one of the VMs 150, 160, 170. The kernel can correspond to the HLOS of the VM 150. For example, when the VM 150 is associated with an Android HLOS, the kernel can be a Linux kernel. The kernel and driver instances 112 that execute at the EL-1 and are associated with the plurality of VMs 150-170 can be the same across the VMs or can be different. In some cases, a VM can be associated with the same kernel but different drivers. For example, the HLOS VM 150 can be associated with a full set of device drivers, the VM 160 can be associated with minimal drivers, and the VM 170 can be associated with one or more protected drivers. At least one instance of the resource manager 117 can also operate at the EL-1 and can be shared across the plurality of VMs 150-170. Each kernel and driver instance 112 can include a trusted execution environment (TEE) communication interface 114 that can be used to provide communication between the non-secure world (in which the plurality of VMs 150-170 operate) and the secure world. As noted above, the TEE can reside in a VM (e.g., in some cases coexisting with other VMs).

[0039] EL-2 is associated with a hypervisor 122, which can also be referred to as a virtual machine monitor (VMM). The hypervisor 122 can be used to create and run VMs, such as the plurality of VMs 150-170 that execute under EL-0. The hypervisor 122 can oversee operations related to virtualization of hardware resources of the computing system 100a used to host the plurality of VMs 150-170 (e.g., the hypervisor 122 can oversee virtual sharing of computing system 100a resources among the plurality of VMs 150-170). The hypervisor 122 can include a secure monitor call (SMC) interface 126 that can be used to provide communication (e.g., secure monitor calls) with the TEE / trusted OS 115 of the secure world.

[0040] For example, a non-secure world VM (e.g., one of the VMs 150-170) can use the SMC routing interface 126 of the hypervisor 122 to communicate with the TEE / trusted OS 115 of the secure world. In some examples, the SMC can originate from the TEE communication interface 114 that executes under EL-1 and is associated with the calling originating VM. For example, in the example of FIG. 1, the SMC associated with the HLOS VM 150 as the originating VM can originate from the TEE communication interface 114 of the EL-1 kernel and driver instance 112 corresponding to the HLOS VM 150. Figure 1A Figure 1A

[0041] ​​EL-3 is associated with a secure monitor 132, which can operate across various execution environments (e.g., secure world and non-secure world) and can be configured to control access to secure execution environments (e.g., TEE / trusted OS 115). By operating at exception level EL-3, the secure monitor 132 operates at the highest exception level associated with the computing system 100a and can have greater execution privileges than components operating at any of the lower exception levels EL-0 through EL-2. The secure monitor 132 may include hardware and / or software components configured to support virtualization (e.g., support multiple VMs 150-170) and / or implement abstraction or virtualization of computing resources. The secure monitor 132 may include any or all of the following: a hardware monitor, specialized hardware fabricated on a chip, a virtual machine monitor (VMM), monitor software running outside a high-level operating system (HLOS), and a software monitor running as part of a device driver, which may be located outside the HLOS, its memory management system, and / or its allocator functionality. The secure monitor 132 can operate in both a rich execution environment (e.g., a non-secure world) and a trusted execution environment (e.g., a secure world). In some cases, the secure monitor 132 can host the hypervisor 122 (e.g., the secure monitor 132 and the hypervisor 122 can be part of the same software).

[0042] Apart from Figure 1A In addition to the components depicted, the computing system 100a may also include various additional functional components configured to perform the various functions described herein, such as a host operating system, a DSP operating system, library modules, software applications, user processes, listener call contexts (e.g., listener threads), execution hardware (e.g., application processors, DSPs, etc.), input / output devices, memory, etc. In some aspects, as used herein, "listener call" may refer to an event listener. In a TEE (e.g., such as Figure 1A The listen call may be a VM service registration call in the context of the TEE 115 of the UEFI and / or any target callback enabled (ADCI). For example, a VM (e.g., such as Figure 1AA VM (e.g., one of VMs 150-170) can make a call to a TEE (e.g., TEE 115) that never returns and waits to handle a VM service request from the TEE. For example, one of VMs 150-170 can make a call to TEE 115. The call from the VM to TEE 115 does not return and waits to handle a future or subsequent request for VM service from TEE 115 to the calling VM (e.g., the particular VM of VMs 150-170 that made the call to TEE 115). As noted above, a "listening call" can also be referred to as an "event listener." An event is a return from the SMC that includes a request for VM service as an additional return code.

[0043] A listener call context can refer to a VM SMC call that waits to handle a VM service request from a TEE (e.g., TEE 115). In the ADCI example, the listener call context can be an SMC in a'sleep' state waiting for an event. The event can be an interrupt that calls the TEE (e.g., TEE 115) to handle the VM service request.

[0044] A'sleep' state can be associated with putting a listener call context (e.g., a VM SMC call) to sleep. ADCI is a protocol that can be used to return an SMC return code that is specific to an implementation that causes the calling party (e.g., a VM SMC call or a listener call context) to go to sleep until it later receives a wake-up event. Receiving a wake-up event can cause the sleeping calling party to resume (e.g., wake up from sleep). A wake-up event can be delivered as an interrupt when an SMC return code that is specific to an implementation is returned from a TEE (e.g., TEE 115).

[0045] A callback service can refer to a VM service. For example, a callback service can be a VM service associated with a VM service request (e.g., such as a VM service request from a TEE and associated with a listener call context, as described above). In some aspects, a callback service can refer to logic in a VM that runs and provides data (e.g., return data) to a TEE (e.g., TEE 115) when requested by the TEE in a callback service request.

[0046] A callback service request (e.g., also referred to as a "callback request") can refer to a VM service request from a TEE (e.g., TEE 115).

[0047] In some aspects, the terms "listener" and "callback" can be used interchangeably.

[0048] As previously noted, the hypervisor 122 can be a software control program between the operating system and the security monitor 132. The hypervisor 122 can host multiple operating systems (e.g., also referred to as guest operating systems). Each guest operating system can be associated with one or more of the VMs 150-170, and can communicate with the hypervisor 122 and / or the security monitor 132 in the same manner as the physical hardware of the computing system 100a would communicate with the guest operating system. For example, each of the multiple VMs 150-170 can be considered as a combination of the hypervisor 122, the security monitor 132, and the underlying hardware of the computing system 100a for the particular VM. This allows each guest operating system associated with a particular one of the multiple VMs 150-170 to operate under the illusion of having exclusive access to the processors, peripherals, memory, I / O, etc. of the host computing system 100a.

[0049] The hypervisor 122 can be configured to manage memory access requests for the virtual machines 150-170. Operating systems are generally responsible for partitioning physical memory across multiple processes. However, in systems that include guest operating systems running on top of the virtual machines 150-170, the memory allocated by the guest operating system is intermediate physical memory, rather than real physical memory. On such systems, the hypervisor 122 is responsible for the actual allocation of physical memory.

[0050] In some cases, a virtual machine can be a software application that executes a software application in conjunction with the hypervisor 122. For example, the hypervisor 122 can be implemented based on a particular CPU architecture utilized by or associated with the underlying physical hardware of the computing system 100a. For example, a virtual machine implemented using the hypervisor 122 can utilize CPU architecture support to implement virtualization and execution of software code at EL-1 and / or EL-0, with access to hardware resources (e.g., hardware resources of the physical hardware of the computing system 100a) and time resources coordinated by the hypervisor 122. In some examples, a virtual machine can be implemented in conjunction with the hypervisor 122 without using emulation or with limited emulation performed by the hypervisor 122. By creating and managing virtual machines (e.g., such as the multiple VMs 150-170), the computing system 100a can create “sandboxes” (e.g., secure separations) around various features (including operating systems, applications, processes, etc.). The computing system 100a can use these sandboxes to enforce access controls among the various features of the device.

[0051] The non-secure world and secure world execution environments can be loaded via a secure boot process. Generally, secure boot is a boot sequence in which each software image loaded and executed on the computing system 100a is authenticated and / or authorized via previously authenticated / authorized software. The boot sequence can be configured to prevent unauthorized or modified code from running on the computing device by ensuring that each software image is checked before it is executed. The first image in the boot sequence is referred to as the primary boot loader (PBL), which is often stored in an immutable read-only memory that cannot be physically altered. The PBL authorizes each software image loaded and executed on the computing system 100a by cryptographically verifying the digital signature on each software image it loads. These software images cryptographically verify the digital signature on the next set of images they load, and so on. This ensures that the software images have not been altered. In some examples, the PBL can be configured to load a first image and a second image, where the first image is a boot loader image and the second image is a trusted secure boot loader image. The first image can be configured to coordinate loading of a rich execution environment (e.g., non-secure world), which can include an OS kernel and peripheral firmware images. The second image can be configured to coordinate loading of a trusted execution environment (e.g., secure world), which can include the TEE 115 and TEE-related images. The separation and isolation of the TEE images during the loading process can improve security by shortening the chain of images that must be loaded, authorized, and executed before the TEE images are operational. The second image can also configure the security monitor 132 or other access control system to isolate the memory used by the TEE 115 and / or secure world execution environment from all other execution environments on the chip, and then execute the first image at a lower privilege exception level.

[0052] The hypervisor and VMs need to be launched, after which the VMs can make calls to the TEE from their communication drivers. The TEE can then require services from the VMs. In some cases, the TEE can need to request one or more services provided by a VM executing in the non-secure world environment. For example, the TEE 115 can need to request one or more services from a particular one of the non-secure world VMs 150, 160, or 170. Examples of VM services that the TEE 115 can request include, but are not limited to, a secure file system (SFS) service, a replay protected memory block (RPMB) service, a secure passage service, and / or a time service, among various other services.

[0053] In existing approaches to TEE and VM services, the TEE 115 is enabled from the normal world (e.g., non-secure world) by a secure monitor call (SMC). For example, the TEE 115 can be enabled by the HLOS VM 150 using an SMC generated by the TEE communication interface 114. As previously described above, the SMC can be routed to the secure world TEE 115 by the SMC routing interface 126 included in the hypervisor 122.

[0054] The TEE 115 can respond to the SMC with a return (e.g., with an exception return (ERET) instruction) to the normal (non-secure) world only (e.g., back to the secure monitor). For example, the TEE 115 does not initiate contact with the normal world, and is only configured to communicate with the normal world via SMC callback requests (SMC callbacks) that are returned synchronously in response to SMCs received by the TEE from the VMs (e.g., instead of returning the results of the requested SMCs). Additionally, the return from the TEE 115 (e.g., back to the normal world) can only be requested by the VM service from the caller VM associated with the return. The caller VM is the VM that generated the SMC that triggered the SMC callback from the TEE 115. For example, other VMs will not concurrently issue SMC instructions (e.g., these instructions are the only valid way to receive SMC callbacks). Along with the exception return to the SMC instruction issued by the VM, the SMC result / callback response can be passed in general purpose registers from the higher EL to the lower EL. The exception return to a VM that is preempted at any other instruction will be corrupted by the unexpected change in registers.

[0055] Accordingly, the TEE 115 cannot initiate calls to VMs or the hypervisor of the normal world (e.g., the TEE 115 cannot initiate calls to the plurality of VMs 150-170, and additionally cannot initiate calls to the hypervisor 122 or its SMC routing interface 126). Based on the TEE’s inability to initiate calls to VMs or the hypervisor, many approaches for implementing normal world VMs that operate in conjunction with a secure world TEE require all VM services to be hosted in a host VM (e.g., such as the HLOS VM 150). For example, when multiple VMs and / or multiple VM configurations are operating in the normal world, the TEE has no mechanism to request VM services hosted in any VM other than the SMC caller VM. In these approaches, because all VM services are hosted in the host VM, the SMC and / or SMC callbacks between the normal world and the TEE are also routed through the host VM. Figure 2

[0056] ​There is a need for systems and techniques that can be used to provide SMC call initiation between a TEE and a selected VM of a plurality of VMs executing in a normal world of the same computing device. For example, a TEE needs to initiate an SMC to a VM that has not sent an earlier SMC to the TEE. There is also a need for systems and techniques that can be used to implement VM services on VMs other than a host VM. For example, there is a need to provide VM services hosted on some (or all) of the VMs included in a plurality of VMs executing on the same computing device as a secure world TEE.

[0057] Described herein are systems, apparatus, processes (also referred to as methods), and computer readable media (collectively referred to as "systems and techniques") that can be used to provide arbitrary target callback enablement between a trusted execution environment (TEE) and one or more virtual machines (VMs) executing in a non-secure or normal world environment associated with the TEE. For example, these systems and techniques can be used to provide secure monitor call (SMC) call initiation from a TEE to a respective VM of a plurality of VMs. The respective VM can be a particular VM associated with one or more VM resources required at the TEE. Based on the SMC initiation from the TEE, the TEE can request a VM service from any of the plurality of VMs. In one illustrative example, these systems and techniques can utilize an interrupt mechanism to notify a particular VM of one or more VMs of a wake-up event associated with the requested resource at the TEE. For example, an interrupt can be used to notify a particular VM (e.g., any of the one or more VMs) via an SMC return value. In some cases, a hypervisor (e.g., as a single entity through which SMCs made by the VMs are routed) can monitor SMC return registers to identify events destined for the same or different VMs as predetermined. In such cases, the hypervisor can generate an interrupt to the VMs to notify the VMs of the event. The VMs can then use an SMC to query the hypervisor and / or the TEE for the nature of the callback request.

[0058] In some aspects, a wait queue can be utilized to arbitrate access to the TEE by one or more VMs. The wait queue functionality can also be referred to as a "waitq" framework. A hypervisor associated with the one or more VMs can coordinate an SMC and forward it to the TEE. For example, the hypervisor can forward an SMC from a respective VM of a plurality of VMs to the TEE.

[0059] In some examples, the SMC that cannot obtain the TEE wait queue aware resource returns to sleep in the calling VM, e.g., via thread sleep. In some cases, this can be accomplished by adding the SMC to a queue or waiters associated with the contended resource. Control can be passed back to the VM by the TEE returning a special sleep result to the hypervisor / VM via an exception return to the SMC indicating that the SMC has gone to sleep. In some examples, the VM thread associated with the SMC can sleep using thread sleep facilities in the VM operating system kernel, or otherwise keep track of the sleeping SMC. Thread sleep can be coordinated by the hypervisor associated with routing or forwarding the SMC received from the calling VM. Subsequently, when the requested TEE resource associated with the SMC is released (e.g., becomes available at the TEE), the VM can be notified to wake up the corresponding sleeping thread and resume the earlier attempted SMC. For example, these systems and techniques can determine that an otherwise unrelated SMC has caused the requested TEE resource to be released. In some cases, the unrelated SMC can be from the same or a different VM that required the resource unblocking of the earlier attempted SMC, can return a special result (that is not the result of the unrelated SMC, but rather a result that informs the hypervisor / VM that the resource has become available). The unrelated call is still in progress, and the recipient hypervisor / VM can make a callback to the TEE to allow the unrelated SMC to continue execution in the TEE. However, the hypervisor / VM now knows that the earlier attempted SMC can be resumed, and can schedule an event (interrupt) to be sent to the VM of the earlier attempted SMC, so that the VM will know that it can attempt to resume the SMC.

[0060] Based on the determination, the call can return an SMC return code configured to wake up a sleeping thread at the calling VM. In one illustrative example, the call can return an SMC_WAKE return code configured to wake up a sleeping thread at the calling VM. In some cases, the SMC_WAKE return code (or other SMC return code) can be handled (e.g., coordinated and / or routed) by the hypervisor.

[0061] In some cases, the hypervisor can notify any of the one or more VMs included in the plurality of VMs of the SMC_WAKE event. For example, the hypervisor can generate one or more interrupts or otherwise send one or more interrupts to a secure channel manager (SCM) driver associated with respective ones of the plurality of VMs. In some examples, these systems and techniques can perform any destination callback enablement (ADCI) based on generating and / or sending the one or more wake-up events to any of the plurality of VMs to service the SMC callback request originated by the TEE.

[0062] Figure 2is a block diagram illustrating an example of a VM call resulting in waking up a previously dormant call from a different VM (VM) according to some examples. As illustrated, Figure 1A Computing system 200 can be similar to computing system 100a described above with respect to Figure 1A Computing system 200 can include a plurality of VMs 250, 260, 270 that can be the same or similar to the plurality of VMs 150, 160, 170 of Figure 1A For example, the plurality of normal world (e.g., non-secure world) applications 202 can be the same or similar to the plurality of normal world applications 102 of Figure 1A Kernel and driver instances 212a, 212b, and 212c can be the same or similar to the kernel and driver instances 112 of Figure 1A Resource manager 217 can be the same or similar to resource manager 117 of Figure 1A TEE communication interfaces 214a, 214b, and 214c can be the same or similar to the TEE communication interfaces 114 of Figure 1A Hypervisor 222 can be the same or similar to hypervisor 122 of Figure 1A SMC routing interface 226 can be the same or similar to SMC routing interface 126 of Figure 1A Hypervisor message tracking interface 228 can be the same or similar to hypervisor message tracking interface 128 of Figure 1A Secure monitor 232 can be the same or similar to secure monitor 132 of Figure 1A Secure world trusted applications 205 can be the same or similar to secure world trusted applications 105 of Figure 1A TEE / trusted OS 215 can be the same or similar to TEE / trusted OS 115 of Figure 2

[0063] In one illustrative example, VM 250 can generate and send an SMC to TEE / trusted OS 215. As previously described (e.g., with respect to Figure 2 SMC from VM 250 can be generated using TEE communication interface 214a of kernel and device driver instance 212a associated with VM 250 at EL-1 exception level. The SMC can be sent from TEE communication interface 214a to SMC routing and TEE communication interface 226 of hypervisor 222, and / or can be sent to hypervisor message tracking interface 228 of hypervisor 222.

[0064] ​The hypervisor 222 can route the SMC from the normal world (e.g., non-secure execution environment) to the TEE / trusted OS 215 of the secure world. In response to determining that the SMC cannot obtain one or more TEEwaitq queue-aware resources associated with the SMC, the SMC from the VM 250 can return to sleep in the calling VM. As Figure 4 The calling VM is illustrated as the HLOS VM 250. In some aspects, the SMC can return to sleep via a thread sleep. The thread sleep can be coordinated by the hypervisor 222.

[0065] In one illustrative example, the TEE 215 can determine that the SMC from the VM 250 requires one or more VM resources that are hosted at a different VM. For example, the TEE 215 can determine that the SMC from the VM 250 requires use of a VM resource that is hosted at the VM 270. Since the TEE 215 can only return to the calling domain (e.g., the calling VM 250), the TEE 215 cannot return to the VM 270 in order to access the required resource at the VM 270 for servicing the SMC received from the VM 250.

[0066] Instead, the SMC callback request can be issued in the TEE 215 by the first VM 250, and the TEE 215 can send an SMC_WAITQ_WAKE return code to wake up the first VM 250. The hypervisor 222 can receive the SMC_WAITQ_WAKE return code from the TEE 215, process and / or route the return code. For example, the SMC routing and TEE communication interface 226 and / or the hypervisor message tracking interface 228 can be used to receive the SMC_WAITQ_WAKE return code from the TEE 215, process and / or route the return code, and route the wake-up return code to the first VM 410. In one illustrative example, the SMC routing and TEE communication interface 226 and / or the hypervisor message tracking interface 228 can be used to send the SMC_WAITQ_WAKE return code from the TEE 215 to the hypervisor 222 using the call return path as indicated. Figure 3 The call return path as indicated can be used to send the SMC_WAITQ_WAKE return code between the TEE 215 and the hypervisor 222. The hypervisor message tracking interface 228 can then utilize the wake-up interrupt path to send the SMC_WAITQ_WAKE return code to the VM 270 that hosts the VM service required by the SMC from the VM 250.

[0067] Further details of the SMC callback service implemented by the systems and techniques described herein for arbitrary destination callback invocation (ADCI) by the TEE 215 will be described in greater depth below with respect to the example ADCI call flow 400 of Figure 2

[0068] Figure 4 ​is a diagram 300 illustrating examples of secure monitor calls (SMCs) and SMC callbacks sent between a VM and a trusted execution environment (TEE) according to some examples. For example, the described systems and techniques can utilize the existing SMC_WAITQ framework to cause the SMC to return and sleep in the calling VM until a corresponding wake-up event is received from the TEE. In one illustrative example, in a computing system (e.g., such as Figure 3 One or more (or all) of the VMs included in the plurality of VMs running on the computing system 200 may initialize the ADCI callback service described herein. For example, at initialization time, each VM hosting a VM service may call TEE 315 to register the corresponding callback service with TEE 315 to listen for SMC callbacks requesting VM services from the corresponding VM.

[0069] For example, the first VM 360 may use the SMC to call the TEE 315 to register an SMC callback service, which the first VM 360 may use to listen for an SMC callback from the TEE 315 requesting a VM service from the first VM 360. Similarly, the second VM 370 may use the SMC to call the TEE 315 to register an SMC callback service, which the second VM 370 may use to listen for an SMC callback from the TEE 315 requesting a VM service from the second VM 370. In some aspects, the first VM 360 and the second VM 370 may use the same type of SMC message to initialize their respective ADCI SMC callback services and register their respective ADCI SMC callback services with the TEE 315.

[0070] The TEE 315 may then determine whether there are service callbacks pending for each VM that has initialized an SMC callback service or registered an SMC callback service with the TEE 315. For example, in response to receiving an SMC from a different VM requesting a VM service hosted by a given VM, the pending service callbacks for the given VM may be posted to the TEE 315 (as will be discussed below with respect to Figure 4 (Example ADCI call flow 400 explained in more depth). If there is no service callback waiting to be processed for the corresponding VM that has registered an SMC callback service, the TEE 315 will put the SMC request to the corresponding VM into hibernation. For example, to put the SMC request to the corresponding VM into hibernation, the TEE 315 may return an SMC_SLEEP return code (e.g., an SMC_WAITQ_SLEEP return code). For example, the TEE 315 may use Figure 2 The depicted corresponding SMC callbacks between the TEE 315 and the first and second VMs 360 and 370 return an SMC_WAITQ_SLEEP return code.

[0071] When a service request is made to a particular VM, and the particular VM has a snooze listener call registered with the TEE 315 (e.g., the VM is one of the registered VMs for the SMC callback service of the TEE 315), the TEE 315 will issue an SMC_WAKE to the particular VM. The SMC_WAKE can wake up the snooze listener call context (e.g., snooze listener thread) in the particular VM. In some cases, the SMC_WAKE can be an SMC_WAITQ_WAKE return code. If the VM needs to be woken up, the hypervisor associated with the VM can issue an interrupt request (IRQ) to the particular VM. Subsequently, the woken up VM will issue an SMC_RESUME call (e.g., smc_waitq_resume call) to the TEE 315. The TEE 315 can respond to the SMC_RESUME with an SMC callback to enable the VM service corresponding to the previous service request made to the particular VM.

[0072] Figure 2 is a diagram illustrating an example call flow 400 for providing arbitrary target callback enablement, in accordance with some examples. The example call flow 400 can be implemented between a first VM 410, which can be a HLOS VM (e.g., such as the HLOS VM 250 of FIG. 2), a second VM 420 (e.g., which can be the same as the VM 270 of FIG. 2), a hypervisor 430 (e.g., which can be the same as the hypervisor 222 of FIG. 2), a first TEE thread 440, and a second TEE thread 450. In some examples, the first TEE thread 440 and the second TEE thread 450 can be implemented at a TEE that is the same as or similar to the TEE 215 of FIG. 2. Figure 2 Figure 2 Figure 2 Figure 2

[0073] In a first operation (e.g., operation 1) of the call flow 400, the HLOS VM 410 can call the TEE to register for a callback service. For example, the VM 410 can call the first TEE thread 440 to register for an ADCI callback service. In some examples, the VM 410 can generate and send an ADCI_accept message to the first TEE thread 440, where the ADCI_accept is used to register for a callback service between the first VM 410 and the first TEE thread 440. For example, the ADCI_accept message can be used to accept or register for an arbitrary target callback enablement (ADCI) implementation between the HLOS VM 410 and the first TEE thread 440. The first TEE thread 440 can register an ADCI buffer (e.g., as depicted at 462).

[0074] ​​​​In a second operation (e.g., operation 2) of the invocation flow 400, the first TEE thread 440 can return a sleep message or command to the HLOS VM 410. For example, the first TEE thread 440 can return a sleep message based on determining that there is no callback (e.g., SMC callback) to a service. In some aspects, an SMC_WAITQ_SLEEP return code can be used to indicate the sleep message returned to the HLOS VM 410.

[0075] In a third operation (e.g., operation 3) of the invocation flow 400, the second VM 420 can generate and send an SMC to the second TEE thread 450. The second VM 420 can be different from the HLOS VM 410, but implemented or otherwise executed on the same computing device (e.g., the computing system 200 such as Figure 2 In some aspects, the second TEE thread 450 can be different from the first TEE thread 440, but implemented or otherwise executed on the same TEE (e.g., the TEE 215 such as Figure 2 In some aspects, the second TEE thread 450 can be different from the first TEE thread 440, but implemented or otherwise executed on the same TEE (e.g., the TEE 215 such as

[0076] Based on receiving the SMC X from the second VM 420 in operation 3, the TEE can determine that servicing the SMC X requires a callback service hosted in a VM other than the second VM 420. For example, as depicted at 464, the TEE can determine that the SMC X from the second VM 420 requires an SMC callback to a VM service hosted in the HLOS VM 410. In one illustrative example, the TEE can issue an SMC callback request in the TEE for the HLOS VM 410 (e.g., the VM identified as hosting the VM service required for the SMC X from the second VM 420).

[0077] In a fourth operation (e.g., operation 4) of the invocation flow 400, the TEE can additionally generate and send a wake-up message to the HLOS VM 410. The wake-up message can be sent in response to the SMC X received from the second VM 420 and analyzed by the TEE at operation 462. For example, the wake-up message can be sent based on the TEE issuing the callback request in the TEE for the HLOS VM 410.

[0078] The wake-up message sent by the TEE to the HLOS VM 410 can be mediated or otherwise routed by a hypervisor associated with the HLOS VM 410. For example, the hypervisor 430 can receive and route the wake-up invocation to the HLOS VM 410 (e.g., using the SMC routing and TEE communication interface 226 and / or using the hypervisor message tracking interface 228 of Figure 2 Figure 5

[0079] ​​In a fifth operation (e.g., operation 5) of the calling flow 400, the hypervisor 430 can send an interrupt request (IRQ) to the VM 410. For example, the hypervisor 430 can generate and send a WAKE IRQ message to the VM 410. In some aspects, the wake message can be an SMC WAITQ WAKE return code generated and sent by the second TEE thread 450 (and forwarded / routed by the hypervisor 430). In some cases, the VM 410 can acknowledge the SMC WAITQ WAKE return code received in operation 5 by sending a smc waitq wake ack SMC.

[0080] In one illustrative example, at 466, the hypervisor 430 can interpret the wake message and issue an interrupt request (IRQ) to the corresponding VM (e.g., the VM 410). In some aspects, the hypervisor 430 can use the hypervisor message tracking interface 228 of Figure 1A to interpret the wake message, and can use the SMC routing interface 226 to route the wake message to the corresponding VM (e.g., the VM 410). As indicated at 468, the corresponding thread in the TEE (e.g., which is the second TEE thread 450 here) can sleep until the callback request issued in the TEE for the VM 410 at operation 464 has completed.

[0081] In a sixth operation (e.g., operation 6) of the calling flow 400, the second TEE thread 450 can return a sleep message to the calling VM, which in this example is the VM 420. In some aspects, the SMC WAITQ SLEEP return code can be used to indicate the sleep message returned to the calling VM 420.

[0082] In a seventh operation (e.g., operation 7) of the calling flow 400, the VM 410 can generate and send an SMC indicating that the VM resources of the VM 410 have been released or have been released to the TEE. The VM resources released at the VM 410 can be the same VM resources required by the SMC X sent from the second VM 420 to the TEE at operation 3. In some aspects, the VM 410 can send a smc waitq resume call to indicate to the TEE (e.g., to the first TEE thread 440) that the VM resources of the VM 410 have been released or otherwise resumed.

[0083] In response to receiving the smc waitq resume SMC from the VM 410, at operation 472, the first TEE thread 440 can process the SMC callback request previously issued in the TEE for the VM 1 (e.g., the SMC callback request issued in the TEE for the VM 1 at operation 464 based on the SMC X from the VM 420).

[0084] In an eighth operation (e.g., operation 8) of the invoking flow 400, and based on processing the previously issued SMC callback request at operation 472, the first TEE thread 440 can generate and send an SMC return (e.g., callback) for the requested VM resource at the first VM 410.

[0085] At operation 474, the SMC callback return from the first TEE thread 440 (e.g., generated and sent at operation 8) can cause the first VM 410 to normally process the callback request to SMCX. At operation 474, the first VM 410 can process the SMC callback request, e.g., by using the requested VM service associated with SMCX (from the second VM 420) to process the SMC callback request.

[0086] In a ninth operation (e.g., operation 9) of the invoking flow 400, the first VM 410 can generate and send an SMC corresponding to the callback response determined at operation 474 by processing the SMC callback request using the appropriate VM service of the first VM 410. The SMC for the callback response can be sent from the first VM 410 to the first TEE thread 440.

[0087] At operation 476, the first TEE thread 440 can determine that the SMC callback response is available (e.g., available for the SMC callback request issued in the TEE at operation 464 for the first VM 410, which is the same SMC callback request associated with the SMC callback request at the second TEE thread 450 associated with the sleep operation 468). Additionally, the first TEE thread 440 can wake up the second VM 420 based on determining that the SMC callback request is available. The first TEE thread 440 can wake up the second VM 420 using the SMC_WAITQ_WAKE return code. After waking up the second VM 420, the first TEE thread 440 can then sleep until the next callback request is issued in the TEE (e.g., issued for the first VM 410 and / or issued for the VM corresponding to the first TEE thread 440).

[0088] In a tenth operation (e.g., operation 10) of the invoking flow 400, the first TEE thread 440 can send the SMC_WAITQ_WAKE return code to the hypervisor 430. The hypervisor 430 interprets the SMC_WAITQ_WAKE return code and issues a corresponding interrupt request (IRQ) to the second VM 420 (e.g., at operation 478).

[0089] At an eleventh operation (e.g., operation 11) of the calling flow 400, the hypervisor 430 generates and sends a WAKE interrupt request to the second VM 420. The WAKE interrupt request of operation 11 can be the same as or similar to the WAKE interrupt request of operation 5 (e.g., as previously described above).

[0090] At a twelfth operation (e.g., operation 12) of the calling flow 400, the first TEE thread 440 can return a sleep message to the first VM 410. In some aspects, the sleep message returned to the VM 410 can be indicated using an SMC_WAITQ_SLEEP return code (e.g., the same as or similar to the sleep message and / or SMC_WAITQ_SLEEP return code described above with respect to operation 6).

[0091] At a thirteenth operation (e.g., operation 13) of the calling flow 400, the second VM 420 can generate and send a RESUME SMC to the second TEE thread 450. The RESUME SMC of operation 13 can cause the second TEE thread 450 to resume processing of the SMC X sent by the second VM 420 at operation 3. In some cases, the second VM 420 can generate and send the RESUME SMC as a smc_waitq_resume SMC (which can be the same as or similar to the smc_waitq_resume SMC of operation 7). In some examples, the smc_waitq_resume call can be generated by the second VM 420 based on the second VM 420 determining that the first VM 410 has completed processing of the SMC callback request. In some examples, the smc_waitq_resume call can be generated by the second VM 420 in response to the WAKE interrupt request (e.g., smc_waitq_resume) from the first TEE thread / hypervisor 430 in operations 10 and 11, respectively.

[0092] After receiving the smc_waitq_resume call from the second VM 420 in operation 13, the second TEE thread 450 can complete the SMC X associated with the second VM 420 and requiring use of the VM resources at the first VM 410. At operation 482, the SMC X can be completed by the second TEE thread 450.

[0093] At a fourteenth operation (e.g., operation 14) of the calling flow 400, the second TEE thread 450 can generate and send an SMC X return indicating the completed SMC X from operation 482 to the second VM 420.

[0094] Figure 2is a flow diagram illustrating an example of a process 500 for data access in accordance with aspects of the present disclosure. The process 500 can be performed by a computing device (or apparatus) or a component of a computing device (e.g., a chipset, codec, etc.). The computing device can be a mobile device (e.g., a mobile phone), a network-connected wearable device such as a watch, an extended reality (XR) device such as a virtual reality (VR) device or an augmented reality (AR) device, a vehicle or a component or system of a vehicle, or other types of computing devices. The operations of process 500 can be implemented as software components running on one or more processors.

[0095] At block 502, the process 500 includes receiving a listen call from a first VM of a plurality of virtual machines (VMs), where the listen call registers a listener call context of the first VM with a callback service of a trusted execution environment (TEE). For example, the plurality of VMs can be the same as or similar to one or more (or all) of: Figure 3 the VMs 150, 160, 170 of FIG. 1; Figure 4 the VMs 250, 260, 270 of FIG. 2; Figure 1A the VMs 360 and 370 of FIG. 3; and / or Figure 2 the VMs 410 and 420 of FIG. 4. In some cases, the TEE can be the same as or similar to: Figure 3 the TEE 115 of FIG. 1, Figure 4 the TEE 215 of FIG. 2, Figure 1A the TEE 315 of FIG. 3, and / or Figure 2 the TEE threads 440, 450 of FIG. 4.

[0096] In some cases, the plurality of VMs and the TEE are executing on the same computing device. The computing device can be the same as or similar to: Figure 6 the computing system 100a of FIG. 1, Figure 2 the computing system 200 of FIG. 2, and / or Figure 1A the computing system 600 of FIG. 6.

[0097] In some examples, the listen call can refer to an event listener. In the context of a TEE and / or any arbitrary callback enabling (ADCI), the listen call can be a VM service registration call. For example, a VM can make a call to a TEE that never returns and waits to handle requests for VM services from the TEE. For example, the first VM can be the HLOS VM 250 of FIG. 2 (e.g., which can be the same as or similar to the HLOS VM 150 of FIG. 1). Figure 2 Figure 2 ​The first VM 250 can make a call to the TEE 215. The call from the first VM 250 into the TEE 215 does not return and waits to handle a future or subsequent request for a VM service from the TEE 215 to the calling VM (e.g., the first VM 250 that made the call to the TEE 215). The listening call can also be referred to as an event listener. The event is a return from the SMC that includes a request for a VM service as an additional return code.

[0098] In some cases, the listening call registers the listener call context of the first VM with a callback service of the TEE 215. In some examples, the listening call is a Figure 2 Figure 2 In some cases, the listener call context is a VM SMC call (e.g., from the first VM 250) that waits to handle a VM service request from the TEE (e.g., the TEE 215). In some examples, the listener call context is a SMC that is in a'sleep' state waiting for an event. Figure 2

[0099] In some cases, the callback service of the TEE can refer to a VM service. For example, the callback service can be a VM service associated with a VM service request (e.g., such as a VM service request from the TEE 215 to the first VM 250). In some aspects, the callback service can refer to logic in the VM that runs and provides data (e.g., return data) to the TEE (e.g., the TEE 215) when the TEE requests in the callback service request. Figure 2

[0100] At block 504, the process 500 includes returning a return code to the first VM indicating that no callback request is available for the first VM, where the return code causes the first VM to put the listener call context to sleep. For example, the return code can be returned to the listening call from the first VM (e.g., the HLOS VM 250). In some cases, the return code is a secure monitor call (SMC) wait queue sleep return code. In some examples, the TEE returns the return code to the first VM based on determining that no callback request associated with the first VM is posted in the TEE. In some cases, the return code indicating that no callback request is available for the first VM is a secure monitor call (SMC) sleep return code. Figure 2

[0101] ​​​​In some cases, causing the first VM to put the listener call context to sleep is associated with a 'sleep' state. The sleep state may be associated with putting a listener call context (e.g., a VM SMC call) to sleep. ADCI is a protocol that can be used to return an implementation-specific SMC return code that causes the caller (e.g., Figure 2 The first VM250 associated with the VM SMC call or listener call context) goes to sleep until it receives a wake-up event later. Receiving a wake-up event can cause the sleeping caller to resume (e.g., wake up from sleep). When the TEE (e.g., Figure 4 When the TEE 215 of the wakeup process returns an implementation-specific SMC return code, the wakeup event may be delivered as an interrupt.

[0102] At block 506, process 500 includes receiving a call from a second VM in the plurality of VMs, wherein the call from the second VM makes a service request for a VM service of the first VM. Figure 4 VM 260 or Figure 1A The first VM may be the same as or similar to the VM 270. Figure 1A The HLOS VM 410 is the same or similar to the second VM, and the second VM can be the same as the HLOS VM 410. Figure 2 The same or similar to the VM2420.

[0103] In some examples, the call from the second VM includes a secure monitor call (SMC). The call from the second VM may be returned to sleep in the second VM before the VM service of the first VM executes. In some cases, the TEE may send a callback request to the first VM based on determining that the call from the second VM has returned to sleep.

[0104] At block 508, process 500 includes returning a wakeup return code to the second VM for a listener call context configured to wake up the first VM. For example, the wakeup return code may be a security monitor call (SMC) wait queue wakeup return code. In some cases, returning the wakeup return code to the second VM includes receiving the wakeup return code from the TEE by a hypervisor associated with the plurality of VMs. For example, the hypervisor may be associated with Figure 2 of and Figure 4 The hypervisor 122 associated with the plurality of VMs 150-170 is the same or similar. The hypervisor may be the same as Figure 4 of and Figure 2 The hypervisor 222 associated with the plurality of VMs 250-270 is the same or similar. The hypervisor may be the same as Figure 2 of and Figure 2 The hypervisors 430 associated with the multiple VMs 410 and 420 are the same or similar.

[0105] Based on receiving the wake-up return code from the TEE by the hypervisor, the hypervisor can signal an interrupt request (IRQ) to the first VM, where the interrupt request wakes up the listener invocation context of the first VM. In some cases, the hypervisor signals the IRQ to an SMC driver of the first VM or a TEE communication driver associated with the first VM. For example, the TEE communication driver can be the same as or similar to the TEE communication driver 214a associated with the first VM 250. In some cases, the SMC driver can be the same as or similar to the SMC routing and TX communication 226 of the first VM 250. Figure 5 Figure 6 Figure 6 The SMC routing and TX communication 226 of the first VM 250 can be the same as or similar to the SMC routing and TX communication 226 of the first VM 250.

[0106] In some examples, the IRQ is associated with the listener invocation context of the first VM or the TEE communication driver associated with the first VM. In some examples, waking up the listener invocation context of the first VM causes the listener invocation context to resume and listen for queued service requests for the VM service of the first VM.

[0107] At block 510, the process 500 includes sending a callback request corresponding to the service request made by the second VM to the VM service of the first VM. For example, the callback request can be received using the listener invocation context of the first VM. In some cases, the callback request can be sent to the TEE, and the TEE can forward the callback request to the VM service of the first VM. In some examples, sending the callback request to the TEE registers the first VM with an arbitrary destination callback enablement (ADCI) service of the TEE.

[0108] At block 512, the process 500 includes receiving a response invocation from the VM service of the first VM indicating a callback response to the callback request. In some cases, the callback response includes output generated using the VM service of the first VM to process the service request made by the second VM. In some examples, the response invocation from the VM service of the first VM includes a secure monitor call (SMC). In some cases, the callback request is received using the listener invocation context of the first VM, and the callback response is generated based on processing the callback request using the VM service of the first VM. The response invocation indicating the callback response can be sent to the TEE using the listener invocation context of the first VM.

[0109] configured to perform ​ ​​The components of the devices of process 500 can be implemented in circuitry. For example, components can comprise or be implemented using electronic circuitry or other electronic hardware, which can include one or more programmable electronic circuits (e.g., microprocessors, graphics processing units (GPUs), digital signal processors (DSPs), central processing units (CPUs), and / or other suitable electronic circuits), and / or can include or be implemented using computer software, firmware, or any combination thereof for performing the various operations described herein.

[0110] Process 500 is illustrated as a logic flow diagram, the operations of which represent a sequence of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored, for example, on one or more computer-readable storage media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the processes.

[0111] Additionally, process 500 and / or other processes described herein can be performed under the control of one or more computer systems configured with executable instructions, and can be implemented as code (e.g., executable instructions, one or more computer programs or one or more applications) executing collectively on one or more processing units, by hardware or combinations thereof. As noted above, the code can be stored on a computer-readable or machine-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable or machine-readable storage medium can be non-transitory.

[0112] ​ is a block diagram illustrating an example of a computing system 600 that can be employed by the disclosed systems and techniques. Specifically, ​ An example of a computing system 600 is illustrated, which can be, for example, any computing device making up an internal computing system, a remote computing system, a camera, or any component thereof, where the components of the system communicate with each other using connections 605. Connections 605 can be physical connections using a bus, or direct connections into processor 610, such as in a chipset architecture. Connections 605 can also be virtual, networking, or logical connections.

[0113] In some aspects, the computing system 600 is a distributed system, where the functionality described in this disclosure can be distributed within one data center, multiple data centers, a peer-to-peer network, etc. In some aspects, one or more of the described system components represent a number of such components, each performing some or all of the functions attributed to the component. In some aspects, the components can be physical or virtual devices.

[0114] The example system 600 includes at least one processing unit (CPU or processor) 610 and a connection 605 that communicatively couples to the processor 610 various system components including a system memory 615, such as read-only memory (ROM) 620 and random access memory (RAM) 625. The computing system 600 can include a cache of high-speed memory directly

[0115] The processor 610 can include any general purpose processor and a hardware service or software service, such as services 632, 634, and 636 stored in storage device 630 configured to control the processor 610, as well as specialized processors in which software instructions are incorporated into the actual processor design. The processor 610 can be essentially a fully self-contained computing system, containing multiple cores or processors, a bus, memory controller, and cache, etc. Multi-core processors can be symmetric or asymmetric.

[0116] To enable user interaction, the computing system 600 includes an input device 645, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and the like. The computing system 600 can also include output device(s) 635, which can be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multi-modal systems can enable a user to provide multiple types of input to communicate with the computing system 600.

[0117] The computing system 600 can include communication interface 640 that can generally govern and manage wired and / or wireless communication with one or more other devices over a wired or wireless connection. The communication interface can receive and / or send wired or wireless communication using a wired and / or wireless transceiver, including utilizing audio jacks / plugs, microphone jacks / plugs, universal serial bus (USB) ports / plugs, Apple TM Lightning TTM ports / plugs, Ethernet ports / plugs, fiber optic ports / plugs, dedicated wired ports / plugs, 3G, 4G, 5G, and / or other cellular data network wireless signal transfers, Bluetooth TM wireless signal transfers, Bluetooth TMBluetooth® low energy (BLE) wireless signaling, iBeacon TM wireless signaling, radio frequency identification (RFID) wireless signaling, near field communication (NFC) wireless signaling, dedicated short-range communications (DSRC) wireless signaling, 802.11 Wi-Fi wireless signaling, wireless local area network (WLAN) signaling, visible light communication (VLC), worldwide interoperability for microwave access (WiMAX), infrared (IR) communication wireless signaling, public switched telephone network (PSTN) signaling, integrated services digital network (ISDN) signaling, ad hoc network signaling, radio wave signaling, microwave signaling, infrared signaling, visible light signaling, ultraviolet light signaling, wireless signaling along the electromagnetic spectrum, or some combination thereof.

[0118] The communication interface 640 can also include one or more ranging sensors (e.g., LIDAR sensors, laser rangefinders, RF radar, ultrasonic sensors, and infrared (IR) sensors) configured to collect data and provide measurements to the processor 610, whereby the processor 610 can be configured to perform determinations and calculations necessary to obtain various measurements of the one or more ranging sensors. In some examples, the measurements can include time of flight, wavelength, azimuth, elevation, distance, linear velocity, and / or angular velocity, or any combination thereof. The communication interface 640 can also include one or more global navigation satellite system (GNSS) receivers or transceivers for determining a location of the computing system 600 based on one or more signals received from one or more satellites associated with one or more GNSS systems. GNSS systems include, but are not limited to, GPS in the United States, Global Navigation Satellite System (GLONASS) in Russia, Beidou Navigation Satellite System (BDS) in China, and Galileo GNSS in Europe. There is no limitation on operating on any particular hardware arrangement, and thus the underlying features here can be readily replaced to obtain improved hardware or firmware arrangements as they are developed.

[0119] The storage device 630 can be a non-volatile and / or non-transitory and / or computer-readable memory device and can be a hard disk or other type of computer readable medium such as a box tape, flash memory card, solid-state memory device, digital versatile disc, cassette, floppy disk, flexible disk, hard disk, magnetic tape, magnetic strip / magnetic stripe, any other magnetic storage medium, flash memory, memristor memory, any other solid-state memory, compact disc read-only memory (CD-ROM) optical disc, compact disc (CD) rewritable (CD-RW) optical disc, digital video disc (DVD) optical disc, Blu-ray disc (BDD) optical disc, holographic disc, another optical medium, secure digital (SD) card, micro secure digital (microSD) card,

[0120] ​The storage device 630 can include software services, servers, services, or the like that, when code defining such software is executed by the processor 610, cause the system to perform a function. In some aspects, a hardware service that performs a particular function can include the software component stored in the computer-readable medium that, in combination with the necessary hardware components, such as the processor 610, the connection 605, the output device 635, and so on, carries out the function. The term "computer-readable medium" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other mediums capable of storing, containing, or carrying instruction and / or data. A computer-readable medium can include a non-transitory medium in which data can be stored and which does not include carrier waves and / or transitory electronic signals propagating wirelessly or over wired connections. Examples of a non-transitory medium can include, but are not limited to, a magnetic disk or tape, optical storage media such as compact disk (CD) or digital versatile disk (DVD), flash memory, memory or memory devices. A computer-readable medium can have stored thereon code and / or machine-executable instructions that can represent a procedure, function, subprogram, program, routine, subroutine, module, software package, class, or any combination of instructions, data structures, or program statements. A code segment can be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, and so on can be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, and so on.

[0121] In the description above, specific details are provided to provide a thorough understanding of the aspects and examples provided herein. However, a person of ordinary skill in the art will recognize that the application is not limited to the specific aspects and examples described above. Thus, although the illustrative aspects of the application have been described in detail above, it should be understood that various modifications can be made without departing from the scope of the application. Accordingly, the appended claims should not be construed to include only the aspects and examples described above, but rather should be construed to include all aspects and equivalents that are within the spirit and scope of the application. Various features and aspects of the above-described application can be used individually or jointly. Further, the application can be used in any number of environments and applications beyond the ones described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings are to be regarded as illustrative in nature and not as restrictive. The methods described herein can be implemented by various means depending upon the application. For example, storage media can be used for implementing some steps of the methods. The term "storage media" includes one or both of computer-readable storage media and transitory media (e.g., carrier waves, electromagnetic signals, etc.). The computer-readable storage media includes all tangible and non-transitory media used to code and carry data.

[0122] For the sake of clarity, in some instances the techniques can be presented as including a specific sequence of steps or functionality. However, the steps or functionality can be re-ordered or omitted within specified embodiments. Further, steps or functionality can be performed simultaneously or concurrently with other steps or functionality. It is expected that many of the steps can be performed by hardware components or modules of a computing device, software components or modules, and / or combinations thereof. Many of the steps can be performed by a single component or module or a single component or module can perform several of the steps. Further, the specific hardware or software components or modules controlling a process or method can be combined with other hardware or software components or modules controlling other processes or methods. For example, a single component or module can control several processes or methods.

[0123] Further, those skilled in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein can be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

[0124] Various aspects can be described herein as a process or method. Although a process or method can be described as sequential, the steps or functions of the process or method can be performed in parallel or concurrently. In addition, the order of the steps or functions can be re-arranged. A process or method can correspond to a set of operations that can be atomic or that can correspond to a procedure. A procedure can correspond to a subset of operations of a process or method. A procedure can also correspond to a subset of operations of another process or method. The procedures can be re-used with different processes or methods in accordance with various aspects.

[0125] The processes and methods described above can be implemented using stored computer-executable instructions or computer-executable instructions accessed from a computer-readable medium. Such instructions can include, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or a processing device to perform a certain function or group of functions. Portions of computer resources used can be accessed over a network. The computer-executable instructions can be, for example, binaries, intermediate format instructions such as assembly language, firmware, source code, etc. Examples of computer-readable media that can be used to store instructions, information used, and / or information created during methods according to described examples include magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, etc.

[0126] In some aspects, computer-readable storage devices, media, and memories can include cables or wireless signals containing bitstreams and the like. However, where mentioned, non-transitory computer-readable storage media expressly excludes media such as power supply, carrier waves, electromagnetic waves, and signals per se.

[0127] Those skilled in the art will understand that information and signals can be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that can be referenced throughout the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof consistent with the particular application, as would be understood by one of ordinary skill in the art.

[0128] The various illustrative logical blocks, modules, and circuits described in connection with the aspects disclosed herein can be implemented or performed with a hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof and can be embodied in any of a number of various forms. When implemented in software, firmware, middleware, or microcode, the program code or code segments (e.g., computer program products) for performing the necessary tasks can be stored in a computer-readable or machine-readable medium. A processor(s) can execute the necessary tasks. Examples of the various shapes include: a laptop computer, a smart phone, a mobile phone, a tablet device, or other small form factor personal computers, personal digital assistants, rack-mounted devices, stand-alone devices, and the like. The functionality described herein can also be embodied in peripheral devices or in interposers. By way of further example, such functionality can also be implemented on circuit boards among different chips or different processes executing on a single device.

[0129] Instructions, media for conveying such instructions, computing resources for executing them, and other structures for supporting such computing resources are example components for providing the functionality described in the present disclosure.

[0130] The techniques described herein can be implemented in electronic hardware, computer software, firmware, or any combination thereof. Such techniques can be implemented in any of various devices such as a general purpose computer, a wireless communication device handset, or an integrated circuit device having many uses including application in wireless communication device handsets and other devices. Any features described as modules or components can be implemented together in an integrated logic device or separately as discrete but interoperable logic devices. If implemented in software, the techniques can be realized at least in part by a computer-readable data storage medium comprising program code including instructions that, when executed, performs one or more of the methods, algorithms and / or operations described above. The computer-readable data storage medium can form part of a computer program product, which can include packaging materials. The computer-readable medium can comprise memory or data storage media, such as random access memory (RAM) such as synchronous dynamic random access memory (SDRAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, and the like. Additionally or alternatively, the techniques can be realized at least in part by a computer-readable communication medium that carries or communicates program code in the form of instructions or data structures and that can be accessed, read, and / or executed by a computer, such as a propagated signal or wave.

[0131] The program code can be executed by a processor, which can include one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application-specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Such a processor can be configured to perform any of the techniques described in this disclosure. A general-purpose processor can be a microprocessor; but in the alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Accordingly, the term “processor,” as used herein can refer to any of the foregoing structure, any combination of the foregoing structure, or any other structure or apparatus suitable for implementation of the techniques described herein.

[0132] Those of ordinary skill in the art will appreciate that the less than (<) and greater than (>) symbols or terms used herein can be replaced with less than or equal to (≤) and greater than or equal to (≥) symbols, respectively, without departing from the scope of this description.

[0133] Where components are described as being "configured to" perform certain operations, such configuration can be accomplished, for example, by designing electronic circuits or other hardware to perform the operation, by programming programmable electronic circuits (e.g., microprocessors, or other suitable electronic circuits) to perform the operation, or any combination thereof.

[0134] The phrase "coupled to" or "communicatively coupled to" means that any component is either directly or indirectly physically connected to another component, and / or any component is either directly or indirectly in communication with another component (e.g., connected to the other component through a wired or wireless connection and / or other suitable communication interface).

[0135] Claim language or other language reciting a set of "at least one of' and / or a set of "one or more of' indicates that a member of the set or members of the set satisfy the claims in any combination. For example, claim language reciting "at least one of A and B" or "at least one of A or B" means A, B, or A and B. In another example, claim language reciting "at least one of A, B, and C" or "at least one of A, B, or C" means A, B, C, or A and B, or A and C, or B and C, or A and B and C. Language reciting a set of "at least one of' and / or a set of "one or more of' does not limit the set to the items listed. For example, claim language reciting "at least one of A and B" or "at least one of A or B" can mean A, B, or A and B, and can additionally include items not listed in the set of A and B.

[0136] Exemplary aspects of the present disclosure include:

[0137] Aspect 1. A method for providing access to one or more execution environments, the method comprising: receiving, from a first virtual machine (VM) of a plurality of VMs, a listen call, wherein the listen call registers a listener call context of the first VM with a callback service of a trusted execution environment (TEE); returning, to the first VM, a return code indicating that no callback request is available for the first VM, wherein the return code causes the first VM to put the listener call context to sleep; receiving, from a second VM of the plurality of VMs, a call, wherein the call from the second VM makes a service request to a VM service of the first VM; returning, to the second VM, a wake-up return code configured to wake up the listener call context of the first VM; sending, to the VM service of the first VM, a callback request corresponding to the service request made by the second VM; and receiving, from the VM service of the first VM, a response call indicating a callback response to the callback request.

[0138] Aspect 2. The method of aspect 1, wherein the callback response comprises an output generated using the VM service of the first VM to process the service request made by the second VM.

[0139] Aspect 3. The method of any of aspects 1-2, wherein one or more of the call from the second VM or the response call from the VM service of the first VM comprises a secure monitor call (SMC).

[0140] Aspect 4. The method of any of aspects 1-3, wherein: the return code is returned to the listening call from the first VM; and the return code is a secure monitor call (SMC) wait queue sleep return code.

[0141] Aspect 5. The method of any of aspects 1-4, wherein the wake-up return code is a secure monitor call (SMC) wait queue wake-up return code.

[0142] Aspect 6. The method of any of aspects 1-5, wherein returning the wake-up return code to the second VM comprises: receiving, by a hypervisor associated with the plurality of VMs, the wake-up return code from the TEE; and signaling, by the hypervisor, an interrupt request (IRQ) to the first VM, wherein the interrupt request wakes up the listener call context of the first VM.

[0143] Aspect 7. The method of aspect 6, wherein the hypervisor signals the IRQ to a secure monitor call (SMC) driver of the first VM or a TEE communication driver associated with the first VM.

[0144] Aspect 8. The method of any of aspects 6-7, wherein: the IRQ is associated with the listener call context of the first VM or a TEE communication driver associated with the first VM; and waking up the listener call context of the first VM causes the listener call context to resume and listen for queued service requests to the VM service of the first VM.

[0145] Aspect 9. The method of any of aspects 1-8, wherein: the callback request is received using the listener call context of the first VM; the callback response is generated based on processing the callback request using the VM service of the first VM; and the response call indicating the callback response is sent to the TEE using the listener call context of the first VM.

[0146] Aspect 10. The method of any of aspects 1 to 9, wherein the TEE returns the return code to the VM based on determining that no callback request associated with the first VM is posted in the TEE.

[0147] Aspect 11. The method of any of aspects 1 to 10, wherein the return code indicating that no callback request is available for the first VM is a secure monitor call (SMC) sleep return code.

[0148] Aspect 12. The method of any of aspects 1 to 11, wherein sending the callback request to the TEE registers the VM with an arbitrary destination callback enablement (ADCI) service of the TEE.

[0149] Aspect 13. The method of any of aspects 1 to 12, wherein the call from the second VM returns to sleep in the second VM before the VM service of the first VM executes.

[0150] Aspect 14. The method of aspect 13, wherein the TEE sends the callback request to the first VM based on determining that the call from the second VM has returned to sleep.

[0151] Aspect 15. The method of any of aspects 1 to 14, wherein the plurality of VMs and the TEE are executing on a same computing device.

[0152] Aspect 16. The method of any of aspects 1 to 15, wherein the listening call registers the listener call context with a VM service handler of the first VM.

[0153] Aspect 17. An apparatus for providing access to one or more execution environments, the apparatus comprising: at least one memory; and at least one processor coupled to the at least one memory and configured to: receive, from a first virtual machine (VM) of a plurality of VMs, a listen call, wherein the listen call registers a listener call context of the first VM with a callback service of a trusted execution environment (TEE); return, to the first VM, a return code indicating that no callback request is available for the first VM, wherein the return code causes the first VM to put the listener call context to sleep; receive, from a second VM of the plurality of VMs, a call, wherein the call from the second VM makes a service request to a VM service of the first VM; return, to the second VM, a wake-up return code configured to wake up the listener call context of the first VM; send, to the VM service of the first VM, a callback request corresponding to the service request made by the second VM; and receive, from the VM service of the first VM, a response call indicating a callback response to the callback request.

[0154] Aspect 18. The apparatus of Aspect 17, wherein the callback response comprises output generated using the VM service of the first VM to process the service request made by the second VM.

[0155] Aspect 19. The apparatus of any one of Aspects 17 to 18, wherein one or more of the call from the second VM or the response call from the VM service of the first VM comprises a secure monitor call (SMC).

[0156] Aspect 20. The apparatus of any one of Aspects 17 to 19, wherein the at least one processor is configured to: return, to the listen call from the first VM, the return code; wherein the return code is a secure monitor call (SMC) wait queue sleep return code.

[0157] Aspect 21. The apparatus of any one of Aspects 17 to 20, wherein the wake-up return code is a secure monitor call (SMC) wait queue wake-up return code.

[0158] Aspect 22. The apparatus of any one of Aspects 17 to 21, wherein to return the wake-up return code to the second VM, the at least one processor is configured to: receive, by a hypervisor associated with the plurality of VMs from the TEE, the wake-up return code; and signal, by the hypervisor, an interrupt request (IRQ) to the first VM, wherein the interrupt request wakes up the listener call context of the first VM.

[0159] Aspect 23. The apparatus of aspect 22, wherein the at least one processor is configured to signal the IRQ to a secure monitor call (SMC) driver of the first VM or a TEE communication driver associated with the first VM by the hypervisor.

[0160] Aspect 24. The apparatus of any one of aspects 22 to 23, wherein: the IRQ is associated with the listener call context of the first VM or a TEE communication driver associated with the first VM; and to wake up the listener call context of the first VM, the at least one processor is configured to cause the listener call context to resume and listen for queued service requests for the VM service of the first VM.

[0161] Aspect 25. The apparatus of any one of aspects 17 to 24, wherein the at least one processor is configured to receive the callback request using the listener call context of the first VM, generate the callback response based on processing the callback request using the VM service of the first VM, and send the response call indicating the callback response to the TEE using the listener call context of the first VM.

[0162] Aspect 26. The apparatus of any one of aspects 17 to 25, wherein the at least one processor is configured to return the return code to the VM by the TEE based on determining that no callback request associated with the first VM is posted in the TEE.

[0163] Aspect 27. The apparatus of any one of aspects 17 to 26, wherein the return code indicating that no callback request is available for the first VM is a secure monitor call (SMC) sleep return code.

[0164] Aspect 28. The apparatus of any one of aspects 17 to 27, wherein to send the callback request to the TEE, the at least one processor is configured to register the VM with an arbitrary destination callback enablement (ADCI) service of the TEE.

[0165] Aspect 29. The apparatus of any one of aspects 17 to 28, wherein the at least one processor is configured to return the call from the second VM to sleep in the second VM prior to execution of the VM service of the first VM.

[0166] Aspect 30. The apparatus of Aspect 29, wherein the at least one processor is configured to send, by the TEE to the first VM, the callback request based on determining that the call from the second VM has returned to dormancy.

[0167] Aspect 31. The apparatus of any of Aspects 17 to 30, wherein the plurality of VMs and the TEE are executing on a same computing device.

[0168] Aspect 32. The apparatus of any of Aspects 17 to 31, wherein the listening call registers the listener call context with a VM service handler of the first VM.

[0169] Aspect 33. A non-transitory computer-readable storage medium comprising instructions stored thereon that, when executed by at least one processor, cause the at least one processor to perform operations in accordance with any of Aspects 1 to 16.

[0170] Aspect 34. A non-transitory computer-readable storage medium comprising instructions stored thereon that, when executed by at least one processor, cause the at least one processor to perform operations in accordance with any of Aspects 17 to 32.

[0171] Aspect 35. An apparatus comprising one or more means for performing operations in accordance with any of Aspects 1 to 16.

[0172] Aspect 36. An apparatus comprising one or more means for performing operations in accordance with any of Aspects 17 to 32.

Claims

1. A method for providing access to one or more execution environments, the method comprising: receiving a listener call from a first VM among a plurality of virtual machines (VMs), wherein the listener call registers a listener call context of the first VM with a callback service of a trusted execution environment (TEE); returning a return code to the first VM indicating that no callback request is available for the first VM, wherein the return code causes the first VM to put the listener call context to sleep; receiving a call from a second VM among the plurality of VMs, wherein the call from the second VM makes a service request for a VM service of the first VM; Returning a wakeup return code of the listener call context configured to wake up the first VM to the second VM; sending a callback request corresponding to the service request made by the second VM to the VM service of the first VM; as well as A response call is received from the VM service of the first VM indicating a callback response to the callback request. 2 . The method of claim 1 , wherein the callback response comprises using the VM service of the first VM to process output generated by the service request made by the second VM. 3 . The method of claim 1 , wherein one or more of the call from the second VM or the response call from the VM service of the first VM comprises a security monitor call (SMC).

4. The method according to claim 1, wherein: The return code is returned to the listen call from the first VM; and The return code is a secure monitor call (SMC) wait queue sleep return code. 5 . The method of claim 1 , wherein the wakeup return code is a secure monitor call (SMC) wait queue wakeup return code.

6. The method of claim 1 , wherein returning the wakeup return code to the second VM comprises: receiving, by a hypervisor associated with the plurality of VMs, the wakeup return code from the TEE; as well as An interrupt request (IRQ) is signaled by the hypervisor to the first VM, wherein the interrupt request wakes up the listener call context of the first VM. 7 . The method of claim 6 , wherein the hypervisor signals the IRQ to a secure monitor call (SMC) driver of the first VM or a TEE communication driver associated with the first VM.

8. The method according to claim 6, wherein: The IRQ is associated with the listener call context of the first VM or a TEE communication driver associated with the first VM; and The listener call context of the first VM is woken up so that the listener call context is restored and listens for queued service requests for the VM service of the first VM.

9. The method according to claim 1, wherein: The callback request is received using the listener call context of the first VM; The callback response is generated based on processing the callback request using the VM service of the first VM; and The response call indicating the callback response is sent to the TEE using the listener call context of the first VM.

10. The method of claim 1, wherein the TEE returns the return code to the VM based on determining that a callback request associated with the first VM is not issued in the TEE.

11. The method of claim 1, wherein the return code indicating that no callback request is available for the first VM is a secure monitor call (SMC) sleep return code.

12. The method of claim 1, wherein sending the callback request to the TEE registers the VM with an Arbitrary Target Callback Initiation (ADCI) service of the TEE.

13. The method of claim 1, wherein the call from the second VM returns to sleep in the second VM before the VM service of the first VM executes.

14. The method of claim 13, wherein the TEE sends the callback request to the first VM based on determining that the call from the second VM has returned to sleep.

15. The method of claim 1, wherein the plurality of VMs and the TEE are executed on the same computing device.

16. The method of claim 1, wherein the listener call registers the listener call context for a VM service handler of the first VM.

17. An apparatus for providing access to one or more execution environments, the apparatus comprising: at least one memory; and at least one processor coupled to the at least one memory and configured to: receiving a listener call from a first VM among a plurality of virtual machines (VMs), wherein the listener call registers a listener call context of the first VM with a callback service of a trusted execution environment (TEE); returning a return code to the first VM indicating that no callback request is available for the first VM, wherein the return code causes the first VM to put the listener call context to sleep; receiving a call from a second VM among the plurality of VMs, wherein the call from the second VM makes a service request for a VM service of the first VM; returning a wakeup return code configured to wake up the listener call context of the first VM to the second VM; sending a callback request corresponding to the service request made by the second VM to the VM service of the first VM; as well as A response call is received from the VM service of the first VM indicating a callback response to the callback request.

18. The apparatus of claim 17, wherein the callback response comprises using the VM service of the first VM to process output generated by the service request made by the second VM.

19. The apparatus of claim 17, wherein one or more of the call from the second VM or the response call from the VM service of the first VM comprises a security monitor call (SMC).

20. The apparatus of claim 17, wherein the at least one processor is configured to: Returning the return code to the listening call from the first VM; The return code is a security monitor call (SMC) wait queue sleep return code.

21. The apparatus of claim 17, wherein the wakeup return code is a secure monitor call (SMC) wait queue wakeup return code.

22. The apparatus of claim 17, wherein to return the wakeup return code to the second VM, the at least one processor is configured to: receiving, by a hypervisor associated with the plurality of VMs, the wakeup return code from the TEE; and An interrupt request (IRQ) is signaled by the hypervisor to the first VM, wherein the interrupt request wakes up the listener call context of the first VM.

23. The apparatus of claim 22, wherein the at least one processor is configured to: The IRQ is signaled by the hypervisor to a secure monitor call (SMC) driver of the first VM or a TEE communication driver associated with the first VM.

24. The apparatus of claim 22, wherein: The IRQ is associated with the listener call context of the first VM or a TEE communication driver associated with the first VM; and To wake up the listener call context of the first VM, the at least one processor is configured to cause the listener call context to resume and listen for queued service requests for the VM service of the first VM.

25. The apparatus of claim 17, wherein the at least one processor is configured to: receiving the callback request using the listener call context of the first VM; generating the callback response based on processing the callback request using the VM service of the first VM; and The response call indicating the callback response is sent to the TEE using the listener call context of the first VM.

26. The apparatus of claim 17, wherein the at least one processor is configured to: The return code is returned by the TEE to the VM based on determining that the callback request associated with the first VM is not issued in the TEE.

27. The apparatus of claim 17, wherein the return code indicating that no callback request is available for the first VM is a secure monitor call (SMC) sleep return code.

28. The apparatus of claim 17, wherein to send the callback request to the TEE, the at least one processor is configured to register the VM with an Arbitrary Target Callback Initiation (ADCI) service of the TEE.

29. The apparatus of claim 17, wherein the at least one processor is configured to return the call from the second VM to sleep in the second VM before the VM service of the first VM executes.

30. The apparatus of claim 29, wherein the at least one processor is configured to: The callback request is sent, by the TEE, to the first VM based on determining that the call from the second VM has returned to sleep.

Images