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

[Laura Abbott]

On 2/19/19 9:21 AM, John Stultz wrote:
> 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
> 

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