cryptest.sh revealed a corner case still producing an incorrect result. We need to check for '*this > m', not '*this > 2m-1'.
The corner case looks obscure. The failure surfaced as 1 failed self test for about every 2048 tests. It was also in a code path where 'a' was explicitly set to '2m-1', with 'm' random.
The test result can be duplicated with 'cryptest.exe v 9996 1521969687'. The value '1521969687' is a seed for the random number generator to reproduce.
It looks like the 0 return value for _SC_LEVEL1_DCACHE_LINESIZE is not a 1-off problem with PPC. It appears Glibc regularly returns 0 instead of failure. Also see https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/sysconf.c.
We were OK before the change. The difference now is, we expect all Glibc queries to misbehave
Perforance increases significantly, but there's still room for improvement. Even OpenSSL's numbers are relatively dull. We expect Power8's SHA-256 to be somewhere between 2 to 8 cpb but we are not hitting them.
SHA-256, GCC112 (ppc64-le): C++ 23.43, Power8 13.24 cpb (+ 110 MiB/s)
SHA-256, GCC119 (ppc64-be): C++ 10.16, Power8 9.74 cpb (+ 50 MiB/s)
SHA-512, GCC112 (ppc64-le): C++ 14.00, Power8 9.25 cpb (+ 150 MiB/s)
SHA-512, GCC119 (ppc64-be): C++ 21.05, Power8 6.17 cpb (+ 450 MiB/s)
This one should have been fixed before the Crypto++ 6.1 release. Its no big deal, however. Power8 accelerated SHA-256 is 1.5x to 2x slower than straight C++. SHA-512 may be better, but the implementation is not ready to performance test.
If CRYPTOPP_GETAUXV_AVAILABLE is undefined, getauxval function is
defined to return 0 however AT_HWCAP and AT_HWCAP2 are not defined so
compilation on toolchain without getauxval and these variables such as
uclibc-ng will fail.
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Jeffrey Walton
Ilja
rocksonhead
Fabrice Fontaine