Message-ID: <43db5c0959b387ff049dbd285093b076ed1421fa.camel@mediatek.com>
Date: Thu, 30 May 2024 16:29:44 +0000
From: Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>
To: "mripard@...nel.org" <mripard@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	Singo Chang (張興國) <Singo.Chang@...iatek.com>,
	"linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"jason-jh.lin@...iatek.corp-partner.google.com"
	<jason-jh.lin@...iatek.corp-partner.google.com>,
	Jason-ch Chen (陳建豪)
	<Jason-ch.Chen@...iatek.com>, Shawn Sung (宋孝謙)
	<Shawn.Sung@...iatek.com>, Nancy Lin (林欣螢)
	<Nancy.Lin@...iatek.com>, "daniel@...ll.ch" <daniel@...ll.ch>,
	"jkardatzke@...gle.com" <jkardatzke@...gle.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@...iatek.com>, "airlied@...il.com"
	<airlied@...il.com>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "matthias.bgg@...il.com"
	<matthias.bgg@...il.com>, "angelogioacchino.delregno@...labora.com"
	<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH v6 0/7] Add mediate-drm secure flow for SVP

Hi Maxime,

On Thu, 2024-05-30 at 17:01 +0200, mripard@...nel.org wrote:
> On Tue, May 28, 2024 at 07:15:34AM GMT, Jason-JH Lin (林睿祥) wrote:
> > Hi Maxime,
> > 
> > On Mon, 2024-05-27 at 16:06 +0200, Maxime Ripard wrote:
> > > Hi,
> > > 
> > > On Sun, May 26, 2024 at 07:29:21AM GMT, Jason-JH.Lin wrote:
> > > > 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
> > > 
> > > I'm not sure what you mean here. Why are you trying to upstream
> > > something that still needs to be removed from your patch series?
> > > 
> > 
> > Because their is too much patches need to be fixed in this series,
> > so I
> > list down the remaining TODO items and send to review for the other
> > patches.
> > 
> > Sorry for the bothering, I'll drop this at the next version.
> 
> If you don't intend to use it, we just shouldn't add it. Removing the
> TODO item doesn't make sense, even more so if heaps should be the way
> you handle this.
> 
Sorry for this misunderstanding.

I mean I'll remove the DRM_IOCTL_GEM_CREATE patch and then change user
space calling DMA_HEAP_IOCTL_ALLOC to allocate buffer from secure heap.

> > > Also, I made some comments on the previous version that have been
> > > entirely ignored and still apply on this version:
> > > 
> > 
> > 
https://lore.kernel.org/dri-devel/20240415-guppy-of-perpetual-current-3a7974@houat/
> > > 
> > 
> > I lost that mail in my mailbox, so I didn't reply at that time.
> > I have imported that mail and replied to you. Hope you don't mind
> > :)
> 
> I haven't received that answer

I don't know why it doesn't show up at your link.

Could you see it here?

https://patchwork.kernel.org/project/linux-mediatek/patch/20240403102701.369-3-shawn.sung@mediatek.com/



Regards,
Jason-JH.Lin
> 
> Maxime

Powered by blists - more mailing lists