linux-kernel - Re: Intel Memory Ordering White Paper

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:	Sat, 08 Sep 2007 05:08:51 -0700
From:	Petr Vandrovec <vandrove@...cvut.cz>
To:	dean gaudet <dean@...tic.org>
CC:	Nick Piggin <nickpiggin@...oo.com.au>,
	Linus Torvalds <torvalds@...ux-foundation.org>, ak@...e.de,
	Jesse Barnes <jesse.barnes@...el.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Intel Memory Ordering White Paper

dean gaudet wrote:
> On Sun, 9 Sep 2007, Nick Piggin wrote:
> 
>> I've also heard that string operations do not follow the normal ordering, but
>> that's just with respect to individual loads/stores in the one operation, I
>> hope? And they will still follow ordering rules WRT surrounding loads and
>> stores?
> 
> see section 7.2.3 of intel volume 3A...
> 
> "Code dependent upon sequential store ordering should not use the string 
> operations for the entire data structure to be stored. Data and semaphores 
> should be separated. Order dependent code should use a discrete semaphore 
> uniquely stored to after any string operations to allow correctly ordered 
> data to be seen by all processors."
> 
> i think we need sfence after things like copy_page, clear_page, and 
> possibly copy_user... at least on intel processors with fast strings 
> option enabled.

I do not think.  I believe that authors are trying to say that

struct { uint8 lock; uint8 data; } x;

lea (x.data),%edi
mov $2,%ecx
std
rep movsb

to set both data and lock does not guarantee that x.lock will be set 
after x.data and that you should do

lea (x.data),%edi
std
movsb
movsb  # or mov (%esi),%al; mov %al,(%edi), but movsb looks discrete 
enough to me

instead (and yes, I know that my example is silly).
							Petr

-
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/