Add support for mips

[saprette]

Hello,

I'm trying to compile Rocket for an Omega2, but it's failing as the ring dependency will not cross compile. Would you have some pointer? Many thanks!

I've been able to cross compile and run an http server on the Omega2 with hello world examples using tiny_http and iron latest but I have an issue cross compiling Rocket due to 'failed to run custom build command for ring v0.11.0' (it does work if I don't cross compile on my laptop). I've installed rust & cargo using rustup and I updated them before trying to build Rocket today.

sam@sam:~/omega/Rocket/examples/hello_world$ cargo build --target=mipsel-unknown-linux-musl 
   Compiling toml v0.4.2
   Compiling url v1.5.1
   Compiling ring v0.11.0
error: failed to run custom build command for `ring v0.11.0`
process didn't exit successfully: `/home/sam/omega/Rocket/target/debug/build/ring-a7af99b63f4ef999/build-script-build` (exit code: 101)
--- stderr
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', /checkout/src/libcore/option.rs:335:20
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:380
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:611
   5: std::panicking::begin_panic_new
             at /checkout/src/libstd/panicking.rs:553
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:521
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:497
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:92
   9: core::panicking::panic
             at /checkout/src/libcore/panicking.rs:51
  10: <core::option::Option<T>>::unwrap
             at /checkout/src/libcore/macros.rs:22
  11: build_script_build::build_c_code
             at ./build.rs:413
  12: build_script_build::ring_build_rs_main::{{closure}}
             at ./build.rs:343
  13: <rayon_core::job::StackJob<L, F, R> as rayon_core::job::Job>::execute::{{closure}}
             at /home/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.2.1/src/job.rs:99
  14: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
             at /checkout/src/libstd/panic.rs:296
  15: std::panicking::try::do_call
             at /checkout/src/libstd/panicking.rs:479
  16: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  17: std::panicking::try
             at /checkout/src/libstd/panicking.rs:458
  18: std::panic::catch_unwind
             at /checkout/src/libstd/panic.rs:361
  19: rayon_core::unwind::halt_unwinding
             at /home/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.2.1/src/unwind.rs:19
  20: <rayon_core::job::StackJob<L, F, R> as rayon_core::job::Job>::execute
             at /home/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.2.1/src/job.rs:99
  21: rayon_core::job::JobRef::execute
             at /home/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.2.1/src/job.rs:55
  22: rayon_core::registry::WorkerThread::execute
             at /home/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.2.1/src/registry.rs:476
  23: rayon_core::registry::WorkerThread::wait_until_cold
             at /home/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.2.1/src/registry.rs:460
  24: rayon_core::registry::WorkerThread::wait_until
             at /home/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.2.1/src/registry.rs:436
  25: rayon_core::registry::main_loop
             at /home/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.2.1/src/registry.rs:559
  26: rayon_core::registry::Registry::new::{{closure}}
             at /home/sam/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.2.1/src/registry.rs:145

warning: build failed, waiting for other jobs to finish...
error: build failed

[saprette]

It is failing here https://github.com/briansmith/ring/blob/master/build.rs#L413

Looks like because misp is not expected / supported. https://github.com/briansmith/ring/blob/master/build.rs#L278

[briansmith]

We can and should add support for MIPS. It mostly involves adding the OpenSSL assembly language code from OpenSSL back, and adding some fallback Rust or C code for ChaCha20-Poly1305.

[saprette]

I'm a complete newbie in rust so sorry if I'm wrong. Does it mean that I need to add these

sam@sam:~/omega/openssl$ find . -name "mips" ./crypto/poly1305/asm/poly1305-mips.pl ./crypto/bn/asm/mips-mont.pl ./crypto/bn/asm/mips.pl ./crypto/aes/asm/aes-mips.pl ./crypto/mips_arch.h ./crypto/sha/asm/sha512-mips.pl ./crypto/sha/asm/sha1-mips.pl

And update build.rs as it is done for ARM?

This is what I tried here

https://github.com/briansmith/ring/compare/master...saprette:mips

but got this

