[Intel-wired-lan] [net-next PATCH v3 00/17] Future-proof tunnel offload handlers

Tom Herbert tom at herbertland.com
Mon Jun 20 21:45:33 UTC 2016


On Mon, Jun 20, 2016 at 2:36 PM, Hannes Frederic Sowa
<hannes at 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
>
>


More information about the Intel-wired-lan mailing list