-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Added CryptoMB private key provider. #17124
Conversation
Intel's IPP (Integrated Performance Primitives) crypto library has support for multi-buffer crypto operations. Briefly, multi-buffer cryptography is implemented with AVX-512 instructions using a SIMD (single instruction, multiple data) mechanism. Up to eight RSA or ECDSA operations are gathered together into a buffer and processed at the same time, providing potentially improved performance. The AVX-512 instructions are available on recently launched 3rd generation Xeon Scalable server processors (Ice Lake server) processors. This commit adds a private key provider to accelerate RSA and ECDSA crypto operations on recent Intel Xeon processors. Every worker thread has a queue of up-to-eight crypto operations. When the queue is full or when the timer is triggered, the queue is processed and all the pending handshakes are notified. The potential performance benefit depends on many factors: the size of the cpuset Envoy is running on, incoming traffic pattern, encryption type (RSA or ECDSA), and key size. In my own testing I saw the biggest performance increase when long RSA keys were used on an Envoy running in a fairly limited environment serving lots of new incoming TLS requests. One new dependency is introduced: Intel’s ipp-crypto library. The library has to be patched at the moment in order to make it compile against BoringSSL and Bazel build system. The ipp-crypto team has indicated that they will accept the patches and release them in future ipp-crypto versions. Basic end-to-end tests are provided, and a fake library interface is included for testing on systems without the required AVX512 instruction set. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
bazel/repository_locations.bzl
Outdated
project_url = "https://github.com/intel/ipp-crypto", | ||
version = "2021.2", | ||
sha256 = "d358e2665d100935f036d84eba70724a12b9e3e5b597ba850d79064a42e6ed5d", | ||
strip_prefix = "ipp-crypto-ippcp_2021.2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove hardcoded version strip_prefix = "ipp-crypto-ippcp_{version}",
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
bazel/repository_locations.bzl
Outdated
version = "2021.2", | ||
sha256 = "d358e2665d100935f036d84eba70724a12b9e3e5b597ba850d79064a42e6ed5d", | ||
strip_prefix = "ipp-crypto-ippcp_2021.2", | ||
urls = ["https://github.com/intel/ipp-crypto/archive/ippcp_2021.2.tar.gz"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove hardcoded version urls = ["https://github.com/intel/ipp-crypto/archive/ippcp_{version}.tar.gz"],
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
Results from OSSF Scorecard. Scores need improving based on https://github.com/envoyproxy/envoy/blob/main/DEPENDENCY_POLICY.md#new-external-dependencies
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
api review
oneof key_type { | ||
string private_key_file = 1; | ||
|
||
string inline_private_key = 2; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use DataSource.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
@@ -0,0 +1,74 @@ | |||
From 0ec11191170a5298d2b4452a7b313195ca46b71d Mon Sep 17 00:00:00 2001 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any chance these patches can be in ipp-crypto repo directly instead of series of patch ended up here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm quite uncomfortable adding these patches. We are really trying to push back against this, since it makes it very hard to bump in response to CVEs, in particular in security sensitive libraries like this. See further rationale in https://docs.google.com/presentation/d/14uotwhgyo5pb0AXJN_D3a69vchRtAjFRG01jHmdZ-G4/edit#slide=id.ga0aa5b53ee_0_1754.
Can we merge these patches upstream first?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I got commitment from the ipp-crypto team that the patches will be part of their next release. I'll ask if the patches could be made part of their development branch already, so that this PR could depend on that before the release is out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer to not merge this PR until these patches are committed to the upstream dependency, even if that means using a non-release-branch as the dependency temporarily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, ipp-crypto added the required changes to the development branch, and their plan is to include the patches in 2021.4 release of ipp-crypto. I made the PR point to the development branch and removed the custom patch files.
I did some work to improve the testing coverage, but it may be that the 96% line coverage target is difficult to reach, because tests use a custom software-only implementation of the relevant AVX-512 accelerated functions. See https://storage.googleapis.com/envoy-pr/13aeb26/coverage/source/extensions/private_key_providers/cryptomb/index.html for current coverage situation.
// is not filled before the delay has expired, the requests already in the | ||
// queue are processed, even if the queue is not full. In effect, this value | ||
// controls the balance between latency and throughput. | ||
uint32 poll_delay = 3; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
google.protobuf.Duration
? If for some reason this doesn't work here, please name the field poll_delay_us
or poll_delay_micros
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
IPP-crypto supports Windows, could later why it doesn't compile. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
The idea is that if the poll delay is 0, might as well process the request synchronously. This would not be used in the real world probably, but for testing synchronous processing makes things a lot easier. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Do we have an assigned sponsor for this extension? As per the extension policy these kind of extensions will need someone shepherding this (especially due to the complexity of this PR) PR cc @ggreenway @lizan @htuch since ya'll have been somewhat involved in reviewing this already Since there seems to be some identified delays here around making sure the necessary patches are upstreamed it might be that the contrib/ extension system will have landed by then, at which point we can be a bit more lax about sponsorship requirements |
I don't have the cycles right now to be able to sponsor this (but super cool extension). @ipuustin what is your thought on a |
I think this is a good candidate for |
@ipuustin should we go with contrib/ and close this PR? |
@htuch Sorry for the delay answering this (I was travelling and am still out of office :-). I now read through the contrib proposal and I think it sounds a good match for CryptoMB private key provider. The extension is clearly relevant only to people who have access to supported hardware. I think that people with that hardware and who are also processing large amounts of TLS requests can find the extension in contrib and take it into use. Do you know what's the timeline for contrib infrastructure work? And will it be possible to enable particular contrib extensions in Envoy builds just from bazel command line, or will it require file changes? @ggreenway Thanks for considering to sponsor this extension in the future! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm api
@mattklein123 is working on |
Waiting for /wait |
Let's continue in contrib: #17826 |
Commit Message:
Intel's IPP (Integrated Performance Primitives) crypto library has support for multi-buffer crypto operations (see https://github.com/intel/ipp-crypto/tree/develop/sources/ippcp/crypto_mb). Briefly, multi-buffer
cryptography is implemented with AVX-512 IFMA instructions using a SIMD (single instruction, multiple data) mechanism. Up to eight RSA or ECDSA operations are gathered together into a buffer and processed at the same time, providing potentially improved performance. The AVX-512 instructions are available on recently launched 3rd generation Xeon Scalable server processors (Ice Lake server) processors.
This commit adds a private key provider to accelerate RSA and ECDSA crypto operations on recent Intel Xeon processors. Every worker thread has a queue of up-to-eight crypto operations. When the queue is full or when the timer is triggered, the queue is processed and all the pending handshakes are notified.
The potential performance benefit depends on many factors: the size of the cpuset Envoy is running on, incoming traffic pattern, encryption type (RSA or ECDSA), and key size. In my own testing I saw the biggest performance increase when long RSA keys were used on an Envoy running in a fairly limited environment serving lots of new incoming TLS requests.
Additional Description:
One new dependency is introduced: Intel’s ipp-crypto library. The library has to be patched at the moment in order to make it compile against BoringSSL and Bazel build system. The ipp-crypto team has indicated that they will accept the patches and release them in future ipp-crypto versions.
Basic end-to-end tests are provided, and a fake library interface is included for testing on systems without the required AVX-512 instruction set.
Risk Level: Medium (TLS security feature, not enabled by default)
Testing: unit tests, integration tests
Docs Changes: API interface is documented
Release Notes: N/A
Platform Specific Features: Requires Intel 3rd generation Xeon Scalable server processor for the AVX-512 IFMA instruction set.
Fixes: #15871