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

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: <1cc769ba-c732-4155-8d96-5b40140a0d49@linux.dev>
Date: Tue, 10 Sep 2024 13:52:14 -0400
From: Sean Anderson <sean.anderson@...ux.dev>
To: 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

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