linux-kernel - Re: [PATCH 2/2] ix86: atomic64 assembly improvements

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:	Wed, 18 Jan 2012 09:47:20 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jan Beulich <JBeulich@...e.com>
CC:	mingo@...e.hu, "eric.dumazet@...il.com" <eric.dumazet@...il.com>,
	tglx@...utronix.de, luca@...a-barbieri.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] ix86: atomic64 assembly improvements

On 01/18/2012 08:50 AM, Jan Beulich wrote:
>>
>> It's atomic in the same way a MOV is atomic.
>
> Then please point me to where this is documented.
>
> As I understand it, there is nothing keeping the CPU (or something
> down the bus) from executing the unlocked version as two 32-bit
> reads followed by two 32-bit writes.
>
>> The CPU could, in fact, execute the locked version at all if the
>> unlocked version didn't behave like that.
>
> Assuming you meant "could not", that's not true: As long as the
> external world has a way to know that both items are locked (think
> of the old bus lock mechanism when there were no caches yet),
> it can very well do so.
>
> I do not question that in practice all CPUs behave as described,
> but without an architectural guarantee (and with the code in
> question not being used in hot paths afaik) I see no reason why
> it should depend on undefined behavior.
>

Sorry, Jan, if you want to play the documentation lawyer game then there 
is very little that will get done.  The code is increasingly being used 
in warm/hot paths and that's actually fair, so I'd like to avoid 
crapping it up.

There are, to my knowledge, only three companies which have brought 
SMP-capable x86 processors to market: Intel, AMD, and VIA and the above 
holds for them.  A new vendor realistically can't bring a new processor 
to market which violates a constraint that the existing processor 
vendors have preserved.

It is somewhat implied in the SDM section 8.1.1 of volume 3A, but as 
with many other things it's not written out specifically... I suspect 
largely because the question hasn't been raised before.

	-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/