Re: dma_heap and protected memory
Jens Wiklander <[email protected]> Tue, 19 May 2026 17:29:21 +0200
| Newsgroups | org.trustedfirmware.lists.op-tee |
|---|---|
| Message-ID | <CAHUa44EG8b74NgdHW=QhKBtKd7e0_xWqQTkZA9tZxEOHenY_AQ@mail.gmail.com> |
Hi Amir, On Fri, May 15, 2026 at 5:10 AM Amirreza Zarrabi <[email protected]> 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