On Thu, Sep 7, 2017 at 1:39 AM, R0b0t1 <r03...@gmail.com> wrote: > On Wed, Sep 6, 2017 at 11:37 PM, Jeffrey Walton <noloa...@gmail.com> 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. > 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'll hit your other point privately. Jeff
