Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Aug 2015 16:21:20 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: JtR on ARM (NEON)

On Mon, Aug 03, 2015 at 04:53:39PM +0800, Lei Zhang wrote:
> I got your points. NEON's vbsl works just as a vcmov.
> 
> With the 2-intruction emulation of vroti, PBKDF2-HMAC-SHA256 got a boost from 644 c/s real to 976 c/s real. Other formats saw no significant performance change.

Cool.  Maybe other formats will see a boost when interleaved.

> However, I have some problem with the emulation of vroti. Literally, it should be defined this way:
> 
> #define vroti_epi32(x, i) \
> 	(i > 0 ? vsliq_n_u32(vshrq_n_u32(x, 32 - (i)), x, i) : \
> 	         vsriq_n_u32(vshlq_n_u32(x, 32 + (i)), x, -(i)))
> 
> Somehow it won't compile when and only when building rawSHA1_ng_fmt_plug.o, giving some cryptic error message:
> 
> 	/tmp/ccgVmq2d.s: Assembler messages:
> 	/tmp/ccgVmq2d.s:4397: Error: co-processor offset out of range

You may capture this assembly output and see what's on that line, then
try to match it back to a source code line.  But yes, I think it's a
compiler bug.

> The version of gcc used is 4.6.4. Unfortunately, there's currently no easy way of upgrading gcc on my mate's board. Solar, do you have a newer gcc on your ARM board?

No, IIRC it's 4.6.x as well.  But we can build a newer version from
source.  It will take ages, but should work.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