linux-kernel - Re: [PATCH v6 0/7] Add mediate-drm secure flow for SVP

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4828461fa10101eec29e2885bc1aa0e2b7114e7c.camel@mediatek.com>
Date: Tue, 28 May 2024 07:15:34 +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 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.

> 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 :)

Regards,
Jason-JH.Lin

> Maxime