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 is very simple. Every single UD packet the kapi side has to process must be unambiguously associated with a gid_index or dropped. Period full stop. I would think that is an obvious conclusion based on the design of the gid cache. This is why we need a clear API to get this critical information. It should not be open coded in init_ah_from_wc, it should not be done some other way in the CMA code. This is a simple matter of sane kapi design, nothing more. I have no idea why this is so objectionable. > scattered to the receive bufs anyway. So, if there is a security hole > it exists from day one of the IB stack and this is not the time we > should insist on fixing it. IB isn't interacting with the net stack in the same way rocev2 is, so this is not a pre-existing problem. Jason -- 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
