Re: dma_heap and protected memory

Hi Jens,

On 5/20/2026 1:29 AM, Jens Wiklander wrote:
> 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.
>

Yes, that is my understanding. For dma-heaps, after the final dma-buf
reference is released, the exporter is free to return the backing pages to
the heap.

>>
>> 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.
> 

Yes, I agree.

The specific case I am looking at is qcomtee without an FF-A backend. In
that configuration, qcomtee currently requires physically contiguous shared
memory, so registering anonymous userspace memory is not very practical.

Today the qcomtee shared-memory pool is implemented on top of
tee_dyn_shm_alloc_helper(), which allocates memory from the normal page
allocator. This makes larger allocations subject to the usual high-order
allocation / MAX_ORDER limitations.

One option would be to move, or extend, the qcomtee shared-memory pool to use
a cma backed allocation path. That would address the default allocation case
through TEE_IOC_SHM_ALLOC (without restriction).

However, I am wondering whether it is better to also allow userspace to choose
the source of the memory, for example when the memory must come from a specific
carveout or from a cma dma-heap selected by the client.

If you feel it is not a correct direction, I totally understand considering
it is workaround for a limitation.

Thanks Jens.

Regards,
Amir

> Cheers,
> Jens