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

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: <fb022db983aa44a5b1a8478d340198ecc52c4e11.camel@nxp.com>
Date:   Wed, 17 Aug 2022 14:52:13 +0000
From:   Olivier Masse <olivier.masse@....com>
To:     "nicolas@...fresne.ca" <nicolas@...fresne.ca>,
        Cyrille Fleury <cyrille.fleury@....com>,
        "brian.starkey@....com" <brian.starkey@....com>
CC:     "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
        "christian.koenig@....com" <christian.koenig@....com>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        "nd@....com" <nd@....com>,
        Clément Faure <clement.faure@....com>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "benjamin.gaignard@...labora.com" <benjamin.gaignard@...labora.com>
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