netdev - Re: [RFC PATCH v2 06/10] udp: cope with UDP GRO packet misdirection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 23 Oct 2018 18:55:31 -0600
From:   Subash Abhinov Kasiviswanathan <subashab@...eaurora.org>
To:     Paolo Abeni <pabeni@...hat.com>
Cc:     netdev@...r.kernel.org, Willem de Bruijn <willemb@...gle.com>,
        Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [RFC PATCH v2 06/10] udp: cope with UDP GRO packet misdirection

>> Is the "likely" required here?
> 
> Not required, but currently helpful IMHO, as we should hit the above
> only on unlikey and really unwonted configuration.
> 
> Note that only SKB_GSO_UDP_L4 GSO packets will not match the above
> likely condition.
> 
>> HW can coalesce all incoming streams of UDP and may not know the 
>> socket
>> state.
>> In that case, a socket not having UDP GRO option might see a penalty
>> here.
> 
> Really? Is there any HW creating SKB_GSO_UDP_L4 packets on RX? if the
> HW is doing that, without this patch, I think it's breaking existing
> applications (which may expext that the read UDP frame length
> implicitly describe the application level message length).
> 

Hi

Yes, I agree that existing HW would not work without the patch.
My question was based on how UDP GRO packets from any future HW would 
interact
with this code path and if they might be potentially have any side 
effects
due to socket option not being set.

We do not have control over the application and the socket options being 
used
on systems like Android. The packet count reduction due to UDP GRO would 
help
when there are multiple firewall rules present even if we do not take
advantage of the reduced recvmsg() calls.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project