linux-kernel - RE: [PATCH] tracing/user_events: align uaddr on unsigned long alignment

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: <94183afa1fca44d18459da3d12a155d3@AcuMS.aculab.com>
Date:   Sun, 17 Sep 2023 21:09:13 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Clément Léger' <cleger@...osinc.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-trace-kernel@...r.kernel.org" 
        <linux-trace-kernel@...r.kernel.org>
CC:     Beau Belgrave <beaub@...ux.microsoft.com>
Subject: RE: [PATCH] tracing/user_events: align uaddr on unsigned long
 alignment

From: Clément Léger
> Sent: 14 September 2023 14:11
> 
> enabler->uaddr can be aligned on 32 or 64 bits. If aligned on 32 bits,
> this will result in a misaligned access on 64 bits architectures since
> set_bit()/clear_bit() are expecting an unsigned long (aligned) pointer.
> On architecture that do not support misaligned access, this will crash
> the kernel. Align uaddr on unsigned long size to avoid such behavior.
> This bug was found while running kselftests on RISC-V.

You don't want to do it on x86-64 either.
A locked accesses that crosses a cache line boundary is horrid.
So horrid that recent cpu's can be made to fault.

I'd also doubt that other cpu that can do misaligned transfers
can even do locked ones.

For x86 (and LE) the long[] bitmap can be treated as char[]
avoiding all the problems.

Perhaps there ought to be bit a bit-array based on char[]
(not long[]) that would be endianness independent and
use byte-sized atomics.
(IIRC that is still an issue on sparc32...)

	David

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