--- stderr MIPS64 only at crypto/poly1305/asm/poly1305-mips.pl line 61. thread '' panicked at 'execution failed', build.rs:668:8

[NilsLattek]

Any update on this?

[pietro]

from crypto/poly1305/asm/poly1305-mips.pl :

$flavour = shift || "o32"; # supported flavours are o32,n32,64,nubi32,nubi64

die "MIPS64 only" unless ($flavour =~ /64|n32/i);

So you have to choose one of the MIPS64 flavours. BTW, you defined as linux32 as the flavour for all mips builds, which seems to be wrong given the above comment.

[athei]

If I understand the last post correctly we can have full support on mips32 except for poly1305 which BoringSSL only supports on mips64?

[jkilpatr]

why isn't there a generic Rust implementation of these algorithms? Native assembly speed is all fine and good but having a fallback is also important.

[briansmith]

In terms of the Rust --target flag, which MIPS targets do you need to support?

[jkilpatr]

@briansmith

mips-unknown-linux-musl mips64-unknown-linux-gnuabi64 mips64el-unknown-linux-gnuabi64 mipsel-unknown-linux-musl

[briansmith]

The first step, before any actual support for MIPS can be considered, would be getting CI working with an emulator for the relevant targets. ring will fail to build w/o the needed code but each of those functions can be temporarily stubbed for the purpose of passing the cargo build phases and for getting the cargo test phases to actually run.

Once that's done we can come up with an implementation strategy.

[jkilpatr]

We'll get to work on a pull request then.

[mpapierski]

@briansmith Thanks for great library! I'm working on MIPS/MIPS64/MIPSEL BE/LE support and so far its going great, with few hiccups mostly related to endianness (swapping bytes is a nightmare!). Once I'll send PR I'd really appreciate your input to make the code better because I'm still learning Rust, and in current shape this code might not fit your goals.

Before that I have few questions though that would clarify things, about library design decisions that arose while working on MIPS.

• It is not clear where C fallback functions always comes from, also it is not that clear where "PerlAsm" comes from. In my case I pulled few PerlAsm codes for MIPS from LibreSSL/OpenSSL/BoringSSL, but I had to change them to make them work with build.rs, not to mention few changes to build.rs. I think it would be beneficial if we somehow keep C sources original, with a way to somehow prove their origin (i.e. at least a commit message copy sha512.c from BoringSSL, or a script that pulls them from git repos to sync). What if we'd just copy OpenSSL/LibreSSL/BoringSSL code?
• Speaking of C functions, I wonder where GFp_ prefix comes from - is it because of OpenSSL license? There is a small C code that seems to be very important, but is different than *SSL libraries - i.e. OPENSSL_malloc is just a #define for malloc. I'd keep it as close to the original sources, with a small shim on top of that, that would call internal functions (i.e. GFp_malloc calls OPENSSL_malloc, GFp_crypto_foo shim calls OPENSSL_crypto_foo, and rust code calls only GFp shims).
• PerlAsm requires perl executable while building. At least in SHA512/Montgomery PerlAsm code I had to change few lines of Perl code to properly generate ASM for a platform from within build.rs. Wouldn't it be easier for maintenance to just keep original .pl sources, and keep pre-generated .S source code in repository? It won't change very often, and that move would greatly simplify build.rs and minimize set of custom changes in .pl files - they could be 100% original. For sure this 'regenerating' process should be scripted. IIRC FreeBSD does it this way: https://github.com/freebsd/freebsd/tree/master/crypto/openssl/crypto/bn/asm - you can see .S and .s files. What if we'd just link to lib*ssl if it is available as a feature switch?
• Perhaps it would be a long term goal but I'd strongly suggest adding a use_asm feature switch that while disabled would favor "C" code, or native Rust implementations instead of ASM for platforms we don't support yet.
• To support endianness properly I added more unit tests for small functions that operates on chunks of bytes - Whats your view on this approach? IMO to make target_endian = "big" a first class citizen in ring it would be good to keep those tests, and even implement more - some crypto operates on BE bytes, some on LE and some (at least to my knowledge - bear in mind that I'm not a crypto expert) dont care much about byte order.

I'll keep you updated once a PR is ready for first review iteration.

Thanks!

[briansmith]

It is not clear where C fallback functions always comes from

There are not many fallback implementations, in general. I think AES is exceptional in that respect. Generally the lowest-level stuff is either 100% in C or 100% in assembly language.

I pulled few PerlAsm codes for MIPS from LibreSSL/OpenSSL/BoringSSL, but I had to change them to make them work with build.rs, not to mention few changes to build.rs.

Please submit a WIP PR that shows what you had to change.

I think it would be beneficial if we somehow keep C sources original, with a way to somehow prove their origin (i.e. at least a commit message copy sha512.c from BoringSSL, or a script that pulls them from git repos to sync). What if we'd just copy OpenSSL/LibreSSL/BoringSSL code?

If you want to do that, you can just use OpenSSL/LibreSSL/BoringSSL. We don't make gratuitous changes to the code we picked up from BoringSSL and every change is explained in the commit messages and comments.

Speaking of C functions, I wonder where GFp_ prefix comes from - is it because of OpenSSL license?

The GFp_ prefix allows ring and one of OpenSSL/BoringSSL/LibreSSL to exist in the same executable at the same time. Without that prefixing the names would collide.

PerlAsm requires perl executable while building. [...] For sure this 'regenerating' process should be scripted.

build.rs is that scripting. Note that when building a release for crates.io, the *.S files are packaged into the crate (and on Windows even the *.obj files are packaged) so you don't need Perl to build a ring release; you only need it to build a git checkout.

Perhaps it would be a long term goal but I'd strongly suggest adding a use_asm feature switch that while disabled would favor "C" code, or native Rust implementations instead of ASM for platforms we don't support yet.

Sure. First somebody needs to build a Rust or C compiler that we can freely and conveniently use, that guarantees side-channel-free code, and that generates code better than the assembly language code for our target platforms.

To support endianness properly I added more unit tests for small functions that operates on chunks of bytes - Whats your view on this approach?

I suggest:

1. In one PR, get the build with --target=<your targets> working in Travis CI without adding any new source files. The build will fail because some implementations will be missing; this is OK.
2. For each algorithm, submit a PR that adds little-endian MIPS support for that algorithm, using the OpenSSL assembly code. In each PR, the first commit should be the original unmodified OpenSSL assembly code and then your changes should be done in a second commit.
3. Later, submit one or more PRs that add big-endian support. This will probably consist of writing a bunch of tests for endian-sensitive logic that are currently missing.

[briansmith]

It is not clear where C fallback functions always comes from, also it is not that clear where "PerlAsm" comes from.

You can look at the history of the file to find out where it came from. If it was in the original commit it came from BoringSSL. Otherwise the commit that added the file will tell you where it came from.

[mpapierski]

Thanks for reply @briansmith. It explains a lot more context of this library.

I'll start with a PR with a CI config for MIPS architectures with allowed_failures option, and submit it, so it won't fail builds with already supported platforms, and would allow to test future PRs for builds on unstable platforms. Also, other PRs that would fill the gaps could be sent and reviewed in parallel after that.

Once that would be done I'll start publishing PRs with new algorithms ported to mipsel/mips64el, and after that PRs with big endian code.

[mpapierski]

Hey @briansmith. Gently ping. I’ll appreciate your feedback on #684. It will unblock me to send more PRs for MIPS support.

[JohnnyFFM]

Cant wait to have MIPS support for my DVR box!

[SuperHacker-liuan]

This feature is needed by me.

[cadubentzen]

I would very much like this too! It's the only blocker for using Rust in a webserver for MIPS currently.

[LinusU]

I would love to see this! Is there anything I can do to help? My use case is also compiling for the Omega2.

In the meantime, I'm working on this patch to be able to skip ring in the Rocket crate: https://github.com/SergioBenitez/Rocket/pull/816

[briansmith]

The main blocker here is coming up with a consistent CI story so that MIPS isn't a special snowflake w.r.t. CI. It seems like the solution may be to use cross for every cross-compilation build. Maybe this would get Android ARM targets working again too?

From me end, I did recently start to eliminate endian-sensitive logic in ring. Check out commit ea9e9f105f6e4a0a875df9ee2230a9d6edda8378 especially, and also 6bc74d900e6a8ff17ca004cb2b59ae3aa29b14c9, 1bba0f060cde266503324297d4e2ab77015eebb3, and 98d680bfc10d7e8835aa1771da33a4b0e516dcb6. The idea here is that every value that isn't endian-neutral must be wrapped in a type that implements endian::Encoding, i.e. BigEndian or LittleEndian. There is now only one place in the code, IIUC, that blocks building for big-endian architectures:

#[cfg(all(target_pointer_width = "32", target_endian = "little"))]
macro_rules! limbs {
    ( $limb_b:expr, $limb_a:expr, $limb_9:expr, $limb_8:expr,
      $limb_7:expr, $limb_6:expr, $limb_5:expr, $limb_4:expr,
      $limb_3:expr, $limb_2:expr, $limb_1:expr, $limb_0:expr ) => {
        [
            $limb_0, $limb_1, $limb_2, $limb_3, $limb_4, $limb_5, $limb_6, $limb_7, $limb_8,
            $limb_9, $limb_a, $limb_b,
        ]
    };
}

#[cfg(all(target_pointer_width = "64", target_endian = "little"))]
macro_rules! limbs {
    ( $limb_b:expr, $limb_a:expr, $limb_9:expr, $limb_8:expr,
      $limb_7:expr, $limb_6:expr, $limb_5:expr, $limb_4:expr,
      $limb_3:expr, $limb_2:expr, $limb_1:expr, $limb_0:expr ) => {
        [
            (($limb_1 | 0u64) << 32) | $limb_0,
            (($limb_3 | 0u64) << 32) | $limb_2,
            (($limb_5 | 0u64) << 32) | $limb_4,
            (($limb_7 | 0u64) << 32) | $limb_6,
            (($limb_9 | 0u64) << 32) | $limb_8,
            (($limb_b | 0u64) << 32) | $limb_a,
        ]
    };
}

I believe that that code is probably endian-neutral already and so the tests for target_endian can probably just be removed. It would be great if somebody could confirm that.

After that, I believe most of the work involves importing in the MIPS assembly language code from OpenSSL and then finding a way to fuzz it; note in particular that Google's BoringSSL project doesn't support MIPS at all and so they don't fuzz MIPS. I've started working on fuzzing infrastucture for other targets but I have no idea how to do fuzzing for MIPS.

[briansmith]

More issues:

• Is it OK to standardize on using only a very new version of clang as the C toolchain, instead of supporting various flavors of GCC? Or at least support no more than the very newest stable GCC and the very newest stable clang?

• What OS(s) are people wanting to run on MIPS?

• More generally, we need to find a way to keep the CI matrix for MIPS under control. The current PR expands the test matrix so that a huge amount of work is done just to verify for MIPS, even though MIPS is the least commonly used (AFAICT) target. We need to find a way to scale this back so that we're adding a small number of new entries to the matrix, instead of (IIRC) dozens.

[LinusU]

My personal answers, which works for my use case:

Is it OK to standardize on using only a very new version of clang as the C toolchain [...]

I'm okay with anything modern, currently using this Docker image to build my projects:

https://github.com/LinusU/omega2-rust

What OS(s) are people wanting to run on MIPS?

I'm running Linux

We need to find a way to scale this back so that we're adding a small number of new entries to the matrix, instead of (IIRC) dozens.

I, again personally, think that the mipsel arch is a good start since it's used in the Omega2 Onion board which is a cheap, fully functional, hacker-friendly Linux computer. This was also the board that the OP was using.

[briansmith]

I, again personally, think that the mipsel arch is a good start since it's used in the Omega2 Onion board which is a cheap, fully functional, hacker-friendly Linux computer. This was also the board that the OP was using.

OK. Can you tell me what kind of AES implementation is normally used by OpenSSL for this target. Is it a VPAES variant?

[briansmith]

I would like to hear what people are expecting in terms of performance for MIPS:

1. Which exact chip(s) are you targeting? Please specify endianness.
2. Is your goal to just get it working, or do you have specific performance goals that you think the OpenSSL assembly language code for MIPS solves? If the assembly language code is important to you, for which algorithms is it important to you?

[senden9]

1. I would use ring on a RUT950 which has, according to the data-sheet an "Atheros Wasp, MIPS 74Kc, 550 MHz" with big endian.

2. "Just get it working" would be enough for my use-case.

[LinusU]

1. I would use ring on a Omega2+ which has a 580MHz MIPS CPU with big endian.

2. "Just get it working" would be enough for my use-case.

[puddly]

1. Qualcomm Atheros QCA956X (MIPS 74Kc running at 775MHz), big endian. Used in gen2 Ubiquiti APs.
2. Just get it working.

[briansmith]

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

[briansmith]

I removed some target-specific code paths so that the other platforms will more often run the code that I expect MIPS to run. I also removed the last tests for target endianness. I think both of these will help with the porting effort.

OTOH, I removed aes.c, which will hurt this porting effort temporarily.

[briansmith]

Do the MIPS chips that you are using have any carryless multiplication instruction?

[senden9]

Sorry, I am not able to find it out for my CPU. I looked at Programming the MIPS32® 74K Core Family but did not find such a instruction for sure. There is multu which does as unsigned multiply.

[xen0n]

I've done something over at #943 as a starting point. 32-bit support, big endian support and performance improvements can always be added later... :joy:

[briansmith]

Update on the strategy for this: I don't have any appetite for merging in any more MIPS assembly language code than is absolutely necessary. I just don't have the time to review, test, and maintain it.

BoringSSL recently implemented portable C code for AES and GCM that is constant-time (as much as C code can be). I am in the process of merging BoringSSL up through the latest BoringSSL commit. Once that is done, those portable C implementations will be available for ring to use, and they will be used on other targets.

Once the BoringSSL merge is done, then this effort can pick back up to adapt and use those C implementations for MIPS.

[xen0n]

BoringSSL recently implemented portable C code for AES and GCM that is constant-time (as much as C code can be). I am in the process of merging BoringSSL up through the latest BoringSSL commit. Once that is done, those portable C implementations will be available for ring to use, and they will be used on other targets.

Once the BoringSSL merge is done, then this effort can pick back up to adapt and use those C implementations for MIPS.

Hi, any updates on this?

[briansmith]

I am working on AES-GCM that will work for MIPS now. It is being tracked in issue #104. RSA and then other algorithms will follow.

[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 MIPS. If there are equivalents to the AES-NI instructions for MIPS then I encourage people to work together to create a PR that adds that code to ring.

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 MIPS.

[briansmith]

I forgot: For big-endian, the changes tracked in #104 will need some small modifications, as the BoringSSL code assumes little-endian. I dont think it would be a huge amount of work, and I encourage somebody to attempt it.

[briansmith]

The next step is to bring a portable chacha20 implementation, probably BoringSSL's, into ring. I'm planning to do that soon. As I mentioned in a couple of PRs, I had to replace Travis CI with GitHub Actions, unfortunately. On the positive side, the new GitHub Actions CI/CD is much faster and so it's more reasonable to add a few MIPs jobs to it.

[bltavares]

With this new commit, built on top of #1174 I've been able to run cross build --target mipsel-unknown-linux-musl successfully.

Running cross test --target mipsel-unknown-linux-musl led to errors on linking tho.

Compiling the changes for mips big-endian with cross build --target mips-unknown-linux-musl leads to an error on BoringSSL bash.h claiming it does not support big-endian architecture. Would it be possible to fallback to a pure rust implementation on those platforms?

[kolapapa]

target: mipsel-unknown-linux-uclibc

error: failed to run custom build command for `ring v0.16.20`

Caused by:
  process didn't exit successfully: `/opt/build/rust_workspace/edge-checker/target/release/build/ring-65505efbf15bc85d/build-script-build` (exit code: 101)
  --- stderr
  thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /root/.cargo/registry/src/rsproxy.cn-8f6827c7555bfaf8/ring-0.16.20/build.rs:358:10
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/2d8a3b9181f41d3af9b9f016c5d73b2553e344bf/library/std/src/panicking.rs:475
     1: core::panicking::panic_fmt
               at /rustc/2d8a3b9181f41d3af9b9f016c5d73b2553e344bf/library/core/src/panicking.rs:85
     2: core::panicking::panic
               at /rustc/2d8a3b9181f41d3af9b9f016c5d73b2553e344bf/library/core/src/panicking.rs:50
     3: core::option::Option<T>::unwrap
     4: build_script_build::build_c_code
     5: build_script_build::ring_build_rs_main
     6: build_script_build::main
     7: core::ops::function::FnOnce::call_once
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...
error: build failed

I seemed to be able to compile in July.

emmm.. Can anyone help?

[LinusU]

@kolapapa I managed to get around that step with the following patch:

diff --git a/build.rs b/build.rs
index e62feb1a7..d48c9ca33 100644
--- a/build.rs
+++ b/build.rs
@@ -244,6 +244,7 @@ const ASM_TARGETS: &[(&str, Option<&str>, Option<&str>)] = &[
     ("arm", Some("ios"), Some("ios32")),
     ("arm", None, Some("linux32")),
     ("wasm32", None, None),
+    ("mips", None, Some("linux32")),
 ];
 
 const WINDOWS: &str = "windows";

The next issue I'm running into is the following two errors:

error[E0425]: cannot find value `SYS_GETRANDOM` in this scope
   --> src/rand.rs:220:40
    |
220 |         let r = unsafe { libc::syscall(SYS_GETRANDOM, dest.as_mut_ptr(), chunk_len, 0) };
    |                                        ^^^^^^^^^^^^^ not found in this scope

error: unused import: `libc::c_long`
   --> src/rand.rs:203:13
    |
203 |         use libc::c_long;
    |             ^^^^^^^^^^^^
    |

(I also get a ton of warnings)

edit: well, that was easily fixed:

diff --git a/src/rand.rs b/src/rand.rs
index 6957952db..12a37fea8 100644
--- a/src/rand.rs
+++ b/src/rand.rs
@@ -216,6 +216,9 @@ mod sysrand_chunk {
         #[cfg(target_arch = "x86_64")]
         const SYS_GETRANDOM: c_long = 318;
 
+        #[cfg(target_arch = "mips")]
+        const SYS_GETRANDOM: c_long = 4353;
+
         let chunk_len: c::size_t = dest.len();
         let r = unsafe { libc::syscall(SYS_GETRANDOM, dest.as_mut_ptr(), chunk_len, 0) };
         if r < 0 {

Now on to cargo test 🚀

update 2: As far as I can tell, I'm now stuck at missing some assembly. Specifically it seems to me like its:

• crypto/fipsmodule/ec/asm/ecp_nistz256-mips.pl
• crypto/fipsmodule/bn/asm/mips-mont.pl
• crypto/chacha/asm/chacha-mips.pl

last edit for today: This is the diff that got me to the point where I could see the missing assembly

diff --git a/build.rs b/build.rs
index e62feb1a7..6fccb50d3 100644
--- a/build.rs
+++ b/build.rs
@@ -51,6 +51,7 @@ const X86: &str = "x86";
 const X86_64: &str = "x86_64";
 const AARCH64: &str = "aarch64";
 const ARM: &str = "arm";
+const MIPS: &str = "mips";
 
 #[rustfmt::skip]
 const RING_SRCS: &[(&[&str], &str)] = &[
@@ -61,12 +62,12 @@ const RING_SRCS: &[(&[&str], &str)] = &[
     (&[], "crypto/mem.c"),
     (&[], "crypto/poly1305/poly1305.c"),
 
-    (&[AARCH64, ARM, X86_64, X86], "crypto/crypto.c"),
-    (&[AARCH64, ARM, X86_64, X86], "crypto/curve25519/curve25519.c"),
-    (&[AARCH64, ARM, X86_64, X86], "crypto/fipsmodule/ec/ecp_nistz.c"),
-    (&[AARCH64, ARM, X86_64, X86], "crypto/fipsmodule/ec/ecp_nistz256.c"),
-    (&[AARCH64, ARM, X86_64, X86], "crypto/fipsmodule/ec/gfp_p256.c"),
-    (&[AARCH64, ARM, X86_64, X86], "crypto/fipsmodule/ec/gfp_p384.c"),
+    (&[AARCH64, ARM, MIPS, X86_64, X86], "crypto/crypto.c"),
+    (&[AARCH64, ARM, MIPS, X86_64, X86], "crypto/curve25519/curve25519.c"),
+    (&[AARCH64, ARM, MIPS, X86_64, X86], "crypto/fipsmodule/ec/ecp_nistz.c"),
+    (&[AARCH64, ARM, MIPS, X86_64, X86], "crypto/fipsmodule/ec/ecp_nistz256.c"),
+    (&[AARCH64, ARM, MIPS, X86_64, X86], "crypto/fipsmodule/ec/gfp_p256.c"),
+    (&[AARCH64, ARM, MIPS, X86_64, X86], "crypto/fipsmodule/ec/gfp_p384.c"),
 
     (&[X86_64, X86], "crypto/cpu-intel.c"),

[briansmith]

https://github.com/openssl/openssl/pull/17258 fixes a bug in the 32-bit MIPS assembly code in OpenSSL.

[decaz]

@briansmith I would use ring on a MediaTek MT7621A 32-bit MIPS1004Kc Little Endian (mipsel) and "Just get it working" would be enough for my use-case.

Are there any updates on support of this?

[decaz]

I've cloned this repo and tried to build the following commits for the mipsel.

Latest commit (32b2c6c39ef459aad47f476fe9139b8d57532ab1): success with warnings

~/ring # cargo build --release
   Compiling libc v0.2.121   
   Compiling ring v0.17.0-not-released-yet (/opt/root/ring)
warning: field is never read: `mask`                                                                                  
   --> src/cpu/arm.rs:199:5
    |     
199 |     mask: u32,                                                                                                                                                                                                                         
    |     ^^^^^^^^^
    |                                                                                                                 
    = note: `#[warn(dead_code)]` on by default                                                                        
                                                           
warning: associated function is never used: `available`
   --> src/cpu/arm.rs:204:12
    |
204 |     pub fn available(&self, _: super::Features) -> bool {
    |            ^^^^^^^^^

warning: constant is never used: `ARMCAP_STATIC`
   --> src/cpu/arm.rs:185:9
    |
185 |           const ARMCAP_STATIC: u32 = 0;
    |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
228 | / features! {
229 | |     // Keep in sync with `ARMV7_NEON`.
230 | |     NEON {
231 | |         mask: 1 << 0,
...   |
251 | |     },
252 | | }
    | |_- in this macro invocation
    |
    = note: this warning originates in the macro `features` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: `ring` (lib) generated 3 warnings
    Finished release [optimized] target(s) in 5m 15s

0.17.0-alpha.11 (08fcf4a5b9bfa7e06863e586cef8e4f137604439): success

~/ring # cargo build --release                                                                                     
    Updating crates.io index                                                                                          
   Compiling cc v1.0.73                                                                                               
   Compiling libc v0.2.121
   Compiling once_cell v1.10.0                                                                                        
   Compiling untrusted v0.9.0                                                                                         
   Compiling ring v0.17.0-not-released-yet (/opt/root/ring)
    Finished release [optimized] target(s) in 10m 09s

0.16.20 (9cc0d45f4d8521f467bb3a621e74b1535e118188): error

~/ring # cargo build --release
    Updating crates.io index
   Compiling untrusted v0.7.1
   Compiling ring v0.16.20 (/opt/root/ring)
error: failed to run custom build command for `ring v0.16.20 (/opt/root/ring)`

Caused by:
  process didn't exit successfully: `/opt/root/ring/target/release/build/ring-9d1e356c7c1dfcbb/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', build.rs:358:10
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[decaz]

@briansmith do you have a plan to release a new version? (with current warnings being fixed I hope)

[lancethepants]

ring is a dependency of boringtun, so would love to compile this for more arches.