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: Sun, 11 Feb 2024 11:12:13 -0500
From: Rich Felker <dalias@...c.org>
To: "D. Jeff Dionne" <djeffdionne@...il.com>
Cc: Guenter Roeck <linux@...ck-us.net>,
	John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
	Yoshinori Sato <ysato@...rs.sourceforge.jp>,
	linux-sh@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Problems with csum_partial with misaligned buffers on sh4
 platform

On Sun, Feb 11, 2024 at 12:41:16PM +0900, D. Jeff Dionne wrote:
> I remember there being problems with alignment on SH targets in the
> network stack. IIRC, wireguard triggered it in actual use, seems to
> me it had to do with skb alignment.
> 
> Rich Felker may remember more, but I don’t think we implemented a
> (complete) solution.

What I recall was that some of the tunneling encapsulation code
ultimately did its zerocopy by arranging for either the inner or outer
headers to be misaligned (due to the historical badness of ethernet),
and thereby blowing up on archs without misaligned access support
(ours read/wrote bogus data, probably ignoring the low address bits or
something, on misaligned addresses). We never solved it; the code that
later worked was doing the encapsulatio in userspace without the
kernel's misaligned zerocopy stuff.

The right solution would be to make the affected accesses happen
through custom int16/int32 types with attribute packed applied to
them, so that on archs with misaligned access, the code would not
change at all, but on archs without it, the codegen would do
everything byte-by-byte and reassemble. But this would probably be an
invasive change that would make the maintainers of the network stack
unhappy...

Rich

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