netdev - RE: [PATCH net-next] af_unix: fix a fatal race with bit fields

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:	Fri, 3 May 2013 15:29:50 +0100
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Benjamin Herrenschmidt" <benh@...nel.crashing.org>,
	"Eric Dumazet" <eric.dumazet@...il.com>
Cc:	"David Miller" <davem@...emloft.net>,
	"netdev" <netdev@...r.kernel.org>,
	"Paul Mackerras" <paulus@...ba.org>,
	"Ambrose Feinstein" <ambrose@...gle.com>,
	<linuxppc-dev@...ts.ozlabs.org>
Subject: RE: [PATCH net-next] af_unix: fix a fatal race with bit fields

> > Could ppc64 experts confirm using byte is safe, or should we really add
> > a 32bit hole after the spinlock ? If so, I wonder how many other places
> > need a change...
...
> Also I'd be surprised if ppc64 is the only one with that problem... what
> about sparc64 and arm64 ?

Even x86 could be affected.
The width of the memory cycles used by the 'bit set and bit clear'
instructions isn't documented. They are certainly allowed to do
RMW on adjacent bytes.
I don't remember whether they are constrained to only do
32bit accesses, but nothing used to say that they wouldn't
do 32bit misaligned ones! (although I suspect they never have).

	David