Device simulation in a secure mode supported by hardware architectures

A secure mode of a computer system is used to provide simulated devices. In operation, if an instruction executing in a non-secure mode accesses a simulated device, then a resulting exception is forwarded to a secure monitor executing in the secure mode. Based on the address accessed by the instruction, the secure monitor identifies the device and simulates the instruction. The secure monitor executes independently of other applications included in the computer system, and does not rely on any hardware virtualization capabilities of the computer system.

BACKGROUND

Device simulation is used in computers system to mimic the behavior of missing or incompatible devices. In one approach to simulating devices, a hypervisor that supports execution of virtual machines (VMs) also performs device simulation. In such systems, if a VM attempts to access a device, such as a serial port, then the hypervisor traps the access and simulates the device. However, other computer systems may not include hypervisors because a hypervisor is not running or the hardware does not have a hypervisor mode, or the hypervisor itself requires the use of a simulated device. Consequently, a more general and flexible approach to simulating devices in computer systems with or without hypervisors is desirable.

SUMMARY

One or more embodiments provide techniques to provide simulated devices in a computer system operable in both a secure operating mode and a non-secure operating mode. A method of simulating a device according to an embodiment includes the steps of receiving an exception caused by a non-secure instruction, and in response, executing secure operations to determine a memory address accessed by the non-secure instruction; determining that the memory address is included in a set of memory addresses associated with the device; and performing secure simulation operations based on the non-secure instruction.

DETAILED DESCRIPTION

FIG. 1is a block diagram of a computer system that is configured to simulate devices according to one or more embodiments. Computer system100may be constructed on a desktop, laptop or server grade hardware platform102, such as a 64-bit ARM® server. As shown, hardware platform102includes, inter alia, one or more central processing units (CPU)103, memory104, and devices182. Within hardware platform102, any number and combination of units, such as CPU103and memory104, are coupled via system bus184. Hardware platform102also includes other standard hardware components such as network interface controllers (not shown) that connect computer system100to a network and one or more bus adapters (not shown) that connect computer system100to a persistent storage device, illustrated herein as storage system160.

Hardware platform102operates in one of two distinct modes: a secure mode and a non-secure mode. Many advanced hardware platforms provide mechanisms to invoke trusted execution environments, such as the secure mode, to protect assets from software and hardware attack. However, the implementation details of the hardware platform and interfaces to the secure operating mode often differ across vendors and architectures. It should be recognized that the techniques described herein are illustrative rather than restrictive.

A secure configuration register186included in hardware platform102indicates whether hardware platform102is operating in secure mode or non-secure mode. The scope of this operating mode extends across hardware platform102, encompassing CPU103and other components such as devices182and system bus184. Notably, software executing on CPU103in secure mode is independent of software executing on CPU103in non-secure mode. Further, software running in secure mode has more extensive access and privileges with respect to hardware platform102than software running in non-secure mode. For instance, hardware platform102enables software running in secure mode to respond to certain exceptions, such as external abort exceptions. By contrast, hardware platform102precludes software running in non-secure mode to generate effective responses to external abort exceptions.

An exemplary computer system100that may implement this method includes an ARM® Cortex®-A57 (based on the ARM®v8 architecture) CPU103. The ARM® Cortex®-A57 supports TrustZone security extensions that provide both non-secure and secure modes of operation. The ARM® Cortex®-A57 is commercially available from ARM Holdings of Cambridge, United Kingdom. It should be recognized that the techniques described herein are illustrative rather than restrictive. In particular, alternate embodiments include any CPU103that supports two independent modes of operation that may be leveraged in a similar fashion to the disclosed techniques.

In conventional usage, secure mode is used to mitigate security concerns (e.g., confidentiality, integrity, authenticity, etc.). Advantageously, in hardware platform102, a secure monitor190is a software module installed on top of hardware platform102to execute in secure mode, so that it can exploit capabilities unavailable in non-secure mode and provide device simulation capability. In one embodiment, secure monitor190operates transparently to a hypervisor and/or operating system (hypervisor/OS)114. In operation, secure monitor190responds to memory accesses to “simulated” devices that are not backed by hardware platform102, generating appropriate responses transparently to non-secure units and non-secure software executing in hardware platform102. Further, unlike many conventional approaches to simulation, secure monitor190does not rely on hardware virtualization capabilities of CPU103. It should be recognized that the techniques disclosed herein may be extended to other computer systems that enable a secure and non-secure operating mode.

