Skip to content
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

Build Envoy with aws_lc on Power (ppc64le) #38403

Merged
merged 7 commits into from
Feb 21, 2025

Conversation

Jenkins-J
Copy link
Contributor

Commit Message: Build Envoy with aws_lc instead of boringssl when building for the ppc64le architecture.
Additional Description: Envoy uses boringssl as the default ssl implementation. As boringssl does not support the ppc64le architecture, a different ssl implementation is necessary to build Envoy for ppc64le.
Risk Level: High
Testing:
Docs Changes:
Release Notes:
Platform Specific Features: Boringssl no longer supports the ppc64le architecture. Here, aws_lc is used as a "drop-in" replacement for boringssl when building Envoy for ppc64le. Aws_lc is conditionally built only when Envoy is built for ppc64le with FIPS support.
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

@repokitteh-read-only repokitteh-read-only bot added the deps Approval required for changes to Envoy's external dependencies label Feb 11, 2025
Copy link

CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to (bazel/.*repos.*\.bzl)|(bazel/dependency_imports\.bzl)|(api/bazel/.*\.bzl)|(.*/requirements\.txt)|(.*\.patch).
envoyproxy/dependency-shepherds assignee is @moderation

🐱

Caused by: #38403 was opened by Jenkins-J.

see: more, trace.

@mattklein123
Copy link
Member

This seems OK to me but will defer to @ggreenway

@phlax
Copy link
Member

phlax commented Feb 12, 2025

needs main merge

Copy link
Contributor

@ggreenway ggreenway left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to document somewhere that any builds using aws-lc or on PPC are not covered by the envoy security policy, and that PPC is currently best-effort and not maintained by the Envoy maintainers.

Both of those caveats are necessary because we don't have any CI coverage for this build variant. If that changes at some point in the future that can be re-evaluated.

