From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Stultz Subject: Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION) Date: Tue, 19 Mar 2019 15:36:06 -0700 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: Rob Clark Cc: "Andrew F. Davis" , Benjamin Gaignard , Alistair Strachan , Vincent Donnefort , Greg KH , Chenbo Feng , lkml , Liam Mark , Marissa Wall , dri-devel List-Id: dri-devel@lists.freedesktop.org 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 wro= te: > > >>> 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 adding > > >> 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 the = dma-buf > > >>> heap framework may want to support > > >>> secure heaps in the future it is a large topic which I assume you d= on't > > >>> want to tackle now. > > >> > > >> So I suspect others (Benjamin?) would have a more informed opinion o= n > > >> the details, but the intent is to allow secure heap implementations. > > >> 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 itself= . > > > 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 internally > > is that we should not allow mmap/kmap on the buffer. That can be done i= n > > 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. thanks -john