Hypervisor/OS114is also installed on top of hardware platform102, and CPU103executes hypervisor/OS114in non-secure mode. Notably, secure monitor190supports device simulation for programs executing in non-secure mode on hardware platform102, such as hypervisor/OS114. One example of a hypervisor that may be used is included as component of VMware® vSphere™, and one example of an operating system is the Linux OS. It should be recognized that the various terms, layers and categorizations used to describe the components inFIG. 1may be referred to or arranged differently. It should further be recognized that other computer systems are contemplated, such as hosted virtual machine systems, where a hypervisor is implemented in conjunction with an operating system.

CPU103has a memory management unit (MMU)105that carries out the mappings from virtual addresses into physical addresses. If a virtual address unmapped by MMU105is accessed, then a page fault is issued. If a physical address is not backed by hardware platform102, then an “external abort” is issued. To facilitate device simulation, accesses to physical addresses that are not backed by memory104or physical devices are configured to trap into secure monitor190. Subsequently, if secure monitor190determines that the accessed address range does not correspond to a simulated device, then secure monitor190reflects an invalid access to hypervisor/OS114that initiated the associated non-secure instruction. By contrast, if secure monitor190determines that the accessed address range corresponds to a simulated device, then secure monitor190responds to the associated non-secure instruction, mimicking the expected behavior.

To enable secure monitor190to correctly identify the non-secure instruction that corresponds to each access to a simulated device, accesses to the address ranges for which secure monitor190provides simulated devices are performed synchronously with the non-secure instructions. More specifically, accesses to such address ranges are performed without any reordering, buffering, or caching. Specifying memory access patterns in such a manner may be done in any technically feasible fashion, such as configuring page table entry flags in MMU105.

FIGS. 2A and 2Bare conceptual diagrams that illustrate a secure configuration register186, a non-secure mode230, and a secure mode232, according to one or more embodiments. Secure configuration register186defines the current state of CPU103, including whether CPU103is executing software in non-secure mode230or secure mode232. Secure configuration register186operates in conjunction with any number (including zero) of other registers included in hardware platform102to define execution flow upon external abort exceptions. As is well known in the art, CPU103generates an external abort exception in response to an attempted access to an address in memory104that is not backed by any hardware included in hardware platform102, such as an address that lies within a simulated region.

As shown inFIG. 2A, secure configuration register186includes, inter alia, a non-secure bit (NS)214and an external abort bit (EA)212. If non-secure bit214is set (i.e., equals 1), then hardware platform102is in non-secure mode230. If non-secure bit214is clear (i.e., equals 0), then hardware platform102is in secure mode232. External abort bit212dictates execution flow following an external abort exception. If external abort212is set, then an external abort exception is processed by a default hypervisor/OS external abort handler. Advantageously, if external abort212is clear, then an external abort exception is processed by a secure mode external abort handler executing in secure mode232.

The left side ofFIG. 2Bdepicts hardware platform102in non-secure mode230, whereas the right side ofFIG. 2Bdepicts hardware platform102in secure mode232. The two sides ofFIG. 2Bare shown separated by a dotted line. As shown inFIG. 2A, external abort bit212and non-secure bit214are included in secure configuration register186. InFIG. 2B, for explanatory purposes only, non-secure bit214is displayed independently of secure configuration register186. External abort212is clear in both non-secure mode230and secure mode232. By contrast, non-secure bit214is set in non-secure mode230and is clear in secure mode232.

Upon power-up of hardware platform102, a platform firmware210executes in secure mode232and then transitions hardware platform102to non-secure mode230. As part of the power-up process, platform firmware210performs various initializations functions such as installing security measures, installing hypervisor/OS114, and installing secure monitor190. In various embodiments, the functionality of platform firmware210, hypervisor/OS114, and/or secure monitor190may be consolidated into a single unit or distributed into additional units. During initialization, platform firmware210configures secure configuration register186and any number of other registers to forward external abort exceptions generated in non-secure mode230to secure monitor190executing in secure mode232.

