2017-10-18 22:07 GMT+02:00 Laura Abbott :
> On 09/27/2017 06:20 AM, Benjamin Gaignard wrote:
>> diff --git a/drivers/staging/android/ion/ion.c
>> b/drivers/staging/android/ion/ion.c
>> index 93e2c90..092b24c 100644
>> --- a/drivers/staging/android/ion/ion.c
>> +++ b/drivers/staging/android/ion/ion
On 09/27/2017 06:20 AM, Benjamin Gaignard wrote:
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index 93e2c90..092b24c 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -40,6 +40,8 @@
>
> #include "ion.h"
>
2017-10-17 0:09 GMT+02:00 Laura Abbott :
> On 10/10/2017 02:11 AM, Mark Brown wrote:
>> On Mon, Oct 09, 2017 at 05:10:37PM -0700, Laura Abbott wrote:
>>> On 10/09/2017 03:08 PM, Mark Brown wrote:
On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
>>
> Anyway, to move this forwar
On 10/10/2017 02:11 AM, Mark Brown wrote:
> On Mon, Oct 09, 2017 at 05:10:37PM -0700, Laura Abbott wrote:
>> On 10/09/2017 03:08 PM, Mark Brown wrote:
>>> On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
>
Anyway, to move this forward I think we need to see a proof of concept
>>>
On Mon, Oct 09, 2017 at 05:10:37PM -0700, Laura Abbott wrote:
> On 10/09/2017 03:08 PM, Mark Brown wrote:
> > On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
> >> Anyway, to move this forward I think we need to see a proof of concept
> >> of using selinux to protect access to specifi
On 10/09/2017 03:08 PM, Mark Brown wrote:
> On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
>
>> Anyway, to move this forward I think we need to see a proof of concept
>> of using selinux to protect access to specific heaps.
>
> Aren't Unix permissions enough with separate files or
On Mon, Oct 09, 2017 at 02:25:47PM -0700, Laura Abbott wrote:
> Anyway, to move this forward I think we need to see a proof of concept
> of using selinux to protect access to specific heaps.
Aren't Unix permissions enough with separate files or am I
misunderstanding what you're looking to see a p
On 10/05/2017 06:06 AM, Benjamin Gaignard wrote:
> 2017-10-04 12:17 GMT+02:00 Mark Brown :
>> On Tue, Oct 03, 2017 at 04:08:30PM -0700, Sandeep Patil wrote:
>>
>>> It is entirely possible and easy in android/ueventd to create those nodes
>>> under "/dev/ion/". (assuming the heap 'subsystem' for th
2017-10-04 12:17 GMT+02:00 Mark Brown :
> On Tue, Oct 03, 2017 at 04:08:30PM -0700, Sandeep Patil wrote:
>
>> It is entirely possible and easy in android/ueventd to create those nodes
>> under "/dev/ion/". (assuming the heap 'subsystem' for these new devices will
>> point to 'ion').
I think it is
On Tue, Oct 03, 2017 at 04:08:30PM -0700, Sandeep Patil wrote:
> It is entirely possible and easy in android/ueventd to create those nodes
> under "/dev/ion/". (assuming the heap 'subsystem' for these new devices will
> point to 'ion').
The reason I didn't say /dev/ion/foo initially is that if p
On 10/03/2017 04:08 PM, Sandeep Patil wrote:
> On Tue, Oct 03, 2017 at 02:42:32PM -0700, Laura Abbott wrote:
>> On 10/03/2017 09:48 AM, Mark Brown wrote:
>>> On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote:
>>>
Thinking about this a bit more, I'm not 100% sure if this
will al
On Tue, Oct 03, 2017 at 02:42:32PM -0700, Laura Abbott wrote:
> On 10/03/2017 09:48 AM, Mark Brown wrote:
> > On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote:
> >
> >> Thinking about this a bit more, I'm not 100% sure if this
> >> will allow the security rules we want. Heap ids are as
On 10/03/2017 09:48 AM, Mark Brown wrote:
> On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote:
>
>> Thinking about this a bit more, I'm not 100% sure if this
>> will allow the security rules we want. Heap ids are assigned
>> dynamically and therefore so will the /dev/ionX designation.
>
On Mon, Oct 02, 2017 at 11:07:48AM -0700, Laura Abbott wrote:
> Thinking about this a bit more, I'm not 100% sure if this
> will allow the security rules we want. Heap ids are assigned
> dynamically and therefore so will the /dev/ionX designation.
> From my understanding, security rules like selin
On 09/27/2017 06:20 AM, Benjamin Gaignard wrote:
> Instead a getting only one common device "/dev/ion" for
> all the heaps this patch allow to create one device
> entry ("/dev/ionX") per heap.
> Getting an entry per heap could allow to set security rules
> per heap and global ones for all heaps.
>
Instead a getting only one common device "/dev/ion" for
all the heaps this patch allow to create one device
entry ("/dev/ionX") per heap.
Getting an entry per heap could allow to set security rules
per heap and global ones for all heaps.
Allocation requests will be only allowed if the mask_id
matc
16 matches
Mail list logo