| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <0f828842524f1518ccb6f75e6b34efd849466016.camel@mediatek.com>
Date: Thu, 21 Sep 2023 01:31:26 +0000
From: CK Hu (胡俊光) <ck.hu@...iatek.com>
To: "jkardatzke@...gle.com" <jkardatzke@...gle.com>
CC: "linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
Johnson Wang (王聖鑫)
<Johnson.Wang@...iatek.com>,
Singo Chang (張興國)
<Singo.Chang@...iatek.com>,
"linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
Jason-JH Lin (林睿祥)
<Jason-JH.Lin@...iatek.com>,
"chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>,
"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
Shawn Sung (宋孝謙)
<Shawn.Sung@...iatek.com>,
Nancy Lin (林欣螢) <Nancy.Lin@...iatek.com>,
Jason-ch Chen (陳建豪)
<Jason-ch.Chen@...iatek.com>,
"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
Project_Global_Chrome_Upstream_Group
<Project_Global_Chrome_Upstream_Group@...iatek.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"matthias.bgg@...il.com" <matthias.bgg@...il.com>,
"angelogioacchino.delregno@...labora.com"
<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH 00/10] Add mediate-drm secure flow for SVP
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@...iatek.com>
> 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
> > >
>
Powered by blists - more mailing lists