[openib-general] multicast code/merge status

[Or Gerlitz]

Michael S. Tsirkin wrote:
>> Quoting Sean Hefty <mshefty at ichips.intel.com>:
>> Subject: Re: multicast code/merge status
>>
>>> sure, it can use the rdmacm qkey (0x1234567 etc) when it creates the QP 
>>> and later --if-- the user joins a multicast group modify the qp state 
>>> with the group qkey and report it in the cma event such that the 
>>> consumer of the rdmacm would set this into his IB UD TX WR
>> Changing the qkey would break its existing UD communication.
>>
>>> Bottom line, Looking in the IB SPEC and IPoIB RFC i did not see 
>>> mentioning of privileged QKEY.
>>  From RFC 4391 (ipoib RFC), 4.1:
>>
>>   2. Q_Key
>>
>>            It is RECOMMENDED that a controlled Q_Key be used with the
>>            high-order bit set.  This is to prevent non-privileged
>>            software from fabricating and sending out bogus IP datagrams.
> 
> BTW, should we be worried that proposed extension (passing qkey in rdma cm param
> list) seems to expose this qkey to non-privileged software?

As was said over related threads here and elsewhere, multicast has its 
in nature non safeties and having IB implement broadcast over multicast 
adds more in safety to the party.

Specifically, as Roland has commented, a user can attach his user space 
UD QP to the MGID of the ipv4 broadcast    (if ipoib is running on this 
node it will join the group) and start making this IP subnet go crazy.

We only want interop with IPoIB and we don't need to join/attach the 
ipv4 broadcast group just have an option for the rdmacm to use its qkey 
for joins and later either the rdmacm or the consumer will also set this 
qkey into the QP and the UD TX WR

> Maybe a machanism should be in place to control access to this separately
> from regular rdma cm for RC QPs?

not following you here, how does qkey relates to RC QPs ?

Or.