Hypervisor/OS114executes in non-secure mode230. By contrast, secure monitor190executes in secure mode232, receiving forwarded external abort exceptions and providing simulation for those external abort exceptions intended for simulated devices without leveraging hardware virtual capabilities. Further, hypervisor/OS114and secure monitor190execute independently of each other. Consequently, both hypervisor/OS114and secure monitor190may effectively operate within hardware architectures such as ARM®v7 and ARM®v8.

FIGS. 3A and 3Bare conceptual diagrams that illustrate mapping and simulating devices according to one or more embodiments. As shown inFIG. 3A, memory104includes a device-backed region310, an unbacked region315, and a simulated region320. In general, memory104may include any number of device-backed regions310, unbacked regions315, and/or simulated regions320. Further, each region in memory104may include any number of addresses. Device-backed region310and simulated region320are depicted as consecutive ranges of addresses, organized into frames. However, it should be understood that each region, such as simulated region320, may include as few as one address. Further, some embodiments may not include any device-backed regions310and/or unbacked regions315.

In general, device-backed regions310correspond to memory104that is properly backed by hardware included in hardware platform102. For instance, an address in device-backed region310may correspond to a particular device182that is a physical unit within hardware platform102. By contrast, an address in unbacked region315corresponds to memory104that is not backed by hardware included in hardware platform102and not simulated by secure monitor190. An address in simulated region320corresponds to memory104that is not backed by hardware included in hardware platform102, but is simulated by secure monitor190. Addresses in simulated region320are configured for access as devices—enforcing a strong ordering within CPU103. As described in detail below, secure monitor190exploits the synchronization inherent in this strong ordering. Configuring addresses as devices may be accomplished in any technically feasible fashion that is consistent with the semantics of CPU103, such as manipulating MMU mapping flags.

FIG. 3Bdepicts the processing of a non-secure instruction325that causes an external abort exception335. Non-secure instruction325may be issued by any software executing on a processor, such as CPU103, included in hardware platform102. Upon receiving non-secure instruction325, CPU103determines that the address associated with non-secure instruction325is not within device-backed region310and generates external abort exception335in non-secure mode230. Hardware platform102then transitions to secure mode232, and secure monitor190receives external abort exception335.

Secure monitor190includes, without limitation, an address analyzer392, an instruction decoder395, and a simulation state machine396. Address analyzer392determines whether the memory access that caused external abort exception335was to an address in simulated region320. If address analyzer392determines that the address is not in simulated region320, then secure monitor190generates a secure monitor response350indicating an error, hardware platform102returns to non-secure mode230, and hypervisor/OS114completes appropriate abort behavior.

However, if address analyzer392determines that external abort exception335was caused by an access to an address included in simulated region320, then instruction decoder394interprets non-secure instruction325. Since simulated region320is configured as device memory104, non-secure instruction325, external abort exception335, and the address accessed by non-secure instruction325are all in-sync with each other. In-sync means that the exception355occurs with the defaulting instruction pointer at the memory access instruction causing the exception355. Instruction decoder394leverages this synchronization to accurately identify non-secure instruction325. After instruction decoder394parses non-secure instruction325, simulation state machine396performs one or more simulation operations that mimic the behavior expected of the appropriate physical device.

Simulation state machine396may include simulation functionality for any number of simulated devices. Further, secure monitor190may include any number of simulations state machines396, each corresponding to a different simulated device. In alternate embodiments, simulation state machine396may be replaced with any combination of software, firmware, and/or hardware that reproduces any subset of device functionality. For example, simulation state machine396may be replaced with a bus functional model. Further, the functionality included in secure monitor190may be included in any number of software, firmware, and/or hardware units in any combination. In one embodiment, address analyzer392, instruction decoder394, and simulation state machine396are combined into a single piece of software.

