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

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

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

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

Powered by blists - more mailing lists