phc-discussions - Re: [PHC] Optimized versions for ARM?

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] [day] [month] [year] [list]

Date: Tue, 28 Apr 2015 14:56:44 +0200
From: Thomas Pornin <pornin@...et.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Optimized versions for ARM?

On Tue, Apr 28, 2015 at 08:14:04AM +0200, Milan Broz wrote:
> But the main reason for trying PPC was big-endian arch, not the performance.

It may be worth mentioning that while x86 is inherently and irremediably
little-endian, ARM, PowerPC and Mips can all run in both big-endian and
little-endian modes. Some PowerPC variants can switch endianness on a
per-page basis (depending on the relevant support in the MMU).

Old ARM systems tended to use big-endian, but "modern" systems use
little-endian (mostly to ease porting of software from the x86 world).
This still shows in the symbolic architecture names in Linux (armeb vs
armel).

For Mips, the kernel uses the endianness selected at last CPU reset
time, and each process can have its own endianness (normally, the same
as the kernel). I have seen both little-endian and big-endian Mips
systems (OpenWRT tends to use little-endian, but older Mips-based Unix
used big-endian). I really don't know which convention is the most
common.

PowerPC supports both little-endian and big-endian, and (like SPARC v9)
may possibly do so on a per-page basis; however, PowerPC is still a bit
more big-endian than little-endian. For instance, unaligned accesses are
supported (and efficient) in big-endian mode but not in little-endian
mode. Similarly, some of the more complex instructions (that are not
used much in practice, especially since they are awfully slow on the
PowerPC cores found in Xbox 360 and PS3) don't work in little-endian
mode.

Qemu is a viable system for testing cross-endian code. What Qemu does
NOT do is trapping unaligned accesses. A true ARM or Mips will choke on
an unaligned access, that will work flawlessly on Qemu running over x86
hardware. If you want to test some code for both endianness and
alignedness (and all combinations, because some unaligned accesses may
be part of big-endian support, or things like that), then you need true
hardware, and, preferably, NOT a PowerPC, since PowerPC is quite happy
with unaligned access. A big-endian ARM or Mips, or an old SPARC system,
can help a lot.

	--Thomas Pornin