Spike: Research supporting GRPC on s390x architecture
Overview
Based on the initial research spike findings, we need to determine how we can compile the grpc
gem on the s390x
architecture.
Technical problem
constant_time_select_8
third_party/boringssl-with-bazel/src/crypto/asn1/../internal.h: At top level:
third_party/boringssl-with-bazel/src/crypto/asn1/../internal.h:420:44: error:
unknown type name 'crypto_word_t'
static inline int constant_time_select_int(crypto_word_t mask, int a, int b) {
^~~~~~~~~~~~~
In file included from
third_party/boringssl-with-bazel/src/include/openssl/asn1.h:61,
from
third_party/boringssl-with-bazel/src/crypto/asn1/a_bool.c:57:
third_party/boringssl-with-bazel/src/include/openssl/base.h:122:2: error: #error
"Unknown target CPU"
#error "Unknown target CPU"
^~~~~
make: *** [Makefile:2935:
What makes this failure unique is how it manifests.
- The
gitaly
gem depends on thegrpc
gem - The
grpc
gem has to build from source ons390x
- The
grpc
upstream uses a library which is a Google fork fromOpenSSL
The verifications from the various upstreams:
-
BoringSSL
is in thegrpc
gem dependencies. - The
BoringSSL
repository does not have includes to matchs390x
This is a show stopper, because we need grpc
to work so we can make various API
calls throughout the product.
Current options
The following options have been documented in the initial research spike. If something better appears during this research, we should add it to the list for consideration.
- Working with the upstream
grpc
project to bring support back for using vanilla OpenSSL - Working with the upstream
BoringSSL
project to adds390x
support
Notable item - because the issues here are all around OpenSSL, we should carefully consider the implications for FIPS compliance and how this would relate to the work in #6316 (closed).
Expected outcomes
- Determine the best course of action to compile the
grpc
gem - Open issues to deliver the tasks identified by this spike