Re: [PATCH for-next V2 00/11] Add RoCE v2 support

> No, not true. You are implementing RoCEv2 support, which is an entirely > new feature. So this feature can't have had a security hole since > forever as it has never been in the kernel before now. The objections > are arising because of the ordering of events. Specifically, we added > the

RE: [PATCH for-next V2 00/11] Add RoCE v2 support

> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- > ow...@vger.kernel.org] On Behalf Of Doug Ledford > These patches add the concept of duplicate GIDs that are differentiated by > their RoCE version (also called network type). So, now, an incoming packet > could match a couple

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

On 12/16/2015 01:56 AM, Moni Shoua wrote: >> The part that bothers me about this is that this statement makes sense >> when just thinking about the spec, as you say. However, once you >> consider namespaces, security implications make this statement spec >> compliant, but still unacceptable. The

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

On Wed, Dec 16, 2015 at 08:56:01AM +0200, Moni Shoua wrote: > I can't object to that but I really would like to get an example of a > security risk. How can anyone give you an example when nobody knows exactly how mlx hardware works in this area? >From an kapi prespective, the security design

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

On Wed, Dec 16, 2015 at 09:57:02AM +, Liran Liss wrote: > Currently, namespaces are not supported for RoCE. IMHO, we should not be accepting rocev2 without at least basic namespace support too, since it is fairly trivial to do based on the work that is already done for verbs. An obvious

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

On Wed, Dec 16, 2015 at 03:39:16PM -0500, Doug Ledford wrote: > These patches add the concept of duplicate GIDs that are differentiated > by their RoCE version (also called network type). and by vlan, and smac, and ... Basically everything network unique about a namespace has to be encapsulted

RE: [PATCH for-next V2 00/11] Add RoCE v2 support

> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- > ow...@vger.kernel.org] On Behalf Of Doug Ledford > In particular, Liran piped up with this comment: > > "Also, I don't want to do any route resolution on the Rx path. A UD QP > completion just reports the details of the packet it

RE: [PATCH for-next V2 00/11] Add RoCE v2 support

> From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma- > > Since you and Jason did not reach a consensus, I have to dig in and > > see if these patches make it possible to break namespace confinement, > > either accidentally or with intentionally tricky behavior. That's > > going to take

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

On 12/15/2015 02:15 AM, Moni Shoua wrote: > On Thu, Dec 3, 2015 at 3:47 PM, Matan Barak wrote: >> Hi Doug, >> >> This series adds the support for RoCE v2. In order to support RoCE v2, >> we add gid_type attribute to every GID. When the RoCE GID management >> populates the GID

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

On Tue, Dec 15, 2015 at 04:45:21PM -0500, Doug Ledford wrote: > In particular, Liran piped up with this comment: > > "Also, I don't want to do any route resolution on the Rx path. A UD QP > completion just reports the details of the packet it received. > > Conceptually, an incoming packet may

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

> The part that bothers me about this is that this statement makes sense > when just thinking about the spec, as you say. However, once you > consider namespaces, security implications make this statement spec > compliant, but still unacceptable. The spec itself is silent on > namespaces. But,

Re: [PATCH for-next V2 00/11] Add RoCE v2 support

On Thu, Dec 3, 2015 at 3:47 PM, Matan Barak wrote: > Hi Doug, > > This series adds the support for RoCE v2. In order to support RoCE v2, > we add gid_type attribute to every GID. When the RoCE GID management > populates the GID table, it duplicates each GID with all supported