linux-kernel - Re: [PATCH v7 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] [thread-next>] [day] [month] [year] [list]

Date: Mon, 12 Feb 2024 17:53:01 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Charlie Jenkins <charlie@...osinc.com>
Cc: David Laight <David.Laight@...lab.com>,
 Palmer Dabbelt <palmer@...belt.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Al Viro
 <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v7 2/2] lib: checksum: Use aligned accesses for
 ip_fast_csum and csum_ipv6_magic tests

On 2/12/24 16:32, Charlie Jenkins wrote:
> On Mon, Feb 12, 2024 at 04:14:49PM -0800, Guenter Roeck wrote:
>> On 2/12/24 12:33, Charlie Jenkins wrote:
>>> The test cases for ip_fast_csum and csum_ipv6_magic were failing on a
>>> variety of architectures that are big endian or do not support
>>> misalgined accesses. Both of these test cases are changed to support big
>>> and little endian architectures.
>>>
>>> The test for ip_fast_csum is changed to align the data along (14 +
>>> NET_IP_ALIGN) bytes which is the alignment of an IP header. The test for
>>> csum_ipv6_magic aligns the data using a struct. An extra padding field
>>> is added to the struct to ensure that the size of the struct is the same
>>> on all architectures (44 bytes).
>>>
>>> Fixes: 6f4c45cbcb00 ("kunit: Add tests for csum_ipv6_magic and ip_fast_csum")
>>> Signed-off-by: Charlie Jenkins <charlie@...osinc.com>
>>
>> This thing really wants to annoy me. Now I get:
>>
>>       # test_csum_ipv6_magic: ASSERTION FAILED at lib/checksum_kunit.c:494
>>       Expected ( u64)csum_result == ( u64)expected, but
>>           ( u64)csum_result == 46543 (0xb5cf)
>>           ( u64)expected == 46544 (0xb5d0)
>>       not ok 5 test_csum_ipv6_magic
>>
>> with the parisc64 tests. All other architectures / platforms work fine
>> after applying the various pending fixes. It looks like a carry gets
>> lost somewhere, but I have not been able to figure out where exactly
>> that happens. This only happens with the 64-bit hppa assembler code.
>>
>> Guenter
>>
> 
> How do you test parisc64? It's not in buildroot which I have been using
> to test the other architectures.
> 

Its qemu support is quite new. 32 bit userspace should work.

The errors are quite interesting.

[   16.989782] ###### i=1 len=0xd22c123d proto=0xb1 csum=0x88e31421 expected=0xb5d0 -> csum 0xb5cf
[   16.990249] ###### i=3 len=0xb15e4531 proto=0xba csum=0xa2853676 expected=0xe6c1 -> csum 0xe6c0
[   16.992119] ###### i=5 len=0xbad8adbb proto=0xce csum=0x9e498ff7 expected=0xa836 -> csum 0xa835
[   16.992498] ###### i=7 len=0xceeaefca proto=0x5c csum=0x2c29f715 expected=0xe87c -> csum 0xe87b
[   16.992769] ###### i=9 len=0x5c1d4d09 proto=0x8c csum=0x1fe21431 expected=0x5875 -> csum 0x5874
[   16.993026] ###### i=11 len=0x8c075723 proto=0x93 csum=0x1f6f03e1 expected=0xd361 -> csum 0xd360
[   16.993282] ###### i=13 len=0x93195303 proto=0x8e csum=0x45499a3b expected=0xdd50 -> csum 0xdd4f
[   16.993538] ###### i=15 len=0x8e0c125d proto=0x9a csum=0x8ab89b8c expected=0xad6b -> csum 0xad6a
[   16.993790] ###### i=17 len=0x9a03e5a2 proto=0x7e csum=0x43d23b4e expected=0x90b5 -> csum 0x90b4

Every odd index fails, and the returned value is one less than the expected value. It is almost
as if something goes wrong with 64-bit loads from 32-bit aligned addresses. I'll do some more
debugging.

Guenter