linux-mediatek.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Yong Wu <yong.wu@mediatek.com>
To: Rob Herring <robh+dt@kernel.org>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	<christian.koenig@amd.com>,
	Matthias Brugger <matthias.bgg@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Benjamin Gaignard <benjamin.gaignard@collabora.com>,
	Brian Starkey <Brian.Starkey@arm.com>,
	John Stultz <jstultz@google.com>, <tjmercier@google.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Yong Wu <yong.wu@mediatek.com>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <linux-media@vger.kernel.org>,
	<dri-devel@lists.freedesktop.org>,
	<linaro-mm-sig@lists.linaro.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	<jianjiao.zeng@mediatek.com>, <kuohong.wang@mediatek.com>,
	Vijayanand Jitta <quic_vjitta@quicinc.com>,
	Joakim Bech <joakim.bech@linaro.org>,
	Jeffrey Kardatzke <jkardatzke@google.com>,
	Nicolas Dufresne <nicolas@ndufresne.ca>,
	<ckoenig.leichtzumerken@gmail.com>
Subject: [PATCH v2 0/8] dma-buf: heaps: Add secure heap
Date: Sat, 11 Nov 2023 19:15:51 +0800	[thread overview]
Message-ID: <20231111111559.8218-1-yong.wu@mediatek.com> (raw)

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.dong@mediatek.com/
[2] https://lore.kernel.org/linux-mediatek/20231023044549.21412-1-jason-jh.lin@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.dong@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.wu@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



             reply	other threads:[~2023-11-11 11:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-11 11:15 Yong Wu [this message]
2023-11-11 11:15 ` [PATCH v2 1/8] dma-buf: heaps: Initialize a secure heap Yong Wu
2023-11-15 23:18   ` Jeffrey Kardatzke
2023-11-11 11:15 ` [PATCH v2 2/8] dma-buf: heaps: secure_heap: Add private heap ops Yong Wu
2023-11-15 23:21   ` Jeffrey Kardatzke
2023-11-11 11:15 ` [PATCH v2 3/8] dma-buf: heaps: secure_heap: Initialize tee session Yong Wu
2023-11-11 16:55   ` kernel test robot
2023-11-11 17:44   ` kernel test robot
2023-11-15 23:23   ` Jeffrey Kardatzke
2023-11-11 11:15 ` [PATCH v2 4/8] dma-buf: heaps: secure_heap: Add tee memory service call Yong Wu
2023-11-11 23:28   ` kernel test robot
2023-11-15 23:26   ` Jeffrey Kardatzke
2023-11-11 11:15 ` [PATCH v2 5/8] dma-buf: heaps: secure_heap: Add dma_ops Yong Wu
2023-11-11 11:15 ` [PATCH v2 6/8] dt-bindings: reserved-memory: Add secure CMA reserved memory range Yong Wu
2023-11-11 12:48   ` Krzysztof Kozlowski
2023-11-13  6:37     ` Yong Wu (吴勇)
2023-11-14 13:18       ` Robin Murphy
2023-11-15 23:35         ` Jeffrey Kardatzke
2023-11-13 20:40   ` Rob Herring
2023-11-11 11:15 ` [PATCH v2 7/8] dma_buf: heaps: secure_heap: Add a new MediaTek CMA heap Yong Wu
2023-11-15 23:44   ` Jeffrey Kardatzke
2023-11-11 11:15 ` [PATCH v2 8/8] dma-buf: heaps: secure_heap: Add normal " Yong Wu
2023-11-15 23:45   ` Jeffrey Kardatzke
2023-11-13 11:38 ` [PATCH v2 0/8] dma-buf: heaps: Add secure heap Pavel Machek
2023-11-15 22:02   ` Jeffrey Kardatzke
2023-11-22 16:48 ` Pratyush Brahma

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231111111559.8218-1-yong.wu@mediatek.com \
    --to=yong.wu@mediatek.com \
    --cc=Brian.Starkey@arm.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=christian.koenig@amd.com \
    --cc=ckoenig.leichtzumerken@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jianjiao.zeng@mediatek.com \
    --cc=jkardatzke@google.com \
    --cc=joakim.bech@linaro.org \
    --cc=jstultz@google.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kuohong.wang@mediatek.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=nicolas@ndufresne.ca \
    --cc=quic_vjitta@quicinc.com \
    --cc=robh+dt@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=tjmercier@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).