Memory deallocation across trust boundaries

Abstract

A memory deallocation method across a trust boundary between a first software component and a second software component is described. Some memory is shared between the first software component and the second software component. A messaging facility in the memory is implemented using the shared memory. The first software component is used to deallocate memory from the shared memory that has been allocated by the second software component. The deallocation is done by freeing at least one allocation from the messaging facility and releasing the at least one allocation using a local deallocation mechanism while verifying that memory accesses to memory owned by a data structure related to the memory allocation within the shared memory are within the shared memory.

Description

Background Technology

[0001] Trust boundaries are found between two software components where the individual components trust each other to varying degrees. In one example, both software components are trusted by a third party, but they do not trust each other. In another example, the first software component is trusted by a third party, and the second software component is not trusted by the same third party.

[0002] Typically, cross-domain communication (CDMA) mechanisms are used to facilitate communication between two software components when a trust boundary exists between them. However, CDMA mechanisms are computationally expensive and / or introduce latency. In one example, where the trust boundary involves transitioning from a trusted execution environment state to an insecure state while deploying side-channel mitigation, CDMA mechanisms introduced approximately 40,000 computation cycles. In another example where the trust boundary spans two virtual machines, CDMA mechanisms involved using a scheduler, which introduced approximately 10 milliseconds of latency.

[0003] The embodiments described below are not limited to implementations that address any or all of the drawbacks of known methods for memory deallocation across trust boundaries. Summary of the Invention

[0004] The following is a simplified summary of the invention disclosed to provide the reader with a basic understanding. 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. Its sole purpose is to present the selection of concepts disclosed herein in a simplified form as a prelude to the more detailed description that follows.

[0005] A method for memory deallocation across a trust boundary between a first software component and a second software component is described. Some memory is shared between the first and second software components. The messaging facility in the memory is implemented using shared memory. The first software component is used to deallocate memory from the shared memory that has been allocated by the second software component. Deallocation is accomplished by: releasing at least one allocation from the messaging facility; and releasing at least one allocation using a local deallocation mechanism while verifying that memory accesses to memory owned by data structures associated with memory allocation within the shared memory are within the shared memory.

[0006] Many of the accompanying features will be easier to understand as they become more readily apparent by referring to the following detailed description taken in conjunction with the accompanying drawings. Attached Figure Description

[0007] This description will be better understood through the following detailed description, taken in light of the accompanying drawings, in which:

[0008] Figure 1 These are schematic diagrams of various types of computing devices, in which software components are separated by trust boundaries, and the techniques disclosed herein are deployable;

[0009] Figure 2A This is a schematic diagram of the procedures within and outside the enclave;

[0010] Figure 2B This is a diagram illustrating a more secure virtual machine and a less secure virtual machine;

[0011] Figure 2C This is a diagram illustrating high-privilege and low-privilege libraries;

[0012] Figure 2D This is a schematic diagram of the first software component and the second software component;

[0013] Figure 3 This is a flowchart of a memory allocation method, in which a thread on one side of a trust boundary allocates memory to the other side of the trust boundary;

[0014] Figure 4 This is a flowchart of the method executed by the thread on the other side of the trust boundary to deallocate memory;

[0015] Figure 5 This is a flowchart of the method by which a thread on one side of the trust boundary deals with memory and executes verification.

[0016] Figure 6 This is a diagram illustrating the data structure used in an example of a message passing mechanism;

[0017] Figure 7 An exemplary computing-based device is illustrated, in which an embodiment of memory deallocation across trust boundaries is implemented.

[0018] In the accompanying drawings, the same reference numerals are used to designate the same parts. Detailed Implementation

[0019] The detailed description provided below, in conjunction with the accompanying drawings, is intended to describe this example and is not intended to represent the only form in which this example can be constructed or utilized. This description states the functionality of the example and the sequence of operations used to construct and operate the example. However, the same or equivalent functionality and sequence can be implemented through different examples.

[0020] Cross-domain communication mechanisms are typically used to facilitate communication between two software components when a trust boundary exists between them. However, these mechanisms are computationally expensive and / or introduce latency. Cross-domain communication mechanisms also impose synchronization. Therefore, dealing with memory allocation across a trust boundary is problematic—that is, using a first software component to deallocate memory already allocated by a second software component, where a trust boundary exists between the two components. Because of the imposed synchronization, it is difficult for the two software components to run concurrently without needing to synchronize memory allocation events.

