Hi Amir,
On Fri, May 15, 2026 at 5:10 AM Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com wrote:
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.
That's surprising. Are the pages returned to the heap also? If so, there's an issue.
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?
No, I think you're pioneering this.
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.
It seems like a workaround, since I assume that the purpose is to share memory between the user space process and the TEE. I think this might be a last resort or something.
Cheers, Jens