Message-ID: <20240525232928.5524-1-jason-jh.lin@mediatek.com>
Date: Sun, 26 May 2024 07:29:21 +0800
From: Jason-JH.Lin <jason-jh.lin@...iatek.com>
To: Chun-Kuang Hu <chunkuang.hu@...nel.org>, AngeloGioacchino Del Regno
	<angelogioacchino.delregno@...labora.com>, Maxime Ripard <mripard@...nel.org>
CC: David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
	Matthias Brugger <matthias.bgg@...il.com>, <devicetree@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-mediatek@...ts.infradead.org>, <dri-devel@...ts.freedesktop.org>,
	<linux-media@...r.kernel.org>, <linaro-mm-sig@...ts.linaro.org>, Jason-ch
 Chen <jason-ch.chen@...iatek.com>, "Jason-JH . Lin"
	<jason-jh.lin@...iatek.com>, Singo Chang <singo.chang@...iatek.com>, Nancy
 Lin <nancy.lin@...iatek.com>, Shawn Sung <shawn.sung@...iatek.com>,
	<Project_Global_Chrome_Upstream_Group@...iatek.com>, Jeffrey Kardatzke
	<jkardatzke@...gle.com>, Jason-jh Lin
	<jason-jh.lin@...iatek.corp-partner.google.com>
Subject: [PATCH v6 0/7] Add mediate-drm secure flow for SVP

From: Jason-jh Lin <jason-jh.lin@...iatek.corp-partner.google.com>

Memory Definitions:
secure memory - Memory allocated in the TEE (Trusted Execution
Environment) which is inaccessible in the REE (Rich Execution
Environment, i.e. linux kernel/userspace).
secure handle - Integer value which acts as reference to 'secure
memory'. Used in communication between TEE and REE to reference
'secure memory'.
secure buffer - 'secure memory' that is used to store decrypted,
compressed video or for other general purposes in the TEE.
secure surface - 'secure memory' that is used to store graphic buffers.

Memory Usage in SVP:
The overall flow of SVP starts with encrypted video coming in from an
outside source into the REE. The REE will then allocate a 'secure
buffer' and send the corresponding 'secure handle' along with the
encrypted, compressed video data to the TEE. The TEE will then decrypt
the video and store the result in the 'secure buffer'. The REE will
then allocate a 'secure surface'. The REE will pass the 'secure
handles' for both the 'secure buffer' and 'secure surface' into the
TEE for video decoding. The video decoder HW will then decode the
contents of the 'secure buffer' and place the result in the 'secure
surface'. The REE will then attach the 'secure surface' to the overlay
plane for rendering of the video.

Everything relating to ensuring security of the actual contents of the
'secure buffer' and 'secure surface' is out of scope for the REE and
is the responsibility of the TEE.

DRM driver handles allocation of gem objects that are backed by a 'secure
surface' and for displaying a 'secure surface' on the overlay plane.
This introduces a new flag for object creation called
DRM_MTK_GEM_CREATE_RESTRICTED which indicates it should be a 'secure
surface'. All changes here are in MediaTek specific code.
---
TODO:
1) Drop MTK_DRM_IOCTL_GEM_CREATE and use DMA_HEAP_IOCTL_ALLOC in userspace
2) DRM driver use secure mailbox channel to handle normal and secure flow
3) Implement setting mmsys routing table in the secure world series
---
Based on 3 series:
[1] v3 dma-buf: heaps: Add MediaTek secure heap
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=809023
[2] v6 media: mediatek: add driver to support secure video decoder
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=853689
[3] v6 Add CMDQ secure driver for SVP
- https://patchwork.kernel.org/project/linux-mediatek/list/?series=855884
---
Change in v6:
1. Rebase to linux-next then rebased on 3 series [1][2][3]
2. Remove some parameter and security settings in normal world
3. Drop secure port related patches
4. Fix some build error and warning

Changes in v5:
1. Sync the local changes

Changes in v4:
1. Rebase on mediatek-drm-next(278640d4d74cd) and fix the conflicts
2. This series is based on 20240129063025.29251-1-yunfei.dong@...iatek.com
3. This series is based on 20240322052829.9893-1-shawn.sung@...iatek.com
4. This series is based on 20240403065603.21920-1-shawn.sung@...iatek.com

Changes in v3:
1. fix kerneldoc problems
2. fix typo in title and commit message
3. adjust naming for secure variable
4. add the missing part for is_suecure plane implementation
5. use BIT_ULL macro to replace bit shifting
6. move modification of ovl_adaptor part to the correct patch
7. add TODO list in commit message
8. add commit message for using share memory to store execute count

Changes in v2:

1. remove the DRIVER_RDNDER flag for mtk_drm_ioctl
2. move cmdq_insert_backup_cookie into client driver
3. move secure gce node define from mt8195-cherry.dtsi to mt8195.dtsi
---

CK Hu (1):
  drm/mediatek: Add interface to allocate MediaTek GEM buffer

Jason-JH.Lin (6):
  drm/mediatek/uapi: Add DRM_MTK_GEM_CREATE_RESTRICTED flag
  drm/mediatek: Add secure buffer control flow to mtk_drm_gem
  drm/mediatek: Add secure identify flag and funcution to mtk_drm_plane
  drm/mediatek: Add mtk_ddp_sec_write() to config secure buffer info
  drm/mediatek: Add secure flow support to mediatek-drm
  drm/mediatek: Add cmdq_insert_backup_cookie before secure pkt finalize

 drivers/gpu/drm/mediatek/mtk_crtc.c           | 263 +++++++++++++++++-
 drivers/gpu/drm/mediatek/mtk_crtc.h           |   1 +
 drivers/gpu/drm/mediatek/mtk_ddp_comp.c       |  14 +
 drivers/gpu/drm/mediatek/mtk_ddp_comp.h       |   5 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c       |   9 +-
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   |   1 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c        |  13 +-
 drivers/gpu/drm/mediatek/mtk_gem.c            | 114 ++++++++
 drivers/gpu/drm/mediatek/mtk_gem.h            |  12 +
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c       |   8 +-
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.h       |   1 +
 drivers/gpu/drm/mediatek/mtk_plane.c          |  25 ++
 drivers/gpu/drm/mediatek/mtk_plane.h          |   2 +
 include/uapi/drm/mediatek_drm.h               |  47 ++++
 14 files changed, 500 insertions(+), 15 deletions(-)
 create mode 100644 include/uapi/drm/mediatek_drm.h

-- 
2.18.0

Powered by blists - more mailing lists