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, 24 Jan 2022 09:21:21 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     "'michael@...haelkloos.com'" <michael@...haelkloos.com>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
        "palmer@...belt.com" <palmer@...belt.com>,
        "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>
CC:     "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2] Fixed: Misaligned memory access.  Fixed pointer
 comparison.

From: michael@...haelkloos.com
> Sent: 23 January 2022 03:45
> 
> Rewrote the riscv memmove() assembly implementation.  The
> previous implementation did not check memory alignment and it
> compared 2 pointers with a signed comparison.  The misaligned
> memory access would cause the kernel to crash on systems that
> did not emulate it in firmware and did not support it in hardware.
> Firmware emulation is slow and may not exist.  Additionally,
> hardware support may not exist and would likely still run slower
> than aligned accesses even if it did.

That may not be true.
On x86 the cost of misaligned accesses only just measurable.
It isn't even one clock per cache line for reads (eg ipcsum).

> The RISC-V spec does not
> guarantee that support for misaligned memory accesses will exist.
> It should not be depended on.
> 
> This patch now checks for the maximum granularity of co-alignment
> between the pointers and copies them with that, using single-byte
> copy for any unaligned data at their terminations.  It also now uses
> unsigned comparison for the pointers.

If the performance of misaligned copies ever matters it is probably
better to use:
	*dst++ = src[0] >> n | src[1] << (64 - n);
for the body of the misaligned loop.
You can always read the aligned src[] even if outside the buffer.
So the only difficult part is writing the odd bytes
and getting 'n' and the direction of the shifts right!

	David

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