<html><body>
<p>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. <br>
<br>
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:
<ul>- Transport to validate an incoming CM message was generated by a priviliged consumer; and<br>
- CM to know the Service ID and first N-bytes of the private data field were generated by a priviliged consumer.</ul>
<br>
Thanks,<br>
<br>
<br>
Renato J Recio<br>
Chief Architect, eServer I/O<br>
IBM Distinguished Engineer<br>
Member IBM Academy of Technology<br>
Tel 512-838-3685, T/L 678-3685<br>
<br>
<img src="cid:10__=09BBFA25DFFC07DE8f9e8a93df938@us.ibm.com" width="16" height="16" alt="Inactive hide details for "Caitlin Bestler" <caitlinb@broadcom.com>">"Caitlin Bestler" <caitlinb@broadcom.com><br>
<br>
<br>
<table V5DOTBL=true width="100%" border="0" cellspacing="0" cellpadding="0">
<tr valign="top"><td width="1%"><img src="cid:20__=09BBFA25DFFC07DE8f9e8a93df938@us.ibm.com" border="0" height="1" width="72" alt=""><br>
</td><td style="background-image:url(cid:30__=09BBFA25DFFC07DE8f9e8a93df938@us.ibm.com); background-repeat: no-repeat; " width="1%"><img src="cid:20__=09BBFA25DFFC07DE8f9e8a93df938@us.ibm.com" border="0" height="1" width="225" alt=""><br>
<ul>
<ul>
<ul>
<ul><b><font size="2">"Caitlin Bestler" <caitlinb@broadcom.com></font></b>
<p><font size="2">11/11/2005 01:12 PM</font></ul>
</ul>
</ul>
</ul>
</td><td width="100%"><img src="cid:20__=09BBFA25DFFC07DE8f9e8a93df938@us.ibm.com" border="0" height="1" width="1" alt=""><br>
<font size="1" face="Arial"> </font><br>
<font size="2"> To: </font><font size="2">Renato Recio/Austin/IBM@IBMUS</font><br>
<font size="2"> cc: </font><font size="2">"Kanevsky, Arkady" <Arkady.Kanevsky@netapp.com>, dat-discussions@yahoogroups.com, "Sean Hefty" <mshefty@ichips.intel.com>, openib-general@openib.org, swg@infinibandta.org</font><br>
<font size="2"> Subject: </font><font size="2">RE: [swg] RE: [openib-general] RE: [dat-discussions] socket based connectionmodel for IB proposal - round 3</font></td></tr>
</table>
<br>
<br>
<font size="4" face="Times New Roman"> </font><br>
<br>
<hr width="100%" size="2" align="left"><b><font face="Tahoma">From:</font></b><font face="Tahoma"> Renato Recio [<a href="mailto:recio@us.ibm.com">mailto:recio@us.ibm.com</a>] </font><b><font face="Tahoma"><br>
Sent:</font></b><font face="Tahoma"> Friday, November 11, 2005 11:01 AM</font><b><font face="Tahoma"><br>
To:</font></b><font face="Tahoma"> Caitlin Bestler</font><b><font face="Tahoma"><br>
Cc:</font></b><font face="Tahoma"> Kanevsky, Arkady; dat-discussions@yahoogroups.com; Sean Hefty; openib-general@openib.org; swg@infinibandta.org</font><b><font face="Tahoma"><br>
Subject:</font></b><font face="Tahoma"> Re: [swg] RE: [openib-general] RE: [dat-discussions] socket based connectionmodel for IB proposal - round 3</font><font size="4" face="Times New Roman"><br>
</font>
<p><font size="4" face="Times New Roman">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.<br>
<br>
</font>
<p><font size="4" face="Times New Roman"> </font>
<p><font color="#0000FF" face="Arial">But a non-privileged remote consumer could make a request of an existing CM.</font><br>
<font color="#0000FF" face="Arial">That existing CM would consider the entire "private data" field to be, well, private.</font><br>
<font color="#0000FF" face="Arial">It would obviously not validate any of it.</font><br>
<font size="4" face="Times New Roman"> </font><br>
<font color="#0000FF" face="Arial">So getting the Q_Key does not guarantee that the private data is validated.</font><br>
<font color="#0000FF" face="Arial">There has to be a field outside of the private data that can only be set by</font><br>
<font color="#0000FF" face="Arial">privileged codes that means "I am aware of the expectation that I have</font><br>
<font color="#0000FF" face="Arial">validated the standardized portion of the private data in this optional format."</font><br>
<font size="4" face="Times New Roman"> </font><br>
<font color="#0000FF" face="Arial">And yes, the Q-Key is how we know that assertion is coming from privileged</font><br>
<font color="#0000FF" face="Arial">remote software.</font><br>
<font size="4" face="Times New Roman"> </font>
</body></html>