On 10/27/2023 1:17 PM, Yong Wu (吴勇) wrote:
On Thu, 2023-10-26 at 10:18 +0530, Vijayanand Jitta wrote:
External email : Please do not click links or open attachments until you have verified the sender or the content.
On 10/20/2023 3:29 PM, Yong Wu (吴勇) wrote:
On Thu, 2023-10-19 at 10:15 +0530, Vijayanand Jitta wrote:
External email : Please do not click links or open attachments
until
you have verified the sender or the content.
On 9/11/2023 8:00 AM, Yong Wu wrote:
Initialise a mtk_svp heap. Currently just add a null heap,
Prepare
for
the later patches.
Signed-off-by: Yong Wu yong.wu@mediatek.com
drivers/dma-buf/heaps/Kconfig | 8 ++ drivers/dma-buf/heaps/Makefile | 1 + drivers/dma-buf/heaps/mtk_secure_heap.c | 99
+++++++++++++++++++++++++
[...]
+static struct dma_buf * +mtk_sec_heap_allocate(struct dma_heap *heap, size_t size,
unsigned long fd_flags, unsigned long heap_flags)+{ +struct mtk_secure_heap_buffer *sec_buf; +DEFINE_DMA_BUF_EXPORT_INFO(exp_info); +struct dma_buf *dmabuf; +int ret;
+sec_buf = kzalloc(sizeof(*sec_buf), GFP_KERNEL);
As we know, kzalloc can only allocate 4MB at max. So, secure heap
has
this limitation. can we have a way to allocate more memory in secure heap ? maybe similar to how system heap does?
This is just the size of a internal structure. I guess you mean the secure memory size here. Regarding secure memory allocating flow,
our
flow may be different with yours.
Let me explain our flow, we have two secure buffer types(heaps). a) mtk_svp b) mtk_svp_cma which requires the cma binding.
The memory management of both is inside the TEE. We only need to
tell
the TEE which type and size of buffer we want, and then the TEE
will
perform and return the memory handle to the kernel. The kzalloc/alloc_pages is for the normal buffers.
Regarding the CMA buffer, we only call cma_alloc once, and its management is also within the TEE.
Thanks for the details.
I see for mvp_svp, allocation is also specific to TEE, as TEE takes care of allocation as well.
Yes. The allocation management of these two heaps is in the TEE.
I was thinking if allocation path can also be made generic ? without having dependency on TEE. For eg : A case where we want to allocate from kernel and secure that memory, the current secure heap design can't be used.
Sorry, This may be because our HW is special. The HW could protect a certain region, but it can only protect 32 regions. So we cannot allocate them in the kernel arbitrarily and then enter TEE to protect them.
Got your point , I see for your case allocation must happen in TEE. I was just saying if we want to make secure heap generic and remove hard dependency on TEE, we must have a way to allocate irrespective of what hypervisor/TZ being used. As current design for secure heap assumes OPTEE.
We have a case where allocation happens in kernel and we secure it using qcom_scm_assign_mem , this wouldn't be possible with current design.
Probably some ops to allocate, similar to ops you pointed out to secure ? in you case these ops would just allocate the internal structure.
Thanks, Vijay
Also i suppose TEE allocates contiguous memory for mtk_svp ? or does it support scattered memory ?
Yes. After the TEE runs for a period of time, the TEE memory will become discontinuous, and a secure IOMMU exists in the TEE.
Thanks, Vijay