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

[Cyrille Fleury]

Hi Nicolas, all,

 The short reply:
      - For DRM, gstreamer, ffmeg, ... we don't use anymore NXP VPU proprietary API 
      - We need secure dma-buf heaps to replace secure ion heaps

  The more detailed reply to address concerns below in the thread:
      - NXP doesn't design VPU, but rely on third party VPU hardware IP we integrate in our soc.  NXP proprietary API are for legacy applications our customers did without using gstreamer or ffmpeg, but we are now relying on V4L2 API for WPE/gstreamer, chromium/ffmpeg ...
      - Even with NXP legacy BSP, there was no API impact for WPE (or chromium) due to NXP VPU API. We use WPE/gstreamer, then a gstreamer pluging relying on NXP VPU proprietary API. But now we use V4L2. So we can forget NXP VPU proprietary API, and I'm very happy with that.
      - We have moved from ion buffer to dma buff to manage secure memory management. This is why we need secure dma-buf heaps, we protect with NXP hardware as we did with ion heaps in the presentation Olivier shared.        
      - For secure video playback, the changes we need to do are in user space world (gstreamer, WPE, ...), to update our patches managing secure ion heaps by secure dma-buf heaps. But dma-buf is file descriptor based as ion heap are.
      - What will change between platforms, is how memory is protected. This is why we requested to have dtb in OPTEE for secure memory, to be able to provide a common API to secure DDR memory, and  then to rely on proprietary code in OPTEE to secure it.
      - We don't have a display controller or VPU decoder running in TEE. They remain under the full control of Linux/REE Word. If Linux/REE ask something breaking Widevine/PlayReady security rules, for example decode secure memory to non-secure memory, read from secure memory will return 0, write to secure memory will be ignored. Same with keys, certificates ...
      - i.MX8 socs have a stateless VPU and there is no VPU firmware. i.MX9 socs have a stateful VPU with firmware. In secure memory context, with secure memory, at software level, stateful VPU are even more simple to manage ->  less read/write operations performed by Linux world to parse the stream, so less patch to be done in the video framework. But for memory management, stateful/stateless, same concern: we  need  to provide support of secure dma heaps to Linux, to allocate secure memory for the VPU and the display controller, so it is just a different dma-buf heaps, so a different file descriptor.
      - i.MX9 VPU will support "Virtual Machine VPU". Till now I don't see why it will not work. I'm not an expert in VM, but from what I understood from my discussions with NXP VPU team integrating the new VPU hardware IP, from outside world, VPU is seen as multiple VPUs, with multiple register banks. So virtualized OS will continue to read/write registers as today, and at software level, secure memory is as non-secure memory, I mean at this end, it is physical DDR memory. Of course hardware shall be able to read/write it, but this is not software related, this is hardware concern. And even without VM, we target to dedicate one virtual VPU to DRM,  so one register bank, to setup dedicated security rules for DRM.
      
  I'm on vacation until end of this week. I can setup a call next week to discuss this topic if more clarifications are needed.

Regards.

-----Original Message-----
From: Olivier Masse <olivier.masse@xxxxxxx> 
Sent: Wednesday, August 17, 2022 4:52 PM
To: nicolas@xxxxxxxxxxxx; Cyrille Fleury <cyrille.fleury@xxxxxxx>; brian.starkey@xxxxxxx
Cc: sumit.semwal@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linaro-mm-sig@xxxxxxxxxxxxxxxx; christian.koenig@xxxxxxx; linux-media@xxxxxxxxxxxxxxx; nd@xxxxxxx; Clément Faure <clement.faure@xxxxxxx>; dri-devel@xxxxxxxxxxxxxxxxxxxxx; benjamin.gaignard@xxxxxxxxxxxxx
Subject: Re: [EXT] Re: [PATCH 1/3] dma-buf: heaps: add Linaro secure dmabuf heap support

+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&amp;data=05%7C01%7Colivier.masse%40nxp.com%7Ce0e00be789a54dff8e5208da805ce2f6%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637963433695707516%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=GHjEfbgqRkfHK16oyNaYJob4LRVqvoffRElKR%2F7Rtes%3D&amp;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