Because the techniques disclosed herein decouple secure monitor190from hypervisor/OS114, these techniques may reduce porting efforts for hypervisors/OSes114in future computer systems with unsupported or radically different devices182and models. In general, it should be recognized that the approaches disclosed herein are illustrative rather than restrictive, and may be altered without departing from the broader spirit and scope of the invention.

FIG. 4depicts a flow diagram that illustrates a method that includes the steps of configuring device simulation in secure mode232of hardware, according to an embodiment. An exemplary computer system100that may implement this method includes an ARM® Cortex®-A57 (based on the ARM® v8 architecture) CPU103and a VMware® vSphere™ product hypervisor114. As previously disclosed herein, ARM® Cortex®-A57 supports TrustZone security extensions that provide secure mode232for secure monitor190and non-secure mode230for non-secure components (e.g., hypervisor/OS114).

This method begins at step403, where CPU103starts (i.e., boots, initiates after reset, powers-up, etc.) in secure mode232. In general, to minimize opportunities for illicit tampering of computer system100, CPU103is designed to start in secure mode232and perform any secure boot protocols that protect computer system100. At step405, platform firmware210installs secure monitor190. In some embodiments platform firmware210is included in hypervisor/OS114. In other embodiments, platform firmware210installs both hypervisor/OS114and secure monitor190. Further, in some embodiments, platform firmware210complies with a unified extensible firmware interface (UEFI).

At step407, platform firmware210configures CPU103to forward external abort exceptions335generated in non-secure mode230to secure monitor190executing in secure mode232. In operation, hardware platform102prohibits software executing in non-secure mode230, such as hypervisor/OS114, from responding to external abort exceptions335with device simulation operations. Advantageously, because secure monitor190executes in secure mode232, hardware platform102permits secure monitor190to handle external abort exceptions335in a flexible manner, including performing device simulation operations in secure mode232.

At step409, platform firmware configures addresses in simulated region320for access as devices. Configuring addresses in simulated region320implies the strongest ordering available in CPU103. This strong ordering ensures that attempted accesses to simulated region320in memory104generate external abort exceptions335that are synchronous with respect to non-secure instructions325associated with the attempted accesses. In particular, CPU103does not perform caching or buffering operations that may perturb the ordering of such accesses relative to non-secure instructions325.

Simulated region320corresponds to addresses of “simulated” devices for which secure monitor190provides functionality. Memory104may include any number of simulated regions320, each simulated region320may include any number of addresses corresponding to any number of simulated devices, and secure monitor190may provide functionality for any number of simulated devices. In general, platform firmware210configures memory104with simulated regions320that correspond to addresses for which secure monitor190is configured to provide constructive secure monitor responses350, such as device simulation operations.

After platform firmware210finishes installing and configuring secure monitor190, hypervisor/OS114, and/or any initial security measures, platform hardware210causes CPU103to transition from secure mode232to non-secure mode230(step411). As part of step411, platform firmware210sets non-secure bit214included in secure configuration register186and relinquishes control to hypervisor/OS114. At step413, hypervisor/OS114launches in non-secure mode230. At step415, secure monitor190executes in secure mode232. If hypervisor/OS114issues non-secure instruction325accessing memory104that is not backed by hardware platform102, including simulated regions320, then CPU103issues external abort exception335. External abort exception335is forwarded to secure monitor190executing in secure mode232—operating independently of hypervisor/OS114. If the attempted access is to an address located within simulated region320, then secure monitor190(executing in secure mode232) performs simulation operations that mimic processing of non-secure instruction325by the appropriate device. Subsequently, secure monitor190returns control to hypervisor/OS114installed on top of hardware platform102(executing in non-secure mode230), indicating successful execution of non-secure instruction325.

FIG. 5depicts a flow diagram that illustrates a method that includes the steps of simulating devices that are not backed by hardware. In the embodiment illustrated herein, CPU103is configured to forward external abort exceptions335caused by non-secure instructions325to secure monitor190. In a complementary fashion to the method detailed inFIG. 4, an exemplary computer system100that may implement this method includes an ARM® Cortex®-A57 (based on the ARM® v8 architecture) CPU103and hypervisor/OS114. In general, prior to the execution of this method, CPU103is configured to forward external abort exceptions335caused by hypervisor/OS114executing on top of hardware platform102in non-secure mode230to secure monitor190executing in secure mode232.

