Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <1551819273-640-1-git-send-email-john.stultz@linaro.org>
 <alpine.DEB.2.10.1903131309260.5023@lmark-linux.qualcomm.com>
 <CALAqxLUkGME+K=0g5QSja4CvN0w9z0WV60djy+5rRC+Dg-jCGg@mail.gmail.com>
 <CA+M3ks7q8QnNirk_WkaE5CmFWkEPn4uu5Hfb2kP+4d5qapHvrA@mail.gmail.com>
 <c51be371-086a-bd5b-b70a-5579f5b95320@ti.com> <CAF6AEGss21WmpF7sHGTxOEjuadSNpM6M_Z-WweK2W68FEHOFdA@mail.gmail.com>
 <CALAqxLVbdpj+T4u3jZ_5Uqda5La1Py-ZGpXSep_CCoLzWyap8A@mail.gmail.com>
In-Reply-To: <CALAqxLVbdpj+T4u3jZ_5Uqda5La1Py-ZGpXSep_CCoLzWyap8A@mail.gmail.com>
From:   Benjamin Gaignard <benjamin.gaignard@linaro.org>
Date:   Wed, 20 Mar 2019 10:16:47 +0100
Message-ID: <CA+M3ks61BGPkPjNd01g32LV7YZfDpy8t100KxQhScOFgGO4KjA@mail.gmail.com>
Subject: Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)
To:     John Stultz <john.stultz@linaro.org>
Cc:     Rob Clark <robdclark@gmail.com>, "Andrew F. Davis" <afd@ti.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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Le mar. 19 mars 2019 =C3=A0 23:36, John Stultz <john.stultz@linaro.org> a =
=C3=A9crit :
>
> 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 =C3=A0 23:31, John Stultz <john.stultz@linaro.=
org> a =C3=A9crit :
> > > >>
> > > >> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark <lmark@codeaurora.org> 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 internal=
ly
> > > 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 buf=
fer
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 w=
ell
but the issue was how to in generic way this behavior.

>
> thanks
> -john