@@ -116,9 +116,15 @@ absl::Status SPIFFEValidator::addClientValidationContext(SSL_CTX* ctx, bool) {
X509_NAME* name = X509_get_subject_name(ca.get());

// Check for duplicates.
#ifdef OPENSSL_IS_AWSLC
if (sk_X509_NAME_find_awslc(list.get(), nullptr, name)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain why this, and only this, function needs a _awslc suffix? Is there a defined policy in aws-lc for when a different function name is used?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking through this a little more, I think it would be easier to read and reason about if you made a header for api compatibility that you include in needed files, and the entire content is inside #ifdef OPENSSL_IS_AWSLC, and you either #define sk_X509_NAME_find sk_X509_NAME_find_awslc, or define a function named sk_X509_NAME_find in the Envoy namespace so that it's a closer match than the global namespace version, which does the needed API translation. I'd prefer that to sprinkling preprocessor directives around the code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain why this, and only this, function needs a _awslc suffix? Is there a defined policy in aws-lc for when a different function name is used?

Yes, the function sk_X509_NAME_find_awslc is consistent with the boringssl implementation while the sk_X509_NAME_find function in aws-lc has a different number of parameters in order to be openssl compatible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking through this a little more, I think it would be easier to read and reason about if you made a header for api compatibility that you include in needed files, and the entire content is inside #ifdef OPENSSL_IS_AWSLC, and you either #define sk_X509_NAME_find sk_X509_NAME_find_awslc, or define a function named sk_X509_NAME_find in the Envoy namespace so that it's a closer match than the global namespace version, which does the needed API translation. I'd prefer that to sprinkling preprocessor directives around the code.

I'll make that fix.

@Jenkins-J
Copy link
Contributor Author

@ggreenway I've made the change to move the preprocessor conditions to a header file. Let me know if there is a better location for the header file or a better place to include it in the build process.

Copy link
Contributor

@ggreenway ggreenway left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine from the point-of-view of the TLS code; this is pretty unobtrusive.

I need someone else to review the bazel changes. Either @phlax or @keith probably.

Is it intended that use of aws-lc will always be FIPS compliant?

Please document somewhere that any builds using aws-lc or on PPC are not covered by the envoy security policy, and that PPC is currently best-effort and not maintained by the Envoy maintainers.

If in the future the boringssl and aws-lc APIs diverge, Envoy will follow boringssl, even if it breaks aws-lc.

Copy link
Member

@keith keith left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

on the bazel side i think this looks good! but i would love it if there were links to upstream patches for all the new patches here so we can work to eliminate them. they all seem super reasonable so hopefully they can land upstream

config_setting(
name = "platform_cpu_ppc64le",
- constraint_values = ["@platforms//cpu:ppc"],
+ constraint_values = ["@platforms//cpu:ppc64le"],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there an upstream patch for this? seems like a good change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no upstream patch for this change yet.

"aarch64-pc-windows-msvc": "rust_windows_aarch64",
"aarch64-unknown-linux-gnu": "rust_linux_aarch64",
"s390x-unknown-linux-gnu": "rust_linux_s390x",
+ "powerpc64le-unknown-linux-gnu": "rust_linux_powerpc64le",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there an upstream patch for all this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have submitted a PR for this one: bazelbuild/rules_rust#3259

struct(
name = "remotejdk21_linux_ppc64le",
- target_compatible_with = ["@platforms//os:linux", "@platforms//cpu:ppc"],
+ target_compatible_with = ["@platforms//os:linux", "@platforms//cpu:ppc64le"],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

upstream patch?

Copy link
Contributor Author

@Jenkins-J Jenkins-J Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no upstream patch for this change yet.
I have submitted a PR for this change: bazelbuild/rules_java#274

@@ -64,6 +72,7 @@ index 32b26cbdc..e28b8e387 100644
+ actual = select({
+ ":linux-aarch_64": "@com_google_protobuf_protoc_linux_aarch_64//:protoc",
+ ":linux-x86_64": "@com_google_protobuf_protoc_linux_x86_64//:protoc",
+ ":linux-ppcle_64": "@com_google_protobuf_protoc_linux_ppcle_64//:protoc",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

upstream patch?

Copy link
Contributor Author

@Jenkins-J Jenkins-J Feb 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is one patch file that existed before my changes (I just added the linux-ppcle_64 case). I have not created an upstream patch for this one either.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is our patch to try and prevent building of protoc

@phlax
Copy link
Member

phlax commented Feb 18, 2025

needs main merge and DCO fix

@keith will land when you are happy

/wait

Build Envoy with aws_lc instead of boringssl when building for the
ppc64le architecture.

Signed-off-by: James Jenkins <James.Jenkins@ibm.com>
Signed-off-by: James Jenkins <James.Jenkins@ibm.com>
Remove conditional compilation gaurds for aws-lc,
adding the new header file to do the proper
translation.

Signed-off-by: James Jenkins <James.Jenkins@ibm.com>
Signed-off-by: James Jenkins <James.Jenkins@ibm.com>
Signed-off-by: James Jenkins <James.Jenkins@ibm.com>
Signed-off-by: James Jenkins <James.Jenkins@ibm.com>
@Jenkins-J
Copy link
Contributor Author

needs main merge and DCO fix

@keith will land when you are happy

/wait

Rebased changes on the main branch and signed all commits.

keith
keith previously approved these changes Feb 18, 2025
@phlax
Copy link
Member

phlax commented Feb 19, 2025

@Jenkins-J the format and deps fails are real

@Jenkins-J
Copy link
Contributor Author

@Jenkins-J the format and deps fails are real

Thank you, I will start fixing those now.

@phlax
Copy link
Member

phlax commented Feb 19, 2025

/retest flakey tsan/quic

@Jenkins-J Jenkins-J force-pushed the aws-lc-fips-1.33.0-pr branch from bd7025b to 0ecbfb9 Compare February 19, 2025 19:09
@Jenkins-J
Copy link
Contributor Author

@phlax There remains a "spelling" error in the aws_lc_compat.h file because the check identifies "ppc64le" as a spelling error. Is the preferred way to resolve this by adding "ppc64le" to the dictionary file or should I just remove the term from the comment?

@ggreenway
Copy link
Contributor

Put backticks around it and the word won't be spell checked. Or possibly double backticks.

Signed-off-by: James Jenkins <James.Jenkins@ibm.com>
@Jenkins-J Jenkins-J force-pushed the aws-lc-fips-1.33.0-pr branch from 0ecbfb9 to 25d2f46 Compare February 20, 2025 14:44
@ggreenway
Copy link
Contributor

Please do not force-push/rebase. It makes PRs difficult to review.

* Once your PR is under review, *please do not rebase it*. If you rebase, you will need to force push to

@Jenkins-J
Copy link
Contributor Author

@ggreenway I'm so sorry, I did not see that before.

@Jenkins-J
Copy link
Contributor Author

I have made all of the formatting and dependency corrections. There is one failing check but it appears to be unrelated to the changes in this PR. Do those checks need to be run again?

@phlax
Copy link
Member

phlax commented Feb 21, 2025

yep - looks unrelated - you can

/retest

... yourself if you need to (but please check it looks unrelated first)

@phlax
Copy link
Member

phlax commented Feb 21, 2025

argh - didnt work

/retest

Copy link
Member

@phlax phlax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thanks @Jenkins-J

@repokitteh-read-only repokitteh-read-only bot removed the deps Approval required for changes to Envoy's external dependencies label Feb 21, 2025
@phlax phlax dismissed ggreenway’s stale review February 21, 2025 16:35

feedback addressed

@phlax phlax enabled auto-merge (squash) February 21, 2025 16:35
@phlax phlax merged commit 60aed1c into envoyproxy:main Feb 21, 2025
26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants