Add support for mips #562
Comments
|
It is failing here Looks like because misp is not expected / supported. |
|
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. |
|
I'm a complete newbie in rust so sorry if I'm wrong. sam@sam:~/omega/openssl$ find . -name "mips" And update build.rs as it is done for ARM? This is what I tried here but got this --- stderr |
|
Any update on this? |
|
from So you have to choose one of the MIPS64 flavours. BTW, you defined as |
|
If I understand the last post correctly we can have full support on mips32 except for poly1305 which BoringSSL only supports on mips64? |
|
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. |
|
In terms of the Rust |
|
mips-unknown-linux-musl |
|
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 Once that's done we can come up with an implementation strategy. |
|
We'll get to work on a pull request then. |
|
@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.
I'll keep you updated once a PR is ready for first review iteration. Thanks! |
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.
Please submit a WIP PR that shows what you had to change.
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.
The
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.
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.
I suggest:
|
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. |
|
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 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. |
|
Hey @briansmith. Gently ping. I’ll appreciate your feedback on #684. It will unblock me to send more PRs for MIPS support. |
|
Cant wait to have MIPS support for my DVR box! |
|
This feature is needed by me. |
|
I would very much like this too! It's the only blocker for using Rust in a webserver for MIPS currently. |
|
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: rwf2/Rocket#816 |
|
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 From me end, I did recently start to eliminate endian-sensitive logic in ring. Check out commit ea9e9f1 especially, and also 6bc74d9, 1bba0f0, and 98d680b. The idea here is that every value that isn't endian-neutral must be wrapped in a type that implements #[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 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. |
|
More issues:
|
|
openssl/openssl#17258 fixes a bug in the 32-bit MIPS assembly code in OpenSSL. |
|
@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? |
|
I've cloned this repo and tried to build the following commits for the mipsel. Latest commit (32b2c6c): success with warnings 0.17.0-alpha.11 (08fcf4a): success 0.16.20 (9cc0d45): error |
|
@briansmith do you have a plan to release a new version? (with current warnings being fixed I hope) |
|
ring is a dependency of boringtun, so would love to compile this for more arches. |
|
As |
Not all target architectures are supported by the "ring" dependency: - mips: briansmith/ring#562 - PowerPC: briansmith/ring#389 - Sparc: briansmith/ring#1512 - s390x: briansmith/ring@4d2e1a8 Signed-off-by: Danilo Bargen <[email protected]> Signed-off-by: Yann E. MORIN <[email protected]>
Not all target architectures are supported by the "ring" dependency: - mips: briansmith/ring#562 - PowerPC: briansmith/ring#389 - Sparc: briansmith/ring#1512 - s390x: briansmith/ring@4d2e1a8 Signed-off-by: Danilo Bargen <[email protected]> Signed-off-by: Yann E. MORIN <[email protected]> (cherry picked from commit 22bdfbd) Signed-off-by: Peter Korsgaard <[email protected]>
|
Need the MIPS support as well |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
Some progress was made on this in the main branch. We even had CI running tests on MIPS targets. However, in PR #1637 I had to remove the MIPS target from testing because of the following error in CI: I remember reading recently that some MIPS targets have been downgraded in "tier" level from the rust-lang project. Is that what affected us here? I am not sure what's going on in the world of Rust on MIPS. |
|
Yes, the targets got downgraded to tier 3 because they are buggy, which means that |
Thanks! I appreciate that context. I have to say that that is not very encouraging, since all the interesting MIPS targets I know of (especially OpenWrt) are |
|
I believe you can run a musl binary on a gnu target, it's statically linked. If the compatibility manages to bubble through dependencies into rustls in some reasonable time, it'd be a gamechanger for many projects. (I didn't really follow the development there, but they forked webpki to fix some bugs, so this is uncertain) |
|
"uClibc, which was what OpenWRT used as their libc, shared quite a lot of code with glibc. They don't use it anymore because the project is dead though (no releases since 2012, no commits since mid-2015) so they switched to musl, which is looking really nice." I also see that Rust has |
Yes you can :) I'm using this for my project, all the software components that I provide to users are statically linked binaries using musl to make it possible to use the same binary on a wide range of systems and not having to deal with LIBC dependency issues. These binaries work fine on Debian / Ubuntu, RedHat, OpenWrt (MIPS, ARMv5, ARMv7), ... OpenWrt is indeed using musl (now). |
|
To restore the MIPS support, we need to:
The PR that removed the MIPS CI was PR #1637. This is what goes in |
|
Actually the MIPS stuff is in target.h already and I think this is all done. |
|
I have created a new issue (#1866) as it seems that |
and others
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.
The text was updated successfully, but these errors were encountered: