Support Power/PowerPC

[briansmith]

I've no intention of doing any PowerPC-specific work, but we did merge in some PowerPC code from BoringSSL.

Besides testing, we should minimize aesp8-ppc.pl the same we did for other targets: Remove the decryption code since all the AEADs we only need AES encryption, remove the XTS and related code, etc.

[AzureMarker]

I'm interested in this. Has anything changed in the last year that should be noted, and where would you suggest to start?

[briansmith]

No movement so far. I imagine the process would go something like this:

1. I merge the last few months of BoringSSL changes into ring.
2. Somebody does a PoC PR that imports the latest PPC-enabling code from BoringSSL into ring and verifies that it works locally for them.
3. Somebody recommends an inexpensive PowerPC system, preferably a small SBC embedded development kit type thing, that I can buy to confirm that it works.
4. It gets merged.

[briansmith]

Also, I remember that some people who want to target PowerPC want to do so because there are some PowerPC-based HSMs that they want to run ring-based programs on. In that case, it would be great to get access to one of the HSMs; this might be something that can be arranged offline (brian@briansmith.org) with the vendor + an interested customer of the vendor.

[Erk-]

There is a Brazilian university that provides POWER8/9 vps instances free of charge that you should be able to use for it: https://minicloud.parqtec.unicamp.br/

[q66]

Any good reason why not have arch-independent fallbacks? I'm packaging a distro for ppc64le/ppc64 these days and I've been coming across an increasing number of Rust projects lately that directly or indirectly depend on ring (to mention some, routinator, rust-sccache, boringtun) and it always fails to build because of this.

[briansmith]

If you are interested in working together on getting ring working on Power/PowerPC, please email me: brian@briansmith.org.

[briansmith]

PR #814 attempts to fix this. I'll look at it after other people interested in POWER/PPC support (e.g. the people who have commented on this issue) have reviewed it and report back their results in testing it.

[q66]

#819 is about ready to start getting reviewed

[briansmith]

I am making substantial progress towards getting this working. We need to split out two parts of the existing PR(s): "whatever is needed for big endian support", which will be shared by MIPS big endian, and the PowerPC/POWER CI infrastructure.

For the CI work, I suggest somebody first stub in unimplemented!() or C abort() implementations of all the missing primitives so that we get a working cargo test --no-run for the relevant platforms. Then we should write a script that downloads whatever is needed to emulate the relevant platforms. Then we should write a script that runs the tests in the emulator. Then we should (probably/maybe) get it working in Travis CI.

I wouldn't spend too much time getting the actual implementations of the primitives working since how they will be implemented is TBD. My main concern right now is having the CI infrastructure ready.

[q66]

Sounds good. I'm away for the weekend right now but I'm available to help next week onwards

[briansmith]

PR #863 adds a pure-Rust implementation of SHA-2 that should kick in automatically for Power/PowerPC. For people working on Power/PowerPC PRs, PTAL.

[andll]

Hi

I came across this issue too. I wanted to compile ring for PowerPC, in order to use it inside HSM custom code, but compilation fails with

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /app/hsm_see/vendor/ring/build.rs:363:34

What is status of this work? Would it be possible to actually support PPC architecture?

CARGO_CFG_TARGET_ARCH: powerpc
CARGO_CFG_TARGET_ENDIAN: big
CARGO_CFG_TARGET_ENV: gnu
CARGO_CFG_TARGET_FAMILY: unix
CARGO_CFG_TARGET_OS: linux
CARGO_CFG_TARGET_POINTER_WIDTH: 32
CARGO_CFG_TARGET_VENDOR: unknown

[mzpqnxow]

@andll I am having the same issue, this is on an IBM POWER8, which is ppc64le architecture. OS is Linux.

@briansmith, just adding this comment to make you aware

I am (for now) )blocked here trying to deploy an application that requires maturin, which in turn requires ring

I am not experienced with rust at all so I can't offer much in the way of help here, aside from testing

The exact error I receive, using the latest stable rustc/cargo (1.42.0) is:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', build.rs:363:34

The full stacktrace

