linux-kernel - Re: 16-bit store instructions &c?

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] [day] [month] [year] [list]

Message-ID: <0974da0a-8788-470d-bb9c-8fc90d7e6f08@paulmck-laptop>
Date: Tue, 3 Sep 2024 15:34:00 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: linux-kernel@...r.kernel.org, Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: 16-bit store instructions &c?

On Thu, Aug 29, 2024 at 09:56:52PM +0200, Arnd Bergmann wrote:
> On Thu, Aug 29, 2024, at 15:37, Paul E. McKenney wrote:
> > My plan is to submit a pull request for the remaining three 8-bit
> > cmpxchg() emulation commits into the upcoming merge window.  In the
> > meantime, I will create similar patches for 16-bit cmpxchg() and perhaps
> > also both 8-bit and 16-bit xchg().  I will obviously CC both you and
> > Russell on the full set.  And if there are hardware-incompatibility
> > complaints, we can deal with them, whether by dropping the offending
> > pieces of my patches or by whatever other adjustments make sense.
> >
> > Does that seem like a reasonable approach, or is there a better way?
> 
> There is one thing I'd really like to see happen here, and that is
> changing the architectures so they only define the fixed-length
> __arch_xchg{8,16,32,64} and __arch_cmpxchg{8,16,32,64} helpers,
> ideally as inline functions to have type checking on the pointer.
> 
> If we make the xchg()/cmpxchg() functiuons handle all sizes
> across architectures, that just ends up cementing the type
> agnostic macros, so I feel it would be better to have
> fixed-size helpers as the generic API so we can phase out the
> use of the existing macros on smaller-than-u32 arguments.
> 
> The macro is still needed to allow dealing with both integer
> and pointer objects, as well as a mix of 'int' and 'long'
> arguments on 64-bit, but for normal fixed-size objects I
> think we can best use the same method as the current
> xchg64()/cmpxchg64().

So the idea is to have architecture-independent xchg()/cmpxchg() that
invoke the __arch_xchg{8,16,32,64} and __arch_cmpxchg{8,16,32,64} helpers?
Seems plausible to me.

How can I best help?  My guess is that I should prototype an emulated
xchg() function, given my limited familiarity with the architectures.

						Thanx, Paul