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

From: Jason-JH Lin (林睿祥)
Date: Thu Sep 21 2023 - 12:59:49 EST

Next message: Frank Li: "[PATCH 1/1] PCI: layerscape-ep: set 64-bit DMA mask"
Previous message: David Lechner: "[PATCH v2 14/19] staging: iio: resolver: ad2s1210: refactor setting excitation frequency"
In reply to: CK Hu (胡俊光): "Re: [PATCH 00/10] Add mediate-drm secure flow for SVP"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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 (胡俊光) <ck.hu@xxxxxxxxxxxx>
> > 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
> > > >

Next message: Frank Li: "[PATCH 1/1] PCI: layerscape-ep: set 64-bit DMA mask"
Previous message: David Lechner: "[PATCH v2 14/19] staging: iio: resolver: ad2s1210: refactor setting excitation frequency"
In reply to: CK Hu (胡俊光): "Re: [PATCH 00/10] Add mediate-drm secure flow for SVP"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]