--- stderr
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', build.rs:363:34
stack backtrace:
   0:        0x13991e6a4 - backtrace::backtrace::libunwind::trace::ha8cf2127a96f82ca
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
   1:        0x13991e6a4 - backtrace::backtrace::trace_unsynchronized::h43807ba4a87f5ac1
                               at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
   2:        0x13991e6a4 - std::sys_common::backtrace::_print_fmt::h4f71b3838339c937
                               at src/libstd/sys_common/backtrace.rs:77
   3:        0x13991e6a4 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h289ab16f24d4c815
                               at src/libstd/sys_common/backtrace.rs:59
   4:        0x1399471e4 - core::fmt::write::h02ed5143da8a94fd
                               at src/libcore/fmt/mod.rs:1052
   5:        0x139918fa8 - std::io::Write::write_fmt::h7e5185cbbf7bf219
                               at src/libstd/io/mod.rs:1426
   6:        0x1399219a4 - std::sys_common::backtrace::_print::h1c4d58383262144b
                               at src/libstd/sys_common/backtrace.rs:62
   7:        0x1399219a4 - std::sys_common::backtrace::print::h604da38a975ed801
                               at src/libstd/sys_common/backtrace.rs:49
   8:        0x1399219a4 - std::panicking::default_hook::{{closure}}::h4fdddbee8f70699c
                               at src/libstd/panicking.rs:204
   9:        0x139921590 - std::panicking::default_hook::haf586c91e2e8c1ca
                               at src/libstd/panicking.rs:224
  10:        0x1399222fc - std::panicking::rust_panic_with_hook::hdb18c2f21fdb8fb7
                               at src/libstd/panicking.rs:472
  11:        0x139921d2c - rust_begin_unwind
                               at src/libstd/panicking.rs:380
  12:        0x139943adc - core::panicking::panic_fmt::hf8376cf1456c10b4
                               at src/libcore/panicking.rs:85
  13:        0x1399439f0 - core::panicking::panic::h9c3ae45a56518eb6
                               at src/libcore/panicking.rs:52
  14:        0x139892e6c - core::option::Option<T>::unwrap::h53cd7f28c3b08014
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libcore/macros/mod.rs:10
  15:        0x139883578 - build_script_build::build_c_code::hea669e47b8d9dfdd
                               at /home/adam.greene/pyboot3.git/maturin/ring/build.rs:363
  16:        0x139882990 - build_script_build::ring_build_rs_main::hee74943ed7ebd3f5
                               at /home/adam.greene/pyboot3.git/maturin/ring/build.rs:295
  17:        0x139882180 - build_script_build::main::h5d990086e9462303
                               at /home/adam.greene/pyboot3.git/maturin/ring/build.rs:252
  18:        0x139881f24 - std::rt::lang_start::{{closure}}::ha1fa9c6b3b6b89d4
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/rt.rs:67
  19:        0x13991f054 - std::rt::lang_start_internal::{{closure}}::{{closure}}::he8e15e29039ba7a3
                               at src/libstd/rt.rs:52
  20:        0x13991f054 - std::sys_common::backtrace::__rust_begin_short_backtrace::h069eb49e6dbbd0e9
                               at src/libstd/sys_common/backtrace.rs:129
  21:        0x139921b6c - std::rt::lang_start_internal::{{closure}}::h901134b4d8707d46
                               at src/libstd/rt.rs:52
  22:        0x139921b6c - std::panicking::try::do_call::hc6cae8e0a5e80be3
                               at src/libstd/panicking.rs:305
  23:        0x13992c380 - __rust_try
  24:        0x13992bd3c - __rust_maybe_catch_panic
                               at src/libpanic_unwind/lib.rs:86
  25:        0x13992278c - std::panicking::try::hb56512670cbc0fd0
                               at src/libstd/panicking.rs:281
  26:        0x13992278c - std::panic::catch_unwind::hb202396fab3c823a
                               at src/libstd/panic.rs:394
  27:        0x13992278c - std::rt::lang_start_internal::h1f1d75d66446f6f8
                               at src/libstd/rt.rs:51
  28:        0x139881ebc - std::rt::lang_start::hb64623016a7c5ed5
                               at /rustc/b8cedc00407a4c56a3bda1ed605c6fc166655447/src/libstd/rt.rs:67
  29:        0x139887010 - main
  30:     0x3fffa2c2309c - <unknown>

[briansmith]

Adding support for AES-GCM for Power/PowerPC will be done as part of #971. Please follow along there. RSA and then ECC stuff will follow.

[briansmith]

Adding support for AES-GCM for Power/PowerPC will be done as part of #971. Please follow along there. RSA and then ECC stuff will follow.

There was already an older issue: Issue #104, so let's use that one instead.

[briansmith]

Issue #104 is fixed, so AES-GCM should be working on all platforms where we do not have assembly language AES-GCM in ring, including little-endian Power. With small changes, which I encourage somebody to do in a PR, it should also work for big-endian Power. However, I know that Power has something very much line AES-NI, and of course we should add that to ring soon.

PR #996 implements (unoptimized) RSA support for WebAssembly, but also other platforms for which we do not have assembly language GFp_bn_mul_mont, including again Power.

[programmerjake]

Also running into this error when attempting to build maturin v0.8.3 on powerpc64le-unknown-linux-gnu:

  thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/jacob/.cargo/registry/src/github.com-1ecc6299db9ec823/ring-0.16.15/build.rs:378:10

[jpturcotte]

Are bounties accepted, would Bountysource be appropriate, and would anyone be interested?

[briansmith]

This should be very close to working. I know we need #1174 and I'm not sure what else. PTAL at #1174 and provide feedback on it.

It would be nice to have a GitHub Actions runner that could be used to test this. Any suggestions for how to get that?

[edelsohn]

PPC64LE does not directly support Github Action runners at this time that hopefully will be addressed.

[programmerjake]

I'd expect qemu could be used, you can check and see what rust uses for its testing infrastructure...

[programmerjake]

Also, you could get some CI infrastructure from https://osuosl.org/services/powerdev/

[omnivagant]

Alpine Linux has aport gitlab CI infrastructure for ppc64le, a few of our aports are disabled on ppc64le due to this issue.

[runlevel5]

@briansmith if you need to access a PowerPC64 box, please let me know

[runlevel5]

It would be nice to have a GitHub Actions runner that could be used to test this. Any suggestions for how to get that?

@briansmith Github Actions does not support ppc64/ppc64le.

Alternatively, you could set up a clone repo on GitLab. I could set up my box to host the gitlab-ci-runner daemon for your Gitlab repo

[jaesharp]

@runlevel5 re:

@briansmith Github Actions does not support ppc64/ppc64le.

https://github.com/marketplace/actions/run-on-architecture

[bmallya]

Hello, I was wondering if there has been any additional progress on supporting powerPC. I am trying to use Vector which has a dependency on this project.

[runlevel5]

@briansmith I hope you are well and sound. Any update on this work? Many thanks in advance

[ghost]

I think the PR for this is #1057

[briansmith]

As I've done for all other architecture-specific issues (besides wasm32 and RISC-V) I'm closing this as a duplicate of #1455 and #1555.