Re: [PATCH 00/10] Add mediate-drm secure flow for SVP

quoted

Hi CK,

On Thu, 2023-09-21 at 01:31 +0000, CK Hu (胡俊光) wrote:
On Wed, 2023-09-20 at 11:25 -0700, Jeffrey Kardatzke wrote:

External email : Please do not click links or open attachments
until
you have verified the sender or the content.
 On Tue, Sep 19, 2023 at 10:26 PM CK Hu (胡俊光) [off-list ref]
wrote:
Hi, Jason:

On Tue, 2023-09-19 at 11:03 +0800, Jason-JH.Lin wrote:
The patch series provides drm driver support for enabling
secure
video
path (SVP) playback on MediaiTek hardware in the Linux kernel.

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_ENCRYPTED which indicates it should be a
'secure
surface'. All changes here are in MediaTek specific code.
How do you define SVP? Is there standard requirement we could
refer
to?
If the secure video buffer is read by display hardware and output
to
HDMI without any protection and user could capture HDMI signal,
is
this
secure?
SVP (Secure Video Path) is essentially the video being completed
isolated from the kernel/userspace. The specific requirements for
it
vary between implementations.

Regarding HDMI/HDCP output; it's the responsibility of the TEE to
enforce that. Nothing on the kernel/userspace side needs to be
concerned about enforcing HDCP. The only thing userspace is
involved
in there is actually turning on HDCP via the kernel drivers; and
then
the TEE ensures that it is active if the policy for the encrypted
content requires it.
But in [Patch 07/10],

in mtk_ovl_layer_config(), the secure input would enable/disable
dynamical in kernel, MediaTek SVP does not hide all control in TEE,
so
I worry that something lost. To achieve SVP, display hardware should
have secure input, secure pipeline, secure output, but in this
series,
I just see secure input. Maybe others is done in TEE, tell me which
part is done by which step.
We'll use cmdq_sec_pkt_set_data() to bring the secure scenario, secure
engine flags and some secure metadata to TEE world. Then will used
these information to make sure the pipeline is secure.

We don't have the secure output feature currently, such as WiFi
display, so we'll do it after we have to support the feature.

Also there are HDMITX_HDCP and DPTX_HDCP TA will check the HDCP statue
in secure world and then CMDQ TA will get that status by calling their
API in TEE.
If CMDQ TA get a HDCP checking failed sstatus, it will insert some
instructions in the secure cmd buffer to mute the DISP HW for each
frames.

Regards,
Jason-JH.Lin

Regards,
CK

Regards,
CK

---
Based on 2 series:
[1] Add CMDQ secure driver for SVP
-

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=785332__;!!CTRNKA9wMg0ARbw!mPocbQwZ4-25DmidvAgd9K5eXjNEhSyIKpvvYHPpdrq2PgS-hkYyHohzDvoJydD45UZp5JvY9DuDVFj1ltVnhGY$

[2] dma-buf: heaps: Add MediaTek secure heap
-

https://urldefense.com/v3/__https://patchwork.kernel.org/project/linux-mediatek/list/?series=782776__;!!CTRNKA9wMg0ARbw!mPocbQwZ4-25DmidvAgd9K5eXjNEhSyIKpvvYHPpdrq2PgS-hkYyHohzDvoJydD45UZp5JvY9DuDVFj10sD4kHE$
---

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

Jason-JH.Lin (9):
  drm/mediatek/uapi: Add DRM_MTK_GEM_CREATED_ENCRYPTTED 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 get_sec_port interface to mtk_ddp_comp
  drm/mediatek: Add secure layer config support for ovl
  drm/mediatek: Add secure layer config support for ovl_adaptor
  drm/mediatek: Add secure flow support to mediatek-drm
  arm64: dts: mt8195-cherry: Add secure mbox settings for
vdosys

 .../boot/dts/mediatek/mt8195-cherry.dtsi      |  10 +
 drivers/gpu/drm/mediatek/mtk_disp_drv.h       |   3 +
 drivers/gpu/drm/mediatek/mtk_disp_ovl.c       |  31 +-
 .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c   |  15 +
 drivers/gpu/drm/mediatek/mtk_drm_crtc.c       | 271
+++++++++++++++++-
 drivers/gpu/drm/mediatek/mtk_drm_crtc.h       |   1 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c   |  14 +
 drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h   |  13 +
 drivers/gpu/drm/mediatek/mtk_drm_drv.c        |  16 +-
 drivers/gpu/drm/mediatek/mtk_drm_gem.c        | 121 ++++++++
 drivers/gpu/drm/mediatek/mtk_drm_gem.h        |  16 ++
 drivers/gpu/drm/mediatek/mtk_drm_plane.c      |   7 +
 drivers/gpu/drm/mediatek/mtk_drm_plane.h      |   2 +
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c       |  11 +-
 drivers/gpu/drm/mediatek/mtk_mdp_rdma.h       |   2 +
 include/uapi/drm/mediatek_drm.h               |  59 ++++
 16 files changed, 575 insertions(+), 17 deletions(-)
 create mode 100644 include/uapi/drm/mediatek_drm.h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help