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

Inactive hide details for "Caitlin Bestler" <[EMAIL PROTECTED]>"Caitlin Bestler" <[EMAIL PROTECTED]>




          "Caitlin Bestler" <[EMAIL PROTECTED]>

          11/11/2005 01:12 PM



To: Renato Recio/Austin/[EMAIL PROTECTED]
cc: "Kanevsky, Arkady" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], "Sean Hefty" <[EMAIL PROTECTED]>, [email protected], [EMAIL PROTECTED]
Subject: RE: [swg] RE: [openib-general] RE: [dat-discussions] socket based connectionmodel for IB proposal - round 3





From: Renato Recio [mailto:[EMAIL PROTECTED]]
Sent:
Friday, November 11, 2005 11:01 AM
To:
Caitlin Bestler
Cc:
Kanevsky, Arkady; [EMAIL PROTECTED]; Sean Hefty; [email protected]; [EMAIL PROTECTED]
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.

GIF image

_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to