linux-kernel - Re: [PATCH v2 3/4] x86, mwaitt: introduce mwaix delay with a configurable timer

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]

Message-ID: <CALCETrUmKWUcW8gWZstGX0k=kuDMYTDn1vU9bn8xSH0epg0WKQ@mail.gmail.com>
Date:	Tue, 9 Jun 2015 11:55:22 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Borislav Petkov <bp@...e.de>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <john.stultz@...aro.org>,
	Aaron Lu <aaron.lu@...el.com>, Tony Li <tony.li@....com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Suravee Suthikulanit <suravee.suthikulpanit@....com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Len Brown <lenb@...nel.org>, Ken Xue <ken.xue@....com>,
	Huang Rui <ray.huang@....com>, X86 ML <x86@...nel.org>
Subject: Re: [PATCH v2 3/4] x86, mwaitt: introduce mwaix delay with a
 configurable timer

On Tue, Jun 9, 2015 at 11:43 AM, Borislav Petkov <bp@...e.de> wrote:
> On Tue, Jun 09, 2015 at 10:55:15AM -0700, Andy Lutomirski wrote:
>> When I looked at the rdtsc ordering a couple years ago, I thought
>> about what it meant for rdtsc to be properly ordered.  I decided that
>> proper rdtsc ordering meant that no one should ever be able to tell if
>> rdtsc ends up reordered.  Concretely, I think that rdtsc should be
>> ordered like an x86 load from a shared memory location.  The manuals
>> are vague but, after a decent amount of experimentation,
>> rdtsc_barrier(); rdtsc() seems to achieve that on all CPUs.  With the
>> barrier, the rdtsc won't happen before a prior load in the same
>> thread, and no CPU seems to ever execute rdtsc after a subsequent
>> memory access.
>
> That sounds weak to me. I think we will need some enlightenment from hw
> people here before we go assume stuff.

For your reading pleasure:

https://lkml.kernel.org/g/80b43d57d15f7b141799a7634274ee3bfe5a5855.1302137785.git.luto@mit.edu

>
>> > By virtue of the address dependency?
>>
>> No, it's just that CPUs seem to work this way.
>
> Err, that sounds funny. And it must be the data dependency forcing the
> RDTSC to execute in order in that case.

Apparently not -- see above.  I tried it with an explicit data
dependency, which amused Linus, but in the end everyone agreed that
rdtsc_barrier(); rdtsc() was the right way to read the time.

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