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. >> - 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 > >
