linux-kernel - RE: [PATCH v2] Fixed: Misaligned memory access. Fixed pointer comparison.

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: <4fa1c4bbf27242cf9835dde0abdc89d5@AcuMS.aculab.com>
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)