From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Gaignard Subject: Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION) Date: Wed, 20 Mar 2019 16:59:10 +0100 Message-ID: References: <1551819273-640-1-git-send-email-john.stultz@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: "Andrew F. Davis" Cc: John Stultz , Rob Clark , Alistair Strachan , Vincent Donnefort , Greg KH , Chenbo Feng , lkml , Liam Mark , Marissa Wall , dri-devel List-Id: dri-devel@lists.freedesktop.org Le mer. 20 mars 2019 =C3=A0 15:54, Andrew F. Davis a =C3=A9cri= t : > > On 3/20/19 4:16 AM, Benjamin Gaignard wrote: > > Le mar. 19 mars 2019 =C3=A0 23:36, John Stultz = a =C3=A9crit : > >> > >> On Tue, Mar 19, 2019 at 2:58 PM Rob Clark wrote: > >>> > >>> On Tue, Mar 19, 2019 at 1:00 PM Andrew F. Davis wrote: > >>>> > >>>> On 3/19/19 11:54 AM, Benjamin Gaignard wrote: > >>>>> Le mer. 13 mars 2019 =C3=A0 23:31, John Stultz a =C3=A9crit : > >>>>>> > >>>>>> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark w= rote: > >>>>>>> On Tue, 5 Mar 2019, John Stultz wrote: > >>>>>>>> > >>>>>>>> Eventual TODOS: > >>>>>>>> * Reimplement page-pool for system heap (working on this) > >>>>>>>> * Add stats accounting to system/cma heaps > >>>>>>>> * Make the kselftest actually useful > >>>>>>>> * Add other heaps folks see as useful (would love to get > >>>>>>>> some help from actual carveout/chunk users)! > >>>>>>> > >>>>>>> We use a modified carveout heap for certain secure use cases. > >>>>>> > >>>>>> Cool! It would be great to see if you have any concerns about addi= ng > >>>>>> such a secure-carveout heap to this framework. I suspect it would = be > >>>>>> fairly similar to how its integrated into ION, but particularly I'= d be > >>>>>> interested in issues around the lack of private flags and other > >>>>>> allocation arguments like alignment. > >>>>>> > >>>>>>> Although there would probably be some benefit in discssing how th= e dma-buf > >>>>>>> heap framework may want to support > >>>>>>> secure heaps in the future it is a large topic which I assume you= don't > >>>>>>> want to tackle now. > >>>>>> > >>>>>> So I suspect others (Benjamin?) would have a more informed opinion= on > >>>>>> the details, but the intent is to allow secure heap implementation= s. > >>>>>> I'm not sure what areas of concern you have for this allocation > >>>>>> framework in particular? > >>>>> > >>>>> yes I would be great to understand how you provide the information = to > >>>>> tell that a dmabuf > >>>>> is secure (or not) since we can't add flag in dmabuf structure itse= lf. > >>>>> An option is manage > >>>>> the access rights when a device attach itself to the dmabuf but in > >>>>> this case you need define > >>>>> a list of allowed devices per heap... > >>>>> If you have a good solution for secure heaps you are welcome :-) > >>>>> > >>>> > >>>> Do we really need any of that? A secure buffer is secured by the > >>>> hardware firewalls that keep out certain IP (including often the > >>>> processor running Linux). So the only thing we need to track interna= lly > >>>> is that we should not allow mmap/kmap on the buffer. That can be don= e in > >>>> the per-heap layer, everything else stays the same as a standard > >>>> carveout heap. > >>> > >>> For at least some hw the importing driver needs to configure things > >>> differently for secure buffers :-/ > >> > >> Does the import ioctl need/use a flag for that then? Userland already > >> has to keep meta-data about dmabufs around. > > > > To secure a buffer you need to know who is allowed to write/read it and > > hardware block involved in the dataflow may need to know that the buffe= r > > is secure to configure themself. > > As example for a video decoding you allow hw video decoder to read in > > a buffer and display to read it. You can also allow cpu to write on the= buffer > > to add subtitles. For that we need to be able to mmap/kmap the buffer. > > Using a carveout heap for secure buffer mean that you reserved a large > > memory region only for this purpose, that isn't possible on embedded de= vice > > where we are always limited in memory so we use CMA. > > In the past I have used dmabuf's attach function to know who write into > > the buffer and then configure who will be able to read it. It was worki= ng well > > but the issue was how to in generic way this behavior. > > > > Okay, I think I see what you are saying now. > > The way we handle secure playback is to firewall everything upfront and > it is up to the application to inform the hardware about what it can and > cannot do to the buffer, or simply not ask anything not allowed (E.g. > writeback the decrypted stream) else it will get a firewall exception. > The buffer itself doesn't have to carry any information. > > It sounds like you want the hardware driver to be able to detect the > use-case based on the buffer itself and configure itself accordingly? Or > the exporter at attach time to check access permissions? Both are needed, the buffer client must know that it is a secure buffer and= heap will have to configure the permissions. > > The first would need a change to DMA-BUF framework, maybe an added flag. Sumit will NACK that because dmabuf have to remain neutral and not embedded flags for every possible usage. > The second would just need a heap exporter with the system wide smarts, > but as you say that is not very generic.. yes it is difficult to find a good solution for that. > > Andrew > > >> > >> thanks > >> -john