On 7/1/2016 1:54 PM, Paul Moore wrote:
> On Thu, Jun 30, 2016 at 5:48 PM, Daniel Jurgens <dani...@mellanox.com> wrote:
>> On 6/30/2016 4:06 PM, Casey Schaufler wrote:
>>> On 6/30/2016 1:42 PM, Paul Moore wrote:
>>>>> };
>>>>>
>>>>> /**
>>>>> diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
>>>>> index 3f6780b..e522acb 100644
>>>>> --- a/include/rdma/ib_verbs.h
>>>>> +++ b/include/rdma/ib_verbs.h
>>>>> @@ -1454,6 +1454,7 @@ struct ib_qp {
>>>>> void *qp_context;
>>>>> u32 qp_num;
>>>>> enum ib_qp_type qp_type;
>>>>> + struct ib_qp_security *qp_sec;
>>>> See my earlier question/comment about just using a void pointer here.
>>> I think that this is in response to my comments to the
>>> effect that I would like to see the LSM infrastructure
>>> using the inode like (inode->i_security) to the xfrm
>>> (void *) approach. I haven't been looking at the IB patches
>>> too carefully to date. It's possible I have not been clear.
>> My understanding at the time was that by using something other than a void *
>> different security modules could maintain their own opaque blobs with in and
>> keep the same prototype for the hook. It's possible I misunderstood you,
>> but it made sense to me. I don't know of any plans for other security
>> modules to support Infiniband, but this leaves the door open.
> All of what you describe above can still happen with a void pointer;
> in some ways it is even easier with a void pointer.
If multiple security modules register an alloc_security hook for example, how
would you coordinate between them to allocate the memory?
_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
