class SharedMemoryView

OP-TEE Shared Memory Management

Inter world memory is provided by the Secure OS. During driver bind, the OpteeController will

query OP-TEE to discover the physical start address and size of the memory to be used for inter

world communication. It can then create a SharedMemoryManager to manage that address space.

The SharedMemoryManager will divide the shared address space into two pools: driver and client.

The driver pool is for the allocation of driver messages, such as an OP-TEE message for opening

a session. The driver messages are used entirely in-proc and do not require a VMO object for

lifetime management. The client pool is for usage by client apps, which requires VMO objects for

sharing between processes. As such, the client pool objects must all be page aligned. The

benefits of splitting these different memory usages into distinct pools include preventing the

client app allocations from starving the driver message usages and grouping similarly aligned

objects together to reduce pool fragmentation.

The SharedMemoryPool uses the region-alloc library to divide the provided address space into

allocations for use. It provides region objects that will return to the allocator upon

destruction. There's also a template trait class parameter that can be used to provide different

traits for the different pools. This has the added benefit of creating distinct types for the

driver and client pools, so we can restrict which messages can be allocated from which pool. For

example, an open session message must be constructed from the driver pool.

The SharedMemory object is essentially just a wrapper around the region object that was allocated

by the SharedMemoryPool. The region object represents the offset and size within the memory pool

that is allocated to this object. It is important to note that the destructor for the RegionPtr

will recycle the region back to the RegionAllocator, eliminating the need for us to explicitly

free it.