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

Message-ID: <AE90C24D6B3A694183C094C60CF0A2F6026B7227@saturn3.aculab.com>
Date:	Fri, 3 May 2013 16:44:22 +0100
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Eric Dumazet" <eric.dumazet@...il.com>
Cc:	"Benjamin Herrenschmidt" <benh@...nel.crashing.org>,
	"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

> > > 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).
> 
> x86 is not affected (or else we would have found the bug much earlier)
> 
> Setting 1-bit field to one/zero uses OR/AND instructions.
> 
> orb  $4,724(%reg)
> 
> doesn't load/store 64bits but 8bits.

I was thinking of code that might be using BT, BTC, BTR or BTS.
These are probably used with the 'lock' prefix - which would
(I think) make them safe.

The documented constraint is more specific than it used to be
the Intel version reads:

    When accessing a bit in memory, the processor may access 4 bytes
    starting from the memory address for a 32-bit operand size, using
    by the following relationship:
        Effective Address + (4 ∗ (BitOffset DIV 32))
    Or, it may access 2 bytes starting from the memory address for a
    16-bit operand, using this relationship:
        Effective Address + (2 ∗ (BitOffset DIV 16))
    It may do so even when only a single byte needs to be accessed to
    reach the given bit.
    When using this bit addressing mechanism, software should avoid
    referencing areas of memory close to address space holes.
    In particular, it should avoid references to memory-mapped I/O registers.
    Instead, software should use the MOV instructions to load from or store
    to these addresses, and use the register form of these instructions to
    manipulate the data.
    In 64-bit mode, the instruction’s default operation size is 32 bits.
    Using a REX prefix in the form of REX.R permits access to additional
    registers (R8-R15). Using a REX prefix in the form of REX.W promotes
    operation to 64 bit operands.

	David