On 2/19/19 9:21 AM, John Stultz wrote:
On Mon, Feb 18, 2019 at 3:51 AM Brian Starkey <brian.star...@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
Yes, the discussion was always based on being able to set separate
security policy for each heap. It's not clear to me how strong a
requirement is these days or if there's other options to enforce
the same thing.
Thanks,
Laura
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
