Re: [PATCH net] selftests: net: csum: Fix checksums for packets with non-zero padding

From: Willem de Bruijn
Date: Tue Sep 10 2024 - 17:01:30 EST


Sean Anderson wrote:
> On 9/10/24 13:42, Willem de Bruijn wrote:
> > 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.
>
> Which is the subject of my second bullet.
>
> > If not adding a new test, detect in csum and fail anytime padding is
> > detected (i.e., not only non-zero)?
>
> As noted below, this is only a problem if we leak kernel memory in the
> padding. Otherwise, any kind of padding at all is completely standard
> conformant.

Ack. I actually was not clear on that.