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

["Jason-JH Lin (林睿祥)" <Jason-JH.Lin@mediatek.com>]

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@mediatek.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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel