Tests failure with cryptopp 6.0.0 on ppc64le #588
Comments
|
Thanks @kwizart. The log is interesting in a morbid sort of way. It looks like 4 or 5 algorithms failed (search for We test on a ppc64le machine. It is A few of questions...
Regarding (1), it looks like Power8. Below is the Regarding (4), how can I duplicate... Using the following command line does not result in a failure on |
At least, I can only reproduce with fedora 28, as fedora 27 doesn't have the issue:
|
Ah, thanks. This explains a lot.
Ack, thanks. Yeah, we want to work through these issues. Removing It is needed for older compilers, like early GCC 4.x on a PowerMac G5 to help engage Altivec. Since you are at Power8 the minimum Altivec/Power4 should already be engaged. I don't recall seeing this one before: It seems like a SIMD float should go missing without
OK, thanks. For PPC64 only... does Fedora governance allow you to build with an additional define? If so, here is what I suggest until we can get to the bottom of it... Open Maybe something like: We actually added that block to A quick heads up... We released Crypto++ 6.0 on January 22, 2018. On February 22 we are releasing Crypto++ 6.1. It is a planned release. We found it is good housekeeping to (1) perform major release, and then (2) perform minor release 30 days later. The testing we hoped for before 6.0 was released always seems to happen after it is released. So 6.1 will be the rollup with the more complete testing and minor bug fixes. Effectively Crypto++ 6.1 is the long term release. Crypto++ 6.1 is also going to fix this issue with Simon and Speck: Issue 585, Speck, Android and Linux kernel interop. Simon and Speck are block ciphers added at 6.0. The issue is fixed so we want to get the modified cipher into circulation. (We would also like to see the Simon and Speck team publish updated test vectors, but that is probably not going to happen). By the way, feel free to email me at noloader, gmail account. It may be easier on you if you want email rather than bug reports. |
The code below was flagged by undefined behavior santizier under GCC 8. The offender was the doubling at "r4 = vec_add(r4, r4)". R4 is rcon and an unsigned type. It depends on integer wrap but GCC is generating code that is being flagged for signed overflow. GCC 7 and below is OK.
for (unsigned int i=0; i<8; ++i)
{
r1 = Rijndael_Subkey_POWER8(r1, r4, r5);
r4 = vec_add(r4, r4);
skptr = IncrementPointerAndStore(r1, skptr);
}
// Final two rounds using table lookup
...
This is due to the removal of a path in Rijndael_UncheckedSetKey_POWER8
|
Good news... I am able to duplicate the issue with GCC 8 now. Thanks to Segher Boessenkool for building GCC 8 and installing on GCC112 for us. Here is the baseline I used to recreate the issue on GCC112 with GCC 8. These are Fedora's options less the Red Hat spec files because GCC112 lacks them. It results in the failure: Next, remove And: Now here is the rub... Compiling with just At this point I don't know how to take things further. I'm usually reliable up to about I pinged the GCC-dev list to see what they have to say. Also see GCC 8, ppc64-le and problems with -fstack-protector-strong. |
|
I've got a feeling things are going to stall at this point. At this point in time I think your options for GCC 8 on ppc64-le are:
I advise you to select option (2) because AES builtins/hardware are hardened against many side channel attacks that are present in software-only implementations. And AES builtins run around 1.2 cycles-per-byte (cpb), so it is about 15x faster than software only using C++. |
|
Confirmed to build and pass tests as appropriate. I will try to test back to the default from time to time and report here if fixed. |
|
Ack, thanks for the help. We test the library using Let's ping László Böszörményi (@gcsideal) to let him know GCC 8 may cause some troubles for him. He is a Debian packager and maintainer. I'm going to close this out for the time being. Please drop a note when you notice |
|
Debian is not affected by for the time being. While we have a recent GCC 8 in the archives, it's not yet the default to be used. But thanks for the heads-up @noloader. |
|
I think I tracked the failure down to a One Definition Rule (ODR) violation in our Power8 code. It was not a GCC problem. Several functions in Jonathan Wakely commented he did not think the Sorry about the troubles the issue caused. |
|
Crypto++ was just released. Release notes at Crypto++ 6.1. |
|
Seen and packaged it. Had to add |
|
Great, thanks.
That should be OK (I think). |
Crypto++ Issue Report
The cryptopp compilation succeeded once a little fix is made:
Prevent an error at aria-simd.cpp compile:
Here is the full log:
State the operating system and version (Ubutnu 17 x86_64, Windows 7 Professional x64, etc)
State the version of the Crypto++ library (Crypto++ 5.6.5, Master, etc)
State how you built the library (Makefile, Cmake, distro, etc)
Show a typical command line (the output of the compiler for cryptlib.cpp)
Show the link command (the output of the linker for libcryptopp.so or cryptest.exe)
Show the exact error message you are receiving (copy and paste it); or
cryptest.exe vare failing:Clearly state the undesired behavior (and state the expected behavior)
The text was updated successfully, but these errors were encountered: