> 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, you guys wanted, and you got, namespace support. > Since that's beyond spec, and carries security requirements, I think > it's fair to say that from now on, the Linux kernel RDMA stack can no > longer *just* be spec compliant. There are additional concerns that > must always be addressed with new changes, and those are the namespace > constraint preservation concerns.
I can't object to that but I really would like to get an example of a security risk. So far, besides hearing that the way we choose to handle completions is wrong, I didn't get a convincing example of how where it doesn't work. Moreover, regarding security, all we wanted is for HW to report the L3 protocol (IB, IPv4, or IPv6) in the packet. This is data that with some extra CPU cycles can be obtained from the 40 bytes that are 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. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
