On 03/13/2017 06:21 AM, Mark Brown wrote: > On Mon, Mar 13, 2017 at 10:54:33AM +0000, Brian Starkey wrote: >> On Sun, Mar 12, 2017 at 02:34:14PM +0100, Benjamin Gaignard wrote: > >>> Another point is how can we put secure rules (like selinux policy) on >>> heaps since all the allocations >>> go to the same device (/dev/ion) ? For example, until now, in Android >>> we have to give the same >>> access rights to all the process that use ION. >>> It will become problem when we will add secure heaps because we won't >>> be able to distinguish secure >>> processes to standard ones or set specific policy per heaps. >>> Maybe I'm wrong here but I have never see selinux policy checking an >>> ioctl field but if that >>> exist it could be a solution. > >> I might be thinking of a different type of "secure", but... > >> Should the security of secure heaps be enforced by OS-level >> permissions? I don't know about other architectures, but at least on >> arm/arm64 this is enforced in hardware; it doesn't matter who has >> access to the ion heap, because only secure devices (or the CPU >> running a secure process) is physically able to access the memory >> backing the buffer. > 3 >> In fact, in the use-cases I know of, the process asking for the ion >> allocation is not a secure process, and so we wouldn't *want* to >> restrict the secure heap to be allocated from only by secure >> processes. > > I think there's an orthogonal level of OS level security that can be > applied here - it's reasonable for it to want to say things like "only > processes that are supposed to be implementing functionality X should be > able to try to allocate memory set aside for that functionality". This > mitigates against escallation attacks and so on, it's not really > directly related to secure memory as such though. > Ion also makes it pretty trivial to allocate large amounts of kernel memory and possibly DoS the system. I'd like to have as little policy in Ion as possible but more important would be a general security review and people shouting "bad idea ahead". Thanks, Laura _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
