dma_heap and protected memory

[Amirreza Zarrabi via OP-TEE <op-tee@lists.trustedfirmware.org>]

Hi Jens,

Recently protected heap support has been added for the TEE subsystem.
This allows dma-heaps to be managed by the TEE subsystem itself.

For standard, non-protected heaps such as the system heap or CMA heap,
I am trying to understand the expected usage model. One possible workaround
appears to be to mmap the dma-buf fd in userspace, then register the
resulting userspace VA with the TEE subsystem to obtain a TEE shared-memory
object, for example:

fd = dma_heap_alloc(...);
va = mmap(fd, ...);

shm_fd = tee_shm_register(va, size);
tee_invoke(shm_fd);

close(shm_fd);
munmap(va, size);
close(fd);

This seems reasonable when the lifetime of the registered shared memory
is limited to a single invocation or callback. However, I am concerned about
cases (multiple exits in qcomtee) where the TEE side needs to retain access
to the memory after the ioctl/invocation returns.

In that case, registering only the userspace VA does not appear
to keep the underlying dma-buf object alive. The TEE core pins the pages,
but it does not hold a dma-buf reference or attachment. If userspace later
closes the dma-buf fd and unmaps the VA, the dma-buf exporter may consider
the buffer released, while the TEE side may still have the memory registered.

Is there a recommended way to use standard heaps, such as the system or
CMA dma-buf heaps, when the sharing lifetime is longer than a single TEE call?

Would it make sense to extend tee_shm_register_fd() so that it can handle
dma-buf fds from regular dma-heaps as well, not only dma-bufs managed by
the TEE subsystem? That would allow the TEE core or backend driver to keep
the dma-buf reference for the lifetime of the TEE shared-memory object.

Best regards,
Amir