-
Notifications
You must be signed in to change notification settings - Fork 717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"cargo build" failed on s390x platform #986
Comments
Ring currently doesn't support s390x. I can't say if it will in the future as that's a decision for @briansmith to make. But you can look at the issue about other platforms like #562 and #389 for information on what would take to add support for new hardware. |
@pietro Thanks. I will have a try. |
@pietro: One common issue @briansmith frequently mentions in the other issue trackers is (Travis) CI support for the particular architecture(s). Fortunately Travis CI introduced support for s390x and ppc64le architectures about 6 months ago (in November, 2019). Details are available here: |
Issue #104 is fixed, so AES-GCM should be working on all platforms where we do not have assembly language AES-GCM in ring. it should work for little-endian s390x. With small changes, which I encourage somebody to do in a PR, it should also work for big-endian s390x. 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 s390x. |
The s390x architecture is always big endian, so that's simple. While Power processors are bi-endian (can operate in either big endian or little endian, and really do in practice), ppc64le (little endian) is that architecture's most popular mode for Linux nowadays and what Travis CI supports at the moment. Yes, these architectures have lots of hardware assists, although software fallback will still be important. For example, on s390x every main processor core has "CPACF" assists, and "Feature Code 3863" enables the full set of CPACF functions including AES128- and AES256-GCM (z14/LinuxONE II generation processors and higher -- and I think the Hitachi AP10000 has this, too). There's no extra charge for FC 3863 (so it's particularly popular), but unfortunately there are a couple countries that evidently block its importation. :-( So, software fallback it is. There are also quite popular Hardware Security Modules (HSMs) on that architecture ("Crypto Expess"), impressively FIPS 140-2 Level 4 certified, but with the same import restrictions. Anyway, software fallback will be important, so that's the minimum viable starting point. Anything else you see outstanding for software fallback besides #104 big endian (which also affects MIPS and perhaps others)? And am I understanding correctly that #996 is OK now for s390x and ppc64le as far as you can tell? Thanks. |
ECC and ChaCha20-Poly1305 will be the next things. |
Would it be possible to at least give a better error message? |
The simplest way to improve the error message would be to change the
|
I am having the same issue :( |
If you can, please give #1037 a try and see if that fixes your problems. |
It's not supported by sccache at the moment, and thus supporting building it on travis is a bit of a PITA. The problem is with sccache's ring dep. Issue: briansmith/ring#986
It's not supported by sccache at the moment, and thus supporting building it on travis is a bit of a PITA. The problem is with sccache's ring dep. Issue: briansmith/ring#986
RE that workaround, see PR #1174. |
Fixed in 0.17.0. |
Hi, I tried to build ring on s390x platform but got error:
From build.xs, line 364:
I searched ASM_TARGETS from build.xs:
It seems the error is due to no s390x support?
My question are:
Thanks
The trace of "cargo build" is as below (RUST_BACKTRACE=1):
The text was updated successfully, but these errors were encountered: