linux-kernel - Re: [PATCH v5 2/2] lib: checksum: Use aligned accesses for ip_fast_csum and csum_ipv6

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] [day] [month] [year] [list]

Message-ID: <ZcU0/ZsCAwxW/oTo@ghost>
Date: Thu, 8 Feb 2024 12:09:33 -0800
From: Charlie Jenkins <charlie@...osinc.com>
To: David Laight <David.Laight@...lab.com>
Cc: Guenter Roeck <linux@...ck-us.net>, Palmer Dabbelt <palmer@...belt.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 2/2] lib: checksum: Use aligned accesses for
 ip_fast_csum and csum_ipv6_magic tests

On Thu, Feb 08, 2024 at 09:54:39AM +0000, David Laight wrote:
> From: Charlie Jenkins
> > Sent: 08 February 2024 00:23
> > 
> > On Sun, Feb 04, 2024 at 09:41:56AM -0800, Guenter Roeck wrote:
> > > Hi,
> > >
> > > On Tue, Jan 30, 2024 at 11:10:04AM -0800, Charlie Jenkins wrote:
> > > > The test cases for ip_fast_csum and csum_ipv6_magic were using arbitrary
> > > > alignment of data to iterate through random inputs. ip_fast_csum should
> > > > have the data aligned along (14 + NET_IP_ALIGN) bytes and
> > > > csum_ipv6_magic should have data aligned along 32-bit boundaries.
> > > >
> > > >
> ...
> > >
> > > So this works on little endian systems. Unfortunately, I still get
> > >
> ...
> > >
> > > when running the test on big endian systems such as hppa/parisc or sparc.
> > 
> > Hmm okay it was easy to get this to work on big endian for
> > test_ip_fast_csum but test_csum_ipv6_magic was trickier. I will send out
> > a new version with the changes.
> 
> Instead of trying to save the expected results why not just
> calculate them with a 'really dumb' implementation.
> (eg: Add 16bit items and then fold.)
> 
> For the generic tests, IIRC:
> Your test vectors looked random.
> They should probably contain some very specific tests cases.
> eg:
> - Zero length and all zeros - checksum should be zero (not 0xffff).
> - Buffers where the final 'fold' needs the carry added in.

The existing csum test cases have three tests, one for random and then
one for each of the two specific test cases you mentioned. I figured
having the random test case would most likely catch an error if one
existed.

The additional tests can be added in a future patch but I would like to
make sure the existing test cases work first.

- Charlie

> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>