On 7/1/2016 12:17 PM, Paul Moore wrote:
> On Fri, Jul 1, 2016 at 2:59 PM, Daniel Jurgens <danielj@xxxxxxxxxxxx> wrote:
>> On 7/1/2016 1:54 PM, Paul Moore wrote:
>>> On Thu, Jun 30, 2016 at 5:48 PM, Daniel Jurgens <danielj@xxxxxxxxxxxx> 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?
> You worry about that in the LSM framework and hide the details behind
> the void pointer. For example, you create an array/list of LSM
> specific blobs and just stash a pointer to the head of the data in the
> void pointer.
Don't worry about it at this point. Patches pending.
If I have to change modules to accommodate the
infrastructure I'm not afraid to do so.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
