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