Re: [PATCH v2 0/8] dma-buf: heaps: Add secure heap

[Pratyush Brahma]

Hi

We have sent a patch series at [1] using this series to add support for 
Qualcomm secure heaps.

Instead of TEE calls, it uses qcom_scm_assign_mem() to secure the memory.

Thanks,
Pratyush

[1] 
https://lore.kernel.org/lkml/cover.1700544802.git.quic_vji...@quicinc.com/

Re: [PATCH v2 0/8] dma-buf: heaps: Add secure heap

[Jeffrey Kardatzke]

The main goal is for secure video playback, and to also enable other
potential uses of this in the future. The 'secure dma-heap' will be
used to allocate dma_buf objects that reference memory in the secure
world that is inaccessible/unmappable by the non-secure (i.e.
kernel/userspace) world.  That memory will be used by the secure world
to store secure information (i.e. decrypted media content). The
dma_bufs allocated from the kernel will be passed to V4L2 for video
decoding (as input and output). They will also be used by the drm
system for rendering of the content.

Hope that helps.

Cheers,
Jeff

On Mon, Nov 13, 2023 at 3:38 AM Pavel Machek  wrote:
>
> Hi!
>
> > This patchset adds three secure heaps:
> > 1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path).
> >The buffer is reserved for the secure world after bootup and it is used
> >for vcodec's ES/working buffer;
> > 2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is
> >dynamically reserved for the secure world and will be got when we start
> >playing secure videos, Once the security video playing is complete, the
> >CMA will be released. This heap is used for the vcodec's frame buffer.
> > 3) secure_cma: Use the kerne CMA ops as the allocation ops.
> >currently it is a draft version for Vijay and Jaskaran.
>
> Is there high-level description of what the security goals here are,
> somewhere?
>
> BR,
> Pavel
> --
> People of Russia, stop Putin before his war on Ukraine escalates.

Re: [PATCH v2 0/8] dma-buf: heaps: Add secure heap

[Pavel Machek]

Hi!

> This patchset adds three secure heaps:
> 1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path).
>The buffer is reserved for the secure world after bootup and it is used
>for vcodec's ES/working buffer;
> 2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is
>dynamically reserved for the secure world and will be got when we start
>playing secure videos, Once the security video playing is complete, the
>CMA will be released. This heap is used for the vcodec's frame buffer. 
> 3) secure_cma: Use the kerne CMA ops as the allocation ops. 
>currently it is a draft version for Vijay and Jaskaran.

Is there high-level description of what the security goals here are,
somewhere?

BR,
Pavel
-- 
People of Russia, stop Putin before his war on Ukraine escalates.


signature.asc
Description: PGP signature

[PATCH v2 0/8] dma-buf: heaps: Add secure heap

[Yong Wu]

This patchset adds three secure heaps:
1) secure_mtk_cm: secure chunk memory for MediaTek SVP (Secure Video Path).
   The buffer is reserved for the secure world after bootup and it is used
   for vcodec's ES/working buffer;
2) secure_mtk_cma: secure CMA memory for MediaTek SVP. This buffer is
   dynamically reserved for the secure world and will be got when we start
   playing secure videos, Once the security video playing is complete, the
   CMA will be released. This heap is used for the vcodec's frame buffer. 
3) secure_cma: Use the kerne CMA ops as the allocation ops. 
   currently it is a draft version for Vijay and Jaskaran.

For the first two MediaTek heaps will be used v4l2[1] and drm[2], thus we
cannot put it in v4l2 or drm, and create a common heap for them. Meanwhile
We have a limited number of hardware entries to protect memory, we cannot
protect memory arbitrarily, thus the secure memory management is actually
inside OPTEE. The kernel just tells the TEE what size I want and the TEE
will return a "secure handle".

[1] 
https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.d...@mediatek.com/
[2] 
https://lore.kernel.org/linux-mediatek/20231023044549.21412-1-jason-jh@mediatek.com/

Change note:
v2: 1) Move John's patches into the vcodec patchset since they use the new
   dma heap interface directly.
   
https://lore.kernel.org/linux-mediatek/20231106120423.23364-1-yunfei.d...@mediatek.com/
2) Reword the dt-binding description.
3) Rename the heap name from mtk_svp to secure_mtk_cm.
   This means the current vcodec/DRM upstream code doesn't match this.
4) Add a normal CMA heap. currently it should be a draft version.
5) Regarding the UUID, I still use hard code, but put it in a private
data which allow the others could set their own UUID. What's more, UUID
is necessary for the session with TEE. If we don't have it, we can't
communicate with the TEE, including the get_uuid interface, which tries
to make uuid more generic, not working. If there is other way to make
UUID more general, please free to tell me.

v1: 
https://lore.kernel.org/linux-mediatek/20230911023038.30649-1-yong...@mediatek.com/
Base on v6.6-rc1.

Yong Wu (8):
  dma-buf: heaps: Initialize a secure heap
  dma-buf: heaps: secure_heap: Add private heap ops
  dma-buf: heaps: secure_heap: Initialize tee session
  dma-buf: heaps: secure_heap: Add tee memory service call
  dma-buf: heaps: secure_heap: Add dma_ops
  dt-bindings: reserved-memory: Add secure CMA reserved memory range
  dma_buf: heaps: secure_heap: Add a new MediaTek CMA heap
  dma-buf: heaps: secure_heap: Add normal CMA heap

 .../reserved-memory/secure_cma_region.yaml|  44 ++
 drivers/dma-buf/heaps/Kconfig |   7 +
 drivers/dma-buf/heaps/Makefile|   1 +
 drivers/dma-buf/heaps/secure_heap.c   | 602 ++
 4 files changed, 654 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/reserved-memory/secure_cma_region.yaml
 create mode 100644 drivers/dma-buf/heaps/secure_heap.c

-- 
2.25.1