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