On Mon, Jun 20, 2016 at 2:36 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > On 20.06.2016 12:27, Tom Herbert wrote: >>> Do we? >>> >>> We look up the socket in a proper way, inclusive the namespace belonging >>> to the device we received the packet on. That said, I don't see a >>> problem with that right now. But maybe I miss something? >>> >> When we so the socket lookup in udp_rcv this is done after IP layer >> and packet has been determined to be loacally addressed. The packet is >> for the host, and if a UDP socket is matched, even if just based on >> destination port, the socket is matched and received functions are >> called. There is no ambiguity. >> >> When the lookup is performed in GRO this is before we processed IP and >> determined that the packet is local. So a packet with any address >> (local or not) will match a listener socket with the same UDP port. >> The GRO can be performed an packet is subsequently forwarded maybe >> having been modified. If this packet turns out to not be the protocol >> we thought it was (e.g. VXLAN) then we have now potentially silently >> corrupted someone else's packets. Grant it, there's probably a lot of >> things that are required to make corruption happen, but it does allow >> the possibly of systematic data corruption and we haven't discounted >> this to become a security vulnerability. > > Agreed. > > Maybe we must switch to always use connected sockets for unicast+UDP+GRO? > No, I don't think we need to go that far. We should be able to enable GRO on pretty much any sort of UDP socket--the other reason to move GRO into udp_rcv is this will be a more suitable environment for user programmable GRO which seems to be on the horizon now.
Tom > Bye, > Hannes > >