dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Gaignard <benjamin.gaignard@linaro.org>
To: "Andrew F. Davis" <afd@ti.com>
Cc: John Stultz <john.stultz@linaro.org>,
	Rob Clark <robdclark@gmail.com>,
	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: Wed, 20 Mar 2019 16:59:10 +0100	[thread overview]
Message-ID: <CA+M3ks77ZGU-VnxV4vJkYHvtE=EwzxZCdedmXG9ceYCyt14fHQ@mail.gmail.com> (raw)
In-Reply-To: <d6f8092d-9f90-d5ff-2ab3-b1867f8f5700@ti.com>

Le mer. 20 mars 2019 à 15:54, Andrew F. Davis <afd@ti.com> a écrit :
>
> On 3/20/19 4:16 AM, Benjamin Gaignard wrote:
> > Le mar. 19 mars 2019 à 23:36, John Stultz <john.stultz@linaro.org> a écrit :
> >>
> >> 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.
> >
> > 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 buffer
> > 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 device
> > 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 working 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

  reply	other threads:[~2019-03-20 15:59 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-05 20:54 John Stultz
2019-03-05 20:54 ` [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework John Stultz
2019-03-06 16:12   ` Benjamin Gaignard
2019-03-06 16:57     ` John Stultz
2019-03-15  8:55     ` Christoph Hellwig
2019-03-06 16:27   ` Andrew F. Davis
2019-03-06 19:03     ` John Stultz
2019-03-06 21:45       ` Andrew F. Davis
2019-03-15  8:54   ` Christoph Hellwig
2019-03-15 20:24     ` Andrew F. Davis
2019-03-15 20:18   ` Laura Abbott
2019-03-15 20:49     ` Andrew F. Davis
2019-03-15 21:29     ` John Stultz
2019-03-15 22:44       ` Laura Abbott
2019-03-18  4:38         ` Sumit Semwal
2019-03-18  4:41         ` Sumit Semwal
2019-03-19 12:08   ` Brian Starkey
2019-03-19 15:24     ` Andrew F. Davis
2019-03-21 21:16     ` John Stultz
2019-03-27 14:53   ` Greg KH
2019-03-28  6:09     ` John Stultz
2019-03-05 20:54 ` [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers John Stultz
2019-03-13 20:18   ` Liam Mark
2019-03-13 21:48     ` Andrew F. Davis
2019-03-13 22:57       ` Liam Mark
2019-03-13 23:42         ` Andrew F. Davis
2019-03-15  9:06   ` Christoph Hellwig
2019-03-19 15:03     ` Andrew F. Davis
2019-03-21 20:01     ` John Stultz
2019-03-19 14:26   ` Brian Starkey
2019-03-21 20:11     ` John Stultz
2019-03-21 20:35     ` Andrew F. Davis
2019-03-21 20:43   ` Andrew F. Davis
2019-03-05 20:54 ` [RFC][PATCH 3/5 v2] dma-buf: heaps: Add system heap to dmabuf heaps John Stultz
2019-03-06 16:01   ` Benjamin Gaignard
2019-03-11  5:48     ` John Stultz
2019-03-13 20:20   ` Liam Mark
2019-03-13 22:49     ` John Stultz
2019-03-15  9:06   ` Christoph Hellwig
2019-03-05 20:54 ` [RFC][PATCH 4/5 v2] dma-buf: heaps: Add CMA heap to dmabuf heapss John Stultz
2019-03-06 16:05   ` Benjamin Gaignard
2019-03-21 20:15     ` John Stultz
2019-03-15  9:06   ` Christoph Hellwig
2019-03-15 20:08     ` John Stultz
2019-03-19 14:53   ` Brian Starkey
2019-03-05 20:54 ` [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test John Stultz
2019-03-06 16:14   ` Benjamin Gaignard
2019-03-06 16:35     ` Andrew F. Davis
2019-03-06 18:19       ` John Stultz
2019-03-06 18:32         ` Andrew F. Davis
2019-03-06 17:01     ` John Stultz
2019-03-15 20:07       ` Laura Abbott
2019-03-15 20:13         ` John Stultz
2019-03-15 20:49           ` Laura Abbott
2019-03-13 20:23   ` Liam Mark
2019-03-13 20:11 ` [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION) Liam Mark
2019-03-13 22:30   ` John Stultz
2019-03-13 23:29     ` Liam Mark
2019-03-19 16:54     ` Benjamin Gaignard
2019-03-19 16:59       ` Andrew F. Davis
2019-03-19 21:58         ` Rob Clark
2019-03-19 22:36           ` John Stultz
2019-03-20  9:16             ` Benjamin Gaignard
2019-03-20 14:44               ` Andrew F. Davis
2019-03-20 15:59                 ` Benjamin Gaignard [this message]
2019-03-20 16:11               ` John Stultz
2019-03-15 20:34 ` Laura Abbott
2019-03-15 23:15 ` Jerome Glisse
2019-03-16  0:16   ` John Stultz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+M3ks77ZGU-VnxV4vJkYHvtE=EwzxZCdedmXG9ceYCyt14fHQ@mail.gmail.com' \
    --to=benjamin.gaignard@linaro.org \
    --cc=Vincent.Donnefort@arm.com \
    --cc=afd@ti.com \
    --cc=astrachan@google.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=fengc@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lmark@codeaurora.org \
    --cc=marissaw@google.com \
    --cc=robdclark@gmail.com \
    --subject='Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).