The makefile tries to pre-qualify NEON (for lack of a better term), and sets IS_NEON accordingly. If IS_NEON=1, then we go on to perform test compiles to see if -mfloat-abi=X -mfpu=neon (and friends) actually work. Effectively we are performing a test to see if we should perform another test.
The IS_NEON flag predates our compile time feature tests. It was kind of helpful when we were trying to sort out if a platform and compiler options supported NEON without a compile test. That was an absolute mess and we quickly learned we needed a real compile time feature test (which we now have).
Additionally, Debian and Fedora ARMEL builds are failing because we are misdetecting NEON availability. It looks like we fail to set IS_NEON properly, so we never get into the code paths that set either (1) -mfloat-abi=X -mfpu=neon or (2) -DCRYPTOPP_DISABLE_NEON or -DCRYPTOPP_DISABLE_ASM. Later, the makefile builds a *_simd.cpp and the result is an error that NEON needs to be activated (or disabled).
This commit removes IS_NEON so we immediately move to compile time feature tests.
adhoc.cpp was a bit uncomfortable because we had to copy it out from adhoc.cpp.proto. For some reason CMake could not perform the copy, so we started using pch.cpp in CMake. This commit keeps them consistent.
We may have problems with one test, and that is the Newlib tests. I seem to recall they a C++ header included to properly identify its use. We cross that bridge during MinGW testing.
This PR adds ARMv8.4 cpu feature detection support. Previously we only needed ARMv8.1 and things were much easier. For example, ARMv8.1 `__ARM_FEATURE_CRYPTO` meant PMULL, AES, SHA-1 and SHA-256 were available. ARMv8.4 `__ARM_FEATURE_CRYPTO` means PMULL, AES, SHA-1, SHA-256, SHA-512, SHA-3, SM3 and SM4 are available.
We still use the same pattern as before. We make something available based on compiler version and/or preprocessor macros. But this time around we had to tighten things up a bit to ensure ARMv8.4 did not cross-pollinate down into ARMv8.1.
ARMv8.4 is largely untested at the moment. There is no hardware in the field and CI lacks QEMU with the relevant patches/support. We will probably have to revisit some of this stuff in the future.
Since this update applies to ARM gadgets we took the time to expand Android and iOS testing on Travis. Travis now tests more platforms, and includes Autotools and CMake builds, too.
Some distros don't want to install cryptest.exe. For folks who don't want to install the test program, they can issue 'make install-lib'.
install-lib is a non-standard target, but the GNU Coding Standard does not have a standard target for the task.
This is a convention that binary compatibity uses one number.
Using that, it's possible to have bugfixes releases (patchlevel
incremented) and enhancement release (minor incremented with no
public interface removed).
Here is more information about convention
https://autotools.io/libtool/version.html
(libtool isn't relevant to this project, but the explanation hold)
Signed-off-by: Nicolas Chauvet <kwizart@gmail.com>
We recently learned our Simon and Speck implementation was wrong. The removal will stop harm until we can loop back and fix the issue.
The issue is, the paper, the test vectors and the ref-impl do not align. Each produces slightly different result. We followed the test vectors but they turned out to be wrong for the ciphers.
We have one kernel test vector but we don't have a working implementation to observe it to fix our implementation. Ugh...
Jeffrey Walton
Blue
PetteriHuusko
Nicolas Chauvet (kwizart)