linux-kernel - Re: [RFT] Please test rdtsc on various x86-64 hardware (app included)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Apr 2011 22:15:33 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	x86 <x86@...nel.org>
Subject: Re: [RFT] Please test rdtsc on various x86-64 hardware (app included)

On Mon, Apr 18, 2011 at 6:10 PM, Andi Kleen <andi@...stfloor.org> wrote:
> I tested it on a dual Westmere-EP and a Quad Westmere-EX.
> Seems to pass everywhere.

I see a failure below...

>
> However I kept the default MAX_THREADS 4. Shouldn't that be
> increased for the large systems?

MAX_THREADS is just the size of a data structure -- the tests use
either two or three threads.   However...

>
> I suspect the tests as written didn't really use the large
> systems.
>
> Dual:
>
> CPU vendor   : GenuineIntel
> CPU model    : Intel(R) Xeon(R) CPU           E5640  ...
> CPU stepping : ..
> TSC flags    : tsc rdtscp constant_tsc nonstop_tsc
> Using lfence_rdtsc because you have an Intel CPU
> Will test the "lfence;rdtsc" clock.
> Now test failed  : worst error 48 with 48647928 samples

...that's not so good.  The "now test" is quite simple and really
shouldn't fail unless lfence doesn't work or the TSCs are out of sync.

Can you run now_test_all_pairs.sh from the same repository?  If you
have two packages that are a little out of sync, that should show it.
(It'll take a minute or so.)

I was thinking about how BIOS or the OS would go about syncing the
TSCs on different CPUs and it's not so obvious.  The problem is that
AFAICT you can't add an offset to a TSC; you have to reprogram the
whole thing.  That means that the time it takes for the wrmsr to
finish is a somewhat unknown error.  If you're off by, say, 70 cycles,
the now test will catch it if it ends up on the right CPUs.

FWIW, I can't reproduce this on a dual-package Xeon E5520.

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