netdev - Re: Regarding UDP-Lite deprecation and removal

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]

Message-ID: <e5e430e6c6fd079847cb7547b96c2cab70906abb.camel@redhat.com>
Date: Thu, 21 Mar 2024 11:31:40 +0100
From: Paolo Abeni <pabeni@...hat.com>
To: Lynne <dev@...ne.ee>, Florian Westphal <fw@...len.de>
Cc: Netdev <netdev@...r.kernel.org>, Kuniyu <kuniyu@...zon.com>, 
	Willemdebruijn Kernel <willemdebruijn.kernel@...il.com>
Subject: Re: Regarding UDP-Lite deprecation and removal

On Mon, 2024-03-18 at 18:58 +0100, Lynne wrote:
> Mar 18, 2024, 14:18 by fw@...len.de:
> 
> > Lynne <dev@...ne.ee> wrote:
> > 
> > > UDP-Lite was scheduled to be removed in 2025 in commit
> > > be28c14ac8bbe1ff due to a lack of real-world users, and
> > > a long-outstanding security bug being left undiscovered.
> > > 
> > > I would like to open a discussion to perhaps either avoid this,
> > > or delay it, conditionally.
> > > 
> > 
> > Is there any evidence UDP-Lite works in practice?
> > 
> > I am not aware of any HW that will peek into L3/L4 payload to figure out
> > that the 'udplite' payload should be passed up even though it has bad csum.
> > 
> > So, AFAIU L2 FCS/CRC essentially renders entire 'partial csum' premise moot,
> > stack will never receive udplite frames that are damaged.
> > 
> > Did things change?
> > 
> 
> I do somehow get CRC errors past the Ethernet layer on consumer rtl cards,
> by default, with no ethtool changes, so maybe things did change.
> 
> I haven't sacrificed a good cable yet to get a definitive proof.
> The cargo-culted way to be sure is to enable rx-all.

I did not consider the mac-level csum - thanks Florian for bringing
that up.

Yes, you can disable FCS checking on the local host - for some NIC at
least - and AFAIK that is the only way to receive csum corrupted
packets. Delivery packets with bad FCS without F_RXALL set would be a
bug.

And you need to set F_RXALL on all the intermediate hops.

All in all, the use-case looks very thin at best.

In any case, to  step-in to maintain a specific protocol you should
start first contributing. I *guess* a reasonable good start would be
implementing UDP-lite selftests.

Cheers,

Paolo