Re: Power 8 in-core crypto not working as expected
On Thu, Sep 7, 2017 at 7:40 AM, R0b0t1 wrote: > Full disclosure: despite my interest in the architecture I have not > been able to get access to a POWER8 machine. A server costs about as > much as a new car. Any account reseller recommendations or any other > options you can think of? If you don't mind responding feel free to do > it privately so it doesn't clutter this thread. Two of the systems in the GNU Compile Farm are POWER8 and the person is reporting about his tests on those systems. Why are you reporting that you don't have access to Power8 systems? - David
Re: Power 8 in-core crypto not working as expected
On Thu, Sep 7, 2017 at 1:10 AM, Jeffrey Walton wrote: > On Thu, Sep 7, 2017 at 1:39 AM, R0b0t1 wrote: >> On Wed, Sep 6, 2017 at 11:37 PM, Jeffrey Walton wrote: >>> Hi Everyone, >>> >>> I'm on gcc rather than gcc-help because we need to talk with some GCC >>> devs who can help take this further. >>> >>> I have implementation for AES on Power 8 using GCC's built-ins. Its >>> available for inspection and download at >>> https://github.com/noloader/AES-Power8. The problem is, it does not >>> arrive at the correct results on GCC112 (ppc64-le) or GCC119 (AIX, big >>> endian). >>> >>> The source file is the reduced, minimal test case. It uses >>> pre-caclulated subkeys so we've removed that variable from the >>> equation. It also uses the null vector (string of 0's) as the message, >>> so that variable has been removed from the equation too. >>> >>> About all we are left with is loading a subkey, calling vcipher to >>> perform a single round of encryption, and assigning the result back to >>> a variable. Lather, rinse, repeat. >>> >>> For the crypto side of things I've consulted with Andy Polyakov of the >>> OpenSSL project. I believe we are doing everything we should be as far >>> as the crypto goes, including the subkey byte-swaps on LE machines. >>> Our subkey table is exactly the same as the one OpenSSL arrives at on >>> both LE and BE machines. >>> >>> Would someone familiar with the processor and knowledge of GCC >>> built-in's please take a look at things. Suggestions for our next >>> steps would be greatly appreciated. >>> >> >> Have you inspected the generated assembly listing and machine >> instructions to be sure that they are correct? > > Unfortunately, I don't read PPC asm. It could be dead wrong and I > could not spot it. > Learning to read the assembly for your processor and having a copy of the ISA manual handy is a good idea when doing things at the level you are. >> You can refer to the source for vmx-crypto >> (https://github.com/torvalds/linux/tree/master/drivers/crypto/vmx) in >> addition to that of OpenSSL. Are you trying to do a cleanroom >> implementation of this software? > > Yeah, Andy's code in used for both OpenSSL and the Linux kernel. I've > spent the last two days trying to connect the dots between our code > and Andy's code. I've also been talking with Andy offline. > > I'm pretty sure it is mostly apples and oranges. Andy's code is highly > optimized hand tuned assembly. Its just does not lineup well with > C/C++ based code. > I did glance over it and was kind of sad to see it is pure assembly (in a Perl file...?). It looks like there is some memory movement and looping logic but you might be able to figure out the proper way to call the AES instructions or at least compare that code to what GCC generates. Based on the quick look I gave the instructions you are using they are being used properly. That makes me think the assembly or machine instructions are not being generated correctly which is unfortunately something I can't check easily. If OpenSSL also uses handwritten assembly then you may be the first person to use these POWER8 features. Intrinsics like you are using almost always correspond 1 to 1 with machine instructions. It is very helpful to be able to use them from assembly because in some cases the compiler will not support the instructions you are interested in (usually the case for embedded platforms). It looks like I can't help directly so I'll try to avoid commenting anymore, but I'm interested in what is wrong. > I'll hit your other point privately. > Thanks. On Thu, Sep 7, 2017 at 2:14 AM, David Edelsohn wrote: > On Thu, Sep 7, 2017 at 7:40 AM, R0b0t1 wrote: > >> Full disclosure: despite my interest in the architecture I have not >> been able to get access to a POWER8 machine. A server costs about as >> much as a new car. Any account reseller recommendations or any other >> options you can think of? If you don't mind responding feel free to do >> it privately so it doesn't clutter this thread. > > Two of the systems in the GNU Compile Farm are POWER8 and the person > is reporting about his tests on those systems. Why are you reporting > that you don't have access to Power8 systems? > I didn't gather that from his message because I wasn't aware the compile farm existed. He sent me instructions on how to apply for an account. Also, despite my presence on this list, I am not a developer. I am not a very smart man and I can only hope to try to understand the great things that others have made. Cheers, R0b0t1.
Re: Power 8 in-core crypto not working as expected
Hi! On Thu, Sep 07, 2017 at 12:37:33AM -0400, Jeffrey Walton wrote: > I have implementation for AES on Power 8 using GCC's built-ins. Its > available for inspection and download at > https://github.com/noloader/AES-Power8. The problem is, it does not > arrive at the correct results on GCC112 (ppc64-le) or GCC119 (AIX, big > endian). First see if you can get a *single* vcipher call to work as expected (it is a single round of AES). Refer to Power ISA 3.0B and FIPS 197. Segher
Announce: GNU MPFR 3.1.6 is released
GNU MPFR 3.1.6 ("canard à l'orange", patch level 6), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:
http://www.mpfr.org/mpfr-3.1.6/
from InriaForge:
https://gforge.inria.fr/projects/mpfr/
and from the GNU FTP site:
http://ftp.gnu.org/gnu/mpfr/
Thanks very much to those who sent us bug reports and/or tested the
release candidate.
The SHA1 digests:
c207aada1c0af969d800c16f25e0a78e15b9c9cc mpfr-3.1.6.tar.bz2
e6ac324627196370f5fe5a415fff931157da4b23 mpfr-3.1.6.tar.gz
f9178ddc0c470faa2e063b3185c4488ad0f74df8 mpfr-3.1.6.tar.xz
4dba04d35eed61f912c70c3301517bf94287510f mpfr-3.1.6.zip
The SHA256 digests:
cf4f4b2d80abb79e820e78c8077b67254e8f41896783c899087be0e94068
mpfr-3.1.6.tar.bz2
569ceb418aa935317a79e93b87eeb3f956cab1a97dfb2f3b5fd8ac2501011d62
mpfr-3.1.6.tar.gz
7a62ac1a04408614fccdc506e4844b10cf0ad2c2b1677097f8f35d3a1344a950
mpfr-3.1.6.tar.xz
c0ad6c88f0aaeb83a0a2ed069713acb3be22ffa1413467a3a08025573add6b2f mpfr-3.1.6.zip
The signatures:
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6.zip.asc
Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:
gpg --recv-keys 980C197698C3739D
or by downloading it from .
The key fingerprint is:
07F3 DBBE CC1A 3960 5078 094D 980C 1976 98C3 739D
The signatures can be verified with: gpg --verify
You should check that the key fingerprint matches.
Changes from version 3.1.5 to version 3.1.6:
- Improved MPFR manual.
- Bug fixes (see and ChangeLog file).
- Autotools: Under Linux, make sure that the old dtags (when supported)
are used if LD_LIBRARY_PATH is defined; otherwise "make check" would
check an installed, compatible MPFR library found in LD_LIBRARY_PATH
instead of the one that has been built with "make".
You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 3.1.6 web page.
Regards,
--
Vincent Lefèvre - Web:
Re: Power 8 in-core crypto not working as expected
On Thu, Sep 7, 2017 at 4:38 AM, Segher Boessenkool wrote: > Hi! > > On Thu, Sep 07, 2017 at 12:37:33AM -0400, Jeffrey Walton wrote: >> I have implementation for AES on Power 8 using GCC's built-ins. Its >> available for inspection and download at >> https://github.com/noloader/AES-Power8. The problem is, it does not >> arrive at the correct results on GCC112 (ppc64-le) or GCC119 (AIX, big >> endian). > > First see if you can get a *single* vcipher call to work as expected > (it is a single round of AES). Refer to Power ISA 3.0B and FIPS 197. Thanks Segher. We are using the key and subkey schedule from FIPS 197, Appendix A. We are using it because the key schedule is fully specified. We lack the known answers for a single round using a subkey like one specified in FIPS 197. IBM does not appear to provide them. I've been trying to obtain a subkey schedule and known answers per-round from IBM. I've been in touch with some folks at Linux Technology Center. I have not been successful. I don't have access to Power ISA 3.0B. It seems to be hidden behind a paywall. https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0. Before I go down a rabbit hole of trying to obtain a membership, do you know if the documents provide the information we need? I.e., the fully specified key schedule and the known answers? This sort of thing takes the fun out of computing. Jeff
Re: Power 8 in-core crypto not working as expected
> On Sep 7, 2017, at 10:35 AM, Jeffrey Walton wrote: > > On Thu, Sep 7, 2017 at 4:38 AM, Segher Boessenkool > wrote: >> Hi! >> >> On Thu, Sep 07, 2017 at 12:37:33AM -0400, Jeffrey Walton wrote: >>> I have implementation for AES on Power 8 using GCC's built-ins. Its >>> available for inspection and download at >>> https://github.com/noloader/AES-Power8. The problem is, it does not >>> arrive at the correct results on GCC112 (ppc64-le) or GCC119 (AIX, big >>> endian). >> >> First see if you can get a *single* vcipher call to work as expected >> (it is a single round of AES). Refer to Power ISA 3.0B and FIPS 197. > > Thanks Segher. > > We are using the key and subkey schedule from FIPS 197, Appendix A. We > are using it because the key schedule is fully specified. > > We lack the known answers for a single round using a subkey like one > specified in FIPS 197. IBM does not appear to provide them. Known answers don't depend on hardware. If there is a documented single round known answer, and the hardware primitive is a single round with a supplied subkey, then that answer should apply. paul
Re: assuming signed overflow does not occur
On 09/04/17 08:54, Manuel López-Ibáñez wrote: > I wrote an explanation of the current status of Wstrict-overflow to the > best of my knowledge: > https://gcc.gnu.org/wiki/VerboseDiagnostics#Wstrict_overflow > > I didn't mention GIMPLE because it is often the case that the root of > the problem is not obvious in gimple unless one also debugs the compiler > at the same time. > > I hope it is useful! Very much so, thank you!
gcc-7-20170907 is now available
Snapshot gcc-7-20170907 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170907/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 251857 You'll find: gcc-7-20170907.tar.xzComplete GCC SHA256=af37950ac7fc4996b4bdf22cbaaf5d1db52ff6490bfe3d83bcae5d5097645bc9 SHA1=133e024ea7fcda56642c2be84d3fd72d76250d4a Diffs from 7-20170831 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
