[lkml]   [2019]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)
On Wed, 13 Mar 2019, John Stultz wrote:

> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark <> wrote:
> > 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.

We are actively working to drop our secure careveout heap in order to
improve memory utilization so I don't think there would be a good case for
upstreaming it.

Our other secure heaps are CMA based and system heap based.
Because people have had difficulty designing a generic secure heap which
would satisfy enough of everybody's use cases to be upstreamable we have
been looking into moving away from having local secure heap changes and
instead have been looking at how to instead have a separate driver be
responsible for making an ION buffer memory secure. The idea was to do
this in order to remove a lot of our local ION changes, but if a secure
heap was upstreamed that supported our secure use cases I am sure we would
be interested in using that.

The local change the ION API to support these heaps is the addition of all
the VMID flags so that the client can specify where the client wants the
memory assigned.

> > 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 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 implementations.
> I'm not sure what areas of concern you have for this allocation
> framework in particular?

I don't have any areas of concern, my thought was just that flushing out a
potential design for an upstreamable secure heap would allow us catch
early on if there is anything fundamental that would need to change
dma-buf heaps framework (such as the allocation API).
I don't think this is a necessary task at this point.


Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

 \ /
  Last update: 2019-03-14 00:29    [W:0.115 / U:0.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site