Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support

[Olivier Masse <olivier.masse@nxp.com>]

+Cyrille

Hi Nicolas,

On mer., 2022-08-17 at 10:29 -0400, Nicolas Dufresne wrote:
> Caution: EXT Email
> 
> Hi Folks,
> 
> Le mardi 16 août 2022 à 11:20 +0000, Olivier Masse a écrit :
> > Hi Brian,
> > 
> > 
> > On ven., 2022-08-12 at 17:39 +0100, Brian Starkey wrote:
> > > Caution: EXT Ema
> > > 
> 
> [...]
> 
> > > 
> > > Interesting, that's not how the devices I've worked on operated.
> > > 
> > > Are you saying that you have to have a display controller driver
> > > running in the TEE to display one of these buffers?
> > 
> > In fact the display controller is managing 3 plans : UI, PiP and
> > video. The video plan is protected in secure as you can see on
> > slide
> > 11:
> > 
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstatic.linaro.org%2Fconnect%2Fsan19%2Fpresentations%2Fsan19-107.pdf&data=05%7C01%7Colivier.masse%40nxp.com%7Ce0e00be789a54dff8e5208da805ce2f6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637963433695707516%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GHjEfbgqRkfHK16oyNaYJob4LRVqvoffRElKR%2F7Rtes%3D&reserved=0
> 
> 
> 
> just wanted to highlight that all the WPE/GStreamer bit in this
> presentation is
> based on NXP Vendor Media CODEC design, which rely on their own i.MX
> VPU API. I
> don't see any effort to extend this to a wider audience. It is not
> explaining
> how this can work with a mainline kernel with v4l2 stateful or
> stateless drivers
> and generic GStreamer/FFMPEG/Chromium support.

Maybe Cyrille can explain what it is currently done at NXP level
regarding the integration of v4l2 with NXP VPU.

> 
> I'm raising this, since I'm worried that no one cares of solving that
> high level
> problem from a generic point of view. In that context, any additions
> to the
> mainline Linux kernel can only be flawed and will only serves
> specific vendors
> and not the larger audience.
> 
> Another aspect, is that this design might be bound to a specific (NXP
> ?)
> security design. I've learn recently that newer HW is going to use
> multiple
> level of MMU (like virtual machines do) to protect the memory rather
> then
> marking pages. Will all this work for that too ?

our fire-walling hardware is protecting memory behind the MMU and so
rely on physical memory layout.
this work is only relying on a reserved physical memory.

Regards,
Olivier

> 
> regards,
> Nicolas