Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)

From: John Stultz <john.stultz@linaro.org>
To: Rob Clark <robdclark@gmail.com>
Cc: "Andrew F. Davis" <afd@ti.com>,
	Benjamin Gaignard <benjamin.gaignard@linaro.org>,
	Alistair Strachan <astrachan@google.com>,
	Vincent Donnefort <Vincent.Donnefort@arm.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Chenbo Feng <fengc@google.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Liam Mark <lmark@codeaurora.org>,
	Marissa Wall <marissaw@google.com>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)
Date: Tue, 19 Mar 2019 15:36:06 -0700	[thread overview]
Message-ID: <CALAqxLVbdpj+T4u3jZ_5Uqda5La1Py-ZGpXSep_CCoLzWyap8A@mail.gmail.com> (raw)
In-Reply-To: <CAF6AEGss21WmpF7sHGTxOEjuadSNpM6M_Z-WweK2W68FEHOFdA@mail.gmail.com>

On Tue, Mar 19, 2019 at 2:58 PM Rob Clark <robdclark@gmail.com> wrote:
>
> On Tue, Mar 19, 2019 at 1:00 PM Andrew F. Davis <afd@ti.com> wrote:
> >
> > On 3/19/19 11:54 AM, Benjamin Gaignard wrote:
> > > Le mer. 13 mars 2019 à 23:31, John Stultz <john.stultz@linaro.org> a écrit :
> > >>
> > >> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark <lmark@codeaurora.org> 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.
> > >>
> > >>> 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?
> > >
> > > 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 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.

thanks
-john