[0021] Trust boundaries appear in many types of computing devices (such as Figure 1 Among the software components illustrated, these computing devices are end-user devices such as smartphones 110, laptops 112, smartwatches 120, tablets 114, and head-mounted augmented reality computing devices 122; as well as enterprise computing devices and cloud computing devices, such as computing nodes 116 in data centers. It should be noted that... Figure 1 The computing device illustrated is an example and is not intended to limit the scope of this technology.

[0022] Figure 1 Each computing device in the computing device includes a reference Figure 7 A detailed description of the various components. For clarity, Figure 1 Some, but not all, of these components of a single computing device are shown. Figure 1 The diagram illustrates a computing device in which each computing device has a memory 100 storing software components 102, which share a shared memory 118 and are separated by a trust boundary. The shared memory 118 stores messaging facilities 104. Each computing device also has one or more processors 106 and one or more interfaces 108, such as communication interfaces, to enable the computing device to communicate with external memory, other computing devices, communication networks, etc.

[0023] The technology disclosed herein has at least two software components 102 separated by a trust boundary, and non-limiting examples of these software components are referenced below. Figures 2A to 2D Given. Each software component executes one or more threads. Threads execute instructions sequentially on one side of the trust boundary and do not cross the trust boundary.

[0024] Software component 102 shared Figure 1Some memory is shown in 118. Each software component 102 is capable of allocating and deallocating memory blocks in shared memory 118. Each software component 102 has at least one allocator for shared memory. If a software component has memory outside of shared memory, then that software component has at least one allocator for the memory outside of shared memory. An allocator is a software component responsible for partitioning memory into objects that can be used by other components and reusing them upon return.

[0025] Shared memory 118 is used to implement messaging facility 104. Messaging facility allows messages to be sent between threads on either side of a trust boundary without using conventional cross-domain communication mechanisms. It uses in-memory operations, making messaging facility highly efficient compared to conventional cross-domain communication mechanisms. By using the messaging facility described herein, memory can be allocated and deallocated efficiently across trust boundaries in a secure manner. This technique has been usefully deployed in a variety of scenarios, some of which are referenced here. Figures 2A to 2D Describe it.

[0026] Software component 102 is separated by trust boundaries. Some memory visible to software component 102 is shared among two or more software components (shared memory 118, which is a region of memory 100). A messaging facility exists in the shared memory 118 region. Allocations are performed within shared memory 118 by any software component 102 sharing shared memory 118. Allocations within shared memory 118 are deallocated by any software component 102 sharing shared memory 118, regardless of which software component releases it (by passing it back to the owning software component using messaging facility 104).

[0027] Deallocation involves at least two operations: marking the memory segment as no longer in use and making the memory segment available for reuse. In a typical C-style programming environment, these two operations are usually combined (a call to free() typically marks the object as unused and immediately makes it available for reuse). The technique disclosed herein breaks these down into two steps, where the first step immediately triggers the second step for local allocation or adds it to a message queue for remote allocation, so that the remote allocator will make it available for reuse later.

[0028] Figure 2A This illustrates a scenario where the first software component is within enclave 200 and the second software component is program 202 located outside the enclave. Enclave 200 has access to some private memory, which is... Figure 2AThe rectangular representation depicts enclave 200. Programs outside enclave 202 can access some, but not all, of the memory. That is, enclave 200 and programs outside the enclave share some memory. In the example, the thread executing within the enclave is trusted, while the thread executing in the program outside the enclave is untrusted. In the example, the technique of this disclosure enables the thread within the enclave (referred to herein as green thread G for clarity) to allocate some memory within the shared memory using an allocator. In the example, the technique of this disclosure enables the thread within the enclave (thread G) to deallocate some memory within the shared memory that has been allocated by a thread in the program outside the enclave (thread R). This technique is symmetric. Therefore, the thread in the program outside the enclave (thread R) can deallocate some memory in the enclave allocated by thread G.

[0029] In such Figure 2A In the enclave system shown, code running within the enclave can view and modify external memory, and the external program 202 is responsible for all untrusted communication (e.g., retrieving encrypted data from disk or over a network). The external program 202 can pre-allocate memory buffers and rings that the enclave 200 can use for communication, but it is generally more convenient for the enclave 200 to be able to allocate arbitrary memory objects.

[0030] The technology disclosed herein enables enclave 200 to allocate memory outside enclave 200 at low cost (where low cost means less computing resources). Therefore, it is relatively easy for the allocator to dynamically adjust the amount of memory used by enclave 200 for communication, rather than pre-allocating everything. For this to be efficient, untrusted code running outside enclave 200 can release memory with low overhead. The technology of this invention enables program 202 outside enclave to release memory with low overhead.

[0031] Figure 2B This is a schematic diagram of a more secure virtual machine 204 and a less secure virtual machine 206. The more secure virtual machine has memory depicted by a larger rectangle, while the less secure virtual machine shares some, but not all, of the memory, such as... Figure 2B As indicated. This type of arrangement is found in some well-known operating systems, where the kernel is split into two parts protected by a hypervisor. The less trusted virtual machine runs the main operating system and normal applications. The more secure virtual machine runs integrity and security services and is able to view the memory owned by the less trusted virtual machine. The techniques disclosed herein remove some constraints on the code running in the more secure virtual machine and allow secure code to create complex data structures for the less secure code to consume.

[0032] Figure 2CThis is a schematic diagram of high-privilege library compartment 208 and low-privilege library compartment 210. High-privilege library compartment 208 has a memory area depicted by a larger rectangle, and low-privilege library compartment 210 shares some, but not all, of this memory, such as... Figure 2C As indicated.

[0033] In a differentiated software deployment, some parts of a program run with lower privileges. It's often desirable to move existing libraries to lower privileges to minimize the attack surface. For example, image and video decoding libraries are often written in insecure languages ​​and handle untrusted data, making them common vectors for exploitation. Running such libraries with a very limited set of privileges makes this significantly more secure.

[0034] Several mechanisms exist for easily implementing strong isolation, such as separate processes with shared memory, software-based fault isolation (SFI) sandboxes (e.g., those used by WebAssembly), and hardware isolation features. These impose a performance penalty on the transition between high-privilege and low-privilege library compartments. Each technique can be used to make the entire memory of an untrusted component visible to a trusted component.

[0035] This is sufficient as long as the library interface is implemented by taking and returning functions of only simple (primitive) types. Unfortunately, this rarely happens, and most libraries expect users to build or consume complex data structures. To improve the programming model for software differentiation, the techniques disclosed herein provide a lightweight capability for high-privilege components to allocate memory within low-privilege libraries, and for both the low-privilege and high-privilege libraries to release that memory.

[0036] Figure 2D This is a typical graph with trust boundaries (where the trust boundaries are not in...). Figure 2D The diagram shows a first software component 212 and a second software component 214. The first software component 212 has a memory depicted by a larger rectangle, and the second software component 214 shares some, but not all, of this memory, such as... Figure 2D As indicated. Using message passing facilities located in shared memory, the techniques of this disclosure enable threads to efficiently and safely deallocate memory, where memory has been allocated by different threads on the other side of a trust boundary.

[0037] Figure 3 This is a flowchart of a memory allocation method executed by thread G located on one side of the trust boundary, in order to allocate memory on the other side of the trust boundary. Figure 3 This is described for the case where thread G is on the more trusted side of the trust boundary. However, it's important to note that this method is symmetric and also applies when the thread executing this method is on the less trusted side of the trust boundary. Figure 3The method also operates in situations involving mutual distrust, where the thread executing the method is in a first software component and on the other side of the trust boundary is a second software component, wherein the first and second software components do not trust each other.

[0038] Thread G executes step 300 on one side of the trust boundary, such as the more trusted side of the trust boundary. During its execution, thread G reaches step 302, requesting the creation of an object in shared memory, which is shared with the other side of the trust boundary. Thread G checks step 304 whether it already has a local allocator. A local allocator is an allocator with its own region (data structures, including a virtual memory space mapped to physical memory) and metadata (recording which blocks are currently allocated in the virtual memory space). In some examples, the local allocator's virtual memory space is mapped to physical memory owned by the other side of the trust boundary. It's important to note that in systems without virtual memory, such as embedded devices where components have overlapping memory protection units (MPUs) protecting regions, the local allocator is a region of physical memory owned by the other side of the trust boundary. In preferred examples, the majority of the local allocator's state resides in private memory, rather than shared memory.

[0039] If there is no local allocator for thread G, then thread G reserves some space in shared memory for the message queue for use by software on the other side of the trust boundary. In some examples, the reservation is done using a shared pointer to a region in shared memory and an atomic operation. In other examples, the reservation is done using a cross-trust boundary call, which is expensive in terms of computation cycles and / or time, but is not performed frequently. The software on the other side of the trust boundary receives the cross-trust boundary call, reserves some space in shared memory, and notifies thread G.

[0040] If a local allocator exists for thread G, but the local allocator is too small to satisfy the allocation, then a cross-trust boundary synchronization operation is performed to reserve some memory in the shared area.

[0041] Thread G instructs the 308 local allocator to construct the object directly in the shared memory. Because the local allocator already has a region, it is able to construct the object directly in the region of the shared memory it has reserved. The reservation step ensures that no other allocator will attempt to allocate the object in that reserved region.

[0042] At checkpoint 304, if thread G already has a local allocator, then the process moves to operation 308.

[0043] During operation 308, when the object is constructed, thread G performs an allocator status check 310. That is, thread G checks 310 whether the local allocator has corrupted memory on the same trust boundary side as thread G. Check 310 includes checking that each address used by data in the shared memory region is itself within the shared memory region. This check is performed by ensuring that any memory access that occurs as part of the allocation process and depends on untrusted data is within the shared memory region. If the check finds that memory outside the shared region will be read or written due to corruption or malicious data in the shared region, then the error recovery path is triggered 312. If check 310 finds no problems, the process returns to operation 300 and thread G continues execution.

[0044] There is no problem if the local allocator damages memory on the same side of the trust boundary as the local allocator, because software on the same side of the trust boundary as the local allocator is untrusted and is expected to potentially damage memory on the trust boundary side.

[0045] Figure 3 The method describes memory allocation performed by a thread to allocate memory on the other side of the trust boundary. The case where a thread allocates memory on the same side of the trust boundary as the thread itself is conventional and therefore will not be described here.

[0046] In the example, each thread has an allocator for local allocation, but there is a single allocator for the first software component to allocate memory owned by the second software component. The single allocator for the first software component is protected by a lock and is accessed by multiple threads.

[0047] In another example, each thread of the first software component has a local allocator and a remote allocator (and thus two instances of the memory allocator).

[0048] Figure 4 This is a flowchart of a method executed by thread R, which is on the other side of the trust boundary of thread G. In the example, thread R is part of the untrusted code, but this is just an example, as thread R can be any thread from the other side of the trust boundary of thread G.

[0049] Thread R executes step 400 and reaches step 402 during its execution, requesting the deallocation of memory region M from shared memory. Memory region M was allocated by thread G. Thread R identifies which allocator allocated M (step 404). In this example, thread R discovers that thread G's local allocator allocated M. This identification is done by looking up a data structure (referred to herein as the allocator index). In some examples, the allocator index is maintained by a first software component in a shared memory region accessible to a second software component. In some examples, the first software component has a copy of the allocator index, and the second software component has a copy of the allocator index, and these copies are... Figure 3 Synchronization during operation 306.

[0050] Thread R adds the request to release M to a record in the messaging facility in memory. This request can be issued immediately or placed in a batch and issued as part of a batch of requests. Further details regarding batch processing and inappropriate batching of requests are given below.

[0051] This record is associated with the allocator that allocated M. In this example, the record is a queue, and each allocator has one queue. A request to release M is added to the queue of the allocator that allocated M. Then thread R continues execution for 400, and this process repeats.

[0052] Figure 5 This is a flowchart of the method executed by the thread initially allocated to M. Figure 4 In the example, the thread that initially allocated M is thread G. Thread G is on the other side of the trust boundary of thread R. Thread G is executing 500. It looks up records in the messaging facility in memory to find which requests to release memory regions are waiting for it. It finds a request to deallocate M, which is waiting for thread G because thread G previously allocated M. Thread G accepts the request and instructs 506 thread G's local allocator to deallocate M directly. Since the local allocator performs the deallocation directly, there are no cross-trust boundary calls, and the deallocation is efficient.

[0053] Operation 506 is executed when thread G verifies 504 by performing a range check of the memory accesses performed during operation 506 within the shared memory region. If the shared memory region is not contiguous, there are multiple ranges to check all points within the shared memory.

[0054] If verification fails, an alarm is triggered (510) and / or memory is cleared. If verification succeeds, the process returns to operation 500, where thread G executes.

[0055] In a situation of mutual distrust, where the first software component and the second software component do not trust each other, and Figure 4The method is the same. Figure 5 The method is symmetrical. That is, during the execution of thread G... Figure 4 In the case of the method, then thread R executes Figure 5 This approach allows for more efficient message caching if a hierarchical trust relationship exists. In this case, an untrusted component doesn't need to perform validation (since it trusts other components), and is free to perform more message caching.

[0056] The technology disclosed herein uses a messaging facility implemented in shared memory. In the example, the messaging facility is implemented using only shared memory.

[0057] An example of a messaging facility is now referenced. Figure 6 This is given as an example, and it should be noted that this is just an example, and other examples are possible.

[0058] Figure 6 It shows the relationship with Figure 2D The first software component 212 and the second software component 214 are separated by a trust boundary. The first software component 212 is schematically illustrated as a rectangle 212 in memory, and the second software component shares some of this memory, as illustrated by rectangle 214, which is located within rectangle 212.

[0059] The second software component includes multiple memory allocators, and... Figure 6 A memory allocator 604 is shown in the diagram. For clarity, other memory allocators are shown below. Figure 6 (The text is omitted.) Each allocator is assigned a separate region.

[0060] The messaging facility is implemented in shared memory and includes multiple queues, with one queue 606 for each memory allocator 604.

[0061] Allocator index 602 is provided. Allocator index 602 is a data structure used to locate the memory allocator, as it stores information about which allocator allocated which memory regions. In the example, allocator index 602 is an array indexed by the most significant bits of the virtual address of the allocated memory region. The most significant bit indicates the type of allocation, and the type of allocation can be used to find metadata indicating the allocator's identity, as an offset within the block. In another example, allocator index 602 is a mapping of the high bits of the virtual address from the hardware messaging facility of a supercomputer.

[0062] In some examples, such as Figure 2A In the enclave example, the second allocator index 600 exists in memory on the other side of the trust boundary and is synchronized with allocator index 602.

[0063] In other examples, such as Figure 2CIn the library partitioning example, there is no second allocator index, and allocator index 602 is a single canonical allocator index containing information about the available memory range for each library partition. Any updates to the canonical allocator index from unauthorized library partitions are proxied to authorized code, which updates the canonical allocator index and the view of the library partition (after verifying the update). The allocator index is updated when a new block is allocated, thus the cost of calls across trust boundaries is amortized.

[0064] exist Figure 4 In this method, thread G from the first software component 212 allocates a memory region in the shared memory, and thread G has a local allocator 604 in the shared memory. Thread G can directly allocate objects in the shared memory using the local allocator 604 without making cross-trust boundary calls.

[0065] exist Figure 5 In this method, if thread R from the second software component 214 wants to deallocate memory region M allocated by thread G, then thread R uses allocator index 602 to identify which thread allocated memory region M. Thread R looks up a reference to memory region M in allocator index 602 and finds the identifier of the allocator that allocated memory region M. Allocator index 602 is populated with data available in the second software component without requiring cross-trust boundary calls.

[0066] In some, but not all, examples, a second allocator index 600 exists outside the shared memory. Due to the location of the second allocator index, it may have information that the allocator index 602 in the shared memory region does not know. However, synchronization methods are used to synchronize the allocator index. Synchronization methods use cross-trust boundary calls, but these calls are infrequent and therefore do not introduce undue overhead and / or latency. In some examples, the cross-trust boundary calls used for synchronization are used to synchronize the allocator index within the shared memory region. Figure 3 The method reserves a region of shared memory for the allocator as part of the same cross-trust boundary call. The second allocator index is in... Figure 2A Used in the enclave example. When Figure 5 When the method is executed by program 202 outside the enclave, only the allocator index (allocator index 602) outside the enclave is visible, and therefore it is the only one that is checked. Program 202 running outside the enclave cannot see the memory within enclave 200, and therefore cannot free the memory within enclave 200. When memory is freed from enclave 200, the thread in the enclave executes... Figure 5 The method is as follows: If the memory is outside the enclave, it searches in the second allocator index 600 and checks other allocator indices 602.

[0067] Thread R (from the allocator index) identifies that thread G is allocating M. Thread R then places the entry into queue 606 of thread G's local allocator 604. For thread R to place the entry into queue 606 of thread G's local allocator 604, the atomic operation is performed in memory, but there are no calls across trust boundaries. Therefore, the process of placing the entry into the queue is very cost-effective. In a preferred example, multiple requests to place the entry into queue 606 are collected and sent to queue 606 in batches to improve efficiency.

[0068] exist Figure 2C In the library segmentation example, batch processing requests to add entries to queue 606 can cause problems when a library segment exits. When a library segment exits, the pointer to the memory it owns is released before the memory can be mapped. If the pointer to the memory owned by the library segment is cached in another allocator (in a queue), releasing the pointer can take an indefinite amount of time. Therefore, for the deallocation of memory owned by untrusted code from trusted code, the entry is immediately added to a remote queue to avoid indefinite delays.

[0069] This entry includes a request to release memory region M. In the example, each queue, such as queue 606, is a multi-producer, single-consumer lock-free queue. The queue is multi-producer because multiple different threads are able to put entries into the queue. The queue is single-consumer because a single allocator retrieves items from the queue. The queue is lock-free because no locks are placed on the queue during operation.

[0070] exist Figure 6 In the method, thread G retrieves an item from queue 606, which is then used as the memory region to be deallocated, and it uses the local allocator 604 to deallocate those memory regions. Retrieving messages from the queue is implemented in a single atomic operation, making it highly efficient. Because the local deallocator 604 is used, no cross-trust boundary calls are involved.

[0071] exist Figure 6 In the method, thread G performs the verification. Thread G verifies that memory accesses to the data structures associated with memory allocation within shared memory are within the shared memory. Verification is typically a simple range check of memory accesses within the shared scope. If the shared memory region is not contiguous, multiple ranges need to be checked.

[0072] Previous allocators supporting multiple threads typically used locks to lock data structures and then manipulated them to handle contention. However, the use of locks is problematic for the highly asynchronous, cross-trust boundary situations disclosed herein. Even if it is a spinlock in memory, the lock implementation cannot necessarily be trusted. It would be very easy to maliciously lock a data structure and never unlock it, or to unlock the data structure while it is being modified, or to unlock the data structure while another entity is modifying it.

[0073] The message passing facilities and verification process in memory disclosed herein operate in an unconventional manner, enabling efficient memory deallocation across trust boundaries between two software components.

[0074] By enabling efficient deallocation of memory across the trust boundary between two software components, the messaging facilities and authentication processes in memory improve the operation of the underlying computing device.

[0075] Figure 7 Various components of an exemplary computing-based device 700 are illustrated, which are implemented as any form of computing and / or electronic device, and embodiments of the functionality for memory deallocation across trust boundaries are implemented in some examples.

[0076] The computing-based device 700 includes one or more processors 708, which are microprocessors, controllers, or any other suitable type of processor, for processing computer-executable instructions to control the operation of the device in order to deallocate memory across a trust boundary between two software components. In some examples, such as where a system-on-a-chip architecture is used, the processor 708 includes one or more fixed-function blocks (also called accelerators) implemented in hardware (rather than software or firmware). Figures 3 to 5 Part of any of the methods.

[0077] Computer-executable instructions are provided using any computer-readable medium accessible by the computing-based device 700. Computer-readable media include, for example, computer storage media, such as memory 702, and communication media. Memory 702 stores two or more software components 704 separated by trust boundaries, and memory 702 also stores messaging facilities 706.

[0078] Computer storage media (such as memory 702) include volatile and non-volatile, removable and non-removable media implemented using any method or technology for storing information (such as computer-readable instructions, data structures, program modules, etc.). Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, optical disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage devices, magnetic cassettes, magnetic tapes, disk storage devices or other magnetic storage devices, or any other non-transmission medium used to store information for access by a computing device. In contrast, communication media implement computer-readable instructions, data structures, program modules, etc., in modulated data signals (such as carrier waves) or other transport mechanisms. As defined herein, computer storage media do not include communication media. Therefore, computer storage media should not be construed as the transmission of signals themselves. Although the computer storage medium (memory 702) is shown within the computing-based device 700, it is understood that in some examples the storage device is distributed or located remotely and accessed via a network or other communication link (e.g., using communication interface 712).

[0079] The computing-based device 700 also includes an input / output interface 710 arranged to output display information to a display device, which may be separate from or essential to the computing-based device 700. The display information may provide a graphical user interface. The input / output controller interface 710 is also arranged to receive and process input from one or more devices, such as user input devices (e.g., a mouse, keyboard, camera, microphone, or other sensors). In some examples, the user input device detects voice input, user gestures, or other user actions and provides a natural user interface (NUI). In embodiments, if the display device is a touch-sensitive display device, it also acts as a user input device. In some examples, the input / output interface 710 outputs data to devices other than the display device, such as a locally connected printing device.

[0080] Alternatively, or in addition to the other examples described herein, examples include any combination of the following:

[0081] Clause A. A memory deallocation method across a trust boundary between a first software component and at least a second software component, the method comprising:

[0082] Some memory is shared between the first software component and the second software component;

[0083] Use shared memory to implement message passing facilities in memory;

[0084] The first software component is used to deallocate memory from shared memory, which has been allocated by the second software component, through the following operations:

[0085] This causes at least one allocation to be released from the messaging facility;

[0086] At least one allocation is released using a local deallocation mechanism, while verifying that memory accesses to memory owned by the data structure associated with the memory allocation within shared memory are within shared memory. Memory deallocation across trust boundaries can be performed efficiently and securely using in-memory messaging facilities and verification. Costly cross-trust boundary calls, which are computationally and / or time-consuming, are minimized. Two software components can run concurrently without synchronizing memory allocation events using in-memory messaging facilities and verification.

[0087] Clause B. According to the method of Clause A, a thread in the first software component causes at least one allocation to be released from the messaging facility, and the thread releases at least one allocation using a local deallocation mechanism, which is the thread's allocator that owns a block of memory in the shared memory. By using a local allocator, cross-trust boundary calls are not required.

[0088] Clause C. The method pursuant to Clause A or Clause B is performed where there is no cross-trust boundary call between the first software component and the second software component.

[0089] Clause D. The method pursuant to any of the foregoing clauses includes: releasing at least one allocation from a queue in the messaging facility associated with the allocator of the allocation to be released. Because the queue is associated in this way, safe and efficient memory deallocation is supported.

[0090] Clause E. Any method pursuant to any of the foregoing clauses, which is executed by a thread, and in which the allocation to be released has been identified as an allocation previously performed by the thread.

[0091] Clause F. The method pursuant to any of the foregoing clauses, wherein verification is completed.

[0092] Clause G. In accordance with any of the foregoing provisions, the allocation to be released has been added to the messaging facility by a thread of a second software component.

[0093] Clause H. The method of Clause G, wherein the allocation to be released is added to the messaging facility as part of a batch of allocations to be released.

[0094] Clause I. The method according to Clause G, wherein the allocation to be released has been added to a queue selected from multiple queues at the messaging facility, which is associated with the allocator that allocated the allocation to be released.

[0095] Clause J. According to the method of Clause I, where the queue has been selected by using the allocator index to identify the allocator to be released.

[0096] Clause K. According to any of the foregoing clauses, the messaging facility in memory is lock-free. Using locks is problematic because locks can be exploited by malicious parties. Using locks incurs high overhead if implemented by a lock manager in a trusted component.

[0097] Clause L. According to any of the foregoing clauses, the in-memory messaging facility comprises a multi-producer, single-consumer queue. Using this type of queue improves efficiency. In another example, the in-memory messaging facility comprises a multi-producer, multi-consumer queue.

[0098] Clause M. The method pursuant to any of the foregoing clauses, wherein the messaging facility in memory includes an allocator index in shared memory and a second allocator index in the memory of the first software component, the second allocator index being not part of the shared memory.

[0099] Clause N. The method according to any one of Clauses A through L, wherein the messaging facility in memory includes a single specification allocator index that maps different ranges of memory regions to each software component in the software components.

[0100] Clause O. The method according to any one of Clauses A to L, wherein the first software component is an enclave and the second software component is a program outside the enclave, and wherein the method comprises: maintaining two allocator indices, one in the enclave and one outside the enclave, and synchronizing the allocator indices.

[0101] In some examples, there are more than two software components. At least two software components share the allocator index, and at least two software components each have their own synchronizer allocator index.

[0102] In some examples, there are three software components that share the same shared memory region in a mutually untrusted setup, and each has its own private portion of the allocator index plus a shared portion private to the allocator.

[0103] Clause P. The method of any one of Clauses A through L, wherein the software component is a library compartment, and wherein the allocation to be released is immediately added to the messaging facility.

[0104] Clause Q. The method according to any one of Clauses A through L, wherein the first software component is a virtual machine and the second software component is a virtual machine that is less secure than the first software component.

[0105] Clause R. An apparatus comprising:

[0106] The first and second software components are separated by a trust boundary:

[0107] A memory, wherein at least some of the memory is shared between the first software component and the second software component;

[0108] The message passing facilities in memory are implemented using shared memory; and

[0109] The first software component is configured to release memory allocated by the second software component from the shared memory by performing a range check within the shared memory during the release of at least one allocation.

[0110] Cause at least one allocation to be released from the messaging facility; and

[0111] At least one allocation is released using a local deallocation mechanism, while verifying that memory accesses to memory owned by data structures associated with memory allocations within the shared memory are within the shared memory.

[0112] Clause S. The apparatus pursuant to Clause R, wherein the first software component is an enclave and the second software component is outside the enclave.

[0113] Clause T. A method executed by an operating system, the operating system including a first library compartment and a second library compartment, the method comprising:

[0114] Some storage is shared between the first and second storage compartments;

[0115] Use shared memory to implement message passing facilities in memory;

[0116] The memory that has been allocated by the second library compartment is released from shared memory using the first library compartment through the following operation:

[0117] This causes at least one allocation to be released from the messaging facility;

[0118] At least one allocation is released using a local deallocation mechanism, while verifying that memory accesses to memory owned by data structures associated with memory allocations within the shared memory are within the shared memory.

[0119] The terms 'computer' or 'computation-based device' are used herein to refer to any device that has processing power to execute instructions. Those skilled in the art will recognize that such processing power is incorporated into many different devices, and therefore the terms 'computer' and 'computation-based device' respectively include personal computers (PCs), servers, mobile phones (including smartphones), tablet computers, set-top boxes, media players, game consoles, personal digital assistants, wearable computers, and many other devices.

[0120] In some examples, the methods described herein are executed by software in a machine-readable form on a tangible storage medium, such as a computer program including computer program code components, which, when the program is run on a computer and where the computer program can be implemented on a computer-readable medium, is suitable for performing all operations of one or more methods described herein. The software is adapted to execute on a parallel or serial processor, such that the method operations can be executed in any suitable order or simultaneously.

[0121] This acknowledges that software is a valuable, separately tradable commodity. It aims to encompass software that runs on or controls “dumb” or standard hardware to perform desired functions. It also aims to encompass software that “describes” or defines hardware configurations, such as HDL (Hardware Description Language) software used to design silicon chips or configure general-purpose programmable chips to perform desired functions.

[0122] Those skilled in the art will recognize that the storage device used to store program instructions can optionally be distributed across a network. For example, a remote computer can store an example of a process described as software. A local or terminal computer can access the remote computer and download part or all of the software to run the program. Alternatively, the local computer can download fragments of the software as needed, or execute some software instructions at a local terminal and some software instructions at a remote computer (or computer network). Those skilled in the art will also recognize that, by utilizing conventional techniques known to those skilled in the art, all or part of the software instructions can be executed by dedicated circuitry, such as a digital signal processor (DSP), a programmable logic array, etc.

[0123] Any range or device value given in this article can be extended or changed without losing the desired effect, which is obvious to those skilled in the art.

[0124] Although the subject matter has been described in language specific to structural features and / or methodological actions, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

[0125] It should be understood that the above benefits and advantages may relate to one embodiment or multiple embodiments. Embodiments are not limited to those that solve any or all of the described problems or have any or all of the described benefits and advantages. It should also be understood that a reference to 'a' item means one or more of these items.

[0126] The operations of the methods described herein can be performed in any suitable order, or simultaneously where appropriate. Additionally, individual boxes can be removed from any method without departing from the scope of the subject matter described herein. Aspects of any of the examples above can be combined with aspects of any other example described to form other examples without losing the desired effect.

[0127] The term 'including' is used herein to mean including the identified method box or element, but such box or element does not include an exclusive list, and the method or apparatus may include additional boxes or elements.

[0128] The term 'subset' is used in this document to refer to a suitable subset of a set such that a subset of a set does not include all elements of the set (i.e., the subset is missing at least one element of the set).

[0129] It should be understood that the above description is given by way of example only, and various modifications can be made by those skilled in the art. The above specification, examples, and data provide a complete description of the structure and use of exemplary embodiments. Although various embodiments have been described above with a degree of specificity or with reference to one or more individual embodiments, those skilled in the art can make many changes to the disclosed embodiments without departing from the scope of this specification.

Claims

1. A method of memory deallocation between a first software component and at least a second software component, the method comprising: implementing a message passing facility in memory using a shared memory between the first software component and the second software component, wherein the first software component is separated from the second software component by a trust boundary, wherein the message passing facility in memory comprises a plurality of queues, wherein the first software component is associated with a first queue of the plurality of queues and the second software component is associated with a second queue of the plurality of queues; using the first software component to deallocate memory from the shared memory at least by adding a request to release a memory allocation to the second queue in the message passing facility in memory, the memory allocation having been allocated by the second software component; and using the second software component: obtaining the request to release the memory allocation from the message passing facility; and releasing the memory allocation using a local deallocation mechanism.

2. The method of claim 1, wherein a thread in the first software component obtains a request to release a memory allocation from the message passing facility, and the thread releases the memory allocation using a local deallocation mechanism that is an allocator of the thread while verifying that memory accesses to memory owned by a data structure related to the memory allocation within the shared memory are within the shared memory, the allocator owning a block of memory in the shared memory.

3. The method of claim 2, the method being performed across the trust boundary without a cross-trust boundary call between the first software component and the second software component. obtaining the request to release the memory allocation from the plurality of queues in the message passing facility, the queue being associated with an allocator that allocated the allocation to be released.

4. The method of claim 1, further comprising:

5. The method of claim 1, the method being performed by a thread, and wherein the allocation to be released has been identified as an allocation previously made by the thread.

6. The method of claim 1, the method being performed by a thread, and wherein the allocation to be released has been identified as an allocation previously made by the thread a range check that memory accesses to memory owned by a data structure related to a memory allocation within the shared memory are within the shared memory during the release of the allocation allocated by the thread.

7. The method of claim 1, wherein the allocation to be released has been added to the message passing facility by a thread of the second software component.

8. The method of claim 7, wherein the allocation to be released has been added to the message passing facility as part of a batch of allocations to be released.

9. The method of claim 7, wherein the allocation to be released has been added to the second queue, the queue being associated with an allocator that allocated the allocation to be released. ​ 10. The method of claim 9, further comprising: The second queue is selected using an allocator index identifying the allocator of the allocation to be freed to select the second queue.

11. The method of claim 1, wherein the message passing facility in the memory is lock-free.

12. The method of claim 1, wherein each of the plurality of queues comprises a multi-producer, single-consumer queue.

13. The method of claim 1, wherein the message passing facility in the memory comprises an allocator index in the shared memory and a second allocator index in the memory of the first software component, the second allocator index not being part of the shared memory.

14. The method of claim 1, wherein the message passing facility in the memory comprises mapping different ranges of memory regions to a single canonical allocator index for each of the software components.

15. The method of claim 1, the first software component being an enclave and the second software component being a program outside the enclave, and wherein the method comprises: Two allocator indices are maintained, one allocator within the enclave and one allocator outside the enclave, and the allocator indices are synchronized.

16. The method of claim 1, the first software component and the second software component are both library compartments separated by the trust boundary, the trust boundary defines the first software component and the second software component as having different privileges, the first software component has first privileges, the second software component has second privileges, and the first privileges are higher than the second privileges, and wherein the allocation to be freed is added to the message passing facility immediately.

17. The method of claim 1, the first software component is a virtual machine, and the second software component is a virtual machine that is less secure than the first software component.

18. An apparatus comprising: a first software component and a second software component separated by a trust boundary; a memory, at least some of the memory being shared between the first software component and the second software component; a message passing facility in the memory, implemented using shared memory between the first software component and the second software component, wherein the message passing facility in the memory comprises a plurality of queues, wherein the first software component is associated with a first queue of the plurality of queues, and the second software component is associated with a second queue of the plurality of queues; and wherein the first software component is configured to deallocate memory from the shared memory at least by adding a request to free a memory allocation to the second queue in the message passing facility in the memory, the memory having been allocated by the second software component; and using the second software component: fetching the request to free the memory allocation from the message passing facility; and using a local deallocation mechanism to free the memory allocation.

19. The apparatus of claim 18, the first software component is an enclave and the second software component is outside the enclave.

20. A method performed by an operating system comprising a first library compartment and a second library compartment, the method comprising: implementing a message passing facility in memory using shared memory between the first library compartment and the second library compartment, wherein the first library compartment is separated from the second library compartment by a trust boundary, wherein the message passing facility in memory comprises a plurality of queues, and wherein the first library compartment is associated with a first queue of the plurality of queues and the second library compartment is associated with a second queue of the plurality of queues; de-allocating memory from the shared memory using the first library compartment by at least adding a request to release a memory allocation to the second queue in the message passing facility in memory, the memory having been allocated by the second library compartment; and using the second library compartment: retrieving the request to release the memory allocation from the message passing facility; and releasing the memory allocation using a local de-allocation mechanism.

Images