[EARLY RFC][PATCH 0/4] ION per heap devices

John Stultz john.stultz at linaro.org
Tue Feb 19 17:21:02 UTC 2019


On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey <Brian.Starkey at arm.com> wrote:
> On Fri, Feb 15, 2019 at 12:24:08PM -0800, John Stultz wrote:
> > This is a *very early RFC* (it builds, that's all I'll say :)
> > but I wanted to share it to get some initial feedback before I
> > go down the rabit hole of trying to adapt the Android userland
> > code to get this fully validated.
> >
> > This patchset tries to implement the per-heap devices for ION.
> > The main benefit is that it avoids multiplexing heap operations
> > through the /dev/ion interface, and allows for each heap to have
> > its own permissions/sepolicy rules.
>
> In general, I've always thought that having a device node per-heap is
> a bit messy for userspace. Multiplexing through the single node
> doesn't seem like an insurmountable problem, but the point about

Hrm. I guess for me having a custom enumeration interface over ioctl
seems less ideal compared to a directory list.

> permissions/sepolicy is reasonably compelling if it's a real
> requirement. What would be the reasons for that?

Its a bit second hand for me, so hopefully I don't have it wrong. I've
cc'ed some additional google folks and Benjamin for extra context, but
my sense of it is that you may have some less-trusted code that we're
fine with allocating system heap dma-bufs, but don't want to to be
giving access to more limited heaps like carveout or cma, or more
potentially security troubling heaps like system-contig.

thanks
-john


More information about the dri-devel mailing list