linux-kernel - Re: [PATCH v8 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]

Message-ID: <6aaa4b89-a967-4b19-b4bf-a1ad5c8e9faa@roeck-us.net>
Date: Thu, 15 Feb 2024 22:09:42 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Helge Deller <deller@....de>, Charlie Jenkins <charlie@...osinc.com>
Cc: David Laight <David.Laight@...lab.com>,
 Palmer Dabbelt <palmer@...belt.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Parisc List <linux-parisc@...r.kernel.org>, Al Viro
 <viro@...iv.linux.org.uk>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 2/2] lib: checksum: Use aligned accesses for
 ip_fast_csum and csum_ipv6_magic tests

On 2/15/24 21:54, Helge Deller wrote:
[ ... ]
> 
> Can you please give a pointer to this test code?
> I'm happy to try it on real hardware.
> 
You should also see the problem if you use v7 of Charlie's checksum
unit test fixes.

I submitted the qemu fix (or at least what I think the fix should be)
a couple of minutes ago.

https://patchwork.kernel.org/project/qemu-devel/patch/20240216053415.2163286-1-linux@roeck-us.net/

>> It is quite easy to show that carry is always set after executing ldd
>> on an unaligned address. That is also why I know for sure that the
>> problem is not seen with ldw on unaligned addresses.
> Interesting.

Ultimately it wasn't surprising, with the unusual carry bit
implementation on hppa. The upper 8 carry bits were not masked
correctly when returning from a trap or interrupt.

> In general I think it's quite important to differentiate between
> running on qemu or running on physical hardware.

I know, that makes testing always tricky (not just with this
architecture) because it is often not obvious if the problem
is a problem in the tested code or a problem in the emulation.

> Qemu just recently got 64-bit support, and it's not yet behaving
> like real hardware. One thing I noticed is, that read hardware
> does not seem to jump into the exception handler twice, while
> qemu does. So, if you run into an exception (e.g. unaligned ldd)
> then if a second exception happens in the fault handler (e.g. second
> unaligned ldd to resolve wrongly-coded code lookup), you will
> get different behaviour between hardware and emulation.

Hmm, interesting. Makes me wonder how the real hardware handles such
double traps.

> This is also the reason why qemu still fails to emulate newer
> 64-bit Linux kernels which uses kernel modules.
> 
I don't use modules in my testing, so I'll leave that alone for
anther day.

Cheers,
Guenter