[swg] RE: [openib-general] RE: [dat-discussions] socket based connectionmodel for IB proposal - round 3

[Renato Recio]

Any active side QP can target a passive side CM QP (QP1 or redirected QPN).
However, due to the use of priviliged Q_Keys, only an active side
priviliged QP can target the passive side CM QP.

It seems to me that our proposal of having the Service ID be generated by
priviliged mode code,  having a Service ID associated with RDMA Services
(e.g. iSER, NFSeR, ...),  and having priviliged mode code generate the
first N bytes of the private data field (i.e. the bytes in question);
allows the passive side:
   - Transport to validate an incoming CM message was generated by a
   priviliged consumer; and
   - CM to know the Service ID and first N-bytes of the private data field
   were generated by a priviliged consumer.

Thanks,


Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685



                                                                                                                                   
                      "Caitlin Bestler"                                                                                            
                      <caitlinb at broadco        To:       Renato Recio/Austin/IBM at IBMUS                                             
                      m.com>                   cc:       "Kanevsky, Arkady" <Arkady.Kanevsky at netapp.com>,                          
                                                dat-discussions at yahoogroups.com, "Sean Hefty" <mshefty at ichips.intel.com>,          
                      11/11/2005 01:12          openib-general at openib.org, swg at infinibandta.org                                    
                      PM                       Subject:  RE: [swg] RE: [openib-general] RE: [dat-discussions] socket based         
                                                connectionmodel for IB proposal - round 3                                          
                                                                                                                                   
                                                                                                                                   






 From: Renato Recio [mailto:recio at us.ibm.com]
 Sent: Friday, November 11, 2005 11:01 AM
 To: Caitlin Bestler
 Cc: Kanevsky, Arkady; dat-discussions at yahoogroups.com; Sean Hefty;
 openib-general at openib.org; swg at infinibandta.org
 Subject: Re: [swg] RE: [openib-general] RE: [dat-discussions] socket based
 connectionmodel for IB proposal - round 3



 The CM cannot get a message from a non-priviliged requestor, because a
 non-privilited requestor cannot insert the priviliged Q_Key into the
 packet.







But a non-privileged remote consumer could make a request of an existing
CM.
That existing CM would consider the entire "private data" field to be,
well, private.
It would obviously not validate any of it.

So getting the Q_Key does not guarantee that the private data is validated.
There has to be a field outside of the private data that can only be set by
privileged codes that means "I am aware of the expectation that I have
validated the standardized portion of the private data in this optional
format."

And yes, the Q-Key is how we know that assertion is coming from privileged
remote software.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051111/a4e8967c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051111/a4e8967c/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051111/a4e8967c/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic22362.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20051111/a4e8967c/attachment-0002.gif>