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. 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 > > > >
