PPC32 acceleration (for certain cryptographic primitives)

[tarcieri]

Foreword: I can understand reluctance to add support for "exotic" platforms, and I'd personally class PPC32 as an "exotic" platform.. I agree supporting a wide range of legacy platforms has complexified and harmed the agility of e.g. OpenSSL in the past. I wholly admit I have purely selfish aims here, and perhaps if I didn't I would be against this sort of thing.

PPC32 is presently used in, as far as I can tell, a reasonable amount of deployed network gear (something confirmed to me by repeatedly asking people "why should we care about PPC32 anymore?"). My personal interest is in the Thales nShield platform.

I can't claim to have done a thorough evaluation of this, but from what I can tell ample Perl scripts exist in OpenSSL which generate PPC32 ASM implementations, but support for these architectures seems to have been dropped from BoringSSL.

Is it worth supporting optimized assembly implementations PPC32? Having wrangled some of OpenSSL's assembly into the general ring hash function framework and tested it on my particular PPC32 platform, I noted a 5X performance advantage over https://github.com/DaGenix/rust-crypto/blob/master/src/sha2.rs on the same platform. I have done no more testing than that.

Rust-proper classes PPC32 as a "Tier 2" platform. This means test failures on these platforms are blocking, and Mozilla performs releases for PPC32. That said, actually exploring running Rust on a PPC32 test box (G4 Mac Mini) I quickly encountered some catastrophic cargo failures. This was fixed by changing the Rust build system to target powerpc instead of power4 (rust-lang/rust#41080). Even after this was corrected, I'm still experiencing problems building Rust code natively on PPC32. Cross-compiling works fine.

The specific algorithm I'd like to have PPC32 acceleration for at the moment is SHA-512. AES acceleration might be nice as well. (Note: My particular platform provides hardware acceleration for both of these primitives, however it requires using a batch-oriented asynchronous message protocol and pipelining operations for efficiency. I'd like to avoid that in the short term)

I'd be interested in immediately contributing PPC32 acceleration for SHA-512, which I think I mostly have ready.

[briansmith]

I don't have a convenient way of testing PowerPC code. If we accept contributions for supporting PowerPC then we need to add a note about the lack of testing to the README.

It is difficult to add just SHA-512 for PowerPC. The build system requires SHA-256, bn_mul_mont(), a P-256 implementation, and an implementation of ring::rand::SystemRandom() too, minimally, off the top of my head. Other than the PRNG stuff, I think there are optimized PPC implementations of all of these mentioned functions in OpenSSL already, and I think it makes sense to add them all at once. Otherwise, ring won't build.

Regarding SystemRandom(), is there a PRNG API for the Thales HSM?

[tarcieri]

I'd certainly be willing to help with testing on PPC32 hardware (as noted earlier I have a G4 Mac Mini for this purpose), however the scope of the APIs you just described is beyond what I'm willing and able to contribute.

Regarding SystemRandom(), is there a PRNG API for the Thales HSM?

The one (proprietary) API they provide claims to be to obtain randomness from the system TRNG. It's part of a class of commands that generally have ~50 microseconds of overhead, FWIW (they use internal communication within the HSM, involving multiple hardware modules)

[tarcieri]

Going to go ahead and close this out.

We've found a number of issues with PPC32, most notably that at least the PPC32 CPU we were using cannot do integer multiplications in constant time.

Debian also dropped support for PPC32 in Sketch, and they were pretty much the only major distribution (or at least, the only one I was interested in using) which supported PPC32.

Thales has a new line of HSMs with PPC64 CPUs: the nShield Connect XC. Given that, we plan on dropping support for PPC32 entirely and migrating to PPC64.

[briansmith]

Tony, thanks for the informative update. Given what you say, I agree that it seems much less likely that anybody will need PPC32 support in ring.