This method begins at step503where hypervisor/OS114attempts to access an address that is not backed by hardware platform102. This attempt occurs as part of processing non-secure instruction325that addresses a portion of memory104that lies within unbacked region315or simulated region320. At step505, CPU103generates external abort exception335. At step507, CPU103forwards external abort exception335to secure monitor190. As part of step507, CPU103transitions from non-secure mode230to secure mode232, clearing non-secure bit214included in secure configuration register186.

After secure monitor190receives external abort exception335(step509), address analyzer392performs one or more comparison operations to determine whether the address associated with external abort exception335is included in simulated region320of memory104. Advantageously, external abort exception335is a synchronous exception and, as part of initializing computer system100, addresses within simulated region320were configured for access as hardware devices. Consequently, computer system100does not execute operations, such as buffering and caching, that might cause non-secure instruction325and/or the address associated with non-secure instruction325to become out-of-sync with external abort exception335.

Notably, memory104may include any number of simulated regions320and each simulated region320may be associated with a different simulated device. Further, address analyzer392may determine the address associated with external abort exception335using any technique as known in the art. In some embodiments, address analyzer392may partially or completely decode non-secure instruction325and perform one or more read operations on registers to ascertain the address associated with external abort exception335.

If, at step509, address analyzer392determines that the address associated with external abort exception335is not included in simulated region320, then the method proceeds to step511. At step511, secure monitor190returns control to hypervisor/OS114, indicating an error condition appropriate to external abort exception335. As part of step511, CPU103transitions from secure mode232to non-secure mode230, setting non-secure bit314included in secure configuration register186. In this fashion, secure monitor190handles external abort exceptions335associated with unbacked regions315of memory104both properly and transparently to hypervisor/OS114. This method then ends.

At step509, if address analyzer392determines that the address associated with external abort exception335is included in simulated region320, then the method proceeds to step513. At step513, instruction decoder394decodes non-secure instruction325that caused external abort exception335. In some embodiments, address analyzer293may perform step513as part of determining the address that caused external abort exception (step509), and this method may skip step513. Instruction decoder394may identify and decode non-secure instruction325in any technically feasible fashion. In alternate embodiments, the functionality included in address analyzer392and instruction decoder394may be combined or further subdivided into any number of units.

After decoding specific non-secure instruction325that caused external abort exception335, simulation state machine396performs one or more finite state operations designed to mimic functionality of a physical device associated with non-secure instruction325—generating secure monitor response350(step515). For instance, suppose that non-secure instruction325were intended to transmit data to a 16550 universal asynchronous receiver/transmitter (UART) that is not included in computer system100but is simulated by secure monitor190. In such a scenario, simulation state machine396would execute finite state machine operations to generate secure monitor response350that imitated the expected response of a physical 16550 UART.

After simulating non-secure instruction325, at step517, secure monitor190returns control to hypervisor/OS114, indicating a successful execution of non-secure instruction325and, consequently, resolution of external abort exception335. Notably, if non-secure instruction325involves a “read data from device” operation, then simulating non-secure instruction325also includes updating a retuned-to-CPU103register state. As part of step517, CPU103transitions from secure mode232to non-secure mode230, setting non-secure bit314included in secure configuration register186. In this fashion, secure monitor190handles external abort exceptions335associated with simulated region320of memory104both properly and transparently to hypervisor/OS114. Notably, secure monitor190may be configured to simulate any number of devices. This method then ends.

Although not shown inFIG. 5, after this method completes, hypervisor/OS114continues to process non-secure instructions325. If hypervisor/OS114again attempts to access an address that is not backed by hardware platform102, then this method is repeated. Further, similar flows may be used to provide functionality beyond simulating devices. For example, the disclosed approach enables modelling non-existing hardware interfaces, such as timers and bus topologies, and shimming away non-standard devices as compatible devices, such as presenting the proprietary ARM® PL011 UART as an industry standard NS1655 UART. In some embodiments, the techniques outlined herein facilitate tracing and debugging hypervisor device driver accesses to hardware platform102.