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> <CA+M3ks61BGPkPjNd01g32LV7YZfDpy8t100KxQhScOFgGO4KjA@mail.gmail.com>
In-Reply-To: <CA+M3ks61BGPkPjNd01g32LV7YZfDpy8t100KxQhScOFgGO4KjA@mail.gmail.com>
From:   John Stultz <john.stultz@linaro.org>
Date:   Wed, 20 Mar 2019 09:11:31 -0700
Message-ID: <CALAqxLX-ooNmHBmSr3iRvHhBwP+rinc7WOe0Aw1dKKyKZWE0iw@mail.gmail.com>
Subject: Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)
To:     Benjamin Gaignard <benjamin.gaignard@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

On Wed, Mar 20, 2019 at 2:16 AM Benjamin Gaignard
<benjamin.gaignard@linaro.org> wrote:
> 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:
> > > 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 b=
uffer
> 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 devi=
ce
> 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.

Given the complexity of the configuration needed when allocating the
buffer, instead of trying to make a generic secure buffer allocator,
would having per-usege heaps make sense?  It just feels there are so
many specifics to the secure buffer setup and configuration that maybe
there can't be a generic configuration interface.  So instead maybe we
let the heap implementations provide set usage configs?

This doesn't necessarily require that you have separate pools of
memory (they can share the same backing store), but by having multiple
per-config heap devices, maybe this could avoid trying to fit all the
options into one interface?

On the import side, I'm not sure how much the importing device needs
to know about the specific rules here (out side of "secure buffer" or
not), so maybe that's another catch.

thanks
-john