Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 03 Aug 2015 12:56:45 +0200
From: magnum <>
Subject: Re: JtR on ARM (NEON)

On 2015-08-03 11:34, Lei Zhang wrote:
>> On Aug 3, 2015, at 10:58 AM, Solar Designer <>
>> wrote:
>> On Mon, Aug 03, 2015 at 04:39:38AM +0200, magnum wrote:
>>> How slow is NEON with unaligned scalar 32-bit? The raw formats'
>>> set_key() read the key (which may be unaligned) using 32-bit
>>> loads and places directly in the SIMD buffer. It might be a
>>> coincidence that MD4/MD5 happens to get aligned test vector keys
>>> and the others doesn't. Other than that I can't see what would be
>>> unaligned.
>> I think we must not have any unaligned accesses on ARM at all.  If
>> we currently do have any, let's fix that as a bug.
>> While not completely unsupported, they are tricky:
>> "How does the ARM Compiler support unaligned accesses?"
> I'm not very clear. Are you talking about unaligned vector
> load/stores or unaligned scalar load/stores?

I think virtually all vector stuff is aligned. But a SIMD build 
"enables" the "32-bit set_key" I described, which uses unaligned scalar 
load from 'key' (and aligned 32-bit scalar store in the SIMD buffer). So 
it's unaligned scalar, but happens only in SIMD builds.

> The links you posted discussed scalar load/stores. As we are not
> writing ARM assemblies in JtR, the compiler should be able to take
> care of scalar variables' alignment for us.

That may be why it doesn't crash but gets slow. The compiler may produce 
inefficient code for this and this function's speed has a huge impact on 
the fastest formats. The functions were written/tweaked with close 
monitoring of Valgrind.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.