On Fri, Dec 05, 2014 at 12:24:27PM -0800, Colin Percival wrote: > On 12/05/14 07:59, [email protected] wrote: > >> Which version of the scrypt code are you using? If you're using the SSE2 > >> version, are you sure that you're running on an SSE2-enabled CPU? > > > > Do you mean to say that if you run the crypto_scrypt-sse.c function on a > > non-SSE CPU, you will get a different result than on a SSE CPU? > > My understanding is that some non-SSE CPUs treat SSE instructions as NOPs.
I am not aware of any such CPUs. I think the problem is different. The behavior I first saw with scrypt's SSE2 code ~2 years ago was that on CPUs that support SSE, but do not support SSE2, the few SSE2 instructions that scrypt uses get misinterpreted as their MMX counterparts (thus 64-bit instead of 128-bit), resulting in incorrect computation (no crash). In particular, I think this applies to all Pentium 3 and P3 Celeron CPUs. It might also apply to Athlon and other CPUs of the era. IIRC, the problem is not seen on pre-SSE CPUs (e.g., it is not seen on Pentium 2), where the program crashes on the plain SSE instructions. This is just a peculiar detail of how the x86 instruction set evolved. Unrelated to the CPU issue above: Another suspect is C strict aliasing rules violations, which I think are present in scrypt's current -nosse and -sse code. I was able to trigger misbehavior in -nosse with either unusual gcc options (aggressive function inlining) or slight source code changes. I was not able to trigger misbehavior in -sse, but per my understanding the violations are in there. Another compiler might expose these. (I fixed both in yescrypt.) Of course, if it's a C strict aliasing issue, it'd be equally seen on all CPUs, as long as the same binary code is run. It is unclear from Maarten's message whether the issue was seen on previously-tested binary code or possibly on an untested new build. Alexander
