[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <66e084ff8f8aa_c435329483@willemb.c.googlers.com.notmuch>
Date: Tue, 10 Sep 2024 13:42:23 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Sean Anderson <sean.anderson@...ux.dev>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Jakub Kicinski <kuba@...nel.org>
Cc: Eric Dumazet <edumazet@...gle.com>,
"David S . Miller" <davem@...emloft.net>,
Paolo Abeni <pabeni@...hat.com>,
netdev@...r.kernel.org,
Willem de Bruijn <willemb@...gle.com>,
linux-kernel@...r.kernel.org,
Shuah Khan <shuah@...nel.org>,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net] selftests: net: csum: Fix checksums for packets with
non-zero padding
Sean Anderson wrote:
> On 9/9/24 21:01, Willem de Bruijn wrote:
> > Jakub Kicinski wrote:
> >> On Mon, 09 Sep 2024 13:26:42 -0400 Willem de Bruijn wrote:
> >> > > This seems to be a bug in the driver.
> >> > >
> >> > > A call to skb_put_padto(skb, ETH_ZLEN) should be added.
> >> >
> >> > In which case this test detecting it may be nice to have, for lack of
> >> > a more targeted test.
> >>
> >> IIUC we're basically saying that we don't need to trim because pad
> >> should be 0? In that case maybe let's keep the patch but add a check
> >> on top which scans the pad for non-zero bytes, and print an informative
> >> warning?
> >
> > Data arriving with padding probably deserves a separate test.
> >
> > We can use this csum test as stand-in, I suppose.
> >
> > Is it safe to assume that all padding is wrong on ingress, not just
> > non-zero padding. The ip stack itself treats it as benign and trims
> > the trailing bytes silently.
> >
> > I do know of legitimate cases of trailer data lifting along.
>
> Ideally we would test that
>
> - Ingress padding is ignored.
I think the goal of a hardware padding test is to detect when padding
leaks onto the wire.
If not adding a new test, detect in csum and fail anytime padding is
detected (i.e., not only non-zero)?
> - Egress padding does not leak past the buffer. The easiest way to
> handle this would be to check that it is constant (e.g. all the
> padding uses the same value), but this could have false-positives for
> e.g. timestamps.
>
> --Sean
Powered by blists - more mailing lists