On Thu, Apr 14, 2016 at 01:11:15PM +0000, Daniel Jurgens wrote: > On 4/13/2016 11:23 PM, Hefty, Sean wrote: > >>>> Former (multicast modifications of fabric) also requires restricting > >>>> arbitrary UD QPs as well as QP1 as SA access is QPn (n > 0) <-> QP1. > >>> > >>> The SA could have an option to ignore all requests that do not originate > >> QP1, > >>> then protect access to QP1 on the client nodes. > >> > >> I'm not really sure what we are protecting against here. Is it simply DoS > >> against the SA? > > > > This would protect against a non-privileged QP trying to change multicast or event subscription, for example. Though it could help with DoS, by avoiding the processing associated with requests. Jason's original question was why would you want to leave qp1 open, and I think the answer to that depends on what restrictions could be enforced for qpX: X > 1. Restricting both seem desirable, IMO. > > > > There are no qpX to qpX restrictions. As long as the users that created > both QPs have permission to use the PKey in the PKey index they > specified then they are free to communicate in any way. For GSI (from 'random' QPs) this seams reasonable. In InfiniBand, the pkey is ignored in SMPs (those packets on QP0/VL15). So it does not really make sense to me to control SMPs via pkey. (OPA does check pkeys in SMPs.) Therefore, I agree with Jason that need to control access to QP0. Furthermore, I think you can/should do that when the agent is registered. This will be more performant for SMs as well. For SA/GSI access using umad I think the best control is to limit access to the umad char device itself? ibacm has been changed to be an SA cache (with plugins available for both IB and OPA) and therefore it can run with sufficient privileges to access the umad char device. Then regular user applications don't need umad access at all. For SA/GSI interactions from 'random' UD QPs, those can be controlled via the Pkey mechanism you mention above. If you do add a check on every packet in the mad stack I would like time to evaluate how that will affect the mad interface for performance. Ira -- 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
